How to Make an AWS Architecture Diagram (Step by Step)
A good AWS diagram is built from the outside in - boundaries first, then services, then flows. This is the method that produces a diagram people trust rather than one they have to decode.
Most AWS diagrams go wrong the same way: someone drops a pile of service icons onto a canvas and connects them with arrows, and the result looks technical but tells you nothing about where things run, what is public, or how requests actually flow. A diagram that people can rely on is built in a deliberate order - the network boundaries first, the services placed inside the right boundaries second, and the request and data flows drawn last - so that every icon sits in a place that means something.
This guide is that method, step by step, for a typical web application on AWS. You can follow along in Atlas Diagram Studio at /diagrams, which provides AWS, Azure, GCP, and Kubernetes stencils and over 1000 shapes, and the network and cloud diagram tool at /diagram-tools/network-diagram gives you Region, VPC, and subnet containers ready to drop in so the structure is correct from the start. If you want the symbol reference behind the icons, the companion AWS symbols guide covers what each shape and box means.
Start with the boundaries, not the services
Before you place a single EC2 instance or Lambda function, draw the containers. Start with an AWS Cloud box, put a Region box inside it - say us-east-1 - and then draw two or three Availability Zone boxes inside the Region if your design is multi-AZ, which most production designs are. Inside the Region, draw the VPC boundary, and inside the VPC draw your subnets, splitting them into public and private and repeating them across the AZs. This scaffold takes a few minutes and it forces every later decision to be honest about where a resource actually lives.
Getting the boundaries right first pays off immediately, because placement now carries meaning. A load balancer dropped into a public subnet reads correctly as internet-facing; a database dropped into a private subnet reads correctly as internal. If you skip the boundaries and place services on a blank canvas, you lose all of that - the diagram cannot show your network design because there is no network to show. The subnet-and-AZ scaffold is the single highest-leverage step in the whole process.
Place the services where they actually run
With the scaffold in place, add the services into the correct boundaries. For a standard web application the layout falls out naturally once the boxes exist.
- Route 53 and CloudFront outside the VPC, at the edge, handling DNS and content delivery before traffic reaches your network.
- An Application Load Balancer in the public subnets, spanning the Availability Zones, as the single internet-facing entry point.
- EC2 instances or ECS/EKS tasks in the private subnets, one group per AZ, inside an Auto Scaling group boundary to show they scale together.
- An RDS primary in one AZ with a standby in another, drawn in private subnets, to show the Multi-AZ database failover design.
- S3 and DynamoDB outside the VPC as managed services, connected to the app tier, since they are regional services not subnet-bound resources.
- Lambda functions and API Gateway where they apply, with Lambda in a VPC only if it truly needs VPC access, since that placement is a real design choice.
- A NAT gateway in a public subnet if private-subnet resources need outbound internet access, since omitting it hides how patches and calls get out.
Draw the request flow and label everything
Now connect the services with arrows that trace a real request. Follow one path end to end: a user hits Route 53, is served through CloudFront, reaches the Application Load Balancer, which routes to a healthy instance in a private subnet, which queries the RDS primary and reads from S3. Drawing this single path makes the architecture legible in a way that a web of every possible connection never does. If there are important secondary flows - a background job, an asynchronous event through SQS or EventBridge - draw them too, but keep them visually distinct so the primary path stays obvious.
Label as you go. Every service icon gets a specific name and role, every non-obvious arrow gets a protocol or purpose, and each boundary box gets its identifier - the Region name, the AZ, the CIDR range of a subnet if that matters to your audience. Direction on arrows should match the real flow of the request or data. A diagram where you can read the labels and follow the arrows without a guide present is a diagram that will still make sense to someone six months from now. The broader method applies to any cloud, as the system architecture diagram guide at /guides/system-architecture-diagram-guide describes.
Keep it accurate as the architecture changes
An AWS diagram is a living document, because the architecture it describes keeps changing. The failure mode is the diagram that was accurate at launch, got exported to a PNG, pasted into a wiki, and never updated - so a year later it describes a system that no longer exists, which is worse than no diagram because people still trust it. The defense is to keep the diagram editable and to update it in the same change process that updates the infrastructure.
Practically, that means keeping the source in an editable tool like Atlas Diagram Studio at /diagrams rather than a flat image, giving each important diagram an owner, and treating a change to the VPC, subnets, or service topology as a trigger to update the diagram alongside the infrastructure-as-code change. Real-time collaboration lets the engineers who made the change annotate the diagram directly. For teams that generate infrastructure from code, the guide on generating diagrams from code at /guides/how-to-generate-diagrams-from-code covers keeping a diagram in sync with the source of truth, and the network diagram tool at /diagram-tools/network-diagram helps validate the subnet and routing layer specifically.