What are the most common AWS architecture patterns in Mermaid (with copy-paste examples)?
A gallery of five ready-to-paste AWS reference architectures in Mermaid architecture-beta: three-tier web app, serverless API, static site, container microservices, and an event-driven pipeline — each a complete diagram built from real AWS icon slugs and validated at zero rule violations.
The most common AWS patterns — three-tier web apps, serverless APIs, static sites, container microservices, and event-driven pipelines — each map to a canonical architecture-beta shape. This gallery gives you five complete, copy-paste Mermaid diagrams built from real aws:<icon-name> slugs, every one validated by LatixEngine's AWS rule engine at zero violations.
Most AWS architectures are variations on a handful of shapes. Once you can recognise those shapes, drawing them is mostly a matter of picking the right services and wiring them together correctly. This post is a gallery of the five patterns that cover the vast majority of real workloads, each as a complete, copy-paste Mermaid architecture-beta diagram.
This is a reference library, not a tutorial. If you are new to the syntax and want a guided walkthrough, start with how to draw AWS architecture diagrams in Mermaid, and keep the architecture-beta syntax reference open for the grammar behind the edges and ports. Everything below shows the correct shape affirmatively; for the inverse — the anti-patterns and how to catch them — see the most common AWS architecture mistakes.
Two placement facts govern every diagram here, and they come from LatixEngine's own AWS rule engine, not just AWS best practice. First, every aws:region must contain a VPC, every VPC must contain a subnet, and every subnet must hold at least one service — so even a "serverless" or "static" diagram carries a minimal account → region → VPC → subnet → service scaffold, which we satisfy with a genuinely VPC-attached Lambda rather than filler. Second, an ALB and an internet gateway are direct children of the VPC (never inside a subnet), a NAT gateway lives inside a public subnet, and a WAF attaches only to CloudFront, an ALB, or API Gateway. Every diagram below was checked against that engine and returns zero violations.
What does a three-tier web app look like in Mermaid?
A public-facing web tier sits behind an Application Load Balancer spread across two Availability Zones, with a Multi-AZ RDS pair in private subnets. Use this for classic stateful web apps that need high availability at both the compute and database layers.
architecture-beta
service net(internet)[Internet]
service users(aws:res-users-light)[Users]
group aws_account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in aws_account
service route53(aws:arch-amazon-route-53)[Route 53] in region
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
service igw(aws:res-amazon-vpc-internet-gateway)[IGW] in vpc
service alb(aws:res-elastic-load-balancing-application-load-balancer)[ALB] in vpc
group pub_a(aws:public-subnet)[Public Subnet AZ-a] in vpc
group pub_b(aws:public-subnet)[Public Subnet AZ-b] in vpc
service web_a(aws:arch-amazon-ec2)[Web EC2 a] in pub_a
service web_b(aws:arch-amazon-ec2)[Web EC2 b] in pub_b
service nat(aws:res-amazon-vpc-nat-gateway)[NAT] in pub_a
group priv_a(aws:private-subnet)[Private Subnet AZ-a] in vpc
group priv_b(aws:private-subnet)[Private Subnet AZ-b] in vpc
service rds_primary(aws:arch-amazon-rds)[RDS Primary] in priv_a
service rds_standby(aws:arch-amazon-rds)[RDS Standby] in priv_b
users:R <--> L:route53
route53:R <--> L:alb
net:L <--> R:igw
nat:R <--> L:igw
alb:B <--> T:web_a
alb:B <--> T:web_b
web_a:B <--> T:rds_primary
web_b:B <--> T:rds_primary
rds_primary:R <--> L:rds_standbyRDS lives in private subnets, the EC2 web tier in public subnets, the ALB as a direct VPC child, a single IGW connects to the internet, and NAT sits in a public subnet. The ALB targets only same-VPC EC2 instances — never RDS or NAT directly.
How do you diagram a serverless REST API?
A fully managed API where API Gateway fronts Lambda backed by DynamoDB, with Cognito for auth and S3 for static assets. Use this for spiky or low-ops workloads where you have no server fleet to manage.
architecture-beta
service users(aws:res-users-light)[Users]
group aws_account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in aws_account
service apigw(aws:arch-amazon-api-gateway)[API Gateway] in region
service cognito(aws:arch-amazon-cognito)[Cognito] in region
service ddb(aws:arch-amazon-dynamodb)[DynamoDB] in region
service s3(aws:arch-amazon-simple-storage-service)[S3 Static Assets] in region
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
group priv(aws:private-subnet)[Private Subnet] in vpc
service fn(aws:arch-aws-lambda)[Lambda] in priv
users:R <--> L:apigw
apigw:R <--> L:cognito
apigw:B <--> T:fn
fn:R <--> L:ddb
users:B <--> T:s3API Gateway and S3 are placed directly in the region because they are regional managed services. API Gateway integrates through Lambda and never wires straight to a database. The VPC-attached Lambda sits in a private subnet, which also satisfies the region-requires-VPC and non-empty-subnet rules.
What is the pattern for static site or SPA hosting?
Route 53 points at CloudFront (fronted by a WAF) serving an S3 origin for static and SPA assets, plus a Lambda origin for server-side-rendered or API routes. Use this for global, cache-first frontends with a minimal dynamic surface.
architecture-beta
service users(aws:res-users-light)[Users]
group aws_account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in aws_account
service route53(aws:arch-amazon-route-53)[Route 53] in region
service cf(aws:arch-amazon-cloudfront)[CloudFront] in region
service waf(aws:arch-aws-waf)[WAF] in region
service s3(aws:arch-amazon-simple-storage-service)[S3 Origin] in region
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
group priv(aws:private-subnet)[Private Subnet] in vpc
service fn(aws:arch-aws-lambda)[SSR/API Lambda] in priv
users:R <--> L:route53
route53:R <--> L:cf
waf:R <--> L:cf
cf:B <--> T:s3
cf:B <--> T:fnThe WAF associates only with CloudFront, and S3 is placed directly in the region. The VPC-attached SSR Lambda in a private subnet doubles as the origin for dynamic routes and satisfies the region-requires-VPC and non-empty-subnet rules.
How do you diagram containerized microservices?
A public ALB routes to ECS/Fargate tasks in private subnets, backed by Aurora and ElastiCache, with images pulled from ECR and egress through NAT. Use this for horizontally-scaled container services that need private data stores.
architecture-beta
service net(internet)[Internet]
service users(aws:res-users-light)[Users]
group aws_account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in aws_account
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
service igw(aws:res-amazon-vpc-internet-gateway)[IGW] in vpc
service alb(aws:res-elastic-load-balancing-application-load-balancer)[ALB] in vpc
service ecr(aws:arch-amazon-elastic-container-registry)[ECR] in region
group pub(aws:public-subnet)[Public Subnet] in vpc
service nat(aws:res-amazon-vpc-nat-gateway)[NAT] in pub
group priv_app(aws:private-subnet)[Private Subnet App] in vpc
group priv_data(aws:private-subnet)[Private Subnet Data] in vpc
service tasks(aws:arch-aws-fargate)[ECS Fargate Tasks] in priv_app
service aurora(aws:arch-amazon-aurora)[Aurora] in priv_data
service cache(aws:arch-amazon-elasticache)[ElastiCache] in priv_data
users:R <--> L:alb
net:L <--> R:igw
nat:R <--> L:igw
alb:B <--> T:tasks
tasks:R <--> L:ecr
tasks:B <--> T:aurora
tasks:B <--> T:cache
tasks:R <--> L:natAurora and ElastiCache sit in a private data subnet, Fargate tasks in a private app subnet, and the ALB is a direct VPC child that targets only same-VPC tasks. NAT lives in a public subnet, and the private tasks reach the internet through NAT rather than connecting to the IGW directly.
What does an event-driven pipeline look like?
An S3 upload triggers an ingest Lambda that queues work to SQS for a worker Lambda writing to DynamoDB, with an EventBridge → SNS fan-out alongside. Use this for decoupled, buffered async processing that needs retries and fan-out.
architecture-beta
group aws_account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in aws_account
service s3(aws:arch-amazon-simple-storage-service)[S3 Uploads] in region
service ingest(aws:arch-aws-lambda)[Ingest Lambda] in region
service sqs(aws:arch-amazon-simple-queue-service)[SQS] in region
service eb(aws:arch-amazon-eventbridge)[EventBridge] in region
service sns(aws:arch-amazon-simple-notification-service)[SNS] in region
service ddb(aws:arch-amazon-dynamodb)[DynamoDB] in region
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
group priv(aws:private-subnet)[Private Subnet] in vpc
service worker(aws:arch-aws-lambda)[Worker Lambda] in priv
s3:R <--> L:ingest
ingest:R <--> L:sqs
sqs:R <--> L:worker
worker:R <--> L:ddb
ingest:B <--> T:eb
eb:R <--> L:snsS3 and the managed messaging services (SQS, SNS, EventBridge, DynamoDB) sit at region level. The ingest Lambda is not VPC-attached, so it has no placement constraint, while the VPC-attached worker Lambda sits in a private subnet and satisfies the region-requires-VPC and non-empty-subnet rules. No Lambda connects to an IGW.
Which pattern fits which workload?
Use this table as a quick index from workload to pattern. Pick the closest match, paste the diagram, then swap the region, labels, and services for your own.
| Pattern | Best for | Compute | Data / state | Entry point |
|---|---|---|---|---|
| Three-tier web app, multi-AZ | Stateful web apps needing HA | EC2 in public subnets | Multi-AZ RDS in private subnets | Route 53 → ALB |
| Serverless REST API | Spiky, low-ops APIs | Lambda | DynamoDB | API Gateway (+ Cognito) |
| Static site / SPA | Global cache-first frontends | Lambda (SSR/API) | S3 origin | Route 53 → CloudFront (+ WAF) |
| Container microservices | Horizontally-scaled services | ECS/Fargate in private subnets | Aurora + ElastiCache | ALB |
| Event-driven pipeline | Decoupled async processing | Lambda (ingest + worker) | DynamoDB | S3 event / EventBridge |
How do you adapt these patterns and publish them?
Each diagram is a starting point, not a fixed template. Swap the region name, add more Availability Zones by duplicating a subnet-and-service pair, or replace one data store with another from the same tier — the placement rules are what keep it valid, not the specific services. When you change the wiring, keep the anchors in mind: ALB and IGW as direct VPC children, NAT inside a public subnet, databases and application compute in private subnets, and regional managed services directly in the region.
If a change breaks something, the fastest way to understand why is to compare it against the common AWS architecture mistakes, which walks through each anti-pattern and its fix. And once a diagram is ready to share, rendering and embedding Mermaid AWS diagrams in GitHub, Notion, and Confluence covers getting it into your docs and repos. Every pattern here renders natively in LatixEngine, which ships 856 official AWS icons for Mermaid architecture-beta — free, in the browser, with no login.
Frequently asked questions
What are the most common AWS architecture patterns?
The five that cover most workloads are the multi-AZ three-tier web app, the serverless REST API, static site / SPA hosting, containerized microservices, and the event-driven async pipeline. This gallery gives each one as a complete, copy-paste Mermaid diagram.
Can I copy these Mermaid AWS diagrams and use them directly?
Yes. Every diagram in this post is a full architecture-beta code block using real AWS icon slugs. Paste it into LatixEngine, swap the region, labels, and services for your own, and render. Each example already passes LatixEngine's AWS rule engine at zero violations.
Why do serverless and static-site diagrams still include a VPC and subnet?
LatixEngine's rule engine requires every aws:region to contain a VPC, every VPC to contain a subnet, and every subnet to hold at least one service. We satisfy that with a genuinely VPC-attached Lambda rather than filler, so the diagram stays valid without misrepresenting the architecture.
Where should an ALB, IGW, and NAT gateway go in the diagram?
An Application Load Balancer and an internet gateway are direct children of the VPC, not of a subnet. A NAT gateway lives inside a public subnet. Databases and application compute go in private subnets. These placements are what the validator checks.
How is this different from the common AWS architecture mistakes post?
This gallery is the affirmative library — the canonical correct shape for each workload. The common-mistakes post is the inverse: the anti-patterns to avoid and how to catch them. Read them together to see both the target and the traps.
Is LatixEngine free to use for these AWS diagrams?
Yes. LatixEngine is free with no login and no usage limits. It runs entirely in the browser and ships 856 official AWS icons for Mermaid architecture-beta, so every slug in this gallery renders as a native icon.
Paste any example in this post into the LatixEngine editor to render it with native cloud icons and validate it against AWS, Azure, and GCP best practices. No login, no install.
Open the editor →