When managing mission-critical databases at scale on AWS, security compliance often necessitates moving Amazon Aurora instances from public to private subnets. As organizations strive to enhance the security posture of their mission-critical databases and accounts, the need to isolate these resources in private subnets often arises.
In today’s internet-based applications, minimizing downtime during migration activities is of paramount importance, as companies demand minimal disruptions to their services. In this post, we demonstrate how you can migrate your instances within an Aurora cluster from a public subnet to a private subnet while keeping downtime to an absolute minimum.
Solution overview
Currently, Aurora does not provide a direct option to change the subnet group of your database (DB) instances within the same virtual private cloud (VPC). However, you can achieve a similar outcome by using a workaround that allows you to migrate your DB instance within an Aurora cluster from a public subnet to a private subnet. This approach avoids the need to create an Aurora clone or use the snapshot restore process. It minimizes downtime and preserves your endpoint configuration, so only failover events cause noticeable downtime. Note that this approach requires deleting and recreating readers as part of the process. Also, if you need to alter the Availability Zones (AZs), you must provision an entirely new Aurora cluster.
In our use case, we have the VPC test- project-vpc with three public subnets in us-east-1a, us-east-1b, and us-east-1c Availability Zones with a route to the internet (using an Internet Gateway) via the route table test-project-rtb-public, as shown in the previous figure.
As shown in the preceding figure, we have an Amazon Aurora MySQL-Compatible Edition DB cluster with a writer and a reader instance in us-east-1a and us-east-1b Availability Zones, respectively, using the public subnets from test- project-vpc. Our aim is to move these two instances to a private subnet and remove all the public subnets.
Prerequisites
You should have the following prerequisites:
An Amazon Aurora PostgreSQL-Compatible Edition or Amazon Aurora MySQL-Compatible Edition cluster associated with public subnets in a VPC.
Permissions to modify subnet groups in your VPC.
Because this solution requires deleting and recreating reader instances, make sure your writer instance can handle the workload or schedule a maintenance window to safely carry out this activity.
To implement this solution, it is necessary to delete the public subnets associated with your current writer and reader instances from your Amazon Relational Database Service (Amazon RDS) subnet group. Therefore, ensure that these public subnets are not attached to any other AWS resources before proceeding with their deletion.
Create a private subnet
We use Amazon Virtual Private Cloud (Amazon VPC) to create a private subnet in the same VPC and Availability Zones as the public subnet of your Aurora cluster. Complete the following steps:
On the Amazon VPC console, choose Subnets in the navigation pane.
Choose Create subnet.
For VPC ID, choose the VPC attached to your current Aurora instances (for this post, test- project-vpc).
For Availability Zone, choose the same Availability Zone as your current reader instance (for this post, us-east-1b). You can locate this on the Amazon RDS console.
Enter your desired private IPv4 subnet CIDR block.
The preceding screenshot shows the updated VPC with one new private subnet in us-east-1b.
Add the private subnet to the RDS subnet group
Complete the following steps to add the new private subnet you created to the subnet group of the cluster:
On the Amazon RDS console, navigate to your Aurora instance.
On the Connectivity & security tab, under Networking, locate your subnet group.
Copy the subnet group name and find it in the Subnet groups tab in your RDS console.
Edit and attach the newly created private subnet. If your subnet is created in different Availability Zones, make sure to add those Availability Zones as well.
Delete the reader instances
Complete the following steps to delete all the reader instances in the cluster:
On the Amazon RDS console, note the Availability Zone in which the current reader is present (for this post, us-east-1b).
On the Amazon RDS console, navigate to your reader instance.
Choose Edit, then choose Delete.
Repeat this for all readers.
Delete the public subnets from your RDS subnet group
Complete the following steps to delete the public subnets associated with the previously deleted reader instance, or any other unused public subnets in the subnet group.
On the Amazon RDS console, navigate to the RDS subnet group attached to your current Aurora instances.
Choose Edit and under Subnets, identify the public subnet in the same Availability Zone where the previous reader instance was located.
Remove the identified public subnet and choose Save.
In our scenario, following the subnet deletions, we now have:
One active public subnet in us-east-1a, where the current writer resides.
A newly added private subnet in us-east-1b.
An additional public subnet in us-east-1c that isn’t used by this Amazon RDS cluster.
Create a reader node
Create a new reader node in the same Availability Zone where the new private subnet was created. When creating the reader instance, specify the Availability Zone in which you created the new private subnet. For this post, we created a new reader called private-db.
Perform a failover
Complete the following steps to failover from the primary writer instance to the reader instance. Note that this will cause a brief downtime.
On the Amazon RDS console, select your writer instance.
On the Actions menu, choose Failover.
Now private-db is the new writer.
Delete the new reader instance
Complete the following steps to delete the new reader instance:
On the Amazon RDS console, select your reader instance.
On the Actions menu, choose Delete.
Create new private subnet in a different Availability Zone to deploy Reader instance
Complete the following steps to create a new private subnet in a different Availability Zone (AZ) to deploy the Reader instance.
See previous steps to create a new private subnet in a different Availability Zone (because Aurora is operated in a multi-AZ configuration). For this post, we created private-subnet-2 in us-east-1c.
Add the new subnet (private-subnet-2) to the subnet group of the RDS instance as demonstrated previously.
Â
Delete the remaining public subnets from the RDS subnet group
Complete the following steps to delete the public subnets:
Complete the steps outlined previously to delete the remaining public subnet associated with your previously deleted reader instance and any other unused public subnets.
Note: Deleting all public subnets from your Amazon RDS subnet group without first adding the new private subnet from the previous step will result in an error. Aurora requires your subnet group to span across at least two Availability Zones.
Â
Create a reader instance
Complete the following steps to add a new reader instance
Create a reader in the same Availability Zone (us-east-1-c) where you created the new private subnet (private-subnet-2).
Now we have the Aurora MySQL instances (writer and reader) moved to the private subnets (private-subnet-1 and private-subnet-2) of the VPC (test-project-vpc).
Cleanup
If you no longer require this setup and want to avoid future charges, you can delete the resources that you created as part of this setup; namely the Aurora MySQL or Aurora PostgreSQL cluster and the associated subnets.
Delete the Aurora DB instances and cluster.
Open the Amazon RDS console.
Navigate to Databases.
Select the Aurora DB cluster and any associated instances.
Choose Actions, and then choose Delete.
Confirm the deletion. Ensure that you also delete any read replicas if they were created.
Remove subnets
Open the Amazon VPC console.
Choose Subnet Groups in the navigation pane.
Select the subnets associated with the Aurora DB cluster.
Choose Actions, and then choose Delete.
Confirm the deletion.
Summary
In this post, we demonstrated how to move your Aurora instances residing in a public subnet to a private subnet with minimal downtime. Although there are other possible solutions involving an Aurora clone, the method discussed in this post removes the necessity to create a new DB instance and change the Amazon RDS endpoint in your applications. Using this method, the only downtime is the failover time.
Try this solution, and share your feedback and questions in the comments section.
About the authors
Sukanth Rajan is a Technical Account Manager in Strategic Accounts at Amazon Web Services. He plays a pivotal role in helping AWS’s largest customers architect, migrate, and optimize their mission-critical workloads on the cloud. He leverages his deep technical expertise, especially in databases, to help customers solve critical issues and build highly reliable, secure, and cost-effective solutions using AWS services. When not at work, Sukanth enjoys staying active by playing soccer and cricket.
Kiran Mulupuru is a Database Specialist Technical Account Manager at Amazon Web Services. She focuses on Amazon RDS and Amazon Aurora databases. She works with enterprise customers, providing technical assistance on database operational performance and sharing database best practices.
Source: Read More
