Amazon Linux 2 (AL2) 的标准支持已于 2026 年 6 月 30 日结束——该日期现已过去。如果您仍在运行基于 AL2 的 Storage Gateway 设备，您已处于不受支持的窗口期，以下是补救方法：AWS 支持的迁移方式，以及让迁移顺利进行的运维经验。

如果您运行 AWS Storage Gateway，有一个截止日期已经改变了您的路线图——而且它已成为过去：*Amazon Linux 2 (AL2) 将于 2026 年 6 月 30 日结束标准支持。* 那个日期已经过去，因此任何基于 AL2 的网关设备在运行中都不再接收软件更新、安全补丁或错误修复。您可以继续运行它们，但现在它们的维护工作由您负责，在任何有合规或审计义务的环境中，处于此窗口期的每一天都在累积风险。

Storage Gateway 值得特别指出，因为它在此过渡中的表现与普通的 EC2 工作负载不同。对于简单的 EC2 实例，您可以重新制作 AMI 并重新部署。对于 Storage Gateway，没有从 AL2 到 AL2023 的原地升级路径——设备操作系统由 AWS 管理，您是通过替换网关的底层实例而非修补它来迁移到 AL2023 的。

这是一份关于规划和经验教训的指南，而不是包含精确点击步骤的操作手册（确切的命令在 AWS 的官方文档中，我在下方提供了链接）。目的是让您了解迁移的整体流程和相关的运维判断，无论是一台网关还是一个集群，您都能心中有数。

时间线与当前状态

AWS 曾开展过特定的迁移活动。以下所有日期现已过去，但了解它们有助于理解当前状态：

  • 2025 年 10 月 28 日 — Storage Gateway 控制台开始默认使用 AL2023 镜像部署新网关。
  • 2026 年 1 月 5 日 — AWS 开始限制新的 AL2 网关激活。
  • 2026 年 6 月 30 日 — 基于 AL2 的网关不再有软件更新，也不再获得 AWS 支持。

此变更适用于 S3 File Gateway、Tape Gateway 和 Volume Gateway 系列中所有基于 AL2 的设备版本。最终日期已过，因此您仍在运行的任何 AL2 网关目前都处于不受支持的窗口期，因此这不再是“计划中的工作”，而是需要优先处理的补救措施。请按风险排序（先处理面向互联网和合规关键的网关），然后系统地处理整个集群。

如何识别受影响的网关

在制定任何计划前，请先进行仔细的盘点。AWS 提供了 3 种不同的方式来识别需要迁移的网关，建议使用多种方式交叉验证：

  • 在受影响网关的详细信息选项卡中，AWS 控制台会显示弃用消息。
  • DescribeGatewayInformation API 会暴露一个 deprecation-date 字段，这是批量扫描多个网关的编程方式。
  • 在AWS Health Dashboard 的受影响资源选项卡中，您可以查看受影响的网关。

如果您有多个网关，API 是您的好帮手，请在每个账户和区域中编写脚本进行检查，而不是通过控制台逐个点击。这些迁移失败的共同原因是不进行盘点。您无法迁移您忘记的网关。

支持的迁移方式

AWS 记录了针对 S3 File Gateway 的替换流程，该流程保留缓存磁盘和当前的网关 ID。 这里的关键是保留网关 ID；它能确保您的文件共享、名称和配置在迁移过程中保持不变。概念流程如下：

  1. 停止通过网关的应用，以确保在切换期间没有写入操作。
  2. 从最新的网关镜像部署一个新的 AL2023 网关实例。
  3. 从旧实例分离缓存磁盘，并附加到新实例。
  4. 执行迁移 API 调用，在新实例上接管现有的网关 ID 和配置。
  5. 检查结果——共享存在、可用且健康。

文档中有两个约束：数据只能在相同网关类型之间移动，且记录的迁移步骤适用于设备版本 2.x，不能用于旧版本，因此您的前期准备工作可能需要先获取当前版本。

我有意不在此处复制确切的控制台点击步骤和 API 参数，因为 AWS 会保持权威版本的最新状态。请从“Storage Gateway AL2 to AL2023 Migration Campaign” 预迁移检查清单（在文末链接）开始替换现有的 S3 File Gateway，并严格遵守。

如果您有多个网关，请自动化

对于一两台网关，手动执行停止-分离-附加-迁移-验证的步骤是可行的。但对于数十台或数百台网关——跨越多个账户和区域——则速度慢且容易出错。

AWS 已在 Storage Gateway Terraform 模块中发布了一个迁移示例，用于自动化 AL2 到 AL2023 的升级，以及一个相应的Ansible playbook，用于编排磁盘交换和迁移 API 步骤。这种组合为您提供了针对整个集群的可重复、可审计且可扩展的迁移路径。如果您在任何实际规模上运行，请在让工程师进行数周的手动切换前，考虑 IaC 路线。仅可审计性（记录了确切更改内容和时间的 git 历史）在受监管的环境中就值得采用。

您需要了解的重要经验教训

上述机制是最简单的 20%。迁移成功或受阻的关键在于：适用于 Storage Gateway 之外更广泛原则的广泛经验。

  1. 整个切换中最重要的因素是网关

迁移会替换底层实例，因此网关的 IP 地址会发生变化。 这究竟是无关紧要还是导致紧急情况，取决于一个问题：客户端是通过 DNS 名称还是通过硬编码的 IP 地址进行连接？

  • 使用 DNS 的客户端是干净的。新实例启动后，您只需在维护窗口期间重新指向一条 DNS 记录，客户端就可以继续使用相同的 hostname：他们永远不知道任何东西发生了移动。 - 痛苦的情况是 IP 硬编码的客户端。新的 IP 意味着每个指向旧地址的客户端现在都指向了无，直到它被更新。这些更新通常由不同的团队负责，遵循不同的时间表，从而将他们的时间线拖入您的计划。

*在迁移任何内容之前，请盘点每个客户端的连接方式。并将迁移作为将原始 IP 替换为适当 DNS 名称的强制功能——这样下一个生命周期事件只需进行一行 DNS 更改，而不是全集群推送。这是整个练习中杠杆作用最大的习惯。

2. 不要修改旧实例，将其视为不可变的基础设施

此类迁移的最佳心智模型是替换，而不是修改。您的旧 AL2 实例是您的回滚基线，这正是您破坏试图保留的东西的方式。对生产设备进行少量的操作系统级调整以“使其工作”。干净地构建新的 AL2023 实例，进行切换，并将旧实例保留为您的安全网。

3. 您将回滚到旧实例，因此不要过早终止它

这种替换和保留策略最大的好处是*您的回滚计划是“旧实例仍在那里，处于停止状态。* 您移出了它的缓存磁盘，但实例本身是完好的。

请制定一条规则：在切换后将旧实例保留停止状态一段时间——时间足够长，以便如果在实际负载下几天后出现问题，您仍然可以回滚，而无需从头开始配置。几周的 EBS 存储费用，您就能安心入睡。在您的变更计划中记录保留窗口，这样一个善意的清理流程就不会在切换后三小时就杀掉您的安全网。

4. 有状态和无状态工作负载的不同方法

Storage Gateway 是有状态的——有缓存数据需要保留——这就是为什么存在磁盘和网关 ID 方法的原因。如果您更广泛的 AL2 资产包含其他工作负载类型，请不要将一个剧本应用于所有：

有状态 EC2：多个实例，数据同步已验证，DNS 切换已管理。

  • Auto Scaling Groups： 使用金丝雀和受保护的实例刷新部署新的 AL2023 AMI。
  • EKS 节点： 添加 AL2023 节点组，停止在新 AL2 节点上调度新 Pod，验证集群插件（VPC CNI、CoreDNS、kube-proxy）与 AL2023 AMI 兼容，然后在稳定后封锁/排空/移除 AL2 节点。

主线是：引入新的，在真实条件下验证，最后移除旧的——在最终步骤之前保持回滚可用。

5. 验证是检查清单，而不是直觉

“共享已恢复”不是一种状态。提前决定已验证的健康状态是什么——共享可访问、正确的共享列表存在、测试读写均成功——并将这些检查写入操作手册，以便任何执行切换的工程师都知道成功的精确标准。当您自动化时，这一点更加重要：您的 playbook 应该断言健康，而不是假设它。

6. 在技术之前先映射人为依赖关系

AWS 的步骤很容易在下午学会。您无法缩短的是切换所涉及的人际网络：拥有 DNS 的人、将配置推送到 IP 硬编码客户端的人、需要事后验证（并提前被告知他们的共享将闪烁）的应用所有者，以及在更高风险阶段提供支持的 AWS 支持或您的 TAM。在接触任何东西之前，请为每个网关绘制依赖关系图，并将“谁必须在我的维护窗口内采取行动”作为计划的一等部分。

7. 超越截止日期——风险排序和有意识的移动

每个网关的技术工作量很小；是跨团队安排生产变更的组织运行需要时间。但是，2026 年 6 月 30 日已成为过去，没有“早”了——但这不是草率赶工的理由。正确的答案是进行分类：识别哪些网关在不受支持状态下风险最高（面向互联网、合规范围、最高数据敏感性），并首先为这些网关预订变更窗口，然后以受控顺序处理整个集群。压缩的紧迫性 + 有组织的顺序 > 恐慌或自满。

要点

Amazon Linux 2 现已结束标准支持，我们已过了截止日期。是否还有基于 AL2 的 Storage Gateway？好消息是，迁移到 AL2023 的技术工作并不是最难的部分——AWS 的替换和保留方法保持了您的网关 ID、缓存数据和共享配置的完整性，现在还有 IaC 工具可以在集群规模上运行它。

困难的部分是其他一切：准确知道哪些网关受到影响、客户端实际上如何访问它们（DNS 或 IP）、在切换过程中保持真正的回滚路径可用，以及协调维护窗口内需要采取行动的人员。遵循 AWS 文档中的机制，操作系统交换将成为它应该成为的简单步骤。期待这些。

可靠来源

  • Storage Gateway AL2 to AL2023 Migration Campaign（预迁移检查清单、时间线、受影响版本）—— docs.aws.amazon.com/filegateway/latest/files3/al2-to-al2023-migration.html.
  • 创建新的文件网关实例以替换现有的 S3 File Gateway（支持的方法）—— docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html - 使用基础设施即代码（Terraform + Ansible）扩展您的 AWS Storage Gateway AL2023 迁移—— aws.amazon.com/blogs/storage/scale-your-aws-storage-gateway-al2023-migration-with-infrastructure-as-code/
  • 将 EC2 实例从 AL2 迁移到 AL2023（通用 EC2 指南）—— `repost.aws/knowledge-center/al2-migrate-al2023

请始终参考最新的 AWS 文档以获取确切步骤——日期、镜像版本和流程会更新，文档是事实来源。