The Problem with AWS Lambda

Key Takeaways

• AWS Lambda works well for short, event-driven workloads; problems often come from mismatched workload requirements rather than a defect in the service.
• Separate hard execution and payload limits from adjustable account quotas. Lambda's different compute models don't all share the same limits.
• Cold starts, downstream capacity, retries, and duplicate delivery belong in your architecture—not just your troubleshooting plan.
• Compare the whole application bill. Intermittent traffic and sustained high utilization can lead to different compute choices.

The problem with AWS Lambda isn't that it's a bad tool. It's that removing server management doesn't remove architectural decisions: you still need to plan for execution limits, latency, state, failures, security, and cost.

These AWS Lambda limitations should inform your workload selection, not automatically disqualify serverless computing.

Is AWS Lambda Reliable?

Lambda provides managed, multi-Availability-Zone infrastructure within a Region. Its service-level agreement states a 99.95% monthly uptime commitment per AWS Region, subject to its definitions, exclusions, and service-credit terms. Neither statement guarantees that your application processes every event correctly.

A function can run successfully while writing incorrect data, charging a customer twice, or depending on an unavailable database. Application reliability requires dependency resilience, appropriate retries, idempotency, and recovery procedures.

AWS Lambda Limitations and Quotas

Time limits depend on the compute model

Default-compute functions have a maximum invocation timeout of 900 seconds, or 15 minutes. Leave headroom for realistic input sizes, dependency delays, and cleanup rather than choosing a workload that barely fits.

The old blanket statement that Lambda can never run longer is now wrong. On September 9, 2026, AWS added 90-minute timeouts for Managed Instances for asynchronous invocations and event source mappings, except Amazon MQ and Amazon DocumentDB. Synchronous invocations retain the 15-minute maximum.

Lambda durable functions can coordinate checkpointed, multi-step executions lasting up to one year. That's a workflow spanning bounded invocations—not one uninterrupted year-long process.

Resource limits: packages, payloads, storage, and concurrency

The following table covers Event Functions on default compute. Check the current Lambda quotas and your account's Service Quotas before deployment; new accounts can have lower concurrency and memory quotas.

Deployment artifacts, aggregate code storage, and runtime scratch space are separate constraints. For code-storage needs beyond the managed quota, AWS supports self-managed S3 code storage. Response streaming also has bandwidth, runtime, Region, and integration constraints; it doesn't remove the limits of an upstream gateway or client.

VPC attachment uses Lambda-managed Hyperplane network interfaces, not one interface per invocation. Check the applicable network-interface quotas and subnet capacity for your VPC, account, and Region rather than designing around an old universal “250 ENIs” figure.

Vendor limits are architectural dependencies

Portability costs extend beyond rewriting a handler. Your application may depend on AWS event formats, IAM policies, queue configuration, deployment tooling, and workflow definitions. Treat these as migration work, even if the business logic is portable.

Keep business logic separate from invocation adapters, and document delivery assumptions. Our comparison of event-driven and REST microservice architectures provides useful context for those boundaries.

The Security Risks of Serverless Computing

Lambda isn't inherently secure merely because it's managed. AWS protects the service infrastructure; you remain responsible for application code, data, dependencies, access permissions, and configuration under the shared responsibility model. Lambda API endpoints use HTTPS, but that doesn't secure your application's downstream connections or authorize its users.

• Execution permissions: Give each function a least-privilege execution role. Avoid sharing a broad administrator role across unrelated functions.
• Invocation permissions: Review resource-based invocation policies and front-door authorization separately from the execution role.
• Secrets: Retrieve credentials from an appropriate secret store, such as AWS Secrets Manager; don't bake them into code or artifacts, or expose them in logs.
• Artifact security: Scan dependencies and container images, rebuild patched artifacts, and control who can publish function code and configuration.

AWS's Lambda security guidance explains the distinction between invocation permissions, execution roles, and secrets. These are separate controls, not interchangeable protections.

Attach a function to a VPC when you need private resource access or controlled network paths. VPC connectivity adds responsibility for security groups, routes, DNS, subnet addresses, and outbound connectivity; it doesn't automatically make an invocation endpoint private. Review the fundamentals in our AWS VPC tutorial.

The Performance Issues of Serverless Computing

Cold starts affect latency, not every invocation equally

A cold start happens when Lambda must initialize an execution environment before handling a request. Runtime startup, dependency loading, and application initialization affect that delay. Package contents, connection establishment, and actual network paths should be part of your end-to-end testing—not reduced to one universal cold-start number.

Reduce unnecessary dependencies and initialization work first. Provisioned concurrency pre-initializes environments for an additional charge; requests beyond that provisioned capacity can still use on-demand environments. SnapStart restores initialized snapshots for supported Java, Python, and .NET runtimes, but has compatibility restrictions and can't be combined with provisioned concurrency on the same function version.

Measure your tail latency—the slowest portion of requests—against your latency service-level objective. A strict response-time target isn't an automatic rejection of Lambda, but satisfying it may require paid capacity.

Concurrency and scaling don't protect your database

Concurrency means requests currently in flight. As a planning estimate, concurrent executions equal requests per second multiplied by average duration in seconds. For example, 500 requests per second taking 0.2 seconds each need about 100 concurrent executions, before allowing for bursts.

Default-compute functions have a scaling rate of up to 1,000 additional execution environments per function every 10 seconds, subject to available account concurrency. Scaling isn't instantaneous or unlimited; excess synchronous requests can be throttled.

Reserved concurrency allocates part of the account pool exclusively to a function and caps its concurrency; it doesn't prewarm environments. Use it alongside event-source controls to avoid overwhelming downstream databases or APIs. Provisioned concurrency addresses initialization latency instead.

More memory also allocates more CPU on default compute, so the smallest memory setting isn't necessarily the cheapest. Benchmark duration and cost together; our Node.js performance tips cover application-level bottlenecks that changing hosting models won't fix.

State isn't guaranteed to survive an invocation

Lambda may reuse an execution environment, making cached clients and temporary files useful optimizations. Ordinary handler memory and /tmp aren't durable shared state. Put durable business state in a database or other appropriate external store, and use workflow services for workflow progress.

Retries and Duplicate Delivery Are Your Problem Too

Retry behavior depends on how a function is invoked:

• Direct synchronous invocation: The caller or integration decides whether to retry.
• Lambda asynchronous invocation: Function errors receive two additional attempts by default. Throttling and service errors follow different retry behavior; configure event age, retries, and an on-failure destination or dead-letter queue.
• SQS event source mapping: Lambda polls and invokes the function with batches. Duplicate processing can occur; failed messages become available again after the visibility timeout.

Don't apply the asynchronous invocation retry policy to every event source. AWS documents asynchronous error handling and SQS delivery behavior separately.

For SQS, enable ReportBatchItemFailures and return failed message identifiers so successful records aren't unnecessarily retried with a failed batch. This doesn't eliminate duplicate delivery.

Make business operations idempotent: processing a duplicate must not repeat an unwanted effect. For an SQS order processor, enforce order-ID uniqueness in the same database transaction as the order write. If it calls a payment provider, use that provider's idempotency mechanism too; a database flag alone doesn't make the external charge atomic.

What Is the Biggest Disadvantage of AWS Lambda?

The biggest disadvantage is workload mismatch, which can surface as cost, latency, or operational complexity. Cost isn't simply a penalty for inefficient code: even well-written functions can be an expensive fit for sustained utilization.

AWS Lambda cost includes more than requests

For default compute, estimate allocated memory multiplied by billed duration, plus requests. Architecture choice affects pricing. Add provisioned concurrency, chargeable ephemeral storage, response streaming, data transfer, logging, and connected services such as gateways, queues, databases, and NAT gateways where applicable.

Managed Instances use a different model: requests, EC2 capacity, and a management fee rather than per-invocation duration charges. Include that option when evaluating steady traffic, not just Lambda versus containers.

A reproducible Lambda-versus-container estimate

Use these illustrative inputs for US East (N. Virginia), x86, on-demand pricing, before free allowances, credits, discounts, or taxes. These are billing calculations, not measured throughput benchmarks.

Lambda default compute:
  1,000,000 synchronous invocations/month
  1,024 MB memory = 1 GB for this calculation
  Average billed duration = 200 ms, including any billed overhead
  Duration rate = $0.0000166667 per GB-second
  Request rate = $0.20 per million

  Compute: 1,000,000 * 0.2 * 1 * $0.0000166667 = $3.33
  Requests: $0.20
  Total: approximately $3.53/month

Continuously running ECS task on Fargate, Linux/x86:
  0.25 vCPU and 0.5 GB memory, 30 days = 2,592,000 seconds
  CPU rate = $0.000011244 per vCPU-second
  Memory rate = $0.000001235 per GB-second

  2,592,000 * (0.25 * $0.000011244 + 0.5 * $0.000001235)
  Total: approximately $8.89/month

The rates come from Lambda pricing and Fargate pricing. The container is a single-task compute baseline, not a highly available service or an equivalent-capacity claim. Both estimates exclude networking, logging, gateways, storage beyond included allocations, and downstream services.

Intermittent work benefits from paying only when functions execute. Sustained work may make continuously provisioned compute attractive, but only a load test can establish how much container or VM capacity delivers the same throughput and latency. Don't compare equal memory labels and assume equal performance.

What AWS Lambda Is NOT Good For

1. Unbounded work: Don't force a job into a bounded invocation when its execution time can't be controlled.
2. Replacing architectural planning: Function boundaries don't solve transactions, dependency failures, or backpressure—the ability to slow producers when consumers can't keep up.
3. Acting as a shared-state store: Execution-environment reuse is an optimization, not a persistence contract.
4. Ignoring strict latency or steady-load economics: Evaluate initialization mitigation and alternative compute rather than assuming automatic scaling settles the decision.

Choose an alternative based on what the workload needs:

Short, independent events      -> Default-compute Lambda
Long-running queued jobs       -> AWS Batch or ECS tasks
Persistent service or worker   -> ECS/Fargate or EC2
Steady event-handler traffic   -> Also evaluate Managed Instances
Multi-step work with waits     -> Step Functions or durable functions
Durable shared business state  -> External database or storage

AWS Batch provides job queues, scheduling, and compute environments. ECS/Fargate fits containerized services and workers; EC2 provides more infrastructure control with more operational responsibility. Step Functions coordinates work across services rather than extending one function's execution time.

Use the AWS Fargate-versus-Lambda decision guide for a broader comparison, or our Amazon EC2 tutorial if you need a VM-based starting point.

Production Checklist

• Measure: Track errors, throttles, duration, concurrency, and queue age or stream lag as applicable. Alarm on user-visible symptoms, not invocation count alone.
• Trace: Follow requests into dependencies so database latency isn't mistaken for function startup latency.
• Log deliberately: Use structured logs and correlation identifiers; redact secrets, control volume, and set retention.
• Test recovery: Exercise duplicate events, partial failures, downstream outages, throttling, and dead-letter replay.
• Recheck economics: Compare the complete bill after measuring representative traffic, including bursts and quiet periods.

Lambda monitoring integrates metrics, logs, and tracing with AWS services. Observability has its own costs; CloudWatch Logs retains data indefinitely by default unless you configure a retention policy.

Conclusion

Lambda is a good tool, not a universal execution environment. Choose it when its model matches your workload, and budget explicitly for the controls that make the whole application reliable, secure, observable, and economical.

FAQ

What are the main limitations of AWS Lambda?

Default-compute Lambda functions have bounded execution time, memory, deployment-package sizes, and invocation payloads. Account concurrency and scaling rates also constrain throughput, while durable state and dependency capacity require separate architecture.

What is the maximum execution time for a Lambda invocation?

Default-compute invocations are limited to 15 minutes. Managed Instances support up to 90 minutes for asynchronous invocations and event source mappings except Amazon MQ and Amazon DocumentDB; synchronous invocations remain limited to 15 minutes.

Can AWS Lambda concurrency limits be increased?

Yes. The common default account concurrency quota is 1,000 per Region, and you can request an increase through Service Quotas; new accounts can start lower. Increasing that quota doesn't remove function scaling rates or downstream capacity limits.

When is AWS Lambda more expensive than ECS or EC2?

Default-compute Lambda can cost more for sustained workloads when per-invocation duration charges exceed the cost of sufficiently utilized container or VM capacity. Compare equivalent throughput, latency, availability, and operating costs, including provisioned concurrency and connected services.

Is AWS Lambda secure?

Lambda provides managed infrastructure security, but your application isn't automatically secure. You must configure least-privilege permissions, invocation authorization, secrets, dependency maintenance, and appropriate network controls.

Further Reading

• Lambda quotas — current limits, scopes, and adjustable quotas.
• AWS Lambda pricing — compute models and additional billing components.
• AWS Fargate pricing — resource rates and supported task configurations.
• Lambda execution-environment lifecycle — initialization and environment reuse.
• Lambda SnapStart — supported runtimes and compatibility restrictions.
• Asynchronous invocation retries — errors, event expiration, and recovery destinations.
• Lambda VPC connectivity — Hyperplane interfaces and network configuration.
• AWS Fargate or AWS Lambda? — workload-selection criteria and operational tradeoffs.