How do you know if your AWS architecture diagram is correct?
An AWS diagram can render perfectly and still be wrong. Here are the placement and connectivity rules that make one correct — and how to check them free.
An AWS architecture diagram is correct when its structure obeys AWS constraints: every resource sits in a valid parent (EC2 in a subnet, S3 in a Region, not a VPC) and every connection is one AWS allows (a private instance reaches the internet via a NAT gateway, never straight to an internet gateway). LatixEngine checks both free in the browser.
You can draw an AWS architecture diagram that renders beautifully and is still wrong. The renderer only cares that the syntax parses; it has no idea that a database does not belong in a public subnet, that S3 is not a resident of your VPC, or that a private instance cannot reach the internet by wiring itself to an internet gateway. The picture looks authoritative, gets pasted into a design doc, and quietly misleads every reviewer who trusts it.
"Correct" for an architecture diagram is not about aesthetics or layout — it is about whether the structure it shows is one AWS would actually let you build. This post breaks down the two kinds of rules that decide that, shows a diagram that passes and the same diagram broken, and covers how to check any diagram automatically instead of eyeballing it.
An AWS diagram is correct when it obeys real AWS constraints, not just Mermaid syntax. Those constraints come in two families: placement (is each resource inside a valid parent — EC2 in a subnet, S3 in a Region, NAT in a public subnet?) and connectivity (is each edge a path AWS allows — private egress via NAT, not straight to the IGW?). Paste the diagram into LatixEngine and it checks both against an AWS rule engine, free, in the browser.
What does it mean for an AWS architecture diagram to be "correct"?
A diagram is a claim about how a system is built. Correctness is whether that claim holds up against how AWS actually works — not whether the boxes are aligned or the colors are on-brand. Two diagrams can be pixel-identical in polish and yet one describes a deployable architecture and the other describes something that would fail at terraform apply.
The useful test is: could you build exactly what this diagram shows? If the diagram puts an RDS instance in a public subnet, or hangs S3 inside the VPC, or draws a load balancer floating outside any network, the answer is no — and the diagram is wrong no matter how clean it looks. This is different from the catalogue of specific anti-patterns; it is the underlying question those anti-patterns are all instances of.
What are the two kinds of rules an AWS diagram must obey?
Almost every AWS correctness rule is one of two kinds, and separating them makes checking a diagram tractable.
- Placement (containment) rules ask where a resource sits. Each AWS resource has a valid parent: an EC2 instance belongs directly inside a subnet, a subnet inside a VPC, a VPC inside a Region, and a Region inside an account. Regional services break out of the VPC entirely — S3 and DynamoDB are direct children of the Region, not residents of a subnet. A NAT gateway must sit in a public subnet specifically. Get the nesting wrong and the architecture is wrong.
- Connectivity rules ask whether an edge is a path AWS allows. A private-subnet instance reaches the internet through a NAT gateway, never straight to the internet gateway. A gateway VPC endpoint connects to S3 or DynamoDB in the same Region. An internet-facing load balancer lives in a public subnet. Edges that ignore these describe traffic that cannot flow.
| Rule family | The question it answers | Examples |
|---|---|---|
| Placement | Is this resource in a valid parent? | EC2 in a subnet; S3 in the Region, not the VPC; NAT in a public subnet |
| Connectivity | Is this edge a path AWS allows? | Private egress via NAT, not the IGW; gateway endpoint to same-Region S3 |
For the grammar that expresses this nesting and these edges, see the architecture-beta syntax reference; for the networking layer in depth, the VPC diagram guide.
What does a correct AWS diagram look like?
Here is a standard load-balanced web application drawn so that every placement and every edge holds up. It validates at zero rule violations: the load balancer attaches to the VPC as the internet-facing entry point, the app server is private and egresses through the NAT gateway, the database is in its own private subnet, and S3 sits at the Region level outside the VPC.
architecture-beta
service users(aws:res-users-light)[Users]
service internet(aws:res-internet-alt1-light)[Internet]
group account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in account
service s3(aws:arch-amazon-simple-storage-service)[Assets S3] in region
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
service igw(aws:res-amazon-vpc-internet-gateway)[Internet Gateway] in vpc
service alb(aws:res-elastic-load-balancing-application-load-balancer)[Load Balancer] in vpc
group pub(aws:public-subnet)[Public Subnet] in vpc
service nat(aws:res-amazon-vpc-nat-gateway)[NAT Gateway] in pub
group priv(aws:private-subnet)[Private Subnet] in vpc
service app(aws:arch-amazon-ec2)[App Server] in priv
group data(aws:private-subnet)[Data Subnet] in vpc
service db(aws:arch-amazon-rds)[RDS Database] in data
users:R --> L:internet
internet:R --> L:igw
igw:B --> T:alb
alb:B --> T:app
app:R --> L:db
app:B --> T:nat
nat:R --> T:igw
app:L --> R:s3Every box is somewhere it is allowed to be, and every line is traffic that can actually flow. That is what "correct" means in practice — nothing more mysterious than each rule holding.
What does the same diagram look like when it's wrong?
Now here is the version that renders just as cleanly but breaks two rules — the kind of thing that slips through review because the picture looks fine. The S3 bucket has been drawn inside the VPC, and the private app server is wired straight to the internet gateway.
architecture-beta
service internet(aws:res-internet-alt1-light)[Internet]
group account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in account
group vpc(aws:virtual-private-cloud-vpc)[VPC] in region
service igw(aws:res-amazon-vpc-internet-gateway)[Internet Gateway] in vpc
service s3(aws:arch-amazon-simple-storage-service)[Assets S3] in vpc
group priv(aws:private-subnet)[Private Subnet] in vpc
service app(aws:arch-amazon-ec2)[App Server] in priv
internet:R --> L:igw
app:R --> L:igwA validator flags exactly two problems here. First, a placement error: S3 is a Regional service and cannot live inside a VPC — it belongs at the Region level. Second, a connectivity error: a private-subnet instance must not connect directly to the internet gateway; its egress has to route through a NAT gateway in a public subnet. Neither is visible from how the diagram looks; both are obvious the moment the rules are applied. The full list of anti-patterns this class of check catches is in common AWS architecture mistakes.
How do you check an AWS diagram automatically?
Applying these rules by hand works for a five-box diagram and falls apart on a real one. The faster path is to let a rule engine do it:
- Author or paste the diagram into the LatixEngine editor. It parses the architecture-beta source into a resource tree — what contains what, and what connects to what.
- It runs that tree through the AWS rule set: placement rules (EC2 in a subnet, S3 in a Region, NAT in a public subnet) and connectivity rules (private egress via NAT, gateway endpoints to same-Region storage, and more).
- Every violation comes back with the offending resource, a plain-English reason, and a fix hint — so you correct the diagram before it ships, not after a reviewer trusts a wrong one.
Because it checks slugs against the icon catalog at the same time, it also catches the hallucinated icon names that LLMs love to invent — the other way a diagram silently goes wrong, covered in prompting LLMs for Mermaid AWS diagrams.
How do you keep a diagram correct as the architecture changes?
A diagram is correct at a point in time; architectures drift. The discipline that keeps the picture trustworthy is the same one you apply to code:
- Store the .mmd source next to the code or infrastructure it documents, so the diagram travels with the system.
- Re-validate whenever the topology changes — a new subnet, a managed service, a new traffic path. Validation takes seconds, so there is no excuse to skip it.
- Review the diagram diff in the pull request. Because the source is text, a reviewer sees exactly which nodes and edges changed, and the validator confirms the change did not introduce an impossible placement or connection.
This is how a diagram stops being decoration and becomes a checkable artifact. LatixEngine is free, runs entirely in the browser with no login, and validates against AWS, Azure, and GCP rules — so the picture you commit is one you can actually rely on. If you are starting from scratch, begin with how to draw AWS architecture diagrams in Mermaid; for a fully worked serverless example, see the serverless architecture guide.
Frequently asked questions
How do you validate an AWS architecture diagram?
Check two things: placement (is each resource inside a valid parent?) and connectivity (is each edge a path AWS actually allows?). You can review these by hand against AWS's rules, but it is faster and more reliable to paste the diagram into LatixEngine, which runs it through an AWS rule engine and flags every misplacement and impossible connection with a fix hint.
Can an AWS diagram be wrong even if it renders fine?
Yes — and that is the most common trap. Rendering only checks that the syntax is valid, not that the architecture is possible. A diagram with a database in a public subnet, S3 drawn inside a VPC, or a private instance wired straight to an internet gateway renders as a tidy picture while describing something AWS would never let you build.
Where does S3 belong in an AWS diagram — inside or outside the VPC?
Outside. S3 is a Regional service, so it is a direct child of the Region group and a sibling of the VPC, never a resource inside a subnet. A workload in a VPC reaches it over a gateway VPC endpoint that keeps the traffic on the AWS network. Drawing the bucket inside the VPC is a placement error.
How should a private EC2 instance reach the internet in a diagram?
Through a NAT gateway, not the internet gateway directly. A private-subnet instance has no public route, so its outbound traffic goes to a NAT gateway sitting in a public subnet, which then reaches the internet gateway. An edge drawn straight from a private instance to the IGW depicts a path that cannot exist.
Does LatixEngine validate Azure and GCP diagrams too?
Yes. The same rule engine covers AWS, Azure, and GCP architecture-beta diagrams. It checks provider-specific placement and connectivity rules against the icon slugs in your diagram, so the same author-and-validate workflow works whichever cloud you are drawing.
Is validating an AWS diagram free?
Yes. LatixEngine runs entirely in the browser with no login, no install, and no usage limit. You paste or draw the diagram, and it validates against the AWS rule set instantly — the validation is part of the free editor.
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 →