A deep
dive into AWS Lambda with API Gateway.
This is the most common entry point
for building serverless APIs.
View:
- Concepts,
- Patterns,
- Architecture,
- Security,
- Performance,
- Operations.
Core Concepts
- Amazon API Gateway: Fully managed service for creating REST,
HTTP, and WebSocket
- APIs. It Handles request routing, throttling, caching,
authentication, and monitoring.
- AWS Lambda:
its Event-driven,
serverless compute service, executes code in response to events
(like an HTTP request via API
Gateway).
- No servers to manage,
scales automatically, and twtech
only pay for execution time.
When combined: Lambda plus API Gateway
API
Gateway will act as the "front door" (routing, auth, transformation).
Lambda
will execute business logic.
Together(AWS Lambda with API Gateway), they form a serverless microservice/API pattern.
Request Flow (Deep Dive)
- Client Request:
User hits https://api.twtechapp.com/resource. - API Gateway Processing:
- Matches resource & method (/resource → GET).
- Handles authentication/authorization (IAM, Cognito, JWT, API keys, custom
authorizers).
- Applies request validation & throttling.
- Optionally transforms request payload using Mapping
Templates (VTL).
- Lambda Execution:
- Lambda receives event payload in JSON (includes method, headers, body, path
params).
- Executes code (Python,
Node.js, Go, Java, etc.).
- Connects to backend services (DynamoDB, RDS, S3, Step Functions, etc.).
- Returns response object.
- API Gateway Response Handling:
- Can map Lambda’s response to client-facing response.
- Handles errors (4xx, 5xx).
- Optionally cache responses in API Gateway Cache.
- Client Receives Response.
Common Architectural
Patterns
- CRUD over DynamoDB
API Gateway → Lambda → DynamoDB
(for simple REST APIs with low ops overhead). - Request/Response Transformation
Use mapping templates to transform XML ↔ JSON or strip headers. - Authentication via JWT/Cognito
API Gateway → Lambda Authorizer (JWT validation) → Lambda backend. - WebSocket APIs
Real-time communication: API Gateway WebSocket → Lambda → backend. - Lambda Proxy Integration
Simplest: API Gateway forwards entire HTTP request to Lambda.
(twtech handles parsing headers/body yourself).
Security Considerations
- Authentication: Use
Cognito User Pools, OIDC providers,
or Lambda authorizers for JWT
validation.
- Authorization: Use IAM
policies, resource policies, or fine-grained
access control.
- Rate Limiting & Throttling: API Gateway enforces
per-client quotas.
- WAF
(Web Application Firewall):
Protects
against SQLi/XSS, bot traffic.
- VPC Access: Lambda can run
in private subnets to connect to RDS/ElastiCache.
Performance &
Scaling
- Cold Starts:
- Lambda "cold start" latency (10–300ms depending on runtime &
VPC).
- Mitigations: Provisioned Concurrency, lighter runtimes
(Node.js, Go).
- Throughput:
- API Gateway scales to tens of thousands of
requests/sec.
- Lambda concurrency is regional (default 1,000, can request quota increases).
- Caching:
- API Gateway cache can reduce Lambda invocations.
- DynamoDB Accelerator (DAX) can help with hot reads.
- Payload Limits:
- API Gateway max payload: 10 MB (REST/HTTP), 128 KB (WebSocket).
- For larger payloads, use S3 pre-signed URLs.
Observability &
Operations
- Logging:
CloudWatch Logs for both API
Gateway and Lambda.
- Tracing:
AWS X-Ray for distributed tracing.
- Metrics:
API Gateway provides latency,
4xx/5xx counts; Lambda provides duration, invocations, errors.
- CI/CD:
Commonly automated via SAM(Serverless
Application Model),
CDK, Terraform, or Serverless Framework.
- Testing:
Use Postman/Insomnia for API
testing, or AWS Console Test tool.
Example High-Level Architecture
Client →
API Gateway → Lambda → DynamoDB
↘ S3
↘ SNS/SQS
↘ RDS (via VPC)
In summary:
- API Gateway =
managed API frontend (routing, auth, throttling, caching).
- Lambda
= serverless backend logic (stateless, scales instantly).
- Together(AWS Lambda with API Gateway) they form the foundation of AWS serverless microservices.
twtech insights:
CI/CD, or Continuous Integration
and Continuous Delivery/Deployment,
is a set of practices in
software development that automates the stages of building, testing, and
deploying applications.
The automation process aims to accelerate the release cycle, improve code quality, and reduce manual errors.
The statement "Commonly automated via SAM" refers to the role of AWS Serverless Application Model (SAM) in
facilitating CI/CD for serverless applications.
While SAM itself is not a full-fledged CI/CD system, it plays a crucial role in defining, developing, and deploying serverless applications on AWS.
Here's how AWS
SAM integrates with CI/CD:
Application Definition:
SAM provides a simplified way to define serverless
applications using a YAML or JSON template. This
template describes the AWS resources, such as Lambda functions, API Gateways,
and DynamoDB tables, that make up the application.
Local Development and Testing:
The AWS SAM CLI allows developers to build, test, and
debug serverless applications locally before deploying them to the cloud. This significantly speeds up the development
process.
Deployment Integration:
AWS SAM integrates with various CI/CD systems like AWS
CodePipeline, Jenkins, GitLab CI/CD, and GitHub Actions. These systems can leverage SAM's capabilities to
automate the deployment of serverless applications to different environments
(e.g., development, staging, production).
Pipeline Templates:
SAM offers starter pipeline templates for common CI/CD systems, providing a quick and easy way to set up automated deployment pipelines that incorporate AWS deployment best practices.
In essence:
AWS SAM simplifies
the development and deployment of serverless applications, making it easier to
integrate them into automated CI/CD pipelines.
CI/CD systems
orchestrate the overall automation,
SAM provides the framework for defining and deploying the serverless components within that pipeline.
No comments:
Post a Comment