Serverless REST API Architecture on AWS
This architecture is the smallest useful serverless API baseline: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is intentionally compact so the first production decisions remain easy to see.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasServerless REST API AWS architecture diagram with API Gateway, AWS Lambda, DynamoDB, and CloudWatch. The image links to a fully editable BuildPlane starter.
Overview
A small serverless REST API with one obvious path from caller to data. API Gateway owns the HTTP surface, Lambda runs the application code, DynamoDB stores records, and CloudWatch makes function behavior visible.
Components
- API Gateway: Publishes REST routes and provides a managed front door for throttling and request validation.
- AWS Lambda: Executes stateless API logic without a continuously running server fleet.
- DynamoDB: Stores application records with on-demand capacity suitable for an early workload.
- CloudWatch: Collects function logs and provides the first place to add latency and error alarms.
Request Flow
- An API client sends an HTTPS request to API Gateway.
- API Gateway validates and invokes the Lambda function for the selected route.
- Lambda applies application logic and reads or writes a DynamoDB record.
- Lambda emits execution logs and metrics to CloudWatch.
Customize First
- Add Cognito or another authorizer when the API needs user identity.
- Add SQS when slow work should leave the synchronous request path.
- Define alarms for error rate, throttling, and latency before launch.
Design rationale
Decisions that shape this architecture
Put the HTTP contract at API Gateway
API Gateway owns routing, throttling, request validation, and the public endpoint. Lambda can stay focused on application behavior instead of rebuilding an HTTP edge.
Keep Lambda handlers bounded
A synchronous request should finish quickly. Slow processing, fan-out, and retries belong behind SQS or EventBridge so client latency is not tied to background work.
Start DynamoDB with explicit access patterns
On-demand capacity removes an early scaling decision, but table keys still need to reflect the queries the API must serve. A schema designed like a relational database can create expensive scans.
Before production
Operational checks
Set API throttles and usage limits before exposing the endpoint publicly.
Alarm on Lambda errors, duration, throttles, and API Gateway 5xx responses.
Make write operations idempotent when clients or integrations can retry.
Capture correlation IDs across API Gateway, Lambda logs, and downstream calls.
Scope and tradeoffs
What this diagram does not solve
Authentication is not included in the minimal path
Add Cognito, IAM authorization, or another authorizer before the API handles user-specific or privileged data.
Long-running work needs an asynchronous boundary
Lambda and API Gateway have execution limits. Queue work that can exceed the request budget and provide a job-status or callback flow.
Common questions
Frequently asked questions
Why use API Gateway in front of Lambda?
API Gateway provides a managed HTTP surface with routing, validation, authorization options, throttling, and request metrics while Lambda runs the application code.
When should this API add SQS?
Add SQS when work is slow, bursty, retryable, or does not need to complete before the HTTP response is returned.
Is this architecture suitable for production?
It is a sound starting point. Production readiness still depends on authentication, alarms, least-privilege IAM, data recovery, deployment controls, and workload-specific limits.
Keep exploring
Related AWS architectures
Secure Application Authentication with Amazon Cognito
This architecture separates identity verification from application authorization. Cognito authenticates the user, API Gateway validates the presented token, Lambda enforces business rules, and DynamoDB remains behind the application boundary.
Explore the architecture
Asynchronous File Processing Pipeline on AWS
This design accepts uploads immediately and lets workers process them at a controlled rate. S3 protects the source file, SQS absorbs bursts and retries, Lambda performs bounded work, and separate result and status stores make completion observable.
Explore the architecture
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.