AWS Serverless API Architecture – API Gateway, Lambda, DynamoDB & RDS Proxy

AWS Serverless API Architecture — Overview

The serverless API pattern is the most common modern application architecture on AWS — combining API Gateway for routing, Lambda for compute, and DynamoDB or Aurora+RDS Proxy for data. It provides zero server management, automatic scaling, and pay-per-request pricing. This architecture appears in 20%+ of SAP-C02 questions and is foundational for SAA-C03.

API Gateway — REST vs HTTP API vs WebSocket

Feature	REST API	HTTP API	WebSocket API
Cost	$3.50/million requests	$1.00/million requests (70% cheaper)	$1.00/million messages + connection-minutes
Auth options	IAM, Cognito, Lambda Authorizer, API Keys	IAM, Cognito (JWT), Lambda Authorizer	IAM, Lambda Authorizer
Caching	✅ Built-in (0.5-237 GB)	❌ (use CloudFront)	❌
Usage Plans/API Keys	✅	❌	❌
Request validation	✅	✅ (parameter validation)	❌
Latency	Higher (~30ms overhead)	Lower (~10ms overhead)	Persistent connection
Best for	Full-featured APIs needing caching, usage plans, API keys	Modern APIs prioritizing cost and latency	Real-time: chat, notifications, gaming

Exam tip: Default to HTTP API unless you specifically need REST API features (caching, usage plans, API keys, request/response transformation). HTTP API is 70% cheaper with lower latency.

Lambda — Patterns & Pitfalls

Connection Pooling Problem (Lambda + RDS)

The #1 tested Lambda anti-pattern: Lambda scales to hundreds of concurrent executions, each opening a database connection → overwhelms RDS connection limit → 5xx errors.

• Solution: RDS Proxy — Sits between Lambda and RDS. Maintains a connection pool. Hundreds of Lambda instances share a few dozen actual DB connections. Handles connection multiplexing transparently.
• Alternative: DynamoDB — HTTP-based connections, no connection limit. Truly serverless-native.

Cold Starts

• Problem: First invocation after idle period requires container initialization (100ms-10s depending on runtime/dependencies)
• Mitigation:
  • Provisioned Concurrency — Pre-warm N instances (eliminates cold starts, costs money)
  • SnapStart (Java only) — Snapshot after init, restore from snapshot on cold start (~10x faster)
  • Keep functions warm — CloudWatch scheduled rule pings function every 5 min (hacky, not recommended)
  • Smaller packages — Reduce deployment package size and dependencies
  • ARM (Graviton) — 20% cheaper + 10% faster startup on arm64

Lambda Best Practices

• Initialize outside handler — DB connections, SDK clients, config loaded once and reused across invocations
• Environment variables — Store config (not secrets) in env vars. Secrets → Secrets Manager with caching.
• Use Powertools — AWS Lambda Powertools provides structured logging, tracing, metrics, idempotency out of the box
• Right-size memory — More memory = more CPU. Use AWS Lambda Power Tuning to find optimal setting.

Database Layer — DynamoDB vs Aurora + RDS Proxy

Factor	DynamoDB	Aurora + RDS Proxy
Connection model	HTTP API (no connection limit)	TCP connections (need RDS Proxy to pool)
Scaling	Infinite (on-demand or provisioned+auto-scale)	Vertical (instance size) + read replicas
Data model	Key-value / Document (single-table design)	Relational (SQL, joins, transactions)
Consistency	Eventually consistent (strongly consistent optional)	Strongly consistent (ACID transactions)
Cost model	Pay per request (on-demand) or per RCU/WCU	Instance-hour + RDS Proxy per-connection
Choose when	Key-value access patterns, extreme scale, serverless-native	Complex queries, existing relational schema, ACID needed

Authentication & Authorization

Method	How	Best For
Cognito User Pool	JWT token validation at API GW (no Lambda invoke for auth)	Standard user auth (sign-up, MFA, OAuth/OIDC, social login)
Lambda Authorizer	Custom Lambda validates token → returns IAM policy	Custom auth logic, third-party tokens, bearer tokens from non-Cognito IdPs
IAM Authorization	SigV4 signed requests, verified by API GW	Service-to-service (machine-to-machine), internal APIs
API Keys	x-api-key header (REST API only)	Rate limiting per client (NOT security — for usage tracking/throttling)

Scaling & Limits

Component	Default Limit	Handling Spikes
API Gateway	10,000 RPS (account-level, adjustable)	Throttling returns 429. Use usage plans for per-client limits.
Lambda	1,000 concurrent (scales +500/min after)	Reserved concurrency for critical functions. SQS buffer for overflow.
DynamoDB (on-demand)	40K RCU / 40K WCU per table (adjustable)	Auto-scales instantly. Previous peak × 2 pre-provisioned.
API GW timeout	29 seconds max (hard limit)	For long tasks: API → SQS → Lambda (async). Return 202 Accepted + poll for result.

Handling the 29-Second Timeout

API Gateway has a hard 29-second timeout. For longer operations:

• Async pattern: API → SQS → Lambda (no timeout). Return 202 + task ID immediately. Client polls a status endpoint.
• WebSocket: Client opens WebSocket connection → receives result when ready (push-based).
• Step Functions: API → Step Functions (async) → callback when complete.

Cost Optimization

• HTTP API over REST API: 70% cheaper ($1/M vs $3.50/M). Use unless you need REST-specific features.
• Lambda ARM (Graviton): 20% cheaper, 10% faster. Switch with one config change.
• API Gateway caching: Reduces Lambda invocations for repeated requests (REST API only). $0.02-$3.80/hr depending on cache size.
• DynamoDB on-demand: Best for unpredictable traffic. Switch to provisioned + auto-scaling for predictable patterns to save 50%+.
• Lambda right-sizing: Use Power Tuning to find optimal memory. Over-provisioned memory wastes money; under-provisioned increases duration (= higher cost).
• CloudFront caching: Cache static responses and semi-dynamic content at edge. Each cache hit avoids API GW + Lambda invoke.
• Reserved Concurrency: Free (limits max scale). Provisioned Concurrency costs money (use only where cold starts matter).

Exam Tips

Exam	Key Points
SAP-C02	“Lambda + RDS connection errors under load” → RDS Proxy. “29s timeout” → async with SQS. “Reduce API cost” → HTTP API. “Eliminate cold starts” → Provisioned Concurrency. “Serverless + SQL” → Aurora Serverless + RDS Proxy.
SAA-C03	Basic pattern: API GW → Lambda → DynamoDB. Auth: Cognito. “Cheapest” → HTTP API + DynamoDB on-demand. “Key-value at scale” → DynamoDB. “Complex queries” → Aurora.

AWS Certification Exam Practice Questions

Question 1:

A serverless application uses Lambda functions and an Amazon RDS PostgreSQL database. Under peak load, the application returns intermittent 5xx errors. CloudWatch shows Lambda concurrency reaching 500 while RDS shows max connections exhausted. What is the MOST operationally efficient fix?

1. Increase the RDS instance size to allow more connections
2. Add Amazon RDS Proxy between Lambda and the database
3. Reduce Lambda reserved concurrency to 50
4. Replace RDS with DynamoDB

Show Answer

Answer: B — RDS Proxy maintains a connection pool and multiplexes hundreds of Lambda connections into a small number of actual database connections. This solves the connection exhaustion without changing application code, reducing Lambda concurrency (which affects throughput), or migrating databases. It’s the purpose-built solution for Lambda-RDS scaling.

Question 2:

A company’s API Gateway REST API costs $10,000/month due to high request volume. Most requests (80%) hit the same 5 endpoints with identical responses for any given 5-minute window. The team wants to reduce costs without changing the application. What should they do?

1. Enable API Gateway caching with a 300-second TTL
2. Switch from REST API to HTTP API
3. Add CloudFront in front of API Gateway with caching
4. Move to Application Load Balancer with Lambda targets

Show Answer

Answer: A — API Gateway caching (REST API) caches responses for the specified TTL. With 80% of requests being cacheable with 5-minute TTL, cache hits don’t invoke Lambda and reduce both API GW request charges and Lambda invocation costs by up to 80%. Switching to HTTP API saves 70% on per-request cost but still invokes Lambda for every request. CloudFront also works but adds complexity.

Question 3:

A serverless API has a Lambda function that takes 45 seconds to process complex report generation requests. Clients receive timeout errors. The API must return results to the client. Which architecture solves this?

1. Increase API Gateway timeout to 60 seconds
2. Use API Gateway → SQS → Lambda (async). Return 202 with task ID. Client polls a separate status endpoint for results.
3. Use Lambda Provisioned Concurrency to speed up processing
4. Switch to Application Load Balancer (120s timeout) with Lambda target

Show Answer

Answer: B — API Gateway has a hard 29-second timeout (cannot be increased). The async pattern: accept the request immediately (202 + task ID), process in background via SQS → Lambda, client polls a GET /status/{taskId} endpoint. ALB has 900s timeout which works technically but the question specifies serverless architecture. The async pattern is the AWS-recommended approach for long-running serverless operations.

Question 4:

A mobile app needs user authentication with social login (Google, Facebook), MFA, and email verification. After authentication, users access an API Gateway API. Which is the SIMPLEST authentication setup?

1. Lambda Authorizer that validates OAuth tokens from social providers
2. Amazon Cognito User Pool with social identity providers, configured as API Gateway authorizer
3. IAM authentication with Cognito Identity Pool for temporary credentials
4. Custom authentication microservice on ECS behind the same API Gateway

Show Answer

Answer: B — Cognito User Pool natively supports social login (Google, Facebook, Apple), MFA, email verification, and issues JWT tokens. API Gateway validates JWTs from Cognito directly without invoking Lambda for auth. This is the simplest managed solution — no custom code for authentication logic. Lambda Authorizers work but require custom code to validate each provider’s tokens.

Question 5:

A DynamoDB table serves a serverless API. Traffic is highly spiky — near zero at night, 50,000 WCU during flash sales (lasting 30 minutes, 2-3 times per month). The table currently uses provisioned capacity with auto-scaling but users experience throttling during the first minutes of each flash sale. What change eliminates the throttling?

1. Pre-scale the table manually before each flash sale
2. Switch to DynamoDB on-demand capacity mode
3. Increase the auto-scaling target utilization to 90%
4. Add DynamoDB Accelerator (DAX) for write caching

Show Answer

Answer: B — DynamoDB on-demand mode instantly accommodates up to double the previous peak throughput. It handles spiky, unpredictable workloads without throttling or pre-provisioning. Auto-scaling (provisioned) takes 5-15 minutes to react — too slow for sudden flash sales. DAX caches reads, not writes. Manual pre-scaling works but has operational overhead and requires knowing the exact timing.

Related Posts

• SQS Standard vs FIFO – Differences, Ordering & When to Use
• Event-Driven Serverless Architecture
• SNS vs SQS vs EventBridge
• Lambda Durable Functions
• Container Platform Architecture
• Aurora vs RDS vs DynamoDB

References

• Lambda Best Practices — AWS Docs
• Lambda Performance Optimization — AWS Compute Blog
• Using RDS Proxy with Lambda — AWS Blog
• HTTP API vs REST API — API Gateway Docs
• Well-Architected Serverless Applications — AWS Blog

Frequently Asked Questions

When should I use serverless vs containers?

Use serverless (Lambda) for event-driven, short-duration tasks (<15 min), variable traffic with periods of zero load, and when you want zero infrastructure management. Use containers (ECS/EKS) for long-running processes, consistent high throughput, specific runtime requirements, or when you need persistent connections (WebSocket servers, gRPC).

What is the difference between HTTP API and REST API?

HTTP API is 70% cheaper, lower latency, and simpler — supports JWT auth, Lambda/HTTP integrations, and CORS. REST API adds caching, usage plans/API keys, request/response transformation, WAF integration, and resource policies. Use HTTP API unless you specifically need a REST API feature.

How do I handle tasks longer than 29 seconds?

API Gateway’s maximum timeout is 29 seconds (hard limit). For longer tasks: (1) Accept request and return 202 immediately, (2) Process asynchronously via SQS → Lambda or Step Functions, (3) Client polls a status endpoint or receives a WebSocket/callback notification when complete. This is the standard async API pattern.