How do you diagram a serverless AWS architecture (Lambda, API Gateway, DynamoDB) in Mermaid?

What makes a serverless AWS architecture different to diagram?

The defining property of a serverless service is that AWS owns the infrastructure it runs on. You do not place a Lambda function on a subnet the way you place an EC2 instance, because there is no instance and no subnet you control — the function runs in AWS-managed capacity inside the Region. The same is true of API Gateway, DynamoDB, S3, Cognito, EventBridge, SQS, and SNS. They are all regional services: scoped to a Region, reached through a regional endpoint, and living outside any VPC.

That single fact changes the shape of the diagram. A three-tier or VPC networking diagram is dominated by containment — a VPC holding subnets holding instances, with route tables deciding what can talk to the internet. A serverless diagram has almost none of that. The containment is shallow: an AWS Account, a Region, and then a flat set of services inside it. What carries the meaning is the edges — the direction a request flows from the client through API Gateway to a function to a table.

This is why copying a VPC layout onto a serverless system produces something misleading. Wrapping a Lambda and a DynamoDB table inside a VPC box implies a network boundary that does not exist and hides the thing that actually matters: the invocation path.

Where do Lambda, API Gateway, and DynamoDB sit in the diagram?

Every core serverless service is a direct child of the Region. There is no intermediate VPC or subnet layer for managed regional services — placing one inside a VPC or subnet is a placement error, and a validator will flag it. Here are the pieces and their Mermaid slugs.

The pattern is uniform: service <id>(aws:<slug>)[Label] in region. For the full icon set, see the icon catalog; for the grammar of the in clause and port-anchored edges, the architecture-beta syntax reference.

Does Lambda go inside a VPC or a subnet?

This is the one place the "everything at Region level" rule bends, and it is worth being precise. A Lambda function has two modes:

• Not VPC-attached (the default). The function runs in AWS-managed infrastructure and can reach public AWS service endpoints — DynamoDB, S3, other APIs — directly. It has no network placement of its own, so on the diagram it sits at the Region level. This is the right default for most serverless apps, and it is what both examples below use.
• VPC-attached. When a function needs to reach a private resource — an RDS database, an ElastiCache cluster, something in a private subnet — you attach it to the VPC. Its elastic network interfaces then live in subnets, and AWS requires those to be private subnets only. On the diagram, a VPC-attached Lambda must be drawn inside a private subnet, never a public one and never loose in the VPC.

That second case is the only serverless placement rule with teeth, and it is the exact mirror of the private-instance rule from the VPC networking guide:

architecture-beta
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
group priv(aws:private-subnet)[Private Subnet] in vpc
service fn(aws:arch-aws-lambda)[VPC-Attached Lambda] in priv
service rds(aws:arch-amazon-rds)[RDS PostgreSQL] in priv
fn:R --> L:rds

If you draw a VPC-attached Lambda in a public subnet, or leave it sitting directly in the VPC, LatixEngine flags it — the same way it catches a database in a public subnet. Unless a function genuinely needs private resources, leave it out of the VPC entirely; attaching it for no reason adds cold-start latency and a diagram box that misrepresents how the function actually runs.

What does a serverless REST API look like in Mermaid?

The canonical serverless stack is a synchronous REST API: a client calls API Gateway, which authorizes the request against a Cognito user pool and invokes a Lambda function, which reads and writes DynamoDB and serves assets from S3. Every service is a direct child of the Region, and the diagram is the request path.

architecture-beta
service users(aws:res-users-light)[Users]
group account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in account
service cognito(aws:arch-amazon-cognito)[Cognito User Pool] in region
service apigw(aws:arch-amazon-api-gateway)[API Gateway] in region
service fn(aws:arch-aws-lambda)[Lambda Function] in region
service ddb(aws:arch-amazon-dynamodb)[DynamoDB Table] in region
service s3(aws:arch-amazon-simple-storage-service)[Assets S3] in region
users:R --> L:apigw
apigw:B --> T:cognito
apigw:R --> L:fn
fn:R --> L:ddb
fn:B --> T:s3

Notice what is not there: no VPC, no subnets, no NAT gateway, no load balancer. A region holding nothing but managed services is a completely valid AWS architecture, and the diagram is honest about it. The edges do the explaining — the request enters at API Gateway, gets authorized, runs in Lambda, and persists to DynamoDB. For this same shape as one of a set of copy-paste starting points, see the serverless entry in the AWS architecture patterns gallery.

How do you diagram an event-driven serverless flow?

Serverless systems are rarely just request/response. The pattern that makes them scale is asynchronous fan-out: a function accepts work, drops an event onto EventBridge or a queue, and a separate worker processes it later. Mermaid handles this cleanly because directional edges read as the flow of events.

architecture-beta
service users(aws:res-users-light)[Users]
group account(aws:aws-account)[AWS Account]
group region(aws:region)[us-east-1] in account
service apigw(aws:arch-amazon-api-gateway)[API Gateway] in region
service ingest(aws:arch-aws-lambda)[Ingest Lambda] in region
service bus(aws:arch-amazon-eventbridge)[EventBridge] in region
service queue(aws:arch-amazon-simple-queue-service)[SQS Queue] in region
service worker(aws:arch-aws-lambda)[Worker Lambda] in region
service ddb(aws:arch-amazon-dynamodb)[DynamoDB Table] in region
users:R --> L:apigw
apigw:R --> L:ingest
ingest:R --> L:bus
bus:R --> L:queue
queue:R --> L:worker
worker:R --> L:ddb

The ingest path stays fast because it just publishes an event; the slow work happens in the worker on its own schedule. Read left to right, the diagram tells that story directly — which is the whole point of drawing it. Everything is still region-level, so the picture stays flat and the flow stays legible.

How do you keep a serverless diagram correct?

Serverless diagrams fail quietly in a specific way: because the layout is so flat, a wrong placement does not look wrong. A Lambda accidentally wrapped in a VPC, a DynamoDB table nested inside a subnet, or an API Gateway drawn under a VPC all render as tidy boxes — they just describe an architecture that cannot exist. That is exactly the class of error a validator is for.

• Keep managed services at the Region level. API Gateway, DynamoDB, S3, and Cognito are regional; if a diagram nests them in a VPC or subnet, it is wrong, and LatixEngine flags each one.
• Only VPC-attach a Lambda when it needs private resources, and then only in a private subnet. Everything else is a non-VPC function at Region level.
• Commit the .mmd text next to the function code it describes, so the diagram diffs in the same pull request as the change. For the anti-patterns this shares with server-based designs, see common AWS architecture mistakes; for turning an existing template or model into this shape with an LLM, see how to prompt LLMs for Mermaid AWS diagrams.

LatixEngine is free, runs entirely in the browser with no login or install, and checks every icon slug against the catalog and every placement against AWS rules — so a serverless diagram that renders cleanly is also one that is actually correct.