AWS Lambda launched in November 2014, and it did something unusual for a cloud service: it removed a concept engineers had never questioned before — the server. Before Lambda, “deploying an application” meant provisioning a machine, keeping it patched, keeping it sized correctly, and keeping it running whether or not anyone was using it. Lambda’s pitch was blunt: give AWS a function, tell it what should trigger that function, and AWS will run it exactly as many times as needed and never bill you for idle time.

This idea did not appear from nowhere. Amazon had been running massive internal fleets of physical hosts for years, and teams inside Amazon had already been experimenting with event-driven internal tooling — small pieces of code reacting to internal events like file uploads or queue messages, rather than long-running services waiting for traffic. Lambda took that internal pattern, wrapped it in a public API, and connected it to the rest of AWS: S3 events, DynamoDB streams, API Gateway requests, and dozens of other triggers that arrived over the following years.

Since 2014, Lambda has evolved substantially: container image support, functions up to 15 minutes in duration, up to 10 GB of memory, Provisioned Concurrency for predictable cold-start-free performance, and SnapStart for faster Java cold starts. The core mental model, however, has stayed remarkably consistent, which is exactly why understanding the internals pays off — the concepts you learn here will still be true next year.

It’s also worth noting how Lambda reshaped the rest of AWS around it. Once Lambda existed as a first-class compute target, almost every other AWS service gained a way to trigger it — S3 got event notifications, DynamoDB got Streams, API Gateway was effectively built to give Lambda an HTTP front door, and EventBridge later arrived as a general-purpose event bus specifically so services (and your own applications) could route arbitrary events to Lambda without custom plumbing. Understanding Lambda well is, in a very real sense, understanding how a large slice of modern AWS architecture is wired together, because Lambda so often sits at the seam between two other services.

The term “serverless,” which Lambda popularized, is also worth being precise about. Servers obviously still exist somewhere — AWS operates enormous physical fleets underneath all of this. What “serverless” actually means, in Lambda’s context, is that you never provision, patch, or directly address an individual server; your unit of concern is the function and its configuration, and AWS handles everything below that line. This distinction matters because it clarifies what Lambda does and does not remove from your responsibilities, a theme this article returns to repeatedly.

To understand why Lambda exists, look at what it replaced. A typical pre-serverless backend needed a fleet of EC2 instances (or a container cluster) running continuously, an auto-scaling policy tuned by trial and error, a patching schedule, and capacity planning for traffic spikes that might happen twice a year. Most of that capacity sat idle most of the time — teams routinely over-provisioned by 3x to 5x just to survive a launch day or a Black Friday spike, and paid for that unused headroom every single hour.

Lambda’s motivation was to decouple “code that needs to run” from “infrastructure that must always exist.” The unit of deployment stopped being a server and became a function — a single-purpose piece of code with one job, triggered by one or more events, billed per invocation and per millisecond of execution.

Netflix uses Lambda extensively for encoding pipeline orchestration and operational automation, precisely because those workloads are bursty and event-driven rather than constant — exactly the shape Lambda was designed to fit. That’s the real motivation: not “serverless is always better,” but “some workloads are naturally event-shaped, and paying for constant capacity to serve bursty, unpredictable traffic is wasteful.”

There’s a second, less discussed motivation worth naming: reducing the surface area of undifferentiated heavy lifting. Every hour an engineering team spends patching an operating system, rotating AMIs, or tuning an auto-scaling group is an hour not spent on the product itself. Lambda’s promise was that this category of work — necessary, but not differentiating for almost any business — could be handed entirely to AWS, freeing teams to spend their engineering time on logic that actually matters to their users. This is also precisely why Lambda is not free of trade-offs: you’re trading some control over exactly how and where your code runs in exchange for that time back.

This section assumes you already know that Lambda “runs functions on events.” We’re skipping that basic layer and going straight into the concepts that actually separate a working Lambda architecture from a fragile one.

Execution Environment vs. Function Instance

An execution environment is the isolated sandbox — CPU, memory, temporary storage, and a runtime process — that AWS provisions to run your code. A “function instance” is really just one execution environment handling one invocation (or, with response streaming and careful design, sequential invocations) at a time. Two simultaneous invocations of the same function are handled by two separate execution environments, not one environment juggling two requests. This single fact explains almost every concurrency behavior Lambda has.

Concurrency, Not Threads

Lambda scales by creating more execution environments, not by adding threads inside one environment. If your function receives 200 simultaneous requests, Lambda (within account and function limits) will spin up roughly 200 separate execution environments to handle them in parallel. This is fundamentally different from a traditional server, which handles concurrency with threads or an event loop inside one process.

Cold Start vs. Warm Start

A cold start happens when no idle execution environment exists for an invocation, so Lambda must build one from scratch: download the code, start the runtime, run any module-level initialization code, and only then call your handler. A warm start reuses an execution environment that already exists from a previous invocation, skipping straight to the handler call. Cold starts typically add anywhere from tens of milliseconds to a few seconds depending on runtime, package size, and language — this single distinction drives a huge share of Lambda performance tuning.

One more intermediate-level distinction worth internalizing: synchronous versus asynchronous invocation. API Gateway invokes Lambda synchronously and waits for a response. S3 and SNS invoke Lambda asynchronously — Lambda queues the event internally and retries it automatically (twice, by default) if your function errors, completely independent of whatever originally produced the event. This retry behavior is invisible unless you know to look for it, and it has real implications for idempotency, which we’ll return to later.

There is a third invocation model, event source mapping, which behaves differently again. For poll-based sources like SQS, Kinesis, and DynamoDB Streams, Lambda doesn’t wait to be pushed an event at all — instead, a Lambda-managed polling process continuously reads from the source and invokes your function with a batch of records. This polling process has its own scaling and error-handling rules, entirely separate from the synchronous and asynchronous invocation models. For instance, with Kinesis and DynamoDB Streams, a batch that fails processing can, by default, block that shard’s processing until it succeeds or the records expire — a behavior that surprises engineers used to SQS, where a single bad message is far easier to isolate and skip.

Finally, don’t confuse the function’s configured timeout with the execution environment’s freeze duration. The timeout governs how long a single invocation is allowed to run before Lambda forcibly terminates it. The freeze duration governs how long an idle execution environment is kept around, ready for reuse, after a successful invocation completes — this is an internal AWS implementation detail that isn’t configurable and isn’t officially documented as a fixed number, which is exactly why you should never design a system that depends on precisely how long an environment stays warm.

A Lambda-based system is really a chain of managed components, each with its own scaling behavior and failure mode. Understanding the whole chain — not just “my function” — is what lets you reason about an incident at 2 a.m.

flowchart LR
  A["Event Sources
API Gateway / S3 / EventBridge / SQS"] --> B["Lambda Control Plane"]
  B --> C["Invoke Request"]
  C --> D["Execution Environment
(Firecracker MicroVM)"]
  D --> E["Runtime + Function Code"]
  E --> F["Downstream Services
DynamoDB / RDS / S3"]
  B --> G["IAM Execution Role"]
  D --> H["CloudWatch Logs & Metrics"]
    

Event sources are the systems that trigger invocation: API Gateway for HTTP requests, S3 for object events, EventBridge for scheduled or cross-service events, SQS and Kinesis for streaming/queued data, and dozens more. Each event source has its own invocation model (sync or async), its own retry policy, and its own payload shape — none of this is standardized across sources, which is a common source of confusion for teams jumping between them.

The Lambda control plane is the management layer — it handles function configuration, versioning, concurrency accounting, and deciding whether to reuse an existing execution environment or build a new one. The data plane is where your code actually executes, inside a Firecracker microVM (more on that in the next chapter). The execution role is a separate IAM component that determines what your function is allowed to do once it’s running — S3 read access, DynamoDB write access, VPC networking permissions, and so on.

CloudWatch Logs automatically captures everything your function writes to stdout/stderr, and CloudWatch Metrics automatically tracks invocation count, duration, error count, and throttle count with zero configuration required — this built-in observability is one of Lambda’s most underrated architectural advantages.

It helps to think of these components as sitting on either side of a boundary. Everything to the left of the execution environment — event sources, the control plane, throttling and concurrency accounting — is AWS-managed infrastructure you configure but never directly operate. Everything inside the execution environment — your code, your dependencies, your runtime version — is entirely your responsibility to build, test, and secure. Most Lambda-related production incidents fall cleanly into one side or the other, and recognizing which side you’re debugging saves significant time: a throttling error is a control-plane/concurrency problem, while a memory error is squarely your responsibility inside the sandbox.

One architectural nuance worth flagging for anyone working with event source mappings: SQS, Kinesis, and DynamoDB Streams don’t push events to Lambda the way API Gateway or S3 do. Instead, the Lambda service itself runs the poller on your behalf, reading batches from the source and calling your function synchronously with that batch. This means the “event source” box in the diagram above is really doing double duty for stream-based sources — it’s both the data source and, indirectly, the invocation trigger, mediated by a polling component you never see or manage directly.

Since 2018, Lambda has run every execution environment inside Firecracker, a lightweight virtualization technology AWS built and open-sourced specifically for this purpose. Firecracker microVMs start in well under 200 milliseconds and provide real hardware-level isolation — meaning one customer’s function cannot see or interfere with another’s, even though thousands of functions from different AWS accounts may run on the same physical host at the same moment.

flowchart TD
  Start["Invocation Request"] --> Check{"Warm Execution
Environment Available?"}
  Check -->|Yes| Warm["Reuse Existing MicroVM"]
  Check -->|No| Cold["Cold Start"]
  Cold --> Download["Download Code Package"]
  Download --> InitVM["Initialize Firecracker MicroVM"]
  InitVM --> InitRuntime["Start Runtime Process"]
  InitRuntime --> InitHandler["Run Init Code Outside Handler"]
  InitHandler --> Invoke["Invoke Handler Function"]
  Warm --> Invoke
  Invoke --> Response["Return Response"]
  Response --> Freeze["Freeze Environment for Reuse"]
    

After a handler returns, Lambda does not immediately destroy the execution environment. Instead it “freezes” it, keeping it available in case another invocation arrives within the next several minutes. This is why code written outside your handler — database connections, SDK clients, configuration loads — only runs once per environment, not once per invocation. Experienced engineers exploit this deliberately: initializing an expensive database connection pool at module load time means only cold-start invocations pay that cost, while warm invocations reuse the existing connection.

A subtlety that trips up intermediate engineers: because the environment is frozen (not terminated) between invocations, any background process you kicked off but didn’t wait for can resume mid-execution on the next invocation, sometimes producing strange, hard-to-reproduce bugs. Always fully await asynchronous work before your handler returns.

Firecracker’s design goal was specifically to make this kind of multi-tenant isolation cheap enough to do at Lambda’s scale. Traditional full virtualization (a complete guest operating system per customer) would be far too slow to start and far too resource-heavy to run millions of short-lived sandboxes economically. Firecracker strips a virtual machine down to the bare minimum needed for isolation and fast boot — no BIOS, no unnecessary emulated devices — while still relying on hardware virtualization extensions for genuine security isolation, not just process-level sandboxing. That combination is what lets AWS safely run workloads from thousands of different customers, with different trust levels, on the same physical hardware, invocation after invocation, without one tenant ever being able to observe another’s memory or execution.

Another internal detail worth understanding: Lambda enforces execution environment reuse per function version, not per function. If you publish a new version, invocations against the new version start cold, even if the previous version has plenty of warm environments sitting idle. This is one reason canary deployments (covered later in this article) often show a brief latency bump for the small percentage of traffic hitting the new version, even when the underlying code change is performance-neutral — the bump is cold-start noise, not a real regression, and distinguishing the two is a genuinely useful skill during a deployment review.

Consider a common event-driven pipeline: a user uploads a file to S3, which should trigger processing and notify subscribers. Tracing this end to end illustrates how Lambda lifecycle events interact with the rest of an architecture.

flowchart LR
  U["User Uploads File"] --> S3["S3 Bucket"]
  S3 -->|"Event Notification"| L["Lambda Function"]
  L --> P["Process / Transform Data"]
  P --> DB[("DynamoDB Table")]
  P --> SNS["SNS Topic"]
  SNS --> Sub1["Email Subscriber"]
  SNS --> Sub2["Downstream Lambda"]
    

The lifecycle of a single invocation moves through distinct phases: Init (only on cold start — bootstrap the runtime and run top-level code), Invoke (your handler executes with the event payload and a context object describing remaining time, request ID, and more), and Shutdown (rare, only when AWS decides to reclaim the environment — you get a brief SHUTDOWN signal via the Extensions API if you’ve registered for it, though most functions never observe this directly).

A critical lifecycle detail for async invocations like the S3 example above: if your function throws an unhandled error, Lambda automatically retries the invocation up to two more times by default, with a delay between attempts. If all retries fail, and you’ve configured a Dead Letter Queue or an on-failure destination, the event lands there for later inspection. If you haven’t configured one, the event is simply dropped — a surprisingly common production gap.

Destinations deserve a slightly closer look, because they’re a more modern and more capable replacement for the older Dead Letter Queue configuration. A destination can be configured for both success and failure separately, and unlike a DLQ (which only ever receives the raw failed event), a destination receives a richer payload including the original event, the response or error, and metadata about the invocation itself — useful context when you’re trying to understand why something failed hours after the fact, without needing to reproduce the exact conditions manually.

It’s also worth walking through what happens for the stream-based lifecycle specifically, since it differs from the S3 example above. With an SQS-triggered function, if your handler throws an error partway through processing a batch, by default the entire batch is considered failed and every message in it becomes visible again in the queue for reprocessing — even the messages your function had already successfully handled before the error occurred. Newer partial batch response support lets your function explicitly report which individual messages within a batch succeeded, so only the genuinely failed ones are retried — a meaningful reliability improvement that’s easy to overlook if you built your function before this feature existed.

No compute model is universally correct, and Lambda’s trade-offs are well understood by teams who have run it at scale for years.

The trade-off in one sentence: Lambda exchanges operational simplicity and cost efficiency for reduced control over execution timing and duration — a good trade for bursty, event-shaped work, and a poor one for steady, long-running, latency-critical workloads.

Lambda scales by adding execution environments, and by default a single AWS account has a regional concurrency limit — historically 1,000 simultaneous executions, though this is a soft limit AWS will raise on request. Beyond that limit, additional invocation attempts are throttled and, for synchronous sources, return a 429-style error to the caller.

Within that ceiling, Lambda applies a burst scaling model: it can immediately provision a batch of new execution environments (historically 500–3,000 depending on region), then continues scaling at a steady additional rate per minute afterward. This means a genuinely enormous, instantaneous traffic spike can still hit throttling even under the account limit, simply because environments can’t be created infinitely fast in the first few seconds.

Memory allocation is the primary performance lever available to you — CPU allocation scales proportionally with configured memory, so a function that’s CPU-bound (image processing, compression, JSON parsing at scale) often runs faster and cheaper at higher memory settings, even though the per-millisecond price also rises, because total duration drops enough to offset it. This is a genuinely counterintuitive result that AWS Lambda Power Tuning tools are specifically built to help you find.

Uber’s engineering team has published on using Lambda for parts of their geofence and surge-pricing computation pipelines, precisely because those workloads spike unpredictably with rider demand — a textbook case where auto-scaling compute beats a fixed fleet sized for peak.

Duration itself deserves a closer look, because “duration” as billed and “duration” as your users experience it aren’t always the same number. Billed duration starts when your handler begins executing and ends when it returns or errors — but for a synchronous API Gateway-fronted function, the caller also experiences the cold-start Init phase (if one occurs) and the network round trip, neither of which shows up in the billed-duration metric. This is why a function can look fast in CloudWatch metrics while still frustrating users with occasional slow responses; you have to look at Init Duration and end-to-end client-side latency separately to see the full picture.

Provisioned Concurrency interacts with auto-scaling in a way that’s worth being explicit about: it can itself be scaled up and down on a schedule using Application Auto Scaling, which matters for predictable traffic patterns like a business application that’s busy from 9 a.m. to 6 p.m. on weekdays and nearly idle overnight. Rather than paying for provisioned capacity around the clock, you can schedule it to ramp up shortly before your known traffic window and back down afterward — combining the cold-start elimination benefit of Provisioned Concurrency with the cost efficiency Lambda is otherwise known for.

Lambda functions are automatically deployed across multiple Availability Zones within a region — you do not configure this, and there is no equivalent of a “multi-AZ toggle” because it’s simply how the service runs by default. If one AZ has a problem, Lambda routes new invocations to healthy AZs transparently.

Reliability at the function level depends heavily on how you handle retries and idempotency. Because many event sources retry failed invocations automatically, your function can receive the same event more than once. A function that isn’t idempotent — for example, one that increments a counter or sends an email on every invocation without checking for duplicates — will produce incorrect results under retry, even though nothing about Lambda itself “failed.”

For multi-region resilience, Lambda has no built-in cross-region failover — you must replicate function code and configuration to a second region yourself (often via infrastructure-as-code) and route traffic with Route 53 health checks or a global accelerator, exactly as you would for any other regional AWS service.

It’s worth being precise about what “reliable” actually means for Lambda, since the term gets used loosely. AWS publishes a service-level agreement for Lambda’s own availability — the ability of the service to accept and execute invocations — but that SLA says nothing about whether your specific function’s logic is correct, or whether the downstream services it depends on are healthy. A function can be perfectly reliable from Lambda’s point of view (invoked promptly, executed as configured) while still producing wrong or failed results because the database it’s calling is overloaded. Reliability engineering for a Lambda-based system therefore has to account for the whole dependency chain, not just the function itself.

Circuit breaking is a pattern worth adopting deliberately rather than assuming Lambda provides it for you. If a downstream dependency starts failing, a naive Lambda function will keep calling it on every invocation, potentially making the downstream problem worse by adding load to an already struggling system, and burning invocation time on calls that were always going to fail. A simple circuit-breaker check — tracking recent failure rates in a fast store like DynamoDB or ElastiCache and short-circuiting calls once a threshold is crossed — can meaningfully improve both your function’s own latency and the health of the system it depends on during an incident.

Lambda security operates on two layers most intermediate engineers conflate: what your function is allowed to do (identity-based, via the execution role), and who is allowed to invoke your function (resource-based, via the function’s resource policy).

Secrets should never be hardcoded into function code or plain environment variables in production — use AWS Secrets Manager or Systems Manager Parameter Store (encrypted with KMS), and cache the retrieved value at module scope so a warm execution environment doesn’t re-fetch it on every invocation.

Attaching a Lambda function to a VPC is sometimes necessary (to reach an RDS instance in a private subnet, for example) but adds real security-relevant complexity: the function now needs correctly configured security groups, route tables, and — if it needs internet access for something like an external API call — a NAT gateway, since VPC-attached functions lose default internet access.

Dependency management is a genuinely underrated security surface for Lambda specifically, because a function’s deployment package often bundles third-party libraries directly rather than relying on a shared, centrally patched runtime environment the way a traditional server might. A vulnerable version of a common library, once packaged into dozens of functions across a team, has to be tracked down and re-deployed function by function unless you’re deliberately using tooling (like AWS’s own dependency scanning integrations, or third-party software composition analysis tools) to catch this automatically. Treating your Lambda deployment packages with the same dependency-hygiene discipline you’d apply to a container image or a server fleet is not optional at any real scale.

Input validation matters more, not less, in an event-driven architecture, because a Lambda function often receives its input from a system boundary that’s easy to forget is untrusted — an S3 object name, a message body from a queue another team owns, a webhook payload from a third party. Because Lambda functions are frequently small and single-purpose, it’s tempting to skip validation “since this function only ever receives one kind of event” — but that assumption breaks the moment another team wires a new producer into the same event source without your knowledge, which is a more common occurrence in event-driven systems than most teams expect.

Every Lambda invocation automatically emits a structured log entry to CloudWatch Logs containing the request ID, billed duration, memory used, and init duration on cold starts — this REPORT line is often the fastest way to confirm whether a slow request was a cold start or genuinely slow application logic.

CloudWatch Metrics tracked automatically, at no extra configuration cost, include Invocations, Duration, Errors, Throttles, and ConcurrentExecutions. For deeper tracing across a distributed event chain — API Gateway to Lambda to DynamoDB to SNS to another Lambda — AWS X-Ray provides end-to-end trace visualization, showing exactly which hop in the chain is contributing the most latency.

IteratorAge deserves special mention for anyone consuming Kinesis or DynamoDB Streams: it measures how far behind your function is falling relative to the latest record on the stream. A steadily rising IteratorAge is an early warning that your function can’t keep pace with incoming data — before customers ever notice anything is wrong.

Structured logging is worth adopting deliberately rather than relying on ad-hoc print statements, especially once a system has more than a handful of functions. Emitting logs as single-line JSON objects — including the request ID, the event source, and a consistent set of fields across every function on your team — makes CloudWatch Logs Insights queries dramatically more useful, letting you filter and aggregate across thousands of invocations from dozens of functions in one query, rather than grepping through unstructured text function by function.

CloudWatch Alarms tied directly to the metrics above are what actually turn observability into operational reliability. An alarm on the Errors metric with a reasonable threshold, an alarm on Throttles (which often indicates a concurrency limit that needs raising, not a bug), and an alarm on Duration approaching your configured timeout are three of the highest-value, lowest-effort alarms a team can set up in the first week of running a production Lambda function, and they catch a surprising share of real incidents before a customer ever files a support ticket.

Production Lambda deployment rarely means simply overwriting the function code in place. Lambda supports versions (immutable, numbered snapshots of code and configuration) and aliases (named pointers, like “prod” or “live,” that can point to one version or split traffic across two).

flowchart LR
  Dev["Developer Commit"] --> CI["CI/CD Pipeline"]
  CI --> Build["Build & Package"]
  Build --> Publish["Publish New Version"]
  Publish --> Alias{"Alias Routing"}
  Alias -->|"90%"| Prod["Version N — Production"]
  Alias -->|"10%"| Canary["Version N+1 — Canary"]
  Canary --> Monitor["CloudWatch Alarms"]
  Monitor -->|"Healthy"| Shift["Shift Traffic to 100%"]
  Monitor -->|"Errors"| Rollback["Rollback Alias"]
    

This alias-weighting mechanism is what powers canary and linear deployment strategies in tools like AWS SAM and CodeDeploy: a new version receives a small percentage of live traffic, CloudWatch Alarms watch its error rate, and traffic either shifts fully to the new version or automatically rolls back — all without a single manual step once configured.

Lambda also supports container image deployment (up to 10 GB images) alongside the traditional zip-based deployment package, which matters for teams with existing container tooling or large native dependencies that don’t fit the zip package size limits comfortably. Regardless of packaging method, Lambda Layers let you share common dependencies (an SDK, a shared internal library) across multiple functions without duplicating that code in every deployment package.

Infrastructure-as-code tooling has become the default way mature teams manage Lambda in production, rather than clicking through the console. AWS SAM (built specifically around Lambda and other serverless resources), the AWS CDK (which lets you define infrastructure in a general-purpose programming language), and Terraform are the three most common choices, and each integrates with CodePipeline or a third-party CI/CD system to automate the build-publish-shift-monitor cycle shown in the diagram above. The specific tool matters less than the discipline of treating function configuration — memory, timeout, IAM policy, environment variables — as version-controlled code reviewed the same way application logic is, rather than a console setting someone changed once and forgot to document.

Environment-specific configuration is a detail that catches teams off guard the first time they set up a real pipeline: because a Lambda function’s environment variables are part of its versioned configuration, promoting the exact same code from a staging environment to production typically means publishing a new version with different environment variables (different database endpoints, different feature flags), not literally reusing the same deployment package with the same in-memory state. Planning for this separation from day one — rather than hardcoding staging-specific values — avoids a class of “works in staging, breaks in production” bugs that are otherwise easy to introduce.

A second common anti-pattern worth naming directly: recursive invocation loops, where a Lambda writes to an S3 bucket or SNS topic that is itself configured to re-trigger the same function. Without a guard condition, this can spiral into runaway invocations and an unexpectedly large bill before anyone notices — always add an explicit check or route the write to a different resource than the trigger.

A third anti-pattern, closely related to the monolithic function described above, is what practitioners sometimes call “Lambda pinball” — an architecture where dozens of small functions call each other synchronously in a long, deeply nested chain, each one invoking the next directly rather than through an event bus or orchestrator. This pattern is easy to fall into because it feels natural coming from a microservices background, but it multiplies cold-start risk across every hop, makes tracing a single request significantly harder, and — because you’re billed for the full duration of every function in the chain including its wait time for the next one to respond — can quietly become far more expensive than a single well-designed function or an EventBridge/Step Functions-based alternative would have been.

The most common mistake at the intermediate level isn’t a Lambda-specific bug at all — it’s treating a downstream dependency (a database, a third-party API) as if it can absorb unlimited concurrent connections just because Lambda can scale to hundreds of parallel executions instantly. A traditional relational database with a fixed connection pool can be overwhelmed in seconds by a Lambda function that scales faster than the database can accept new connections — this is precisely the problem RDS Proxy was built to solve, by pooling and reusing database connections across many short-lived Lambda execution environments.

A second frequent mistake is misunderstanding what “cold start” actually costs versus what teams often blame it for. It’s common to see a slow endpoint and assume cold starts are the culprit without checking the REPORT log line to confirm it — when the real cause is often a slow downstream call, an inefficient query, or a large dependency being loaded and parsed at import time regardless of whether the environment is cold or warm. Measuring before optimizing is a basic engineering discipline, but it’s one that’s easy to skip with Lambda specifically because “cold starts” is such a well-known, easy-to-reach-for explanation.

A third mistake worth naming: over-permissioning execution roles “to save time,” typically by attaching a broad managed policy instead of a scoped, resource-specific one during initial development, and then never revisiting it before shipping to production. This is exactly backwards from a security standpoint — the cost of writing a precise, least-privilege policy is paid once, while the cost of an overly broad policy is paid continuously, every day the function runs in production with permissions it doesn’t need.

“The workloads that suit Lambda best aren’t defined by their industry — they’re defined by their shape: unpredictable, bursty, and naturally triggered by an event rather than a clock.”

These examples share a common thread worth drawing out explicitly: none of these companies moved their entire platform onto Lambda wholesale. Each identified a specific slice of their system whose traffic shape — bursty, event-triggered, hard to predict in advance — matched what Lambda is genuinely good at, and left the rest of their architecture on whatever compute model suited it best, whether that’s containers, traditional servers, or a managed database service. This selective adoption pattern is itself a best practice worth internalizing: Lambda is a tool for a specific shape of problem, not a wholesale replacement for every compute decision a platform needs to make.