Introduction
Provisioning servers, patching operating systems, and scaling infrastructure for traffic spikes eats up engineering hours that could go towards building actual features. Many teams struggle with exactly this: keeping servers running and secure, even when the application only needs to process a handful of events a day.
AWS Lambda addresses this by letting you run code in response to events, without owning or managing the underlying servers. Serverless still runs on real servers; AWS manages them on your behalf. Datadog's 2025 report found that 65% of its observed AWS customer base already uses Lambda in some capacity.
This article covers how Lambda works, why organisations adopt it, common use cases, how it compares with EC2, cost considerations, and what you need to operate it reliably in production.
Key Takeaways
- Lambda runs your code in response to events and automatically provisions the compute capacity it needs.
- Billing is based on requests and execution duration, but your total architecture cost depends on connected services too.
- Event-driven and variable workloads suit Lambda well; long-running or specialised workloads often don't.
- Security, permissions, retries, and downstream capacity planning remain your responsibility, not AWS's.
What Is AWS Lambda and How Does Serverless Computing Work?
AWS Lambda is a serverless compute service: you upload code, define what triggers it, and Lambda runs it. There's no virtual machine to boot, no operating system to patch, and no idle server racking up charges while it waits for traffic.
This is what's known as Function as a Service (FaaS): compute delivered as small, triggered units of logic rather than an always-on application server. A traditional VM runs continuously whether it's handling requests or not. A Lambda function exists only to execute, then stops.
The Function Lifecycle: Handler, Event, and Context
Every Lambda function has three core components:
- Handler: the entry point Lambda calls when your function is invoked
- Event payload: the input data describing what triggered the function (an S3 object key, an API request body, a queue message)
- Execution context: runtime metadata passed automatically, such as the request ID and remaining execution time
AWS documents the current list of supported runtimes and deployment options (ZIP packages and container images) on its runtimes page, which is worth bookmarking since supported versions change over time.
Why Lambda Is Called "Event-Driven"
An event occurs somewhere: a file lands in an S3 bucket, an API Gateway request arrives, a message hits an SQS queue, a DynamoDB table changes, or an EventBridge schedule fires. Lambda creates or reuses an execution environment, runs your handler against that event, and then shuts down (or freezes the environment for reuse).
This sequence repeats for every invocation, which is why Lambda functions are typically stateless: nothing is guaranteed to persist between runs. For actual persistence, functions lean on services like S3, DynamoDB, RDS, ElastiCache, or a queue.
One of our own internal workflows, an automated data-ingestion pipeline built for an outdoor sports equipment manufacturer, used exactly this pattern: Lambda functions triggered on incoming data, with S3 holding both raw and processed files.
How AWS Lambda Works: Events, Execution, Scaling, and Integrations
Understanding the mechanics matters once you move past a simple test function.
Invocation Types
| Invocation type | What happens |
|---|---|
| Synchronous | Caller waits for the response; the caller handles retries on failure |
| Asynchronous | Lambda queues the event and responds immediately; Lambda manages retries |
| Event source mapping | Lambda polls a stream or queue, batches records, and invokes the function |
These aren't interchangeable. An API Gateway request is typically synchronous because the user is waiting. An S3 upload notification is asynchronous. An SQS or Kinesis trigger uses event source mapping, which behaves differently from both.
Scaling, Concurrency, and Cold Starts
Lambda scales automatically, but not infinitely. The default regional concurrency limit is 1,000 concurrent executions per account, shared across every function in that account, according to AWS Lambda quotas. New accounts sometimes start with lower limits. Functions also scale at a capped rate rather than instantly absorbing unlimited traffic.
Cold starts happen when Lambda has to initialise a fresh execution environment: downloading code, starting the runtime, and running any setup logic before your handler executes. Factors that affect duration include:
- Package size and number of dependencies
- Runtime choice (compiled languages generally start faster than interpreted ones with heavy imports)
- VPC networking configuration
- Provisioned concurrency settings that keep environments pre-warmed
Common Integrations
Lambda rarely operates alone. A typical pattern is an invoice landing in S3, a Lambda function validating and transforming it, then writing the result to a database or pushing it to a queue for the next processing step.
Lambda commonly pairs with:
- API Gateway for serverless APIs
- S3 for object-triggered processing
- DynamoDB Streams for reacting to data changes
- SQS and SNS for decoupled messaging
- EventBridge for scheduled or cross-service events
- Kinesis for streaming data
- Step Functions for multi-step orchestration
- CloudWatch for logging and monitoring
Benefits, Use Cases, and Practical Trade-Offs of AWS Lambda
Why Teams Choose Lambda
The appeal comes down to a handful of concrete benefits:
- No server administration — AWS handles patching and capacity
- Automatic scaling that matches demand without manual intervention
- Fast deployment cycles since there's no infrastructure to stand up first
- Pay-per-use billing instead of paying for idle capacity
- Native integration with the broader AWS ecosystem
- Isolation of business logic into small, independently deployable units
Where It Fits in Practice
Common Lambda use cases include:
- Serverless APIs and event-driven microservices
- Document and image processing
- Scheduled automation and data transformation pipelines
- Stream processing, notifications, and webhooks
For enterprises handling compliance-heavy document workflows, this maps cleanly to event-driven design. We've automated shipping bill and bill of entry invoice operations for a construction company, replacing manual handling with triggered processing.
GST data, bank statements, and invoice records are frequent candidates for the same pattern. They arrive intermittently and need consistent, rules-based handling rather than a server running around the clock.
Cost Considerations
Lambda bills for requests and execution duration, which makes it attractive for intermittent or unpredictable workloads where an always-on server would sit idle most of the time. But the total bill depends on more than invocation count:
- Memory allocation (duration is billed per GB-second)
- Logging volume sent to CloudWatch
- Data transfer between services
- Add-ons like provisioned concurrency
Check current rates on AWS Lambda pricing before estimating — regional rates and billing units change.
The Trade-Offs Worth Knowing
Lambda isn't free of complexity:
- Cold-start latency can affect user-facing workloads with tight response times
- Standard invocations time out at 15 minutes, which rules out long batch jobs
- Statelessness pushes persistence logic onto other services
- Distributed architectures are harder to debug than a monolith
- Moving fully serverless increases dependence on AWS-specific services
- Concurrency limits need active planning, not assumption
Cygnet.One is an AWS Advanced Tier Partner that helps enterprises design event-driven Lambda workflows, cloud migration paths, and digital automation as part of broader modernisation programmes.
AWS Lambda vs EC2: Which Compute Option Is Appropriate?
Lambda and EC2 solve different problems, and the choice usually comes down to how predictable and long-running your workload is.
| Dimension | AWS Lambda | Amazon EC2 |
|---|---|---|
| Infrastructure management | AWS handles servers, patching, capacity | You manage the OS, patching, and scaling |
| Billing model | Per request plus execution duration | Per hour or second of instance uptime |
| Execution duration | Capped at 15 minutes for standard invocations | No inherent limit: runs continuously |
| Scaling | Automatic, within account and regional quotas | Managed via Auto Scaling groups |
| Runtime control | Limited to supported runtimes or containers | Full control over OS and software stack |
| Best for | Event-driven, short-lived, variable workloads | Sustained, predictable, specialised workloads |
When Lambda Makes Sense
Choose Lambda when the workload is event-driven, traffic is variable, processing is short-lived, or you're building lightweight APIs and scheduled jobs that don't justify an always-on server.
When EC2 or Containers Make More Sense
Reach for EC2 or a container platform when you need long-running processes, sustained high utilisation, specific operating system requirements, persistent applications, GPU access, or granular control over networking and infrastructure.
Quick decision checklist:
- Can the workload be broken into discrete, triggered functions? Lean Lambda.
- Does the process run continuously or need custom OS-level configuration? Lean EC2 or containers.
- Is traffic unpredictable or bursty? Lambda's automatic scaling helps.
- Does the task exceed 15 minutes per execution? EC2, containers, or Lambda Managed Instances are better fits.
Always verify current limits and pricing on AWS's official documentation before finalising architecture decisions. Both services update quotas and rates periodically.
Getting Started and Operating AWS Lambda Reliably
Your First Function
- Create or access an AWS account and open the Lambda console
- Choose a runtime supported by AWS (check the current list, since versions change)
- Create a function and write or upload your handler code
- Define an execution role with the permissions the function actually needs
- Add a test event matching the format your trigger will send
- Deploy and invoke the function manually to confirm it runs
- Review the result in CloudWatch Logs to check output and errors
Production-Readiness Checklist
A working test function isn't the same as a production-ready one. Before going live, confirm:
- IAM permissions follow least-privilege, not broad access
- Secrets are stored in a secrets manager, not hardcoded
- Timeouts and memory are sized for the actual workload
- Retry behaviour and dead-letter destinations are configured for failed invocations
- Function logic is idempotent, since duplicate event delivery can and does happen
Monitoring and Cost Control
Use CloudWatch metrics for invocations, duration, errors, and throttles. For multi-service workflows, distributed tracing (AWS X-Ray) helps pinpoint where a request slows down or fails.
On the cost side:
- Right-size memory allocation instead of over-provisioning by default
- Trim unnecessary initialisation code and dependencies
- Set concurrency limits to avoid runaway invocation costs
- Configure billing alerts so unexpected spikes don't go unnoticed
Before calling the architecture done, test it under realistic conditions — duplicate events, a downstream service going offline, timeouts, and partial failures. These scenarios reveal gaps that a clean test run never will.
Frequently Asked Questions
What is the correct way to use a Lambda function?
A well-built Lambda function performs one focused task, receives a clearly defined event, and runs with least-privilege permissions. It should handle retries safely and rely on external services like S3 or DynamoDB for any state that needs to persist.
Why use Lambda instead of EC2?
Lambda removes server management and scales automatically in response to events, while EC2 gives you full control over a persistent server at the cost of ongoing maintenance. The right choice depends on whether your workload is event-driven and variable, or continuous and predictable.
What is AWS Lambda and why is it used?
AWS Lambda is a serverless compute service that runs code in response to triggers like API requests, file uploads, or scheduled events. Teams use it to cut infrastructure management and build APIs, automation, and data processing pipelines that scale automatically.
Is AWS Lambda serverless computing?
Yes, Lambda is AWS's serverless compute service. "Serverless" means AWS manages the underlying servers, not that servers don't exist.
Does Netflix use Lambda?
AWS's own Lambda customer resources state that Netflix was planning to use Lambda to build rule-based, self-managing infrastructure: this confirms an announced plan, not a specific production claim. Large enterprises typically run multiple AWS services across different workloads rather than relying on just one.
