What is serverless?
A paradigm where developers don’t manage servers—only deploy code.
Typically involves deploying functions (FaaS).
Originated with AWS Lambda; now includes managed services like databases, messaging, storage.
Servers still exist—you just don’t provision, manage, or see them.
What AWS services are commonly used in a serverless architecture?
Lambda
DynamoDB
Cognito
API Gateway
S3
SNS & SQS
Kinesis Data Firehose
Aurora Serverless
Step Functions
Fargate
Typical flow:
Users → S3 (static content)
Users → API Gateway → Lambda → DynamoDB
Users → Cognito (login)
Why choose AWS Lambda over EC2?
EC2:
Virtual servers in the cloud
Limited by RAM/CPU
Always running
Scaling requires manual intervention
Lambda:
Virtual functions with no servers to manage
Short, time-limited executions
Runs on-demand
Scaling is fully automated
What are the key benefits of AWS Lambda?
Simple pricing: pay per request/compute; generous free tier
Deep integration with AWS services
Supports many programming languages
Built-in monitoring via CloudWatch
Easy to scale function resources (up to ~10 GB RAM)
More RAM also boosts CPU and network performance
What languages and runtimes does AWS Lambda support?
Node.js
Python
Java
C# (.NET Core) / Powershell
Ruby
Custom runtimes (e.g., Rust, Go) via Runtime API
Container images that implement the Lambda Runtime API (use ECS/Fargate for general Docker workloads)
What does Amazon Cognito provide, and how do User Pools differ from Identity Pools?
Purpose: Gives users an identity to interact with web or mobile apps.
Cognito User Pools:
Handles user sign-in for app users.
Integrates with API Gateway & Application Load Balancer.
Cognito Identity Pools (Federated Identity):
Provide AWS credentials so users can access AWS resources directly.
Can use User Pools as an identity provider.
Cognito vs IAM: Best for hundreds of users, mobile users, and SAML authentication.
What features do Cognito User Pools provide for managing users in web and mobile applications?
Serverless user database
Username/email + password login
Password reset
Email & phone number verification
Multi-factor authentication (MFA)
Federated identities (Google, Facebook, SAML, etc.)
How do Cognito User Pools integrate with API Gateway and Application Load Balancer?
CUP issues tokens used to authenticate requests
API Gateway receives the token and validates it with Cognito
Application Load Balancer (ALB) can authenticate users using CUP
ALB listeners evaluate the Cognito token before routing traffic
Backend applications receive only authenticated requests
What does a Cognito Identity Pool provide, and how is it used?
Provides temporary AWS credentials for users
Users can come from Cognito User Pools or 3rd-party logins (Google, Facebook, SAML, etc.)
Allows direct access to AWS services (e.g., S3, DynamoDB) or via API Gateway
IAM policies are defined in the Identity Pool
Policies can be customized per user_id for fine-grained access control
Supports default IAM roles for authenticated and guest users
How does a Cognito Identity Pool provide users with temporary AWS credentials?
User logs in through a provider:
Cognito User Pool, Google, Facebook, SAML, etc.
The login provider returns a token
Identity Pool exchanges the token for temporary AWS credentials
These credentials allow direct access to AWS services (e.g., S3, DynamoDB)
Access is controlled by IAM roles assigned in the Identity Pool
How do Cognito Identity Pools enable row-level security in DynamoDB?
Identity Pools assign temporary AWS credentials to each authenticated user
IAM policies can include conditions based on the user’s identity (e.g., cognito-identity.amazonaws.com:sub)
DynamoDB item access can be restricted so users can only read/write their own items
Achieves fine-grained, per-user authorization without application-side filtering
What are the main ways AWS Lambda integrates with other AWS services?
API Gateway — invoke Lambda for REST/HTTP/WebSocket APIs
EventBridge / CloudWatch Events — cron, scheduled, and event-driven triggers
S3 — invoke Lambda on object creation or deletion
DynamoDB Streams — process item-level changes
SNS — process messages fan-out style
SQS — poll and process queue messages
Kinesis / Kafka — consume streaming data
Cognito — trigger Lambda on auth events
CloudFormation custom resources — Lambda-backed actions
How does the serverless thumbnail-creation workflow using AWS Lambda work?
An image is uploaded to Amazon S3
The S3 upload triggers a Lambda function
Lambda generates a thumbnail of the image
Lambda then:
Stores the new thumbnail in S3
Saves metadata (image name, size, creation date, etc.) in DynamoDB
Entire workflow is fully serverless and event-driven
How do you implement a serverless scheduled (CRON) job in AWS?
Create a CloudWatch Events / EventBridge rule
Configure it with a CRON or rate expression
The rule triggers a Lambda function on the schedule
Lambda runs the task (e.g., cleanup, reporting, automation)
Common example: run every 1 hour
How is AWS Lambda priced?
Pay per request
First 1M requests free
Then $0.20 per 1M requests
Pay per duration (billed per 1 ms)
First 400,000 GB-seconds free per month
Cost: $1.00 per 600,000 GB-seconds after free tier
Cost varies with memory size (more RAM = more CPU + network)
Lambda is typically very cheap because usage is event-driven & short-lived
What are the key AWS Lambda limits to know (per region)?
Execution Limits
Memory: 128 MB – 10 GB
Max runtime: 900 sec (15 min)
Env vars: 4 KB
/tmp storage: 512 MB – 10 GB
Concurrency: 1000 (increasable)
Deployment Limits
Deployment package (zip): 50 MB
Uncompressed size: 250 MB
Env vars size: 4 KB
How does AWS Lambda concurrency and throttling work?
Concurrency
Default regional concurrency: 1000
You can set reserved concurrency per function to limit or guarantee capacity.
Throttling Behavior
When concurrency is exceeded → Throttle
Synchronous invokes: return 429 ThrottleError
Asynchronous invokes: automatically retried, then sent to DLQ
To increase the limit: open a support ticket
What problem can occur if you don’t set reserved concurrency on a Lambda function?
How does AWS Lambda handle concurrency limits for asynchronous invocations?
If the function doesn’t have enough available concurrency, extra events are throttled.
When throttled (429) or on system errors (5xx), Lambda automatically retries.
Retry window: up to 6 hours.
Retry delay: exponential backoff from 1 sec up to 5 minutes.
Events are returned to the queue and reprocessed until successful or timeout.
What is a Lambda cold start, and how does Provisioned Concurrency prevent it?
Cold Start
Happens when a new Lambda instance is created.
Lambda loads code + dependencies and runs initialization.
First request to a new instance has higher latency.
Provisioned Concurrency
Pre-initializes Lambda instances in advance, so they’re always warm.
Ensures consistent low latency for all invocations.
Can be auto-scaled with Application Auto Scaling.
Cold starts in VPC were significantly reduced (Oct–Nov 2019).
What is the difference between Reserved Concurrency and Provisioned Concurrency in AWS Lambda?
Reserved Concurrency
Sets a hard limit on how many concurrent executions a function can use.
Guarantees that this amount is always available for that function.
Also prevents the function from consuming more than the reserved amount (protects other functions from being starved).
Provisioned Concurrency
Pre-initializes Lambda instances so they are always warm (no cold starts).
Ensures consistently low latency for all invocations.
Managed automatically through Application Auto Scaling.
What does AWS Lambda SnapStart do, and how does it improve performance?
Speeds up Lambda functions by up to 10x for Java, Python, and .NET.
Invokes functions from a pre-initialized snapshot instead of starting from scratch.
When you publish a new version:
Lambda initializes the function.
Takes a snapshot of memory + disk state.
Snapshot is cached for fast reuse.
Result: dramatically reduced initialization time → reduced cold start latency.
What does “Customization at the Edge” mean in AWS, and which services enable it?
Running application logic at AWS edge locations to reduce latency for end users.
Achieved using Edge Functions attached to CloudFront distributions.
Two AWS services enable this:
CloudFront Functions (lightweight, very fast)
Lambda@Edge (more powerful, supports deeper request/response manipulation)
No servers to manage; code runs close to users globally.
What is Lambda@Edge and what can you do with it?
A feature of CloudFront that lets you run Lambda functions at AWS edge locations.
Used to customize and modify CloudFront requests and responses.
Common capabilities:
Inspect/alter viewer requests (from users).
Modify origin requests (to the backend).
Adjust origin responses and viewer responses.
Helps with A/B testing, header manipulation, user authentication, URL rewrites, caching logic, and more.
Global execution with no servers to manage.