AWS VPC Multi-AZ Architecture

What this diagram shows

This diagram illustrates a resilient AWS VPC spanning two Availability Zones with segregated network tiers. Traffic from the internet reaches a load balancer in public subnets, then routes to application servers in private subnets across both AZs. Private instances access external services through NAT gateways in each AZ. Database traffic flows to a multi-AZ RDS instance in isolated data subnets. VPC endpoints provide private paths to S3 and other AWS services without traversing the internet. Route tables govern traffic between subnets, whilst security groups and network ACLs enforce access control at instance and subnet boundaries.

Key components

• Internet Gateway — Accepts inbound traffic from the public internet and routes egress traffic outbound.
• NAT Gateway — Enables outbound internet connectivity for instances in private subnets whilst blocking inbound unsolicited traffic.
• Public Subnet — Houses load balancers and bastion hosts with direct internet routing via the internet gateway.
• Private Subnet — Contains application servers and web servers protected from direct internet access, routing outbound traffic through NAT.
• Data Subnet — Isolated subnet tier that hosts the RDS database with no internet routing.
• RDS Multi-AZ — Managed relational database with automatic failover between two AZs and synchronous replication.
• VPC Endpoints — Privately connects the VPC to S3 and other AWS services without requiring internet gateway or NAT traversal.

When to use it

Use this template for production workloads requiring high availability, fault tolerance, and compliance with network isolation best practices. It suits applications needing database persistence, static asset storage, and horizontal scaling across zones. The architecture accommodates regulatory requirements for network segmentation and is appropriate when you need to minimise data transfer costs and latency to AWS services.

Common mistakes

• Placing RDS in public subnets or failing to use multi-AZ deployment, eliminating automatic failover capability during AZ outages.
• Creating a single NAT gateway in one AZ, causing an outage in that zone to break egress connectivity for the entire application in both zones.
• Omitting VPC endpoints for S3 and forcing all object storage traffic through NAT, increasing costs and latency unnecessarily.

Adapting it to your system

Rename subnets and AZs to match your region and naming scheme. Adjust CIDR blocks to fit your organisation's IP allocation policy. Replace RDS with Aurora, DynamoDB, or other datastores if needed. Add more AZs by replicating the public/private/data subnet pattern. Include additional VPC endpoints for services your application uses, such as Secrets Manager, Systems Manager, or CloudWatch. Modify security group rules to permit only necessary traffic between tiers. Add VPN or AWS Direct Connect if you need hybrid connectivity.