AWS Lambda in practice: where it earns its keep, where it bites back, and how to keep your code portable

AWS Lambda has a specific place in our backend toolkit. The service rewards small, event-driven jobs where each invocation finishes quickly and does not depend on heavy local resources. When the workload matches that shape, Lambda is a productivity win and the operational overhead is close to zero. When the workload does not, Lambda becomes the source of the next problem you have to solve.

This article walks through one project where Lambda performed well in production, a second project where Lambda was the wrong tool, the wrapper-based pattern we use to keep our business logic portable, and the tradeoffs, alternatives, and decision checks we apply on every new build.

The workload fits Lambda almost perfectly. Each event is short, stateless, and independent, so cold starts add almost nothing to perceived latency. The downstream queue handles its own batching and rate management, so the Lambda never has to reason about backpressure. AWS scales the function automatically with traffic, billing reflects only the time the code spent running, and a comparable service running full-time on a small VM would cost more while sitting idle most of the day.

The inputs ranged from 50 MB to roughly 2 GB, with occasional outliers above that. We started at 3 GB of memory and worked our way up to the Lambda ceiling of 10,240 MB, and the largest files still produced out-of-memory errors. Execution times pushed past five minutes on the slow transformations, with several jobs timing out near the fifteen-minute hard cap. We spent meaningful engineering effort splitting the work into chunks just to fit it back inside the Lambda envelope.

The shape of the problem did not match the runtime. We eventually rebuilt the heavy portion of the pipeline on AWS Fargate, where a single container sized for the worst case could load the full file, transform it in place, and write the artifact in a single pass. The chunking machinery went away with it. The lesson is direct: if your workload has any meaningful chance of large inputs or long-running transformations, then Lambda is not the right home for the heavy step.

In practice, the split looks like this in our codebases:

// handler.ts (thin wrapper, AWS-specific)
import type { SQSEvent } from "aws-lambda";
import { processWebhook } from "./logic";

export async function handler(event: SQSEvent) {
  const input = parseEvent(event);
  return processWebhook(input);
}

// logic.ts (runtime-agnostic business logic)
export function processWebhook(input: WebhookInput): Result {
  // validation, normalization, side-effect orchestration
}

With that separation in place, migrating off Lambda becomes mostly a wrapper change. The handler that read an SQS payload becomes a handler that reads an HTTP request, a CLI argument, or a Kafka message. The business logic, where most of the engineering effort and most of the testing investment lives, moves to the new runtime without modification.

The pattern pays for itself even while you stay on Lambda. Pure functions are easy to unit test, because the test does not need to simulate an AWS event or stand up a mock runtime. The handler then becomes a small integration seam covered by a handful of targeted tests, rather than a tangle of business rules and AWS plumbing fighting each other in the test suite.

Lambda ties your code to the AWS ecosystem

Every Lambda function sits inside a web of AWS services. IAM holds the access policies, CloudWatch holds the logs, triggers come from EventBridge, SQS, S3, or API Gateway, and deployment usually runs through CloudFormation or one of its descendants. The same lock-in concerns we wrote about in our article on software vendor lock-in apply here: deployment tooling, IAM policies, observability, and event infrastructure all become AWS-specific, and a migration is rarely just a code move.

The account-level concurrency limit is real, and we have hit it

AWS enforces concurrency at the account and region level, not per function. The default quota starts at 1,000 concurrent executions per region. We have, to our surprise, hit our raised ceiling of around 4,000 invocations during client implementations. That ceiling throttled new invocations until the existing ones finished, and the throttling was observable to end users during a traffic spike. Before deploying Lambda for spiky workloads, verify your headroom and request quota increases ahead of launch.

Memory and execution-time ceilings bound what you can run

The 10,240 MB memory cap and the fifteen-minute execution limit are deliberate constraints of the runtime. Multi-gigabyte in-memory transformations, video transcoding, and long streaming model invocations will eventually exceed those limits. Recognize the constraint up front, and choose a different runtime for the heavy step.

Containers on Fargate, ECS, or Kubernetes

Containers are the right answer for workloads that need more memory, longer execution times, or warm in-memory state across requests. The container can be sized for the worst case rather than the average case, and it does not restart between invocations, so cold starts disappear from the latency budget.

AWS Batch and Step Functions for orchestrated batch jobs

When the workload really is a batch job, AWS Batch handles the queueing, retries, and lifecycle of the underlying compute. Step Functions can orchestrate multi-step workflows where each step runs on the runtime that fits it best, often with Lambda used for the lightweight steps and containers used for the heavy ones.

A small managed VM running a queue consumer

For sustained throughput, a managed VM with a long-running queue consumer is often cheaper and easier to reason about than the equivalent Lambda deployment. The consumer holds persistent database connections and in-memory caches that Lambda invocations cannot reuse efficiently across calls.

Cloudflare Workers for edge-latency workloads

Cloudflare Workers is a different shape of serverless runtime that fits workloads where latency to a global audience matters more than tight AWS integration. The tradeoff is that you commit to the Cloudflare ecosystem instead of the AWS one, with the same set of portability questions to answer.

If your team already operates a production container platform, whether ECS, Fargate, Kubernetes, or a self-managed cluster, then much of Lambda's operational advantage has already been realized. The platform team has already paid the cost of running production infrastructure, and adding Lambda on top does not remove that cost. It introduces a second runtime with its own concurrency quotas, deployment tooling, and observability story, while the original platform stays in place alongside it.

In that situation, deploying onto the existing container platform is often operationally simpler than introducing Lambda as a second runtime. The code itself still benefits from the wrapper pattern described earlier, because keeping the business logic portable costs almost nothing once it becomes habit. The production deployment, however, should run where the operational expertise already lives.

• How large is the worst-case input, and does the processing fit inside 10,240 MB of memory and fifteen minutes of execution time?
• How spiky is the traffic, and does the projected peak concurrency fit inside our current account quota with a comfortable margin?
• Does the workload need warm in-memory state, persistent connections, or local caches that are expensive to rebuild on every invocation?
• Is the rest of the system already deeply integrated with AWS, or is this the first AWS-specific component in the stack?
• Can the business logic be written as a pure function with typed input and typed output, so that the Lambda handler stays thin?

If your team is deciding between Lambda, containers, or queue workers for a new system, then we can help evaluate the tradeoffs before the architecture hardens. Reach out through our contact page with a short description of the workload, and we will work through it with you.