You are building a secure application for a banking client. The compliance team mandates that production traffic between your application servers and your private Amazon RDS database must never traverse the public internet. How do you design this?

Picture a bank's internal pneumatic tube system connecting the teller counter to the vault in the back room — a physical, private pipe that never routes money-filled canisters out onto the public street just to travel twenty feet. The tube system is entirely self-contained within the building; there's no window it passes to get from point A to point B. A private-subnet-to-private-subnet RDS connection works the same way: as long as both endpoints live inside the VPC's private address space, AWS routes traffic through its own internal network fabric, never touching the public internet, regardless of how far apart the resources are physically.

AWS designed VPCs around this exact separation of concerns: a subnet is 'private' specifically because its route table has no route to an Internet Gateway (IGW), only to the VPC's local CIDR range (and optionally a NAT gateway for one-way outbound internet access, which is irrelevant here since RDS traffic never needs to leave the VPC at all). This means the compliance requirement isn't actually something you have to build — it's the default behavior of AWS networking, as long as you don't accidentally give either side a path to the internet, such as placing the RDS instance in a public subnet or attaching a public IP to the database (which AWS disables by default for RDS, but can be misconfigured).

Internally, when the application server issues a query, DNS resolution for the RDS endpoint returns a private IP address within the VPC's CIDR block (assuming the RDS instance has 'Publicly Accessible' set to No), and the packet is routed entirely through the VPC's internal routing table — AWS's software-defined networking layer handles this at the hypervisor level using its own backbone, never emitting the packet onto the public internet even for cross-Availability-Zone traffic within the same region, since AZs within a VPC are connected by AWS's private inter-AZ links.

At production scale for a banking client specifically, the design typically goes further than 'just use private subnets': security groups on the RDS instance are locked down to allow inbound traffic only from the application tier's specific security group (not a CIDR range, which is more precise and self-documenting), NACLs add a stateless second layer of defense at the subnet boundary, and traffic is encrypted in transit via TLS/SSL enforced through the RDS parameter group (rds.force_ssl = 1) even though it's already physically private, satisfying compliance frameworks that require encryption in transit as a defense-in-depth measure regardless of network isolation. For multi-account setups (common in banking, where prod and the database might sit in separate AWS accounts for blast-radius isolation), the same 'never touches the internet' guarantee is achieved via VPC Peering or Transit Gateway rather than a public endpoint with an IP allowlist, since IP allowlisting a public endpoint technically does route through the internet even if access is restricted.

The non-obvious gotcha: enabling a Multi-AZ RDS deployment or a read replica in a different region can silently reintroduce a compliance violation if the second region's VPC isn't connected via a private path (like a cross-region VPC peering connection or Transit Gateway peering) — engineers sometimes assume Multi-AZ failover traffic is automatically private, but a misconfigured cross-region replica without inter-region private connectivity will replicate over the public internet by default unless explicitly set up otherwise, silently breaking the exact guarantee the compliance team mandated.