Serverless on AWS: When Lambda Is (and Isn't) the Right Choice

"Serverless" doesn't mean there are no servers — it means you don't manage them. With AWS Lambda, you deploy functions; AWS runs them on demand, scales them automatically and bills per request and execution time. For the right workloads it's remarkably efficient. For the wrong ones it adds cost and complexity.

My own hands-on AWS work has included static hosting on S3 behind CloudFront, IaC with CloudFormation, and Docker containers on EC2 backed by DynamoDB — which makes the trade-offs between these models very concrete.

Each component scales automatically and bills per use.

How Lambda Works

A function is triggered by an event: an HTTP request through API Gateway, a file uploaded to S3, a message on SQS, a schedule, or a DynamoDB stream. AWS creates an execution environment, runs the handler and keeps the environment warm for a while to serve later requests.

export const handler = async (event: APIGatewayProxyEventV2) => {
  const id = event.pathParameters?.id;
  const item = await db.get({ TableName: "Contacts", Key: { id } });
  return item.Item
    ? { statusCode: 200, body: JSON.stringify(item.Item) }
    : { statusCode: 404, body: "Not found" };
};

Where Serverless Shines

• Spiky or unpredictable traffic — scale from zero to thousands of concurrent requests without capacity planning.
• Event processing — resizing images on upload, processing queue messages, reacting to database changes.
• Scheduled jobs — nightly reports and clean-up tasks without an always-on server.
• Low-traffic APIs — pay nothing when idle.

The Limits

• Cold starts — the first request to a new environment is slower. Keep deployment packages small and initialise clients outside the handler.
• Execution time limit — 15 minutes maximum; long jobs belong in containers or Step Functions.
• Database connections — many concurrent functions can exhaust a relational database's connections; use RDS Proxy or a connection-pooling service.
• Cost at steady high load — continuously busy workloads are often cheaper on containers.
• Local development and debugging can be harder than for a single long-running service.

Serverless vs Containers

	Lambda	Containers (ECS/Fargate, Cloud Run, EC2)
Scaling	Automatic, per request	Automatic or manual, per instance
Idle cost	Zero	Pay for running instances
Long-running work	Up to 15 min	Unlimited
Control over runtime	Limited	Full

Many production systems combine both: containers for the core API, Lambda for events and scheduled tasks.

Practices for Production

• Define functions with IaC (AWS SAM, CDK or Terraform).
• Give each function its own least-privilege IAM role.
• Use dead-letter queues for failed asynchronous events.
• Make handlers idempotent, because events can be delivered more than once.
• Monitor duration, errors, throttles and cost per function.

Key Takeaways

• Lambda is ideal for spiky traffic, event processing and scheduled jobs.
• Plan for cold starts, time limits and database connection limits.
• Continuously busy workloads are often cheaper on containers.
• Use IaC, least-privilege roles, idempotent handlers and dead-letter queues.

Sources

• AWS Lambda — Developer Guide
• AWS — Serverless Application Lens (Well-Architected)
• AWS — Amazon RDS Proxy