AWS于8月13日宣布，Amazon Lambda在中国区域为Java 8、Java 11和Java 17增加基于Amazon Linux 2023的运行时。新选项同时以托管运行时和容器基础镜像提供，适用于北京区域与宁夏区域。
这项更新的直接价值是把两次升级拆开。仍在使用Java旧版本的函数可以先从Amazon Linux 2迁移到AL2023，完成底层操作系统更新后，再根据应用计划升级Java版本，避免在一次发布中同时改变两层关键依赖。
Java旧版本现在可以直接使用AL2023
此前在Lambda上选择较新的Amazon Linux基础环境时，Java运行时版本也可能成为迁移条件。对于依赖旧框架、第三方SDK或内部公共库的函数，操作系统和语言版本同时变化会扩大测试范围。
本次新增的Java 8、11和17运行时都基于AL2023。使用托管运行时的团队可以继续由Lambda维护语言执行环境，使用容器镜像的团队则可以从AWS提供的对应基础镜像开始构建。
AL2023采用更新的软件包与安全基线，但函数业务逻辑并不会因此自动兼容。原生库、证书路径、系统命令和依赖安装脚本仍要在迁移前逐项检查。
操作系统与Java版本可以分阶段迁移
生产函数通常同时依赖Java字节码、框架版本、构建插件和底层Linux组件。一次性从AL2迁移到AL2023并升级Java，出现问题时很难迅速判断是JDK行为变化还是系统库差异。
现在可以先保持Java主版本不变，只替换Lambda运行时或容器基础镜像。团队能够集中验证冷启动、文件系统、网络连接、日志输出与原生依赖，再把Java升级安排到后续独立变更窗口。
分阶段并不代表零风险。运行时标识、镜像标签、部署流水线和依赖锁定方式都应记录清楚，回滚包也要保留，避免新旧环境混用时无法恢复。
AL2退役时间推动现有函数尽快盘点
AWS公告指出，Amazon Linux 2计划在2026年6月30日结束生命周期。对仍使用AL2运行时的Lambda函数来说，底层基础环境迁移已经不只是性能选择，也关系到后续安全维护。
AWS还会为基于AL2的Java 8、11和17旧运行时继续提供关键及部分重要安全补丁，期限到2027年6月30日。这个缓冲期让复杂应用有时间测试，但不适合被当作长期维持旧环境的理由。
管理员应先按账号、区域和运行时版本建立清单，区分无人维护函数、低频批处理和核心在线接口。越靠近维护截止时间再集中处理，越容易遇到测试资源与发布窗口不足。
Java 21与25仍是更长期的优先路线
AWS明确建议新应用优先使用同样基于AL2023的Java 21或Java 25。较新的长期支持版本通常能获得更长维护周期，也便于采用新的虚拟机优化、框架版本和安全修复。
Java 8、11和17的AL2023运行时更适合作为迁移桥梁，而不是让旧应用无限期停留。对于能够修改和重新测试的函数，直接评估Java 21或25可能减少未来再次迁移的工作。
实际选择要由依赖兼容性决定。Spring、日志组件、数据库驱动、序列化库和监控代理都可能限制JDK版本，升级前应结合构建测试和真实调用回放判断。
中国区域迁移需要验证镜像与依赖
该能力已在AWS中国北京区域和宁夏区域提供。跨分区部署时，镜像仓库地址、服务端点、IAM权限和可用依赖不一定与其他AWS区域完全相同，不能直接复制海外区域的流水线配置。
使用ZIP包部署的函数应建立新运行时测试版本，再通过别名逐步转移流量。使用容器部署时，应重新构建而不是只替换标签，并通过镜像扫描确认基础包与业务依赖。
验证指标至少应覆盖初始化时长、调用延迟、错误率、内存占用和外部连接。对Java函数而言，还应观察类加载、JIT预热和连接池恢复，确认迁移后没有把兼容问题转化为冷启动波动。
