When each AWS Lambda runtime stops getting patches, when AWS blocks creating new functions on it, when AWS blocks updating existing ones, and what to move to. Every date comes from the AWS Lambda runtime deprecation table — each row links the source.
Scan your stack free — find your deprecated runtimes →
| Runtime | Blocks create | Blocks update | Severity | Upgrade to | Source |
|---|---|---|---|---|---|
nodejs20.x | 2027-02-01 | 2027-03-03 | high | nodejs22 | AWS |
python3.9 | 2027-02-01 | 2027-03-03 | high | python3.12 | AWS |
python3.10 | 2027-02-01 | 2027-03-03 | high | python3.12 | AWS |
nodejs18.x | 2027-02-01 | 2027-03-03 | high | nodejs22 | AWS |
python3.8 | 2027-02-01 | 2027-03-03 | high | python3.12 | AWS |
python3.11 | 2027-07-31 | 2027-08-31 | medium | python3.12 | AWS |
Functions keep running after deprecation, but become unpatched and — after the block-update date — unmodifiable. Dates reflect the AWS-published schedule and can shift; the linked AWS page is authoritative.
The upgrade usually surfaces specific errors — removed stdlib modules, the unbundled AWS SDK v2 on Node 18+, native-wheel/ABI breaks. See common migration error fixes, or get a hash-anchored audit ($299, 30-day money-back) that scores every finding and hands back a roll-forward plan.