AWS于2026年9月3日发布了Amazon Linux 2027 (AL2027) 公开预览版。Amazon Linux是AWS为在EC2和容器等AWS上运行的工作负载而专门构建和维护的Linux发行版。本次发布的重点不仅仅是名称中年份的变化。安全默认设置、CPU基线、软件包管理器和开发工具链都得到了全面现代化。
然而，现在可以下载并不意味着可以投入生产环境。AWS明确指出当前版本是用于评估和测试的预览版，不建议用于生产用途。现在要做的事情不是立即更换服务器，而是在非生产环境中提前找出AL2023工作负载在新默认设置下可能出现问题的地方。
Amazon Linux 2027 转换场景，在现代AWS云服务器基础上，配备了安全防护和两种CPU路径。
发布中确认的关键变化
AL2027继承了AL2023的基础，但提供了Linux内核7.1或更高版本、SELinux默认强制模式、DNF5、OpenSSL 3.5和AWS-LC，以及最新的语言运行时和编译器。x86-64和Arm64 AMI在所有商业AWS区域均提供预览版，容器基础镜像可从Amazon ECR Public获取。
| 项目 | AL2023中熟悉的标准 | AL2027预览版的变化 | 首先要检查的 |
| — | — | — | — |
| SELinux | 默认 permissive | 默认 enforcing | 应用程序/代理的AVC拒绝 |
| 软件包管理 | 基于DNF | DNF5 | 自动化脚本和插件兼容性 |
| x86基线 | x86-64-v2 | x86-64-v3 | 旧实例/本地CPU |
| Arm基线 | 64位Arm | ARMv8.2+crypto, Graviton2或更高 | 是否排除A1和旧主板 |
| 加密 | 现有系统策略 | 默认启用PQC, OpenSSL 3.5, AWS-LC | TLS/SSH互操作性 |
| 开发工具 | GCC 11系列默认 | GCC 16.1, LLVM/Clang 22 | 警告/编译错误和语言标准变化 |
虽然AWS产品页面也提到了GCC 16.2，但目前详细的用户指南和软件包文档均以GCC 16.1为基准进行说明。在预览期间，软件包和配置可能会发生变化，因此在实际AMI上通过gcc --version并结合发布说明进行确认更为安全。
最大的操作变化是SELinux强制模式
AL2023默认SELinux为permissive模式，即记录策略违规但不阻止。AL2027默认SELinux为enforcing模式，这意味着策略不允许的文件访问、端口绑定和进程行为将被实际阻止。从安全角度来看，这是一个更安全的起点，但对于那些之前忽略permissive日志的应用程序，即使在启动后看起来正常，也可能在特定功能上失败。
在预览实例中，首先检查以下内容：
cat /etc/os-release
getenforce
sudo ausearch -m AVC,USER_AVC -ts recent
sudo journalctl -t setroubleshoot --since today一旦出现阻止就立即关闭SELinux并非良好的迁移测试方法。您应该确认服务是否确实需要该访问权限，并使用文件上下文、布尔值或策略模块中最窄的方法进行允许。
x86-64-v3是性能机遇，也是兼容性边界
AL2027的x86-64软件包是按照x86-64-v3基线构建的，该基线包含AVX、AVX2、BMI1/2和FMA等功能。这大致对应2015年以后的CPU，但并非所有旧的EC2类型或本地虚拟化主机都能满足条件。如果不符合条件，可能会在启动初期因illegal instruction而失败，而不是应用程序错误。
Arm64要求ARMv8.2和Cryptography Extension，AWS支持Graviton2或更高版本。A1实例和Raspberry Pi 5之前的型号不在此列。在简单替换AMI之前，您应该首先检查当前实例类型和自定义镜像构建机器的CPU功能。
量子抗性密码和SSH强化成为默认设置
AL2027在系统加密策略中默认启用量子抗性密码学（PQC）。OpenSSH使用PQC密钥交换，OpenSSL 3.5、GnuTLS和NSS包含对ML-KEM混合密钥交换和新签名算法的支持。这并不意味着现有的RSA/ECDSA证书将立即无法使用。实际检查的重点是旧的TLS设备、代理、库和SSH客户端是否能正确处理新的协商组合。
OpenSSH 9.9p1的强化设置也需要审查。DSA不再受支持，默认不允许短于2048位的RSA密钥。如果旧的自动化账户和设备使用DSA密钥或短RSA密钥，则在转换为AL2027之前应将其替换为Ed25519、ECDSA或足够长的RSA密钥。
开发环境和镜像管道也需要重新测试
DNF5并非现有DNF的简单版本变更，而是一个新的实现。虽然常见的安装命令是熟悉的，但输出解析、插件、缓存和自动化行为可能会有所不同。如果Packer、EC2 Image Builder、cloud-init和引导脚本依赖于dnf的输出或内部目录，则需要进行测试。
编译器默认值也发生了变化。GCC 16.1使用C23和C++20作为默认标准。在AL2023中可以顺利通过的源代码可能会产生新的警告或错误，因此与其在构建失败时仅仅固定软件包，不如明确审查代码和-std=选项。
AI/ML工作负载包括对Trainium和Inferentia的AWS Neuron驱动程序支持。然而，这并不意味着自动兼容NVIDIA CUDA或特定的框架组合。您必须在单独的矩阵中验证所使用的加速器、内核模块、容器运行时和框架版本。
现在可以进行的安全预览验证
预览AMI可以通过AWS控制台、CLI和SSM公共参数找到。由于确切的参数和AMI ID可能因区域和发布而异，请使用文档中的最新值。请在单独的沙盒账户或隔离的VPC中启动，而不是在生产账户中，并且不要包含实际数据或长期凭证。
验证顺序可以很简单。首先，将相同的应用程序分别部署到AL2023和AL2027。比较启动、软件包安装、服务启动和正常请求。然后，检查SELinux拒绝、SSH连接、TLS集成、日志/监控代理和备份。最后，自动化AMI构建和回滚，以验证其不会影响现有生产环境。
uname -r
rpm -E '%{fedora}' 2>/dev/null || true
dnf --version
openssl version
ssh -V
gcc --version预览结果中务必记录所使用的AMI ID、区域、架构和发布版本。如果预览版更新，必须重新运行相同的测试才能比较结果。
GA之前的判断标准
AWS表示计划在AL2027正式发布（GA）后提供5年的标准支持。此外，它还阐述了在GA时提供最新的LTS内核，并在此后每年发布新内核，每个内核支持4年的方向。然而，这不应被解读为GA日期和最终软件包配置已确定。预计在2026年11月公布的预览第二阶段将增加SPAL软件包、DCV支持和EKS优化AMI配方。
目前看待AL2027最现实的角度不是“我们是否应该立即切换到新操作系统？”，而是“我们的系统是否已准备好接受2027年的安全默认设置？”特别是SELinux强制模式、CPU基线、DNF5、SSH和加密策略可能会在应用程序代码之外造成故障。如果在预览期间将这四个边界转换为自动化测试，那么GA之后的迁移将变得更具可预测性。
发表回复