When using the command
aws dms create-replication-instance
How can I force/choose the VPC that will contain the instance ?
If you want to create a DMS Replication Instance somewhere other than the default VPC and subnet, you need to first create a replication subnet group. This is created with a name and a list of one or more subnet ids (all in the same VPC).
Reference for the aws-cli call to create-replication-subnet-group: https://docs.aws.amazon.com/cli/latest/reference/dms/create-replication-subnet-group.html
You would then pass that resulting replication subnet group id to create-replication-instance command as the --replication-subnet-group-identifier option.
Reference for the the aws-cli call for create-replication-instance: https://docs.aws.amazon.com/cli/latest/reference/dms/create-replication-instance.html
The DMS Replication Instance would then be created in the VPC determined by the subnet group.
VPC is too broad. You need to specify the subnet in which you want the replication instance to be created. VPC can be derived from the subnet id.
create-replication-instance
--replication-subnet-group-identifier (string)
A subnet group to associate with the replication instance.
Related
I'm trying to use CDK (Typescript) to create an RDS (Postgres) instance within an ISOLATED subnet. As far as I understood, the default VPC created automatically in each of my account regions only has Public Subnets.
If I then want to launch a Fargate instance on top of one of those Public Subnets, do I need to create a VPC Peering between the ISOLATED subnet and the default VPC?
Any idea how to create that using CDK?
"Any idea how to create that using CDK?" -> yes:
Use AWS CDK to provision a new VPC similar to this. As you can see, there are subnets for public, applicational and database layers;
[OPTIONAL] For a better AWS CDK project organization, you can use multiple stacks like network (VPC resources), compute (Fargate resources), and database (RDS). You can pass the vpc on network stack to compute & database stacks;
Be sure that you set vpc on the ECS cluster and at load-balanced level (if applicable) and put RDS database in the isolated/database by using vpcSubnets attribute
To sum up, one VPC. No applicational or database exposed to the public. I have a git repo in case you want to look for sample code/template
VPC peering is when you have two VPC with different CIDR ranges. You have one VPC hence no need to use VPC peering.
aws dms create-replication-instance does not get VPC as an option. When I create a new instance it does not create it in the VPC I intend to create the replication instance in.
How can I achieve that?
You need to create a subnet group first and then use that when you build your instance.
The create-replication-subnet-group derives the VPC ID from the subnets you use for input. The documentation is vague but VpcId is output from the command.
The docs for that command state:
Creates a replication subnet group given a list of the subnet IDs in a VPC.
Then use the replication-subnet-group-identifier as input for the create-replication-instance command.
References
https://docs.aws.amazon.com/cli/latest/reference/dms/
I've created a VPC. By default the VPC created one public and one private subnet. I've created an additional private subnet in a different availability zone.
I then (in the ElasticCache console) created a new subnet group that contains these two private subnets from the VPC. This subnet group is also associated, of course, with the VPC.
Then, on creating an Aurora RDS within this VPC, it asks for a subnet group. There's one there, a 'default' group, but my new subnet group doesn't appear.
How do I create a subnet group that is acceptable when creating a database?
Well.. as it turns out the ElasticCache subnet groups are not visible when creating a database. You have to use the RDS console to create a 'Database Subnet Group'. Once you do that.. you're set.
ElasticCache and RDS are different types of product groups. Their SubnetGroups are different entities and they don't over lap with each other. You would need to create subnet groups in RDS to use it with RDS engines (database engines). They are not tied to any db engine, so you can re-use them within RDS.
One additional thing to note is that some other Database productions like Amazon Neptune and Amazon DocDB are able to access your RDS subnet groups as well. Just an FYI.
I have one Oracle SE instance that is not multi-az and does not have encryption enabled, and I have an Oracle EE instance that is multi-az and has encryption enabled. The former has the option to change the subnet group through the console (modify instance > network and security), whereas the latter does not. Both instances are in a subnet group within the default vpc, and I have a custom vpc within the same account with another subnet group in it.
What conditions determine whether or not it is possible to change the subnet group of an RDS instance? I have not been able to find any documentation on this so far.
It is the Multi AZ Deployment that is the determining factor. To test this, modify your DB instance and turn off the Multi AZ Deployment. Once it is done, go modify it again and you'll notice you now have the option to change the subnet group.
I haven't found any indication as to the reason for this behavior in the AWS documentation.
As #hackakhan mentioned, you need to have Multi AZ Deployment turned off to modify the DB subnet group of an RDS instance. Unfortunately, the RDS instance will only be migrated to one of the subnets from the new DB subnet group if the new DB subnet group resides in a different VPC. You could create a temporary VPC to migrate away the RDS instance only to migrate it back to your existing VPC and the right DB subnet group within that VPC.
The AWS Premium Support Knowledge Center has a detailed explanation of the steps involved: https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-rds-db-instance/
My understanding
RDS instances can't be migrated from one database subnet group to another if:
The destination database subnet group is in the same VPC as the current group
The instance has the multi-availability zone setting enabled
What worked for me
Creating the subnet group within my VPC that would be the eventual home of my RDS instance
Creating a temporary database subnet group in the "DEFAULT" VPC (my RDS instance has previously been a subnet group in a VPC that I had provisioned, not the default one) consisting of the three subnets that belong to the "DEFAULT" VPC—this can be done in the RDS section of the AWS Console, no need to go to the VPC section
Modifying the instance's subnet group to the newly created group (from 2.)
Modifying the instance's subnet group to its eventual home within my original VPC (from 1.)
I'm trying to create my first RDS Instance... I select Create a new VPC and then on the next page it tells me:
"A VPC and DB Subnet Group are required but you do not have any compatible subnet groups for your current selection."
Why is it not recognizing the subnet group that is generated with the new vpc? I'm so confused. How can I launch my database?
From the RDS console, there is an option for "Subnet Groups" on the left. You have to pick a VPC, then an existing subnet(s), before you can deploy RDS into it.