Lambda is the most tested service on the DVA-C02 exam. For those who are new to Lambda, let's start with the basics. Lambda is a service that lets you run code without managing servers yourself. Think of it as a "code vending machine" — just like putting in a coin (event fires) and getting the drink you want (code executes), you simply write your function without worrying about servers. This article explains, in beginner-friendly terms, what you need to know when actually developing and configuring Lambda.
Core Lambda Configuration
Environment Variables — Separating Code from Configuration
It's very dangerous to hard-code sensitive information like database passwords or API keys directly into your code. Environment variables are a way to inject these configuration values from outside the code. Think of it like keeping a restaurant menu and recipe separate — the code (recipe) stays the same, but you can change the configuration values (supplier information) independently. Using KMS (Key Management Service), you can encrypt environment variables for even more secure storage.
Lambda Layers — Sharing Common Libraries
Imagine multiple Lambda functions all use the same library (for example, an image processing library or common utilities). Including the same library in every function creates duplication and makes management harder. Lambda Layers packages commonly used libraries as a separate layer that multiple functions can share. It's like a company's shared supply room — teams don't each need to buy their own supplies; everyone uses shared resources.
Memory and Timeout
When running a Lambda function, you set two limits.
Memory can be configured from 128MB to 10,240MB (about 10GB). An important point: increasing memory proportionally increases CPU performance as well. If a function is slow, one approach is to increase the memory allocation.
Timeout is the maximum time a function can run, up to 15 minutes. Tasks that take longer than 15 minutes cannot be handled by Lambda alone, so you'll need to use Step Functions or another service.
Concurrency Models — How Multiple Requests Are Handled Simultaneously
When requests come in, Lambda automatically creates new execution environments to handle them in parallel. This is concurrency.
Reserved Concurrency
This is a way of pre-allocating a set number of concurrent executions to a specific function. For example, if you set Reserved Concurrency to 100 on a payment function, that function is always guaranteed 100 execution environments even when other functions are very busy. Setting it to 0 effectively disables the function completely — useful for stopping a specific function during maintenance.
Provisioned Concurrency
To understand this, you first need to know about cold starts. Lambda doesn't keep execution environments ready when there are no requests. When a request suddenly arrives, it needs to create a new environment, and this preparation time (the cold start) makes the initial response slower. Provisioned Concurrency pre-warms execution environments so that cold starts are eliminated. It costs more, but is appropriate for services where latency matters (for example, real-time financial transactions or games).
!Reserved versus Provisioned Concurrency
Cold Start vs Warm Start
A cold start is the preparation process Lambda goes through when it runs for the first time. It creates a new execution environment, downloads the code package, initializes the runtime (Python, Java, etc.), and only then runs the actual code (the handler). It's like the boot time when you first turn on a PC.
A warm start is when an already-prepared execution environment is reused. Only the handler runs, so it's very fast. It's like launching a program immediately on a PC that's already on.
There are three ways to reduce cold starts. First, use Provisioned Concurrency. Second, place database connection and initialization code outside the handler function — this allows the connection to be reused on warm starts. Third, keep the deployment package small. The less code there is to download, the faster the function starts.
Running Lambda in a VPC
A VPC (Virtual Private Cloud) is a virtual private network you create within AWS. If Lambda needs to access a database (like RDS) in a private subnet that is not directly accessible from outside, you need to connect Lambda to the VPC.
A Lambda connected to a VPC creates an ENI (Elastic Network Interface) — a virtual network card — in the VPC's subnet. This allows it to access resources within the same VPC.
One important note: a Lambda connected to a VPC cannot access the internet by default. If internet access is needed, you'll need to route through a public subnet that has a NAT Gateway, or use a VPC Endpoint.
Error Handling — What Happens When Things Fail
DLQ (Dead Letter Queue)
When a Lambda function that was invoked asynchronously fails, you can send that failure event to an SQS queue or SNS topic. This lets you analyze or reprocess the failure event later.
Lambda Destinations
This is a more powerful approach than DLQ. You can specify separate targets (SQS, SNS, Lambda, EventBridge) for when the function succeeds and when it fails. For example, you can configure it so that on success the next Lambda is invoked, and on failure an alert is sent to SNS — giving you flexible, granular control.
Exam Key Points
"Share common libraries across multiple functions" -- Lambda Layers
"Eliminate cold starts" -- Provisioned Concurrency
"Fix concurrent executions for a specific function" -- Reserved Concurrency
"Disable a function" -- Set Reserved Concurrency to 0
"Access RDS in VPC" -- Connect Lambda to VPC (needs ENI)
"VPC Lambda needs internet access" -- NAT Gateway required
"Handle async invocation failures" -- DLQ or Lambda Destinations
"Different targets for success vs failure" -- Lambda Destinations
Place initialization code outside the handler for connection reuse, which improves performance