AWS architecture diagram layers
A well-structured AWS architecture diagram organises services into layers that reflect how traffic flows through the system. The standard layering used in AWS reference architectures follows a top-down flow: edge → load balancing → compute → data → observability. Drawing services in this order makes the diagram readable without a legend.
| Layer | AWS Services | What to show |
|---|---|---|
| Edge / CDN | CloudFront, Route 53, AWS WAF, Shield | CloudFront distribution with origin groups, Route 53 record types, WAF web ACL attached to CloudFront or ALB. |
| VPC boundary | VPC, subnets, Internet Gateway, NAT Gateway | VPC CIDR, public and private subnets per AZ, IGW attached to VPC, NAT Gateway in public subnet routing private subnet outbound traffic. |
| Load balancing | ALB, NLB, API Gateway | Listener rules and target group routing, SSL termination point, health check configuration. |
| Compute | EC2 (Auto Scaling), ECS, EKS, Lambda, Fargate | Instance types or task definitions, Auto Scaling group min/max, placement across AZs. |
| Storage | S3, EFS, EBS, FSx | Bucket names and replication configuration, EFS mount targets per AZ, EBS volumes attached to specific EC2 instances. |
| Database | RDS, Aurora, DynamoDB, ElastiCache, Redshift | Primary and read replica placement, Multi-AZ standby, Global Tables or Aurora Global Database replication arrows. |
| Messaging / async | SQS, SNS, EventBridge, Kinesis, MSK | Queues and topics, producer → queue → consumer flow, dead-letter queue connections. |
| Security / identity | IAM, Cognito, Secrets Manager, KMS, Certificate Manager | IAM roles on compute services, Cognito User Pool connected to API Gateway authoriser, KMS key used by RDS or S3. |
| Observability | CloudWatch, X-Ray, CloudTrail, Config | Log groups receiving logs from compute, X-Ray traces, CloudWatch alarms on key metrics. |
Example: three-tier web application on AWS
The most common AWS architecture pattern is a three-tier web application: a presentation tier served from CloudFront, a compute tier behind an ALB, and a data tier with RDS and ElastiCache. Here is a prompt that generates this diagram in flow-chart.io:
Three-tier web application on AWS in us-east-1. Route 53 A record points to CloudFront distribution. CloudFront origin is an Application Load Balancer. ALB in a public subnet, with a listener on 443 forwarding to a target group of EC2 instances (t3.medium, Auto Scaling group min 2, max 10) in two private subnets across us-east-1a and us-east-1b. EC2 instances connect to RDS Aurora MySQL (writer in us-east-1a, reader replica in us-east-1b) and to an ElastiCache Redis cluster (one shard, two replicas across AZs) in private subnets. EC2 instances write logs to S3 via an S3 VPC Endpoint. NAT Gateway in the public subnet for outbound traffic from the EC2 instances. AWS WAF attached to the CloudFront distribution. Cognito User Pool as the authentication provider, with the ALB listener rule forwarding authenticated users only. Show VPC boundary, subnet labels, AZ groupings, and all connections. AWS architecture diagram.
Serverless AWS architecture patterns
Serverless architectures eliminate EC2 instances and Auto Scaling groups in favour of managed, event-driven services. The key difference in the diagram is the absence of VPC subnets around compute (Lambda functions can run outside a VPC), and the prominence of event sources (API Gateway, SQS, EventBridge, S3 events) and IAM execution roles.
| Pattern | Key AWS services | Diagram focus |
|---|---|---|
| REST API backend | API Gateway → Lambda → DynamoDB | API Gateway resource paths, Lambda function names, DynamoDB table names, IAM execution role on Lambda. |
| Event-driven processing | S3 → Lambda → SQS → Lambda → DynamoDB | S3 event notification trigger, SQS queue with DLQ, Lambda concurrency and timeout annotations. |
| Async orchestration | API Gateway → Step Functions → Lambda (multiple) | Step Functions state machine connected to multiple Lambda functions, with retry and catch states annotated. |
| Real-time streaming | Kinesis Data Streams → Lambda → S3 / DynamoDB | Kinesis shard count, Lambda event source mapping, S3 Firehose delivery stream. |
| Full-stack serverless | CloudFront → S3 (SPA) + API Gateway → Lambda → Aurora Serverless | S3 static hosting as CloudFront origin, API Gateway as second origin, Aurora Serverless cluster with auto-pause annotation. |
Multi-region AWS architecture diagrams
Multi-region diagrams add a geographic dimension to the architecture. The outer boundary is the AWS account; inside are two or more AWS region containers. Cross-region connections show data replication and routing policies.
- Draw each region as a labelled container (e.g. "us-east-1 — Primary", "eu-west-1 — Secondary") with its own VPC, subnets, and compute resources.
- Show Route 53 latency-based or failover routing policies directing traffic to each region's ALB or CloudFront distribution — annotate with routing type and health check.
- Draw S3 Cross-Region Replication as a directed arrow from the source bucket to the destination bucket, annotated with replication rule name.
- For RDS, show the primary cluster in one region with a cross-region read replica or Aurora Global Database secondary cluster in the other region. Annotate with the replication lag SLO if relevant.
- For DynamoDB Global Tables, draw bidirectional replication arrows between the tables in each region to show the active-active write topology.
- Annotate RTO and RPO targets on the cross-region connections for business continuity review diagrams.
AWS architecture diagram best practices
- Use nested containers to represent the VPC hierarchy: AWS Region → VPC → Availability Zone → Subnet → Compute resources. This nesting makes the failure domain boundaries immediately visible.
- Always show the NAT Gateway in the public subnet with an arrow to the Internet Gateway — this is one of the most commonly misunderstood network paths and is often omitted.
- Show security group rules as annotations on the resources they protect rather than as separate objects — security groups describe which traffic a resource accepts, so they belong on the resource.
- Use different arrow styles to distinguish synchronous calls (solid line), asynchronous messages (dashed line), and data replication (double-headed arrow).
- Draw the happy-path traffic flow top-to-bottom through the layers. Feedback paths (response, error, return) can be shown as lighter arrows or omitted if not relevant to the diagram's purpose.
- Show AZ distribution explicitly for any resource that is HA-capable: ALBs span AZs, Auto Scaling groups place instances across AZs, RDS Multi-AZ has a standby in a different AZ. Omitting this creates diagrams that look like single-AZ architectures.
- Separate large architectures into multiple focused diagrams: one for VPC and networking, one for the application tier, one for the data tier. Each diagram should answer one question clearly.
Frequently asked questions
- What AWS services should I include in an architecture diagram?
- Include the services relevant to the diagram's purpose and audience. A complete production architecture includes: network (VPC, subnets, IGW, NAT, Security Groups), compute (EC2 ASG, ECS, Lambda), load balancing (ALB), storage (S3, EFS), database (RDS Aurora, ElastiCache, DynamoDB), CDN and DNS (CloudFront, Route 53), and security (IAM roles, WAF, Cognito, KMS). A developer-focused diagram can omit networking detail; a security review diagram should prioritise Security Groups, IAM roles, and WAF configuration.
- How do I draw an AWS VPC diagram?
- Structure the VPC diagram with three nesting levels: (1) AWS Region as the outer boundary. (2) VPC inside the region, annotated with its CIDR block. (3) Subnets inside the VPC, each labelled with CIDR, availability zone, and public/private designation. Place compute resources inside the appropriate subnets. Show the Internet Gateway attached to the VPC at its boundary. Show the NAT Gateway inside the public subnet with an outbound arrow to the IGW, and an inbound arrow from the private subnets. Annotate route tables on the subnets they control.
- How do I diagram a serverless AWS architecture?
- For serverless diagrams, show event sources (API Gateway, S3 events, SQS, EventBridge) triggering Lambda functions, with Lambda connecting to data services (DynamoDB, Aurora Serverless, S3). Show IAM execution roles on each Lambda. For orchestration, show Step Functions connecting multiple Lambda invocations. For real-time processing, show Kinesis Data Streams as the event source. Omit VPC subnets unless Lambda functions are VPC-attached — most serverless architectures run Lambda outside a VPC.
- How do I show a multi-region AWS architecture?
- Draw each region as a labelled container with its own VPC and resources. Show Route 53 routing policies directing traffic to each region. Draw S3 Cross-Region Replication, RDS Cross-Region Read Replica, or DynamoDB Global Tables as annotated arrows between the region containers. For active-active DynamoDB, use bidirectional arrows. Annotate cross-region connections with replication type, replication lag, and RTO/RPO targets if the diagram is for business continuity planning.
- What is the difference between an AWS architecture diagram and a network diagram?
- An AWS architecture diagram shows managed service relationships — which services talk to which, how data flows, and how they are grouped into VPCs. A network diagram focuses on lower-level topology — IP CIDRs, routing tables, BGP peering, VPN tunnels, Direct Connect connections. Most AWS architecture diagrams combine both views: service relationships at the application level, with CIDR annotations and security group rules at the network level.
- Should I use official AWS icons in my architecture diagram?
- AWS publishes an official icon set (AWS Architecture Icons) available for free. Official icons make service identification instant for AWS-familiar engineers, but they add visual density in complex diagrams. flow-chart.io uses labelled shapes by default, which are cleaner for multi-service diagrams and easier to edit. Diagrams can be exported to draw.io format where AWS icon stencils can be applied if the final diagram requires official icons.
- Is the generated AWS architecture diagram editable, or is it a static image?
- Fully editable. flow-chart.io generates a typed scene graph, not a raster image. Every AWS service node, VPC boundary, subnet container, and connection arrow is a named object you can rename, reposition, or delete. You can add a new subnet, insert a read replica, or reroute a CloudFront origin without rebuilding the diagram. Nothing is flattened to pixels until you export to PNG or PDF.