Your function keeps running, but AWS may stop applying security patches to the runtime, support ends, and later AWS blocks creating new functions and then updating existing ones. You can still move to a supported runtime at any time. Staying put means running unpatched language code.
The timeline
AWS describes the phases like this:
| Phase | When | What changes |
|---|---|---|
| Notice period | At least 180 days before deprecation | Email, Health Dashboard and Trusted Advisor alerts |
| Deprecation | On the deprecation date | Security updates may stop, no technical support, console creation and update stops (CLI, SAM and CloudFormation still work) |
| Block create | At least 30 days after | New functions cannot be created on that runtime |
| Block update | At least 60 days after | Code and configuration updates are blocked, though you can still switch to a supported runtime |
AWS has delayed the block dates for some runtimes beyond the usual 30 and 60 days. Always read the dates for your runtime in the supported and deprecated tables rather than assuming the standard offsets.
Why the block update date is the real deadline
After updates are blocked, you cannot ship a patched dependency to that function either, because you cannot update its code. That turns a runtime problem into a dependency problem. The sensible window to act is before this date, while you can still deploy and test freely.
The AWS page also notes that you cannot revert to the deprecated runtime once function updates are blocked, which is why it recommends using versions and aliases for rollback during the move.
What "no patches" means in practice
The deprecation policy says deprecated runtimes are provided as is, may contain bugs and vulnerabilities, and may suffer issues such as an expired certificate. AWS sometimes delays deprecation for a limited period after a language version reaches end of support. During that time it applies security patches to the runtime operating system only, not to the language runtime itself.
What to do this week
- Pull the supported and deprecated runtime tables and mark the dates for the runtimes you use.
- List your functions and versions by runtime (see our post on finding functions on a deprecated runtime).
- Test each function on the target runtime in a copy, using a new alias.
- Rebuild dependencies for the new runtime, since native packages must match the platform and architecture.
- Shift the alias, watch error rates, and keep the old version until you are confident.
- Record the change so audit evidence shows the runtime was current.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how ongoing monitoring flags a change over time. Runtime dates are the same kind of signal: known in advance, easy to miss.
Quick check
Do container image functions get deprecation emails?
No. AWS states that deprecation notifications are not available for functions that use container images, so you must watch base image support dates yourself.
Can I upgrade after updates are blocked?
Yes. AWS says you can still change the function configuration to a supported runtime, although rolling back to the deprecated one may be blocked.
Safeguard's dependency scanning and compliance evidence automation can help you show that runtimes and libraries were reviewed on a schedule. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
