Lambda is wonderful, but it is not a silver bullet. Like any tool, it has technical limits and there are situations where using it is a bad idea (anti-patterns). We close the chapter by learning to recognize when Lambda is not the right answer: knowing this will save you headaches and make you a better architect.

Lambda imposes a series of restrictions. You don't need to memorize exact numbers (they change over time), but you do need to know what is limited:

The most important limit to remember is the 15-minute one: a Lambda function cannot run for more than 15 minutes. If your task takes longer, Lambda is not the tool.

An anti-pattern is using a tool for something it wasn't designed for. These are the cases where Lambda doesn't fit:

If a process takes more than 15 minutes (processing a huge video, a scientific calculation, a massive data migration), Lambda will cut it off halfway.

Better alternative: containers (ECS/Fargate, Chapter 17), EC2 instances, or batch processing services. For long workflows made up of short steps, you can orchestrate several Lambdas with Step Functions (Chapter 28).

Lambda is great for intermittent or unpredictable traffic (you only pay for usage). But if you have huge and constant traffic 24 hours a day, billions of executions can end up more expensive than a group of servers always on.

Better alternative: EC2 with Auto Scaling (Chapter 13) or containers, which at very high constant volume can be more economical. (It's worth doing the math: it depends a lot on the case.)

Lambda is stateless: each invocation can run in a different environment, and you can't rely on memory being preserved between calls. If your application needs to keep data in memory between requests (a user session in RAM, a persistent local cache), Lambda is not suitable.

Better alternative: store the state outside the function, in services designed for it: DynamoDB (subchapter 8.3), ElastiCache (subchapter 8.4), or S3 (Chapter 5). This is, in fact, the correct way to design: state goes to an external service, not in the function.

Since Lambda can create thousands of executions in parallel, each trying to open a connection to a relational database (RDS, Chapter 8), it can exhaust the available connections and bring down the database.

Better alternative: use RDS Proxy (which manages and reuses connections), serverless databases like Aurora Serverless (subchapter 8.2) or DynamoDB, which scale better with Lambda.

If you need ultra-low and guaranteed latency on every request, and cold starts (subchapter 14.4) are a constant problem even with provisioned concurrency, maybe an always-on service is better.

Lambda doesn't replace servers: it's another tool in your toolbox. A good architect combines services: use Lambda for event processing and short tasks, containers or EC2 for constant and long workloads, and managed services (DynamoDB, S3, queues) for state and data.

The key question is not "Should I use Lambda?", but "Which tool fits this specific job best?". Sometimes it's Lambda, sometimes not, and many real architectures use several at once.

• Lambda has limits: the most important is the 15-minute maximum execution time; there are also limits on memory, package size, temporary storage, and concurrency.
• Anti-patterns (when NOT to use Lambda): tasks of more than 15 min, constant, very high 24/7 traffic, need for in-memory state between requests, and poor handling of connections to relational databases at scale.
• State should go outside the function (DynamoDB, ElastiCache, S3): Lambda is stateless.
• Alternatives depending on the case: ECS/Fargate or EC2 (long/constant tasks), Step Functions (long workflows by steps), RDS Proxy / Aurora Serverless / DynamoDB (databases at scale).
• The right question is "Which tool fits this job best?", not "Should I use Lambda for everything?".

You've finished Chapter 14 and mastered the fundamentals of serverless! In Chapter 15 we'll look at the pieces that connect all these functions and services: messaging and events (SQS, SNS, EventBridge), key to building decoupled systems.