I have doubt on how RDS behaves regarding removing subnets from subnet groups.
In my subnet group configuration, I realized I have configured an unwanted subnet. It's unwanted because it doesn't (and shouldn't) have the routing as the rest of the subnets that form the subnet group, for a specific RDS instance.
I want to remove this subnet from the subnet group, and can do so directly by going to RDS > Subnet Groups > Edit
My doubt is on failover behavior if the instance is sitting in this unwanted subnet. What does RDS do in this case? I don't have Multi-AZ enabled for this instance. Want to keep downtime to a minimum, or zero of possible.
Appreciate the help.
You can view the AZ in which the instance is running by looking in the Amazon RDS console. The Security and Network section shows the current Availability Zone.
You can edit the Subnet Group to remove AZs. (It even lets you remove the AZ in which the database is currently running, but that won't affect the database.)
If you are uncomfortable with making changes, you can always spin-up a test environment with the same settings and play around with the changes.
Bottom line: You can view which AZ is being used. Feel free to remove the AZ from the Subnet Group.
For anyone else reading this, I'm trying something similar with an aurora PSQL cluster and getting
Some of the subnets to be deleted are currently in use: subnet-xxxx (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 1111111-1111-1111-1111-11111; Proxy: null)
AWS documentation[1] hints this is not possible, because the subnet/az has already been used to store data.
[1] https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-rds-db-instance/
Update: aws support confirmed this and it's also mentioned in [2]. This applies even if there's currently no instance in the subnet I'm trying to remove.
[2] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html#Aurora.Overview.Storage
Related
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 have a t2.micro instance running, that is producing some data that needs to be written to a database. So, I created a RDS database with MySQL on it.
The issue I'm facing is, nonsurprisingly, getting the EC2 instance to communicate with the RDS database in any way/shape/form.
I'm been battling with it all day. I'm left with these bits of confusion:
I figured I've just add the public IP of the EC2 instance to the security group of the RDS. Turns out the RDS doesn't really have a security group, only a VPN. So how do I allow communication from the EC2 instance, then?
Speaking of security groups, do I need to se the EC2 up to require outbound connections?
The RDS has an 'endpoint' and not a public IP as far as I can tell. So I can't add it to any security group at all. Is this correct?
Am I going to have to figure out how to use Elastic Beanstalk or some other way to get these components to play together?
These are all the things I'm trying to troubleshoot but I'm not getting anywhere. There doesn't seem to be any good blogs / etc; mostly what I'm finding is stuff on how to get the RDS to be accessed by your local hardware, not an EC2 instance.
How should I set this up?
There are two ways to allow inbound connection to RDS database: CIDR/IP or EC2 security group.
You can go to VPC, at the left panel there is "Security Groups" (yes, RDS do have security group). Click that, and choose your DB security group (if you already have the RDS instance created) or create a new one.
Under connection type, choose either CIDR/IP or EC2 security group.
If you choose to go with CIDR/IP, you should know what IP address your EC2 instance is and put the address or range in e.g. "10.11.12.0/24".
If you choose to go with EC2 security group, you should know the security group nameof your EC2 instance and select it from the dropdown provided e.g. "my security group".
Please note that the EC2 instance and the RDS instance need to be able to "see" each other i.e. in the same region, VPC, subnets with proper NACL (network access control list) etc.
Speaking of outbound connection and security group, no, security groups only manage inbound connection.
Hope that helps, let me know if I can make my answer clearer.
I am faced with a chicken and egg problem. I currently have a server in EC2 classic, as well as an RDS instance -- in EC2 classic as well. The EC2 instances also interact with Cassandra cluster, which also resides in EC2 classic.
However, I need to move RDS into the VPC. Now, in an ideal world, I'd have all of my stuff in VPC at this point. However, that presents a major migration challenge and I'd like to minimize impact on users and keep steps to minimum -- this is mainly because of the Cassandra cluster.
It turns out that I cannot create security group rules between VPC and Non-VPC security groups.
So, how can I have RDS in VPC that my EC2 instances can access w/o having to open up my RDS to the entire world ?
Any help is greatly appreciated.
UPDATE: So, one idea I had is to assign elastic IPs to my EC2 instances and add IPs explicitly to the security group for RDS within VPC. Would that work ? (trying it now using https://github.com/skymill/aws-ec2-assign-elastic-ip)
Yes, unfortunately that's the only way to do it. You cannot use DNS in security groups, so you're stuck with IP address.
So, I ended up solving it exactly like I described -- assign elastic IPs to my EC2 instances and add IPs explicitly to the security group for RDS within VPC. It ended up working great.
We have couple of RDS that are not added under VPC, so we need to bring them under VPC. Please let me know the steps and downtime expected. Also let me know if there need to be any changes in the webservers, so that everything works fine after RDS is under VPC.
You must have a VPC created before hand that have subnet in atleast two different regions.
After this go and create a "subnet group" for RDS and add two existing subnet in that.
Next take a snapshot of your RDS instance and start a new RDS instance from snapshot in VPC.
That should be it.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.html#USER_VPC.Non-VPC2VPC - official documentation from Amazon.
Depending on your configuration and if the RDS needs to be accessible from the Internet you will have to check the option "Publicly Accessible" in the creation wizard and (in addition to the subnets mentioned in other answers) ensure that the Security has port for the DB properly enabled (and maybe from 0.0.0.0/0).
When a new security group is added, or the existing one is modified, the affects are not visible. For instance, I have a security group called “mdi-sg-redshift” with two rules:
As you can see, these rules allow inbounds from anyone across the globe. When applied to the cluster, they should allow inbounds at those ports. Does NOT work! I have rebooted the cluster to no affect.
Here is the snapshot of my Redshift Cluster:
Here is the snapshot of the port scanner.
The cluster was rebooted several times to no effect.
Also noted that the cluster belongs to the same region as the VPC and the security group. The cluster belongs to the VPC that has the security group applied.
I have seen similar issues on EC2 side, but reboots usually fixed it. Not this time.
Anyone with insights? Thanks!
This sounds mostly a VPC rules issue.
Things I will check:
Do you get the same issue if you create your cluster outside of VPC?
Check Cluster Subnet group. It says default in your screen shot. Which subnet groups is dded to this default subnet group? Make sure your cluster is running in the subnet which is added to default subnet group.
Check VPC security group policy for the Red-shift cluster
Did this set-up ever worked in the past ? OR is it the 1st time you are working on this cluster? If it worked in the past, then what setting with respect to VPC/cluster subnet group/ VPC security groups has changed?
Where are you accessing Redshift from?
If you ar trying to access Redshift from outside VPC then please check the Route Table for an entry of Internet Gateway (to verify if the Redshift cluster is publicly available over internet)
If you are trying to access Redshift from within VPC then there might be some other issue that might be stopping access