AWS VPC Diagrams: Public and Private Subnet Patterns
Every AWS architecture review starts with the same drawing: a VPC box, two or three availability zones, public subnets on top, private subnets below. The layout is so standardized that deviating from it makes reviewers suspicious, yet most VPC diagrams still omit the details that matter — route tables, CIDR labels, and the exact placement of NAT gateways. This guide covers the canonical VPC diagram, the four patterns you will draw most often (3-tier, peering, Transit Gateway hub-spoke, and hybrid), and the conventions that make a network diagram actually reviewable instead of decorative.
What does a standard AWS VPC diagram look like?
The canonical layout is a set of nested containers. The outermost frame is the AWS Cloud, containing a Region container, containing the VPC box labeled with its CIDR — typically 10.0.0.0/16. Inside the VPC, availability zones are drawn as two or three vertical columns (us-east-1a, us-east-1b, us-east-1c), and each subnet is a smaller box placed inside its AZ column. This nesting mirrors how AWS actually scopes resources: subnets belong to exactly one AZ, and the diagram should never show a subnet straddling an AZ boundary.
Each AZ column follows the same top-to-bottom order: a public subnet at the top holding a NAT gateway, then a private subnet for the application tier (EC2 Auto Scaling group, ECS tasks, or EKS nodes), then a second private subnet for the data tier (RDS, Aurora, or ElastiCache). The Application Load Balancer is drawn spanning the public subnets across all AZs, because that is how ALBs deploy — one node per subnet, one logical resource. The Internet Gateway sits at the top edge of the VPC box, attached to the VPC rather than to any subnet.
Traffic flow reads top to bottom: internet, IGW, ALB, app tier, database. Drawing two AZs is the minimum that communicates high availability; three matches what most production teams actually deploy, since services like Aurora and EKS behave better with three-way quorum. If you draw a single AZ, expect the first review comment to be about it.
How do you show public and private subnets in a diagram?
A subnet is public or private because of its route table, not because of its name — and a good diagram makes that visible. A public subnet has a route table entry sending 0.0.0.0/0 to the Internet Gateway; a private subnet sends 0.0.0.0/0 to a NAT gateway (or has no default route at all for fully isolated data tiers). The clearest technique is a small route table callout attached to each subnet group, listing two rows: the local route (10.0.0.0/16 -> local) and the default route with its target.
Public subnets contain exactly the resources that need direct inbound or outbound internet paths: ALB nodes, NAT gateways, and occasionally a bastion host — though in 2026 you should draw SSM Session Manager instead of a bastion and keep the subnet emptier. Private app subnets hold the compute; private data subnets hold RDS instances inside a DB subnet group. Placing an RDS icon in a public subnet in a diagram is the visual equivalent of a failed security audit, so tier placement is worth double-checking before you share the drawing.
NAT gateway placement is the detail people get wrong most often: the NAT gateway lives in the public subnet, but it is referenced by the private subnet's route table. Draw one NAT gateway per AZ for production (each private subnet routes to the NAT gateway in its own AZ, avoiding cross-AZ data charges and a single point of failure), or one total for dev environments where the cost of three gateways is not justified. An arrow from each private subnet's route callout to its NAT gateway makes this dependency unambiguous.
Which VPC architecture patterns come up most often?
The 3-tier VPC is the baseline: web tier (public subnets with ALB), application tier (private subnets), and data tier (isolated private subnets with no internet route). Security group chaining belongs on this diagram — the app tier's security group allows ingress only from the ALB's security group, and the database's only from the app tier's. Annotating those references (sg-alb -> sg-app -> sg-db) turns the diagram into a security review artifact instead of just a topology sketch.
VPC peering connects two VPCs with a single line labeled with the peering connection ID (pcx-xxxx). Two facts must be visible on the diagram: the CIDRs cannot overlap (10.0.0.0/16 peered with 10.1.0.0/16), and peering is non-transitive — if VPC A peers with B and B peers with C, A cannot reach C. Beyond three or four VPCs, the peering mesh becomes n(n-1)/2 lines and the diagram itself tells you it is time for Transit Gateway.
The Transit Gateway hub-spoke pattern puts the TGW icon in the center with spoke VPCs around it — production, staging, shared services, and often an egress VPC that centralizes NAT gateways and inspection. Each connection is a TGW attachment, and if you use separate TGW route tables to keep spokes from talking to each other, draw those routing domains explicitly, because that isolation is the entire point of the design.
Hybrid connectivity adds an on-premises box outside the AWS Cloud frame, linked either through a Site-to-Site VPN (Customer Gateway on-prem, Virtual Private Gateway or TGW attachment on the AWS side) or through Direct Connect via a Direct Connect Gateway. Label the tunnel type and the on-prem CIDR range (commonly 192.168.0.0/16 or a 172.16.0.0/12 block), since overlapping address space with the VPC is the most common hybrid design failure and the diagram is where it gets caught.
What conventions make a VPC diagram readable?
Label every subnet with its CIDR: 10.0.0.0/24, 10.0.1.0/24 for public, 10.0.10.0/24 and up for private app, 10.0.20.0/24 and up for data. A consistent numbering scheme lets a reviewer infer tier and AZ from the address alone, and it exposes sizing mistakes — a /24 gives you 251 usable IPs after AWS reserves five, which matters when an EKS cluster starts consuming an IP per pod.
Follow the official AWS diagramming style for containers: availability zones are dashed blue rectangles, the VPC is a solid purple-bordered box, public subnets get a green tint and private subnets a blue tint. These colors come from the official AWS Architecture Icons set, and using them means anyone who has read an AWS whitepaper can parse your diagram without a legend. The dashed AZ boundary specifically signals a logical grouping rather than a resource, which is exactly what an AZ is.
Use the current official AWS icons rather than screenshots or generic shapes, and keep the whole diagram on one icon generation — mixing 2019-era orange squares with the current release reads as unmaintained. Draw.io ships the AWS icon libraries built in (AWS17 through the current set), so there is no excuse for a NAT gateway represented by a gray box labeled NAT.
Which tool should you use to draw a VPC diagram?
Draw.io (diagrams.net) is the default for a reason: free, offline-capable, complete AWS shape libraries, and XML files that diff reasonably in Git. The cost is manual labor — a proper 3-AZ VPC diagram means drawing and aligning a dozen nested containers, and re-flowing everything when the architecture changes. Lucidchart is more polished and can import a live AWS account into a diagram, but the AWS import sits behind the paid tier and the output usually needs heavy cleanup before it is presentation-ready.
Mermaid's architecture-beta syntax handles simple grouped diagrams in Markdown, which is attractive for READMEs, but it cannot express the nested VPC-AZ-subnet hierarchy with the precision this diagram type demands, and you get no control over the AZ-column layout. Text-to-diagram tools built on AI close that gap: AIDrawIO takes a plain-English description of your VPC and generates a draw.io-compatible diagram using the official AWS icon set, so you get draw.io's editability without hand-placing thirty shapes.
The honest decision rule: if the diagram lives next to code and changes rarely, hand-maintained draw.io XML in the repo is fine. If you produce architecture diagrams weekly — design docs, review boards, client proposals — generating the first 90 percent and editing the rest is the only approach that keeps diagrams from going stale.
How do you generate a VPC diagram with AI?
Describe the network the way you would in a design doc and let the model do the layout. A working prompt: Draw an AWS VPC diagram, CIDR 10.0.0.0/16, across 3 availability zones. Each AZ has a public subnet (10.0.0-2.0/24) with a NAT gateway, a private app subnet (10.0.10-12.0/24) with an ECS service, and a private data subnet (10.0.20-22.0/24) with Aurora PostgreSQL. ALB spans the public subnets, Internet Gateway at the top, dashed AZ boundaries, route table callouts showing 0.0.0.0/0 targets. The more routing detail you specify, the less you fix afterward.
The output is draw.io XML, so nothing is locked in: open it in AIDrawIO's editor or in diagrams.net, drag subnets around, correct a CIDR, add the Transit Gateway your prompt forgot. Version history tracks iterations as the architecture evolves, and if your current diagram exists only as a whiteboard photo, uploading the photo converts it into an editable vector diagram instead of forcing a redraw from scratch. Export goes out as draw.io XML for the repo, SVG for docs, or PNG for slides.
The free tier runs on Gemini 3 Flash at 5 generations per hour with no account required; subscribers get Claude Opus 4.8, Claude Sonnet 5, and Gemini 3.1 Pro, which handle dense multi-VPC and hub-spoke prompts more reliably. Try it with your own VPC description at aidrawio.com/en/tools/aws-diagram-generator — paste the prompt above, then compare the output against the conventions in this guide.
Experimente gratis AWS generator
AI-generated AWS architecture diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
Perguntas frequentes
What is the difference between a public and private subnet in AWS?
A public subnet's route table sends 0.0.0.0/0 to an Internet Gateway, so resources with public IPs are directly reachable from the internet. A private subnet routes 0.0.0.0/0 to a NAT gateway for outbound-only access, or has no default route at all. The distinction is purely routing — in a diagram, show it with route table callouts, not just subnet names.
How many availability zones should a VPC diagram show?
Two is the minimum for communicating high availability, and three matches most production deployments since Aurora, EKS, and quorum-based systems favor three AZs. Draw each AZ as a dashed-border column and repeat the same subnet stack in each one. A single-AZ diagram is only appropriate for dev environments, and it should be labeled as such.
Do NAT gateways go in public or private subnets?
NAT gateways are placed in public subnets, because they need a route to the Internet Gateway to forward traffic. Private subnets then reference the NAT gateway in their route tables as the target for 0.0.0.0/0. In production, deploy one NAT gateway per AZ so a single AZ failure does not cut outbound access for the others.
When should I use Transit Gateway instead of VPC peering?
VPC peering works well for two to four VPCs but is non-transitive, so the connection count grows as n(n-1)/2 and becomes unmanageable. Transit Gateway replaces the mesh with a hub-spoke model: each VPC attaches once, and TGW route tables control which spokes can communicate. If your peering diagram looks like a spiderweb, switch to Transit Gateway.
Can I create an AWS VPC diagram from a text description?
Yes. AIDrawIO generates a draw.io-compatible VPC diagram from a plain-English description, using official AWS architecture icons, and the result stays fully editable in AIDrawIO or diagrams.net. The free tier allows 5 generations per hour with no account, and exports include draw.io XML, SVG, and PNG.