Warm a Release with Provisioned Concurrency

Warm a Release with Provisioned Concurrency

Publish a version, alias it, and allocate provisioned concurrency until it reports READY.

1. Cut an immutable version. Provisioned concurrency cannot target $LATEST, so a published version is a precondition rather than an optimization.
2. Create the alias that carries the warm capacity. Allocating against an alias rather than a bare version number means the next release can move the alias without clients having to learn a new qualifier.
3. Request provisioned concurrency against the alias. The call returns as soon as the request is accepted; the environments are not yet warm at this point.
4. Poll until Status reports "READY". While it reads "IN_PROGRESS" Lambda is still initializing environments and invocations continue to cold start; StatusReason carries the explanation when allocation fails, typically an account concurrency l

What you'll need to have ready

• functionName: The name or ARN of the function to warm.
• aliasName: The alias that will carry the provisioned capacity (e.g. warm or prod).
• provisionedConcurrentExecutions: Number of execution environments to pre-initialize. Must be at least 1 and counts against the account's concurrency limit for the region.
• versionDescription: Description recorded against the published version (e.g. a git SHA or release tag).

For your developer

Arazzo workflow aws-lambda:provisioned-concurrency-warmup, 4 operations: PublishVersion → CreateAlias → PutProvisionedConcurrencyConfig → GetProvisionedConcurrencyConfig. Specs on APIs.io.