Amazon Linux 2 的標準支援已於 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 會保持權威版本的最新狀態。使用新的執行個體替換您現有的 S3 File Gateway，請從「Storage Gateway AL2 to AL2023 Migration Campaign」遷移前檢查清單（連結於文末）開始，並嚴格遵守。

如果您有超過少數幾個，請自動化

停止-卸離-連接-遷移-驗證的流程手動執行一兩個閘道是可以的。但在數十個或數百個——跨越多個帳戶和區域——執行時，則緩慢且容易出錯。

AWS 已在 Storage Gateway Terraform 模組中發布了遷移範例，可自動化 AL2 到 AL2023 的升級，以及一個對應的Ansible playbook，可編排磁碟交換和遷移 API 步驟。該組合為整個機群提供了一條可重複、可稽核、可擴展的路徑。如果您在任何一種實際規模上執行，請考慮在指派工程師進行數週的手動移轉之前，先考慮 IaC 路線。僅僅是可稽核性（精確記錄什麼改變、何時改變的 git 歷史記錄）在受管制的環境中就值得。

您需要知道的重要經驗

上述的機制是最簡單的 20%。以下是遷移成功或受阻的地方：適用於遠不止 Storage Gateway 的廣泛原則。

  1. 對整個移轉而言最重要的事情就是閘道

遷移會替換基礎執行個體，因此閘道的 IP 位址會改變。 這究竟是無關緊要還是火燒屁股，取決於一個問題：用戶端是透過 DNS 名稱還是硬式編碼的 IP 位址進行連接？

  • 乾淨的 DNS 用戶端。新的執行個體啟動後，您只需在維護窗口期間重新指向一條 DNS 記錄，用戶端就會繼續使用相同的主機名稱：他們永遠不會知道任何東西被移動。 -痛苦的情況是 IP 硬式編碼的用戶端。新的 IP 位址意味著每個指向舊位址的用戶端現在都指向無效位址，直到它被更新為止。這些更新往往與不同的團隊、不同的時程表有關，將他們的時程拖進您的時程。

*在您遷移任何東西之前，請清點每個用戶端如何連接。並將遷移作為強制功能，將任何您仍使用原始 IP 的地方替換為適當的 DNS 名稱——這樣下一個生命週期事件就會是一行 DNS 變更，而不是全機群的推送。這是整個練習中槓桿作用最大的習慣。

2. 不要修改舊的執行個體，將其視為不可變的基礎架構

這種遷移的最佳心智模型是替換，而不是修改。* 您的舊 AL2 執行個體是您的復原基準，這正是您破壞您試圖保留的東西的方式。對生產設備進行少量的作業系統層級調整以「使其運作」。乾淨地建置新的 AL2023 執行個體，進行移轉，並將舊的執行個體保留作為您的安全網。

3. 您將復原至舊的執行個體，因此不要過早終止它

替換和保留策略最大的安慰在於*您的復原計畫是「舊的執行個體仍然存在，已停止。* 您移出了它的快取磁碟，但執行個體本身是正常的。

請制定一條規則，在移轉後讓舊的執行個體保持停止狀態一段時間——時間長到如果一兩天後在實際負載下出現問題，您仍然可以復原，而無需從頭開始佈建。幾週的 EBS 儲存空間讓您可以安心休息。請在您的變更計畫中記載保留窗口，以便妥善的清理程序不會在移轉後三小時就終止您的安全網。

4. 具狀態和無狀態工作負載的不同方法

Storage Gateway 是具狀態的——有快取資料需要保留——這就是為什麼存在磁碟和閘道 ID 方法的原因。如果您更廣泛的 AL2 環境包含其他工作負載類型，請不要將一份操作手冊應用於所有：

具狀態 EC2：多個執行個體、已驗證的資料同步、已管理的 DNS 移轉。

  • Auto Scaling Groups： 使用 Canary 和受保護的執行個體刷新部署新的 AL2023 AMI。
  • EKS 節點： 新增 AL2023 節點群組，停止在新 AL2 節點上排程新的 Pod，驗證叢集附加元件（VPC CNI、CoreDNS、kube-proxy）與 AL2023 AMI 相容，然後在穩定後對 AL2 節點進行 cordon/drain/remove。

貫穿始終的原則：引入新的，在實際條件下驗證，最後移除舊的——在最後一步之前保持復原可用。

5. 驗證是檢查清單，而不是直覺

「共享回來了」不是狀態。請提前決定證明正常是什麼樣子——共享可連線、存在正確的共享清單、測試讀取和寫入都成功——並將這些檢查寫入操作手冊，以便任何執行移轉的工程師都知道成功的確切標準。當您自動化時，這點更加重要：您的 playbook 應該斷言健康狀態，而不是假設它。

6. 在技術之前先繪製人員依賴關係圖

AWS 的步驟很容易在一個下午學會。您無法 shortcut 的一件事是移轉所觸及的人際網絡：擁有 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 文件以取得精確步驟——日期、映像版本和程序會更新，文件是真相的來源。