This chapter covers serverless computing on AWS, a core concept tested in Domain 1 (Cloud Concepts) of the CLF-C02 exam. Understanding serverless is critical because it represents a fundamental shift in how applications are built and deployed, moving away from managing servers to focusing solely on code. This objective carries approximately 24% of the exam weight, and serverless questions appear frequently, often asking you to identify the correct service for a given use case or to distinguish serverless from traditional compute models. By the end of this chapter, you'll understand what serverless means, how AWS implements it with services like AWS Lambda, and how to choose the right serverless service for a scenario.
Jump to a section
Imagine you want to run a pop-up restaurant. With a traditional restaurant (on-premises servers), you must rent a building, buy kitchen equipment, hire staff, and pay rent even when closed. If you get busy, you can't instantly expand the kitchen; if slow, you still pay full costs. Serverless computing is like a food truck that can appear anywhere at a moment's notice. You don't own the truck; you just tell a food truck company (AWS) what you want to cook (your code) and how much you expect to sell (traffic). The company brings the truck, sets up, and scales the kitchen up or down automatically—if a lunch rush hits, they deploy more trucks; if it's a slow afternoon, they reduce to one. You only pay for the time the truck is actually cooking and serving customers. You never worry about cleaning the truck, repairing the engine, or hiring cooks—the company handles all that. Under the hood, AWS manages the servers, runtime, and scaling, just like the food truck company manages logistics. You focus entirely on your menu (code) and customer experience. That's serverless: you provide the code, AWS provides the infinitely scalable, zero-management execution environment, billing only for actual usage.
What is Serverless Computing and What Problem Does It Solve?
Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. The term "serverless" is a misnomer—servers still run your code, but you never have to think about them. You write and upload your code, and AWS handles everything needed to run and scale it. The core problem serverless solves is the operational overhead of managing infrastructure. In traditional on-premises or even IaaS (Infrastructure as a Service) setups, you must provision servers, install operating systems, apply patches, monitor health, and plan for capacity. This is time-consuming and error-prone. Serverless eliminates this by abstracting the server layer entirely.
How Serverless Works on AWS
AWS offers several serverless services, but the most foundational is AWS Lambda. Lambda lets you run code without provisioning or managing servers. Here's the mechanism:
You create a function: You write your code (in supported languages like Python, Node.js, Java, Go, etc.) and upload it to Lambda. You also configure a trigger—an event source that invokes your function.
AWS provisions execution environment: When an event occurs (e.g., an HTTP request via API Gateway, a file upload to S3, a message in SQS), Lambda automatically allocates a container with the specified memory (from 128 MB to 10,240 MB) and CPU proportional to memory. The runtime environment is initialized.
Code executes: Your function runs until it completes or times out (maximum 15 minutes). AWS scales horizontally by launching as many concurrent executions as needed, up to a regional default of 1,000 concurrent executions (can be increased).
Billing: You pay only for the compute time consumed, rounded to the nearest millisecond, plus requests. The first 1 million requests per month and 400,000 GB-seconds of compute time are free (Free Tier).
Key characteristics of AWS Lambda: - Event-driven: Functions are triggered by events from other AWS services or custom events. - Stateless: By default, Lambda functions are stateless—no data persists between invocations. You use external services like DynamoDB or S3 for state. - Short-lived: Maximum execution duration is 15 minutes (900 seconds). For longer-running workloads, use AWS Fargate or EC2. - Cold starts: When a function is invoked after being idle, AWS must initialize a new container, causing a slight delay (cold start). This can be mitigated with Provisioned Concurrency.
Key Serverless Services on AWS
Beyond Lambda, AWS offers a suite of serverless services that together form a full application platform:
AWS Fargate: A serverless compute engine for containers. You define your containerized application, and Fargate runs it without managing servers. Unlike Lambda, Fargate can run long-running, stateful, or heavy workloads. You pay for vCPU and memory resources allocated per second.
Amazon API Gateway: A fully managed service to create, publish, and secure APIs at any scale. It acts as a front door for Lambda functions or other backend services. It supports RESTful and WebSocket APIs.
Amazon S3 (Simple Storage Service): Object storage with a serverless interface. You can host static websites, store data, and trigger Lambda functions on events (e.g., object creation).
Amazon DynamoDB: A fully managed NoSQL database with single-digit millisecond latency. It is serverless—you don't provision servers, but you do provision read/write capacity (on-demand or provisioned).
Amazon SQS (Simple Queue Service): A fully managed message queuing service for decoupling application components. It is serverless and scales automatically.
Amazon SNS (Simple Notification Service): A pub/sub messaging service for sending notifications to subscribers. It is serverless.
AWS Step Functions: A serverless orchestration service to coordinate multiple AWS services into workflows. It uses state machines to define steps.
Amazon EventBridge: A serverless event bus that connects application data from your own apps, SaaS services, and AWS services.
Comparison to Traditional (On-Premises) and IaaS Approaches
| Aspect | On-Premises / IaaS | Serverless (Lambda) | |--------|-------------------|---------------------| | Provisioning | Manual, time-consuming | Automatic, instant | | Scaling | Manual or auto-scaling with lag | Automatic, fine-grained | | Pricing | Pay for provisioned capacity (idle included) | Pay only for usage (requests + duration) | | Maintenance | You manage OS, patches, security | AWS manages everything | | Execution time | Unlimited | Max 15 minutes | | State | Persistent (you control) | Stateless by design | | Cold start | Not applicable | Yes (first invocation after idle) |
When to Use Serverless vs Alternatives
Use serverless (Lambda) when: - Your workload is event-driven, intermittent, or unpredictable (e.g., processing S3 uploads, responding to API calls). - You want to reduce operational overhead and focus on code. - You have short-running tasks (under 15 minutes). - You need rapid scaling from zero to thousands of concurrent executions.
Use containers (ECS/Fargate) when: - You need long-running processes (e.g., web servers, batch jobs over 15 minutes). - You require custom runtime environments or specific dependencies not supported by Lambda. - You want more control over the execution environment (e.g., specific OS version, GPU).
Use EC2 when: - You need full control over the operating system, network, and security. - You have legacy applications that require a specific OS or configuration. - You need to run stateful applications with persistent local storage.
Pricing Models
AWS Lambda: Pay per request (first 1M free) and per GB-second of compute time (first 400,000 GB-seconds free). No charge when code is not running.
AWS Fargate: Pay per vCPU per hour and per GB of memory per hour, billed per second. You pay for the resources allocated, not usage.
API Gateway: Pay per API call and data transfer out. First 1M calls per month free (REST APIs).
DynamoDB: On-demand mode: pay per read/write request. Provisioned mode: pay for provisioned capacity per hour. Free tier includes 25 GB of storage and 25 RCU/WCU.
S3: Pay per GB stored, per request, and data transfer. Free tier includes 5 GB of S3 Standard storage.
Important Limits and Defaults for CLF-C02
Lambda execution timeout: 15 minutes (900 seconds).
Lambda temporary storage: 512 MB to 10,240 MB (ephemeral storage in /tmp).
Lambda concurrency limit: 1,000 per region (soft limit, can be increased).
Lambda function payload size: 6 MB (synchronous) and 256 KB (asynchronous).
Lambda deployment package size: 50 MB (zipped) and 250 MB (unzipped).
Lambda supported runtimes: Python, Node.js, Java, Go, Ruby, .NET, and custom (provided).
Fargate: Task definitions can run up to 12 hours (for ECS) but can be extended with ECS service scheduling.
API Gateway: Maximum integration timeout is 29 seconds.
DynamoDB: Item size limit is 400 KB.
Create a Lambda Function
1. Open the AWS Lambda console and click 'Create function'. Choose 'Author from scratch'. 2. Enter a function name, e.g., 'ProcessImage'. 3. Select a runtime, e.g., Python 3.12. 4. Choose an execution role—this is an IAM role that grants permissions to your function to access other AWS services (e.g., S3, DynamoDB). You can create a new role with basic Lambda permissions or use an existing one. 5. Click 'Create function'. AWS sets up the function with a default handler code that returns 'Hello from Lambda!'. Behind the scenes, AWS creates a secure execution environment, prepares a container, and attaches the IAM role. The function is now ready to be invoked but does not incur any cost until triggered.
Configure a Trigger (S3 Event)
1. In the Lambda console, under 'Function overview', click 'Add trigger'. 2. Select 'S3' from the dropdown. 3. Choose the S3 bucket that will trigger the function. 4. Select the event type, e.g., 'All object create events' (s3:ObjectCreated:*). 5. Optionally, specify a prefix or suffix filter to narrow which objects trigger the function (e.g., only .jpg files). 6. Acknowledge that the S3 bucket and Lambda function must be in the same region. 7. Click 'Add'. AWS now configures S3 to send a notification to Lambda whenever a new object is created in the bucket. Internally, S3 publishes an event to EventBridge or directly invokes the Lambda function (asynchronous invocation). The function will receive an event payload containing bucket name, object key, and metadata.
Write and Test the Function Code
1. In the Lambda console, scroll to the 'Code' tab. 2. Replace the default code with your logic. For example, a function that resizes an image and saves it to another S3 bucket: use the boto3 library to download the source image, use Pillow to resize, and upload the resized image. 3. Click 'Deploy' to save the code. 4. To test, create a test event by selecting 'Test' from the dropdown, then 'Create new test event'. Choose an S3 event template and customize the bucket name and object key. 5. Click 'Test'. Lambda executes the function with the test event. You can view logs in CloudWatch Logs. Behind the scenes, AWS allocates a container, runs your code, and returns the result or logs any errors. If the function times out or runs out of memory, you'll see an error. Adjust timeout and memory in the 'Configuration' tab.
Monitor and View Logs
1. After testing, go to the 'Monitor' tab in the Lambda console. 2. You'll see metrics like Invocations, Duration, Errors, and Throttles. 3. Click 'View logs in CloudWatch' to open the CloudWatch Logs console. Each invocation creates a log stream with timestamps, log messages, and any print statements from your code. 4. You can set up CloudWatch alarms based on metrics (e.g., error count > 0) to get notifications. 5. For production, consider using AWS X-Ray for tracing. CloudWatch Logs are automatically enabled; you pay for storage of log data. AWS retains logs indefinitely by default, but you can set expiration policies. Monitoring helps you debug cold starts, identify performance bottlenecks, and ensure your function is within timeout and memory limits.
Set Up Provisioned Concurrency (Optional)
1. If your function requires consistent low latency without cold starts, you can enable Provisioned Concurrency. 2. In the Lambda console, go to 'Configuration' > 'Concurrency'. 3. Under 'Provisioned concurrency configurations', click 'Add'. 4. Specify the number of concurrent executions to pre-warm (e.g., 10). 5. Choose an alias or version (e.g., $LATEST or a specific version). 6. Click 'Save'. AWS will immediately initialize that many execution environments, keeping them warm. You pay for the provisioned concurrency even when not in use (per GB-second). This is useful for latency-sensitive applications. Note that Provisioned Concurrency does not eliminate cold starts entirely for new instances beyond the provisioned count, but it ensures a baseline of warm capacity.
Real-World Scenarios
Scenario 1: Image Processing Pipeline A social media company allows users to upload profile photos. The upload goes to an S3 bucket. An S3 event triggers a Lambda function that resizes the image to multiple sizes (thumbnail, medium, large) and saves them to separate S3 buckets. The function also updates a DynamoDB table with metadata. This is fully serverless: no servers to manage, scales automatically with upload volume, and costs only when uploads occur. Misconfiguration: If the Lambda timeout is set too low (e.g., 3 seconds) for large images, the function will fail. The team must ensure timeout and memory are adequate. Also, if the IAM role lacks permissions to write to the destination buckets, the function errors.
Scenario 2: Real-Time File Processing A financial services company processes transaction files uploaded by customers. Files are uploaded to S3, triggering a Lambda function that parses the file, validates data, and inserts records into DynamoDB. If validation fails, the function sends a notification via SNS to an admin. This replaces a legacy batch system that ran on EC2 instances nightly. Benefits: no idle cost, instant processing, and automatic scaling during peak hours (e.g., month-end). Pitfall: If the Lambda function exceeds the 15-minute timeout for very large files, the processing fails. The team must split large files into smaller chunks or use Step Functions to orchestrate multiple Lambda invocations.
Scenario 3: Serverless Web Application Backend A startup builds a REST API for a mobile app. They use API Gateway to expose endpoints, each backed by a Lambda function. User authentication is handled by Amazon Cognito. Data is stored in DynamoDB. The entire backend is serverless. Cost is minimal during early stages with low traffic, and scales seamlessly as the user base grows. Misunderstanding: A developer might think Lambda can handle long-lived WebSocket connections, but API Gateway WebSocket API has a 10-minute idle timeout. For persistent connections, consider using AppSync or a dedicated service. Also, if the Lambda functions make multiple database calls without connection pooling, they may hit DynamoDB throttling. Using DAX (DynamoDB Accelerator) or optimizing queries is necessary.
Exam Focus for CLF-C02
1. What CLF-C02 Tests: The exam tests your understanding of serverless as a concept within Cloud Concepts (Domain 1, Objective 1.2: Compare and contrast cloud computing models). You must be able to:
Define serverless computing and its benefits (no server management, automatic scaling, pay-per-use).
Identify AWS serverless services: Lambda, Fargate, API Gateway, DynamoDB, S3, SQS, SNS, Step Functions, EventBridge.
Differentiate serverless from IaaS (EC2) and PaaS (Elastic Beanstalk).
Know Lambda's limits: 15-minute timeout, 1,000 concurrent executions (default), 6 MB synchronous payload, 256 KB asynchronous.
Understand that Lambda is event-driven and stateless.
Recognize that Fargate is serverless for containers, not Lambda.
2. Common Wrong Answers and Why Candidates Choose Them: - Wrong: "Serverless means no servers are used." Many candidates take the term literally. Reality: Servers exist but are managed by AWS. - Wrong: "Lambda can run any workload indefinitely." Candidates confuse Lambda with EC2. Reality: Lambda has a 15-minute timeout. - Wrong: "AWS Fargate is the same as Lambda." Both are serverless, but Fargate runs containers, not functions; it's for long-running or stateful workloads. - Wrong: "Serverless is always cheaper than EC2." For steady-state workloads, EC2 Reserved Instances can be cheaper. Serverless excels for variable or low-volume workloads.
3. Specific Terms and Values on the Exam: - Lambda timeout: 15 minutes (900 seconds) – often tested as a limit. - Lambda concurrency: 1,000 per region (default). - Lambda invocation modes: synchronous (e.g., API Gateway), asynchronous (e.g., S3), and poll-based (e.g., SQS). - Fargate launch type vs EC2 launch type for ECS. - DynamoDB on-demand vs provisioned capacity. - API Gateway endpoint types: edge-optimized, regional, private.
4. Tricky Distinctions: - Lambda vs Fargate: Both are serverless, but Lambda is for short-running functions (max 15 min), Fargate for containers (any duration). You choose Lambda for event-driven tasks; Fargate for microservices or batch jobs. - Lambda vs Elastic Beanstalk: Elastic Beanstalk is PaaS—you still manage the platform (e.g., OS updates) but not servers. Lambda is serverless—you manage nothing. - S3 vs EBS vs EFS: S3 is serverless object storage; EBS is block storage attached to EC2 (not serverless); EFS is file storage (can be used with Lambda but is not serverless itself).
5. Decision Rule for Multiple-Choice Questions: If the question describes a workload that:
Is event-driven (triggered by S3 upload, API call, etc.) → likely Lambda.
Runs longer than 15 minutes → not Lambda (use Fargate or EC2).
Requires custom OS or software → not Lambda (use EC2 or Fargate).
Needs to scale to zero when idle → serverless (Lambda or Fargate).
Is stateful or needs persistent local storage → not Lambda (use EC2 or Fargate with EFS).
Eliminate options that mention managing servers (EC2, on-premises) when the question emphasizes "no server management." Eliminate Lambda if execution time >15 minutes.
Serverless computing means the cloud provider manages servers; you only provide code or containers.
AWS Lambda is the core serverless compute service; max execution time is 15 minutes.
Lambda is event-driven and stateless; use external services for state (DynamoDB, S3).
AWS Fargate is serverless for containers, suitable for long-running or stateful workloads.
Other serverless services include API Gateway, DynamoDB, S3, SQS, SNS, Step Functions, and EventBridge.
Lambda concurrency default limit is 1,000 per region; can be increased via support.
Lambda pricing: pay per request and compute time; free tier includes 1M requests and 400,000 GB-seconds per month.
Serverless is ideal for variable, event-driven workloads; not always cheaper for steady-state high usage.
Cold starts occur when a Lambda function is invoked after being idle; Provisioned Concurrency reduces latency.
On the CLF-C02 exam, differentiate serverless from IaaS (EC2) and PaaS (Elastic Beanstalk).
These come up on the exam all the time. Here's how to tell them apart.
AWS Lambda
Runs functions (code snippets) up to 15 minutes.
Event-driven: triggered by AWS services or API calls.
Stateless; no local persistence (except /tmp).
Priced per request and per GB-second of compute.
Cold starts possible; mitigated by Provisioned Concurrency.
AWS Fargate
Runs containers (Docker images) with no time limit.
Continuous or long-running processes; not event-driven.
Can be stateful with persistent storage (EFS).
Priced per vCPU and memory allocated per second.
No cold starts; containers run continuously.
Mistake
Serverless means no servers are involved at all.
Correct
Servers are still used, but AWS manages them entirely. The user never provisions, patches, or monitors servers. The term 'serverless' refers to the user's experience—they do not see or manage servers.
Mistake
AWS Lambda can run any application, including long-running processes.
Correct
Lambda has a maximum execution timeout of 15 minutes (900 seconds). For longer-running processes, use AWS Fargate or EC2.
Mistake
Lambda functions are stateful and can store data locally between invocations.
Correct
Lambda functions are stateless by default. The /tmp directory provides temporary storage (up to 10,240 MB) but data is not persisted after the function finishes. Use DynamoDB, S3, or EFS for persistent state.
Mistake
AWS Fargate is the same as AWS Lambda, just for containers.
Correct
Fargate is a serverless compute engine for containers, but it runs continuously (like EC2) rather than being event-driven and short-lived. You pay for allocated resources per second, not per invocation.
Mistake
Serverless is always the cheapest option.
Correct
Serverless can be more expensive for steady-state, high-utilization workloads compared to reserved EC2 instances. It is cost-effective for variable, low-volume, or sporadic workloads.
The maximum execution timeout for AWS Lambda is 15 minutes (900 seconds). This is a hard limit. If your function runs longer, it will be terminated. For workloads exceeding 15 minutes, use AWS Fargate or EC2. On the exam, this is a common fact tested. Remember: Lambda is for short-running tasks.
Yes, AWS Lambda is a serverless compute service. You upload your code and AWS runs it on a fleet of servers that are fully managed. You do not provision, scale, or patch servers. You only pay for the compute time consumed. However, servers are still running underneath; you just don't manage them. The exam tests this concept: serverless does not mean no servers, but no server management.
Lambda runs functions (code) with a maximum 15-minute timeout, is event-driven, and is stateless by default. Fargate runs containers (Docker) that can run indefinitely, are not event-driven (you run them continuously), and can be stateful with persistent storage. Use Lambda for short, event-driven tasks; use Fargate for long-running or stateful containerized applications. Both are serverless.
Yes, you can configure a Lambda function to access resources in a VPC (e.g., RDS, ElastiCache) by attaching it to a VPC subnet and security group. However, this adds latency due to ENI (Elastic Network Interface) creation and may increase cold start times. Lambda functions in a VPC cannot access the internet unless you use a NAT gateway or VPC endpoints.
A cold start occurs when a Lambda function is invoked after being idle for a period, causing AWS to initialize a new execution environment (container). This adds latency (typically hundreds of milliseconds to a few seconds). To reduce cold starts, you can use Provisioned Concurrency, which keeps a specified number of environments warm. Cold starts are a key consideration for latency-sensitive applications.
Lambda pricing has two components: requests and duration. You pay per request (first 1 million per month free) and per GB-second of compute time (first 400,000 GB-seconds per month free). Duration is calculated from the time your function begins execution until it returns or terminates, rounded up to the nearest millisecond. You also pay for any additional resources like Provisioned Concurrency or data transfer.
The default regional concurrency limit for AWS Lambda is 1,000 concurrent executions. This is a soft limit that can be increased by requesting a quota increase via AWS Support. If your function invocations exceed this limit, they are throttled (you receive a 429 error). On the exam, remember the default value of 1,000.
You've just covered Serverless Computing on AWS — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?