Serverless Architecture Diagram on AWS: API Gateway, Lambda, DynamoDB and Events

On a serverless system the servers are gone, and so is the usual shape of an architecture diagram. What matters instead is how each function gets triggered, what happens when it fails, and which events connect one part of the system to the next. A diagram that shows twenty Lambda boxes and no triggers looks complete and explains nothing.

This guide shows how to draw a serverless architecture diagram on AWS that a new teammate can follow: one worked example, a notation for invocation types and failure paths, and the mistakes that make these diagrams misleading.

Start with how each function is invoked

Every Lambda function on the diagram is started by something, and AWS has three invocation models with different behavior when things go wrong. This is the most useful thing a serverless diagram can show.

Invocation model	Typical sources	Who retries on failure	Where failures end up
Synchronous	API Gateway, a function URL, an SDK call	The caller decides	An error response to the caller
Asynchronous	EventBridge, S3 notifications, SNS	Lambda retries twice by default	An on-failure destination or a dead-letter queue, if you configure one
Event source mapping (Lambda polls)	SQS, DynamoDB Streams, Kinesis	Lambda keeps retrying the batch	SQS: the queue's dead-letter queue. Streams: an on-failure destination, or the records expire

Label each trigger edge with its source and model: sync, async, or poll, batch 10. When an incident starts with "messages are piling up", this is the line people look for.

The example: a serverless orders API

A small orders service built entirely on managed services:

1. Clients call an API Gateway HTTP API. A JWT authorizer checks tokens issued by an Amazon Cognito user pool.
2. API Gateway invokes createOrder synchronously. The function validates the request and writes the order to the orders DynamoDB table.
3. A DynamoDB stream on the table triggers publishOrderEvents, which sends OrderPlaced to a custom EventBridge bus. Because the event comes from the stream, it is only published for writes that succeeded.
4. An EventBridge rule matches OrderPlaced and sends it to the receipts SQS queue.
5. Lambda polls the queue and invokes sendReceipt with batches of up to ten; the function emails the customer through Amazon SES.
6. A message that fails five times moves to receipts-dlq, where an alarm tells the team.

The request path ends at step 2: the client gets its response as soon as the order is stored. Everything after that is asynchronous, and the diagram draws those triggers with dashed edges.

Rules for serverless diagrams

Draw triggers as labeled edges

The edge into a function says what starts it: POST /orders, DynamoDB stream, rule: OrderPlaced, SQS, batch 10. A function without an incoming edge is either dead code or a missing line on your diagram.

Separate the request path from the asynchronous work

Use solid edges for synchronous calls and dashed edges for everything that happens later. Readers should be able to trace the path that adds latency for the user without reading every label.

Draw the failure path on purpose

For every asynchronous edge, decide where failures go and draw it: a dead-letter queue, an on-failure destination, or a note that says "records expire after 24 hours". DynamoDB Streams keep records for 24 hours, so a consumer that keeps failing loses events once they expire. An S3 on-failure destination keeps a copy of the failed records; an SQS or SNS destination gets only metadata, so something must read the records back from the stream within those 24 hours.

One function per node

A single "Lambda" node for thirty functions hides the triggers, and the triggers are the architecture. If there are too many functions, split the diagram by service, not by merging boxes.

Frame by deployment unit

Group the resources that are deployed together, such as one SAM, CDK or Terraform stack, in a frame. It shows ownership and what changes together.

Keep permissions and limits as notes

Every function has an IAM execution role, and some have reserved concurrency or long timeouts. Do not draw a role per function. Add a note for what matters in a review: "only createOrder can write to orders", "sendReceipt SQS trigger maximum concurrency 5 to protect SES limits".

Common mistakes

• API Gateway drawn as a load balancer. It also authenticates, throttles and transforms requests, and the authorizer belongs on the diagram.
• Missing dead-letter queues, or dead-letter queues that nobody watches. Draw the alarm too.
• Event buses without rules. An EventBridge bus fans out by rule; label the edge with the rule, not just the bus.
• No sync and async distinction. It is the difference between a slow API and a slow email.
• Infrastructure noise. Log groups, layers and every IAM policy belong in the template, not on the overview.

Build it in Archboard

Archboard's Cloud pack nodes are provider-neutral and have ports, so you label each node with the AWS service name:

1. Sign in with Google or GitHub and create a diagram.
2. Add Core Box nodes for the clients and for Amazon SES, a Cloud pack API Gateway, and a Security pack Identity Provider labeled Amazon Cognito.
3. Add a Cloud pack Function for each Lambda function, named exactly as in your template.
4. Add a Cloud pack Managed DB labeled DynamoDB: orders, a Data pack Topic labeled EventBridge bus, Cloud pack Queue nodes for the queue and its dead-letter queue, and a DevOps pack Alert for the alarm.
5. Connect ports. Keep the request path solid, set asynchronous edges to dashed, and label every trigger with its source and invocation model.
6. Put the stack in a Core Frame, add notes for permissions and limits, then share the live link with the team.

The example uses 13 diagram nodes, which fits the Free plan. For the network around a serverless or container workload, see the AWS VPC diagram guide, and for more cloud patterns the cloud use case page.

FAQ

Should I draw every Lambda function? On the service diagram, yes, because each one has its own trigger and failure behavior. On a system overview, show the service as one node and link to its diagram.

Can I use the official AWS icons? Archboard has no AWS-specific pack: build the diagram from typed Cloud, Network and Security nodes with ports and label each with the service name, such as Amazon SES or DynamoDB: orders. If you also want logos, Search and insert has brand icons for AWS services, such as AWS Lambda, which you can place as icon nodes.

How do I show Step Functions? As one node on the architecture diagram, labeled with the state machine name, and the workflow itself as a separate flowchart or BPMN diagram.

Where do cold starts and concurrency go? In notes next to the functions where they matter, for example provisioned concurrency on a latency-sensitive endpoint.

Do I need to show IAM roles? Not as nodes. Note the permissions that shape the design, and keep the full policies in your infrastructure code.

Start free — one seat, no credit card.