AWS VPC Diagram: Subnets, Route Tables and NAT, Drawn Right

Most VPC diagrams are drawn once, at the start of a project, and copied from the console's resource map. They show every resource and answer none of the questions people actually bring to them: can the internet reach this database? Why can the app download packages but not receive connections? What breaks if one Availability Zone goes down?

This guide shows how to draw an AWS VPC diagram that answers those questions. We use one common layout, a VPC across two Availability Zones with public, private and data subnets, and go through the parts that decide reachability: subnets, route tables, gateways, endpoints and security groups.

The questions a VPC diagram must answer

• What can the internet reach? Only resources in public subnets with a route to an internet gateway, and only if their security groups allow it.
• How do private resources get out? Usually through a NAT gateway, sometimes through VPC endpoints, sometimes not at all.
• How does traffic flow between tiers? Load balancer to app, app to database, and on which ports.
• What happens when an AZ fails? Which resources exist in each zone, and which ones are shared.

If the drawing makes any of these hard to answer, it needs fewer resources and more structure.

The building blocks

Part	What it is	How to draw it
VPC	Your private network, with a CIDR block such as 10.0.0.0/16	The outer frame, CIDR in the label
Availability Zone	An isolated location in the region	A column or frame inside the VPC
Subnet	A range of the VPC CIDR in exactly one AZ	A frame inside its AZ, CIDR in the label
Route table	Rules that send traffic from a subnet to a target	A small table per subnet tier
Internet gateway	The VPC's door to the internet	On the VPC border, toward the internet
NAT gateway	Lets private subnets start outbound connections	Zonal: inside a public subnet, one per AZ. Regional: one gateway for all AZs, no subnet
VPC endpoint	A private path to AWS services	Gateway endpoints for S3 and DynamoDB; interface endpoints in subnets
Security group	Stateful firewall on each network interface	Port rules as edge labels, not as boxes
Network ACL	Stateless filter on the subnet	A note on the subnet, only if you use custom rules

Two facts shape the whole layout. A subnet lives in exactly one Availability Zone, so a subnet can never span the AZ columns on your diagram. And a standard (zonal) NAT gateway lives in one AZ: if the only one sits in AZ a, the private subnets in AZ b lose outbound access when AZ a fails. Since November 2025 AWS also offers regional NAT gateways, which expand across AZs on their own and need no public subnet; this example uses zonal ones.

The example: two AZs, three tiers

The VPC uses 10.0.0.0/16 in two Availability Zones, with three subnets in each:

Tier	AZ a	AZ b	Route for 0.0.0.0/0
Public	10.0.0.0/24	10.0.1.0/24	Internet gateway
App (private)	10.0.10.0/24	10.0.11.0/24	NAT gateway in the same AZ
Data (private)	10.0.20.0/24	10.0.21.0/24	None

Every route table also has the local route for 10.0.0.0/16, which lets subnets in the VPC reach each other; security groups then decide what is actually allowed. AWS reserves five addresses in every subnet, so a /24 gives you 251 usable addresses.

What runs where:

• An Application Load Balancer has nodes in both public subnets and accepts HTTPS from the internet.
• App servers (EC2 instances or ECS tasks) run in both app subnets and accept traffic only from the ALB's security group.
• An RDS PostgreSQL primary runs in one data subnet with a standby in the other. RDS requires a DB subnet group with subnets in at least two AZs.
• A NAT gateway in each public subnet gives the app servers outbound access for updates and third-party APIs.
• A gateway endpoint for S3 lets the app servers reach S3 without going through the NAT gateway, which also saves NAT data processing charges.

Here is the diagram:

Layout rules that keep it readable

Columns for AZs, rows for tiers

Put Availability Zones side by side and tiers top to bottom: public on top, then app, then data. Reachability then reads from the top down, and a resource missing from one column is visible immediately.

Put the internet gateway on the border

The internet gateway attaches to the whole VPC, not to a subnet. Draw it on the VPC frame, between the internet and the public subnets.

Show routes as a table, not as arrows to everything

An arrow from every subnet to every gateway turns the diagram into a web. A small route table per tier, like the one above, says the same thing precisely. Draw arrows only for the main traffic paths.

Put security group rules on the edges

Security groups belong to network interfaces, not to subnets, so frames are the wrong shape for them. Label the edges instead: HTTPS 443 from internet, 8080 from ALB SG, 5432 from app SG. That is the information people look for.

Keep peering and VPN at the edge

Transit gateways, peering connections and site-to-site VPNs connect the VPC to other networks. Draw them on the VPC border, with the remote CIDRs in the label, and keep the remote side on its own diagram.

Common mistakes

• A subnet that spans two AZs. It cannot exist. Draw one subnet per AZ, even if they are twins.
• One zonal NAT gateway for both AZs without saying so. It may be a deliberate cost decision; write it on the diagram so nobody assumes zone independence.
• Security groups drawn as nested boxes. They overlap freely and apply per interface; nesting suggests rules that do not exist.
• Copying the console's resource map with every network interface and route table association. Useful for audits, unreadable for design.
• No CIDRs. Overlapping ranges are what block peering later. Put the CIDR on every VPC and subnet frame.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. From the Network pack, add a VPC frame and set its CIDR to 10.0.0.0/16.
3. Inside it, add Core Frame elements for the two AZs, and Network pack Subnet frames inside each AZ with their CIDRs.
4. Add a Network pack Internet node outside the VPC and a Router on the VPC border for the internet gateway.
5. Add a Cloud pack Cloud LB (load balancer) for the ALB, Compute nodes for the app servers, and Managed DB nodes for the RDS primary and standby. Use Network pack Router nodes for the NAT gateways.
6. Connect ports and label edges with ports and security group sources.
7. Add a Core Table with the route tables and a Note for decisions such as NAT per AZ.

The full example uses more than the Free plan's 15 diagram nodes, so a VPC diagram this detailed is a good fit for Pro. For multi-region designs, see the AWS multi-region architecture diagram, and for more network patterns the network use case page.

FAQ

Should every subnet be on the diagram? On the VPC design diagram, yes, because reachability depends on subnet and route table. On an application diagram, a frame per tier is usually enough.

Do I need a NAT gateway in every AZ? With zonal NAT gateways, yes, for zone independence. A single zonal NAT gateway saves money but makes every AZ depend on one zone for outbound traffic, and adds cross-AZ data charges. A regional NAT gateway is one gateway that expands into each AZ with workloads. Whichever you choose, write it on the diagram.

Where do VPC endpoints go? Gateway endpoints (S3 and DynamoDB) are targets in route tables, so draw them on the VPC border and mention them in the route table. Interface endpoints are network interfaces in your subnets, so draw them inside the subnets that host them.

Security groups or network ACLs on the diagram? Security groups as edge labels, always. Network ACLs only as a note on the subnet, and only when you changed the defaults.

Can I generate this from my AWS account? Archboard does not read your AWS account. Draw the design you intend, then compare it with the console's resource map during reviews.

Start free — one seat, no credit card.