Introduction#
AWS Lambda is often marketed as “run code without thinking about servers”. In reality, Lambda has a very concrete execution model, strict limits, and operational pitfalls that every Cloud or DevOps engineer should understand.
This article focuses on how AWS Lambda really works under the hood and what matters when you run it in production.
What AWS Lambda Really Is (and Is Not)#
AWS Lambda is an event-driven compute service. You upload code, configure a trigger, and AWS executes your function on demand.
Lambda is not:
- A general-purpose replacement for EC2
- Suitable for long-running or stateful workloads
- A black box you can ignore operationally
Lambda is:
- Stateless by design
- Optimized for bursty, short-lived workloads
- Tightly integrated with AWS services
Understanding this distinction avoids many architectural mistakes.
Lambda Execution Environment Explained#
Each Lambda invocation runs inside an execution environment.
Cold Starts vs Warm Starts#
- Cold start: AWS creates a new environment (slower)
- Warm start: Existing environment is reused (faster)
Cold starts are affected by:
- Runtime (Node.js, Python, Java, etc.)
- Package size
- VPC configuration
- Provisioned Concurrency (if enabled)
Execution Context Reuse#
Anything defined outside the handler may persist across invocations:
db = create_connection()
def handler(event, context):
db.query("SELECT 1")
This can improve performance — but never rely on it for correctness.
Memory, CPU and Performance#
Lambda pricing and performance scale with memory allocation.
Important detail:
More memory also means more CPU and network throughput.
This often means:
- 512 MB is slower and more expensive than 1024 MB
- Increasing memory can reduce total execution cost
Always benchmark critical functions with different memory settings.
Timeouts, Retries and Failure Modes#
Timeouts and retries are one of the most misunderstood Lambda topics.
Timeouts#
- Default timeout: 3 seconds
- Maximum timeout: 15 minutes
Always set timeouts explicitly.
Retries (Critical!)#
Retry behavior depends on the event source:
- Synchronous invocations: no automatic retry
- Asynchronous invocations: automatic retries
- SQS / Kinesis / DynamoDB Streams: retry until success or DLQ
This means:
A Lambda function may run multiple times for the same event.
Design functions to be idempotent.
Logging and Debugging AWS Lambda#
CloudWatch Logs#
Every Lambda invocation automatically writes logs to CloudWatch:
print("Processing event")
Best practices:
- Use structured logging (JSON)
- Log request IDs and key identifiers
- Avoid excessive logging in hot paths
AWS X-Ray#
X-Ray can help with:
- Tracing downstream calls
- Latency analysis
But:
- Adds overhead
- Not always worth enabling for simple functions
Use it selectively.
Security and IAM Gotchas#
IAM Permissions#
Lambda runs with an IAM execution role. Follow least-privilege principles:
- Separate roles per function
- Avoid wildcard permissions
- Audit policies regularly
Secrets Handling#
Avoid:
- Hardcoded secrets
- Plain environment variables for sensitive data
Prefer:
- AWS Secrets Manager
- AWS SSM Parameter Store
VPC Lambdas#
Running Lambda inside a VPC:
- Increases cold start time
- Requires careful networking setup
Use only when necessary (e.g., private RDS access).
Cost Model Explained (With Reality in Mind)#
Lambda pricing consists of:
- Invocation count
- Execution duration
- Memory allocation
Lambda becomes expensive when:
- Functions run frequently with long durations
- High-throughput, low-latency APIs
- Poor memory sizing
Always compare:
- Lambda vs Fargate
- Lambda vs EC2 for steady workloads
When NOT to Use AWS Lambda#
Lambda is the wrong choice for:
- Long-running batch jobs
- Stateful applications
- Ultra-low latency APIs
- Heavy CPU-bound workloads
In these cases, EC2 or containers are often simpler and cheaper.
Final Thoughts#
AWS Lambda is a powerful tool — when used correctly. Most production issues come not from Lambda itself, but from misunderstandings about its execution model, retries, and limits.
Treat Lambda like any other production compute platform:
- Observe it
- Secure it
- Test it under load
Need Help with AWS or Cloud Operations?#
If you need support designing or operating AWS Lambda, cloud-native architectures, or Linux-based workloads,
visit https://techz.at — we help teams build and run reliable production systems.