AWS Scenarios
Serverless API With Lambda And DynamoDB
Design a serverless API using API Gateway, Lambda, DynamoDB, IAM, CloudWatch, throttling, retries, and cost controls for SAA-C03 architecture decisions.
After this, you will understand
This scenario turns the common serverless trio into architecture judgment: managed ingress, event-driven compute, NoSQL access patterns, and operational limits.
Use API Gateway for HTTP entry, Lambda for request logic, and DynamoDB for low-operations key-value or document data.
Learners choose serverless only because it sounds modern, without checking data access patterns, latency, quotas, retries, and observability.
Model the API around known access patterns, give Lambda least-privilege access, protect the API with authorization and throttling, and monitor errors, latency, concurrency, and DynamoDB throttles.
Think before readingWhat makes DynamoDB a good fit for a serverless API?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Serverless API architecture
- API Gateway HTTP and REST API decisions
- Lambda functions and execution roles
- DynamoDB tables and access patterns
- Authorization and throttling
- CloudWatch logs and alarms
- DynamoDB point-in-time recovery
- Serverless cost drivers
- SAA-C03 serverless traps
1. Situation
You need to build a public API for a web or mobile application. The API has uneven traffic, starts small, and may grow quickly. The team wants low operational overhead and does not want to patch servers, manage load balancers, or pre-provision application instances.
The data model is simple: user profiles, sessions, preferences, shopping carts, or request records. Most operations can be expressed as key-based reads and writes. There is no strong requirement for relational joins or complex ad hoc SQL queries.
This is a classic serverless API scenario:
client -> API Gateway -> Lambda -> DynamoDB
The exam does not reward choosing "serverless" blindly. It rewards matching the workload to the service boundaries.
2. Naive Design
The naive design is an EC2 web server and local database:
internet -> public EC2 instance -> local app and database
That design creates server patching, OS hardening, scaling, deployment, backup, and failover work.
Another naive serverless design is one giant Lambda function that handles every route, uses broad IAM permissions, writes logs forever, and stores data in DynamoDB without a thought-out partition key. It removes servers but creates a new kind of operational mess.
A third naive design uses DynamoDB as if it were a relational database. The team later asks for joins, arbitrary filters, and reports that the table was not designed to support.
3. What Breaks
With EC2, small teams spend time managing infrastructure instead of API behavior. Capacity is idle during quiet periods and insufficient during traffic spikes.
With a poorly designed serverless API, failure moves to different boundaries. Lambda can throttle because concurrency is exhausted. API Gateway can reject requests because throttling limits are hit. DynamoDB can throttle hot partitions. A Lambda retry can duplicate work. Logs can become expensive. Cold starts can matter for latency-sensitive APIs.
DynamoDB access patterns must be known early. If a page needs "show all orders filtered by several arbitrary fields," a single poorly indexed table may not answer efficiently.
Serverless reduces some operations. It does not remove design responsibility.
4. AWS Architecture
Use Amazon API Gateway as the public API entry point. Choose HTTP API when the required feature set is simple and cost matters. Choose REST API when the scenario requires REST-only features, advanced API management behavior, or legacy compatibility.
Integrate API Gateway with Lambda functions. Keep functions small enough to own clear operations, but do not split so aggressively that every request becomes a maze.
Use DynamoDB for the primary data store when the access patterns are key-value, document, item lookup, or predictable query patterns. Choose on-demand capacity for spiky or unknown workloads. Choose provisioned capacity with auto scaling when traffic is predictable and cost tuning matters.
Use IAM execution roles so each Lambda function can access only the tables, indexes, secrets, and logs it needs.
Use CloudWatch for logs, metrics, alarms, and dashboards.
5. Request Or Data Flow
A client sends an HTTPS request to API Gateway. API Gateway applies authorization, throttling, request validation, and routing according to API type and configuration.
API Gateway invokes the Lambda function. The event contains request details. The function validates input, performs business logic, and reads or writes DynamoDB.
DynamoDB returns the item or write result. The Lambda function formats a response. API Gateway sends the response back to the client.
Metrics and logs flow to CloudWatch. CloudTrail records control-plane API activity. DynamoDB can emit streams if downstream event processing is required.
For asynchronous work, the Lambda function should enqueue a message to SQS or publish an event rather than forcing the client to wait for every long-running step.
6. Security Controls
Use HTTPS. API Gateway provides the public endpoint, not a public EC2 instance.
Choose the right authorization model: IAM authorization, JWT authorizers, Lambda authorizers, Cognito, or another supported pattern depending on the application.
Give Lambda functions least-privilege IAM roles. A read endpoint should not automatically have permission to delete every item in every table.
Do not put secrets in code or environment variables without proper protection. Use Secrets Manager or Parameter Store where appropriate.
Use DynamoDB encryption at rest. Use KMS customer-managed keys when compliance or key control requires them.
Avoid logging sensitive payloads. Serverless logs are easy to create and easy to forget.
7. Resilience Controls
Lambda and DynamoDB are managed services, but the application still needs failure handling.
Handle retries and idempotency. If a client retries a request or Lambda retries an operation, the system should not create duplicate orders or double-charge a user.
Use DynamoDB conditional writes for conflict control where needed.
Enable DynamoDB point-in-time recovery for important tables.
Use reserved concurrency when a function must be protected from consuming all account concurrency or when downstream services need a cap.
Use API throttling to protect the backend from abusive or accidental spikes.
8. Performance Controls
For API Gateway, watch latency, integration latency, 4xx errors, and 5xx errors.
For Lambda, watch duration, errors, throttles, concurrent executions, and cold-start-sensitive paths.
For DynamoDB, design partition keys to distribute load. A hot partition can throttle even when the table seems broadly provisioned.
Use Global Secondary Indexes only when they match real query patterns. Indexes add cost and write amplification.
Use DAX or caching only when repeated reads and latency requirements justify it.
Keep Lambda packages lean and initialize reusable clients outside the handler where appropriate.
9. Cost Controls
Serverless cost follows usage: API requests, Lambda invocations and duration, DynamoDB reads and writes, CloudWatch logs, KMS calls, data transfer, and optional features.
HTTP APIs can be lower cost than REST APIs when their feature set is enough.
Lambda memory affects CPU and duration. Sometimes more memory lowers total cost by finishing faster.
DynamoDB on-demand is useful for unknown or spiky traffic. Provisioned capacity can be cheaper for predictable workloads when tuned.
Control log retention. Verbose logs for every request can become a serious cost line.
Use Cost Explorer and Budgets to watch growth after launch.
10. Exam Variants
"Low operational overhead public API" can point to API Gateway plus Lambda.
"Serverless NoSQL database with single-digit millisecond performance" points to DynamoDB.
"Need relational joins and SQL" points away from DynamoDB and toward RDS or Aurora.
"Unpredictable traffic" may point to Lambda and DynamoDB on-demand.
"Protect backend from too many requests" points to API Gateway throttling and quotas.
"Need asynchronous background processing" adds SQS, EventBridge, or Step Functions.
11. Common Traps
Do not choose Lambda for long-running compute beyond service limits.
Do not choose DynamoDB if the workload depends on ad hoc joins and relational reporting.
Do not use one broad IAM role for every function.
Do not forget idempotency for retries.
Do not leave CloudWatch log retention unbounded.
Do not assume serverless means no quotas, no throttling, or no architecture design.
12. Related Topics
Review Amazon API Gateway, AWS Lambda, Amazon DynamoDB, and Amazon CloudWatch.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.