Provisioned Concurrency Does Not Work As Described
See original GitHub issueBug Report
Provisioned Concurrency was recently added in Serverless v1.59 and described in detail in this blog post: https://serverless.com/blog/aws-lambda-provisioned-concurrency/
The blog post makes the claim that enabling provisioned concurrency is as easy as:
functions:
hello:
handler: handler.hello
events:
- http:
path: /hello
method: get
provisionedConcurrency: 5
This is not true.
What this configuration will do is assign provisioned concurrency to the version number that was deployed, but API Gateway will continue invoking the Lambda with the $LATEST alias (no version). What effectively ends up happening is every deploy keeps assigning provisioned concurrency to each new version and never actually utilizes it. If a developer does not use any version pruning they will quickly rack up an expensive bill paying for new provisioned capacity on each version, and potentially worse, eventually exhaust their reserved (or unreserved) concurrency on their AWS account.
I think this is a critical issue and needs to, at the very least, be addressed in the blog post. Without some form of version cleanup or aliasing I don’t think there’s much Serverless can do to make this work in a simple configuration like that.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:33
- Comments:38 (16 by maintainers)
I’ll reopen until we have all issues mentioned here solved.
@vavarodrigues it’s still not really fixed, but it should be shortly with v1.60.2, stay tuned.