Your First Serverless API on AWS: Lambda, API Gateway, and DynamoDB
Explore a practical architecture for a task API, from request routing and data modeling to authorization, monitoring, and cost control.
For a small web or mobile application, a backend needs to receive requests, run business logic, and store data. AWS offers a serverless combination that covers those responsibilities: Amazon API Gateway, AWS Lambda, and Amazon DynamoDB.
This article uses a task management API to explain how the pieces fit together. It is an architecture walkthrough, with a link to AWS's hands-on implementation tutorial at the end.
How a request moves through the system
Imagine a user updating a task from a mobile app. The app sends an HTTPS request to API Gateway. API Gateway selects the route and invokes a Lambda function. The function validates the input, updates DynamoDB, and returns a response through API Gateway.
| Service | Responsibility in this example |
|---|---|
| Amazon API Gateway | Provide the HTTP endpoint and route requests |
| AWS Lambda | Validate requests and execute application logic |
| Amazon DynamoDB | Persist task records |
You still own the application code, permissions, data model, and operational decisions. Serverless reduces the infrastructure you provision directly; it does not remove the need to design and operate the application.
Start with a small API contract
Define the operations before choosing implementation details:
| Method | Route | Purpose |
|---|---|---|
| POST | /tasks | Create a task |
| GET | /tasks/{taskId} | Retrieve one task |
| PATCH | /tasks/{taskId} | Update a task |
| DELETE | /tasks/{taskId} | Delete a task |
A task might look like this:
1
2
3
4
5
{
"taskId": "task-001",
"title": "Review the architecture",
"status": "pending"
}Decide how the API handles invalid input, missing tasks, and duplicate creation requests. For example, a successful creation can return
201, invalid input 400, and an unknown task 404. A clear contract makes backend and frontend work easier to coordinate.Choose API Gateway features deliberately
An API Gateway HTTP API is a reasonable starting point for this example because it supports Lambda integrations and JWT authorizers.
Check the feature comparison before committing to it. API Gateway REST APIs support additional capabilities, including request validation, API keys, per-client throttling, and AWS WAF integration. Choose according to your requirements rather than treating the two API types as interchangeable.
For a browser frontend, configure CORS for the origins, methods, and headers you actually use. CORS controls browser behavior; it does not authenticate callers or protect an otherwise public endpoint.
Model DynamoDB around the questions you will ask
For the initial single-user learning example, use a string partition key named
taskId. This supports retrieving, updating, and deleting a task by its identifier.Before adding a multi-user task list, reconsider the access patterns. “Get task by ID” and “list all tasks belonging to this user” are different requirements. A composite key or secondary index may be appropriate. Avoid designing a growing application around repeated full-table scans.
On-demand capacity is useful when traffic is uncertain because it removes the need to provision read and write capacity in advance. It still has costs and throughput limits, and key design still matters.
Keep function permissions narrow
Give Lambda an execution role with access to the required DynamoDB operations on the specific table, plus the logging permissions it needs. The function should use the role's credentials; do not embed AWS access keys in source code.
Keep request validation close to the business logic. Check required fields, accepted status values, and allowed updates before writing data. Consider conditional writes to prevent accidental overwrites and define how clients should handle retries.
A small learning exercise can use one function. As responsibilities grow, separate handlers or functions can make testing, permissions, and deployment easier to manage. AWS's CRUD tutorial discusses this tradeoff.
Add identity before storing private user data
Use a JWT authorizer with an identity provider such as Amazon Cognito to validate incoming tokens. Authentication establishes who made a request. Your application must also decide whether that identity can access the requested task.
For a multi-user design, derive ownership from the verified identity rather than trusting a
userId supplied in the request body. Include ownership in the data model and enforce it for reads, updates, and deletes. Checking that a token is valid is only one part of protecting user data.Observe behavior and understand the bill
Use Amazon CloudWatch to inspect Lambda logs and metrics such as errors, duration, and throttles. Log useful request context without recording tokens or sensitive task content. Configure alarms around failures that matter to your users.
Estimate API Gateway requests, Lambda requests and execution duration, DynamoDB activity and storage, and logging costs. Set AWS Budget notifications before opening the API to real traffic. Budget alerts notify you about spending; they are not a hard spending cap.
Configure throttling and test realistic workloads. Those controls help manage traffic, but do not guarantee a maximum bill. Review actual usage after launch and adjust the architecture based on evidence.
Turn the design into a learning project
Follow AWS's CRUD HTTP API tutorial to create the table, Lambda integration, routes, and test requests. Adapt its item example to tasks, then add authorization and ownership checks before using private data.
Once the workflow makes sense, express the resources in AWS SAM or CloudFormation so you can recreate the environment reliably. When you finish the exercise, delete the API, functions, table, and unused log groups to avoid retaining resources you no longer need.
The main lesson is how responsibilities connect: an HTTP boundary, focused application logic, a data model built for its access patterns, and explicit controls for identity and operations.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article