Amazon Linux 2の標準サポート終了日は2026年6月30日で、既に期限が過ぎました。AL2ベースのStorage Gatewayアプライアンスをまだ運用している場合、サポート対象外の期間に入っており、以下にその対処方法を説明します：AWSがサポートする方法と、スムーズに進めるための運用上のポイントです。

AWS Storage Gatewayを利用している場合、既にロードマップを変えた期限があります — それは後ろに残っています：* Amazon Linux 2（AL2）は2026年6月30日に標準サポートを終了します。* その日は過ぎたため、AL2ベースのゲートウェイアプライアンスはソフトウェアアップデート、セキュリティパッチ、バグ修正の提供を受けられなくなっています。運用は継続できますが、保守は自己責任となり、コンプライアンスや監査の義務がある環境では、この期間の1日ごとにリスクが積み重なっていきます。

Storage Gatewayを特に取り上げる理由は、この移行において通常のEC2ワークロードとは異なる動作をするためです。単純なEC2インスタンスであればAMIを再作成して再デプロイできますが、Storage GatewayにはAL2からAL2023へのインプレースアップグレードパスはありません — アプライアンスOSはAWSが管理しており、AL2023への移行はゲートウェイのインスタンスを置き換えることで行い、パッチ適用ではありません。

これは計画と教訓をまとめたガイドであり、クリックバイクリックの正確な手順書ではありません（正確なコマンドはAWSの公式ドキュメントにあり、以下にリンクします）。目的は移行の全体像と運用判断を提供することで、1つのゲートウェイでも大規模なフリートでも、事前に状況を把握した上で進められるようにすることです。

タイムラインと現在の状況

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つの方法を提供しており、クロスチェックのために複数を使用することを推奨します：

  • Detailsタブでは、影響を受けるゲートウェイに非推奨メッセージが表示されます。
  • DescribeGatewayInformation APIは非推奨日フィールドを公開しており、多数のゲートウェイを一度にスキャンするプログラム的な方法です。
  • AWS Health DashboardのAffected resourcesタブで影響を受けるゲートウェイを確認できます。

多数のゲートウェイがある場合はAPIを活用し、すべてのアカウントとリージョンにわたってスクリプトでチェックしてください。コンソールをクリックして確認するのではなく、これらの移行で共通するのは、インベントリを取らないために失敗することです。忘れていたゲートウェイは移行できません。

AWSがサポートする移行アプローチ

AWSはS3 File Gateway向けに、キャッシュディスクと現在のゲートウェイIDを保持する置き換え手順をドキュメント化しています。ここで重要なのはゲートウェイIDを保持することで、ファイル共有、その名前、設定を移行中に維持できることです。概念的なフローは以下の通りです：

  1. アプリケーションを停止して、交換中に書き込みが発生しないようにします。
  2. 最新のゲートウェイイメージから新しいAL2023ゲートウェイインスタンスをデプロイします。
  3. キャッシュディスクを古いインスタンスからデタッチし、新しいインスタンスにアタッチします。
  4. 移行APIコールを実行して、既存のゲートウェイIDと設定を新しいインスタンスに引き継ぎます。
  5. 結果を確認 — 共有が存在し、利用可能で健全であることを確認します。

ドキュメント上の制約が2つあります：データは同じゲートウェイタイプ間でのみ移動でき、記載された移行手順はアプライアンスバージョン2.x向けであり、古いバージョンには使用できません。事前作業として現在のバージョンを確認しておく必要があるかもしれません。

正確なコンソール操作やAPIパラメータはここでは意図的に再現していません。AWSは最新の権威あるバージョンを常に更新しています。既存のS3 File Gatewayを新しいインスタンスで置き換えるには、「Storage Gateway AL2 to AL2023 Migration Campaign」の移行前チェックリスト（末尾にリンク）から始め、記載された手順を厳密に遵守してください。

少数の場合の自動化

停止-デタッチ-アタッチ-移行-検証の手順は、1〜2台のゲートウェイであれば手動でも問題ありませんが、数十〜数百台、複数のアカウントやリージョンにまたがる場合は遅く、エラーが発生しやすいです。

AWSはStorage Gateway Terraformモジュール内にAL2からAL2023へのアップグレードを自動化する移行例と、ディスクスワップおよび移行APIステップをオーケストレーションする対応するAnsibleプレイブックをリリースしています。この組み合わせにより、フリート全体に対して再現性があり、監査可能でスケーラブルなパスを提供します。実運用規模で運用している場合は、エンジニアに数週間の手動カットオーバーを任せる前にIaCルートを検討してください。監査可能性（変更内容とタイミングの正確なgit履歴）だけでも、規制環境では価値があります。

知っておくべき重要な教訓

上記の仕組みは全体の20%に過ぎません。移行の成否を分けるのは以下です：Storage Gatewayを超えて広く適用可能な原則です。

  1. カットオーバー全体で最も重要な要素はゲートウェイです

移行は基盤となるインスタンスを置き換えるため、ゲートウェイのIPアドレスが変更されます。 これが問題にならないか火災訓練になるかは、1つの質問にかかっています：クライアントはDNS名で接続しているか、ハードコードされたIPアドレスで接続しているか？

  • クリーンなDNSクライアントの場合：新しいインスタンスが起動したら、メンテナンスウィンドウ中にDNSレコードを1つ変更するだけで、クライアントは同じホスト名を使い続け、何も移動したことに気づきません。
  • 問題となるケースはIPハードコードのクライアントです。新しいIPは、古いアドレスを指していたすべてのクライアントが更新されるまで何も指さない状態になります。これらの更新は別のチームが別のスケジュールで実施することが多く、そのタイムラインがあなたの作業に影響します。

*何かを移行する前に、各クライアントの接続方法をインベントリしてください。そして、IPが残っている箇所を適切なDNS名に置き換えることを移行の強制力として活用してください — そうすれば次のライフサイクルイベントは、フリート全体へのプッシュではなく、1行のDNS変更で済みます。これがこの作業全体で最もレバレッジの高い習慣です。

2. 古いインスタンスを変更せず、イミュータブルインフラストラクチャとして扱う

この種の移行に最適なメンタルモデルは置き換え、変更しないです。古いAL2インスタンスはロールバックのベースラインです。これがまさに、保護しようとしていたものを壊す原因になります。本番アプライアンスへの小さなOSレベルの調整で「動作させる」のは避けましょう。新しいAL2023インスタンスをクリーンに構築し、カットオーバーし、古いインスタンスは安全網として untouched のままにしておきます。

3. ロールバック用に古いインスタンスを残すため、早めに削除しない

置き換えと予約戦略の最大の利点は、* バックアウト計画が「古いインスタンスが停止した状態で残っている」 ことです。キャッシュディスクは移動しましたが、インスタンス自体は無事です。

カットオーバー後、一定期間、古いインスタンスを停止状態で残すことをルールにしてください — 実負荷がかかって1〜2日後に問題が発生した場合でも、ゼロからプロビジョニングせずにロールバックできる期間を確保します。数週間のEBSストレージで安心して眠れます。変更計画に保持期間を明記し、善意のクリーンアッププロセスがカットオーバー後3時間で安全網を削除しないようにしてください。

4. ステートフルとステートレスワークロードの異なるアプローチ

Storage Gatewayはステートフル — キャッシュデータを保持する必要があるため、ディスクとゲートウェイIDの方法が存在します。より広範なAL2環境に他のワークロードタイプが含まれる場合、1つのプレイブックをすべてに適用しないでください：

ステートフルEC2：複数インスタンス、データ同期の検証、DNSカットオーバーの管理。

  • Auto Scaling Groups： AL2023 AMIを新しいカナリアとガード付きインスタンスリフレッシュでデプロイ。
  • EKSノード： AL2023ノードグループを追加し、AL2ノードへの新規Podスケジューリングを停止し、クラスタアドオン（VPC CNI、CoreDNS、kube-proxy）がAL2023 AMIと互換性があることを検証し、安定後にAL2ノードをcordon/drain/remove。

共通の考え方：新しいものを導入し、実環境で検証し、古いものを最後に削除 — 最終ステップまでロールバックを可能にしておく。

5. 検証はチェックリストであり、勘ではない

「共有が戻ってきた」はステータスではありません。事前に証明された健全性の定義を決めましょう — 共有が到達可能、正しい共有リストが存在、テスト読み書きが成功 — これらのチェックをランブックに書き込み、カットオーバーを実行するエンジニアが成功の基準を正確に理解できるようにします。これは自動化する場合に特に重要です：プレイブックは健全性を仮定せず、アサートする必要があります。

6. 技術的依存関係の前に人的依存関係をマッピングする

AWSの手順は午後で習得可能です。ショートカットできないのは、カットオーバーが関わる人々のネットワークです：DNSを管理する人、IPハードコードクライアントに設定をプッシュする人、事後検証が必要なアプリケーション所有者（事前に共有が一時停止することを伝える必要がある）、高リスクの波についてはAWSサポートまたはTAM。触れる前に各ゲートウェイごとに依存関係マップを作成し、「メンテナンスウィンドウ中に誰が行動する必要があるか」を計画の第一級の要素にしてください。

7. 期限を超えて — リスク順序と計画的な移動

ゲートウェイごとの技術的作業は小さいですが、チームを横断して本番変更をスケジュールする組織的な作業に時間がかかります。しかし2026年6月30日が過ぎた今、「早い」はもう存在しません — しかしそれは雑に急ぐ理由にはなりません。正しい答えはトリアージです：サポート対象外状態で最もリスクが高いゲートウェイ（インターネット接続、コンプライアンス範囲、最高のデータ機密性）を特定し、それらを最初に変更ウィンドウに組み込み、制御された順序でフリートを処理します。圧縮された緊急性 + 組織化された順序 ＞ パニックまたは自己満足。

要点

Amazon Linux 2は標準サポートを終了し、期限を過ぎました。AL2ベースのStorage Gatewayはまだ存在しているでしょうか？良いニュースは、AL2023への技術的移行は本当に難しい部分ではないということです — AWSの置き換えと保持の方法は、ゲートウェイID、キャッシュデータ、共有設定をそのまま維持し、フリート規模で実行するためのIaCツールも利用可能です。

難しい部分はそれ以外です：影響を受けるゲートウェイを正確に把握すること、クライアントが実際にどのように接続しているか（DNSまたはIP）、カットオーバー中に実際のロールバックパスを維持すること、メンテナンスウィンドウ内にアクションが発生する人々を調整すること。AWSドキュメントの仕組みに従えば、OSの交換は本来あるべき簡単なステップになります。それを期待してください。

信頼できる情報源

  • 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ドキュメントを参照してください — 日付、イメージバージョン、手順は更新されており、ドキュメントが信頼できる情報源です。