2.1.1.2. Lambda Execution Environment & Runtime
2.1.1.2. Lambda Execution Environment & Runtime
First Principle: Lambda's execution environment provides a secure, isolated, and managed runtime for your code, abstracting server operating systems and simplifying dependency management.
When Lambda invokes your function, it creates an isolated execution environment with your chosen runtime (Python, Node.js, Java, etc.), your code, and any dependencies. Understanding this environment is critical for optimizing performance.
Memory drives everything. You configure memory (128 MB to 10 GB), and CPU scales proportionally. A function with 1,769 MB gets one full vCPU. This means CPU-bound functions run faster with more memory — even if they don't need the extra RAM. This is one of the most common optimization questions on the exam.
Each environment gets /tmp storage (512 MB by default, up to 10 GB) for temporary file processing. This space is ephemeral — it persists across warm invocations of the same environment but vanishes when the environment is recycled.
Lambda Layers let you package shared libraries separately from your function code. Instead of bundling a 50 MB ML library into every function, you deploy it once as a Layer and attach it to multiple functions. Container images (up to 10 GB) give you full control over the runtime environment when Layers aren't sufficient.
The execution context — the environment that persists between warm invocations — is where optimization lives. Database connections, SDK clients, and configuration loaded outside your handler function are reused across invocations, avoiding repeated initialization.
Handler and configuration: the handler setting (file.function) names the entry point; a Python handler is def lambda_handler(event, context) — event is the input payload and context carries runtime information such as the request ID and remaining time. Put environment-specific settings such as table names in environment variables rather than in code; a published version freezes its environment variables along with its code.
Layers in practice: layer contents are extracted to /opt and must suit the function's runtime — a layer of Python libraries can't be imported by a Node.js function. To share a layer version with other accounts, add a resource-based permission to it (aws lambda add-layer-version-permission).
VPC access: to reach private resources such as an RDS instance in a private subnet, attach the function to the VPC by choosing subnets and security groups (the execution role needs network-interface permissions, e.g. the AWSLambdaVPCAccessExecutionRole managed policy). A VPC-attached function has no public IP, so to call the internet it needs a route from its private subnet to a NAT gateway in a public subnet — an internet gateway, Elastic IP or security-group rule alone won't provide one.
Scenario: You're developing a Python Lambda function that needs to process a large image file (several MBs), requiring temporary local storage during processing. You also want to include a common Python library without bundling it directly in your function's deployment package.
⚠️ Exam Trap: Increasing Lambda memory also increases CPU proportionally. A function that's CPU-bound (not memory-bound) will run faster with more memory — even if it doesn't need the extra RAM. This is a common optimization question.
