Networking Considerations for RDS Aurora Databases

RDS Aurora Supporting Infrastructure Series

Cloud-native databases require other pieces of infrastructure and policies to make them viable. This article is part of a series on all the surrounding infrastructure and policies necessary to support RDS Aurora databases.

The correct surrounding infrastructure will enable you to better monitor, control, access, and operate your database with minimal disruption. It may also help you save money by avoiding and replacing costly default AWS-provided solutions with similar arrangements, trading off some complexity and convenience for considerable financial savings.

Photo by Brett Sayles.

Part 1: Networking

Networking is especially important for cloud-native databases. It is also an often-overlooked line of defence for your data. Mind the Network early and you will save yourself headaches and costly mandatory maintenance downtime later on.

A (Preferably) Dedicated VPC

Databases hold very valuable information. We should protect this information as effectively as possible. I always recommend deploying databases in a dedicated VPC, which makes it easy to control access for both humans and services. It can also help minimise data-transfer costs.

Newcomers often start building in AWS without paying much attention to Virtual Private Clouds (VPCs) and other network access control structures. This is the mistake everybody makes at least once when starting out with AWS and other public cloud providers. With a bit of luck, somebody else in your organisation has already committed (and corrected) this mistake, so you can harmlessly skip over this section.

Within your dedicated database VPC, you’ll need:

• Private subnets
• Route tables
• Network ACLs (NACLs)
• Security Groups
• A Database Subnet Group

Each of the following sections groups my thoughts and considerations on each structure. I hope these offer you some insights into the reasoning and goals for using them.

Private Subnets

Hypothetically speaking, one could also deploy relational databases in a Public Subnet. Implementing this is unwise and can be highly dangerous for your data and your organisation. Demonstrating the truth of this statement is considered trivial and will be left as an exercise for the reader.

In AWS, subnets are tightly coupled with their corresponding Availability Zone (AZ). According to the Reliability Pillar of the Well-Architected Framework, for a database cluster to be highly available, it must be able to withstand the failure of one AZ. This implies that at least two private subnets are necessary to enable the database servers to span a sufficient number of AZs.

To allow operators to execute changes to database instances without causing unnecessary disruptions to the services they support, I recommend always maintaining a second instance available no matter what happens to the AZs within an AWS Region. Therefore, it is necessary to deploy a minimum of three instances in a production-worthy RDS Aurora Cluster to ensure you can lose one AZ—and consequently one database instance—without losing the ability to failover to a new Writer and restart the instances in the cluster.

Obviously, for environments where high availability is not a concern, relaxing this requirement can reduce your cloud infrastructure costs. You can quite easily get away with deploying just one or two database instances for a staging or development environment, assuming the database may not be available all the time (for example, there may be an outage during the mandatory weekly maintenance window).

Photo by Preyansh Patel.

Route Tables

You need Route Tables. That is a fact of your AWS networking life. That is about all you need to know from a Database Reliability Engineering (DBRE) point of view.

Network Access Control Lists

Network Access Control Lists (NACLs) help control access to subnets within a VPC. This is yet another layer in your layered defence strategy. It is an important part of compliance and security risk mitigation. Ignore at your own peril.

Security Groups

Security Groups (SGs) provide a mechanism to ensure that a given application can only access databases (and data) relevant to it. While your application will most likely never touch data that does not belong to it, this is yet another layer in your compliance and security risk mitigation. Once again, ignore at your own peril.

Organisations that handle financial, medical, and other sensitive types of personal information usually lean further into security groups to ensure that only individuals with the correct level of authorisation can actually log in to the databases and query them.

Depending on the size of your organisation and the complexity of your services, you may run into VPC quota limits for Security Groups. I advise keeping an eye on your quota limits.

Database Subnet Groups

The RDS automations use the Database Subnet Groups (DBSGs) associated with a given RDS cluster to choose the subnet (and AZ) where to deploy the next database instance you request.

Failure to declare a DBSG causes AWS to use the default subnet groups to deploy database instances. As you demonstrated above in Private Subnets, deploying databases to public subnets is unwise and can be highly dangerous for your data and your organisation.

This is one of those pitfalls that baffles me. In a decade of AWS-wrangling, I have yet to find a production-worthy use case for the default, public-by-default VPC. Yet that is the didactic example AWS hands to newcomers, like a life-jacket that comes with an anchor stitched in.

Moreover, keep an eye on the number of DBSGs you create. AWS imposes an initial, adjustable quota on the number of DBSGs you can create per account and region.

A vintage brass cash registry

The FinOps Aspect

Dear reader, please keep in mind the prices quoted here reflect what I found at the time of writing and will age poorly. I strongly believe the conclusions I reached, however, should hold true regardless of actual price points. Please, always verify current AWS pricing.

Cost efficiency in cloud-native databases is not just about right-sizing instances. Networking decisions have a direct, often underappreciated impact on your AWS bill. Left unchecked, data transfer and ancillary networking services can quietly inflate costs to rival (or exceed) the price of the database clusters themselves.

Data Transfer Costs

Aurora’s architecture replicates data across three AZs with six copies by default. It's intra-region replication is included in the service price (Amnic, 2025, Redress Compliance, 2026). This is a rare win for cost-conscious engineers. As AWS bundles the cost of its distributed storage layer, you pay for the feature, not the traffic.

However, cross-region data transfer is a different beast. Cross-region read replicas and Disaster Recovery (DR) scenarios all incur US$0.02/GiB in each direction for replication traffic (Usage.ai, 2026). Worse still, this traffic is often the least understood and most poorly budgeted in AWS environments (CloudZero, 2025). A lightly used secondary region for DR can quietly add five figures to your annual bill simply by existing.

There is one more insidious cost driver: application-to-database traffic. If your app servers and Aurora cluster reside in different AZs, every query and result set traverses AZ boundaries, racking up US$0.01/GiB in each direction. Architect for locality where possible, deploying compute and database in the same AZ to avoid this tax.

AWS documentation downplays cross-region costs by focusing on RPO/RTO benefits. Third-party analyses consistently show these costs are the number-one budget surprise for Aurora users (PlanetScale, 2025).

VPC Endpoints

One very important and often-overlooked way to save costs on cross-AZ and cross-region networking is to deploy and use VPC Endpoints properly.

VPC Endpoints eliminate the need to route traffic through NAT Gateways (hourly + per-GB charges) or the public internet, keeping it within AWS’s private network. For Aurora clusters, the following endpoints are non-negotiable for both security and cost control:

Pro Tip: Gateway endpoints (S3, DynamoDB) are free and should always be used for those services. Interface endpoints, while not free, are still cheaper than NAT Gateways for consistent, high-volume traffic c3x.dev, 2025. For a 3-AZ Interface endpoint to S3, you’d pay ~US$21/month in endpoint fees alone—peanuts compared to the NAT Gateway alternative, but not negligible at scale.

AWS’s pricing pages bury the per-AZ hourly cost for Interface endpoints as if it were a bag of hákarl. Employ a third-party calculator and avoid feeling a bad taste in your mouth when you look at your AWS bill.

Beached cargo ship photo by ManxHarbours.

Disaster Recovery

Disaster Recovery (DR) is Compliance’s darling, Sales’ closer, and Finance’s nightmare. With stakes this high, it is no surprise it can also become a major cost-multiplying factor in your infrastructure.

Your DR strategy is the main pricing factor. To put it simply, the shorter the RTO (how fast you want to be back in business) and the smaller the RPO (how little data you are willing to lose as a consequence of an incident), the higher the DR costs.

From a cross-AZ and cross-region data-transfer perspective, there are only a few strategies for Disaster Recovery: you can choose to minimise the RPO when a disaster happens, thus increasing cross-AZ and cross-region data transmission; or you can compromise on RPO and RTO by transmitting data more sparsely.

Keeping a pilot-light or warm standby database is covered by the RPO-minimisation strategy. Transmitting data dumps or incremental, differential, partial backups and allowing your business to be down for the time it takes to rebuild a database in the DR environment is covered by the network-traffic minimisation strategy. Perhaps a table will help. DR strategies here match AWS’ Disaster Recovery Options in the Cloud:

At this point, you can probably see this is a very delicate balancing act without many balanced options. There are no good options; it quickly degenerates into all-or-nothing. Remember, this is only the cross-AZ and cross-region data-transfer costs we are looking at here. Many other factors outside the scope of this article will also weigh in, making your costs swell.

Conclusion

Networking is not just plumbing—it is the difference between a database that merely limps along and one that stands resilient, secure, and cost-conscious. Get this right, and you are not just avoiding pitfalls; you are laying the groundwork for a platform that can scale, adapt, and thrive. Take heart, as this is only the first piece of the puzzle.