【2026年6月期限】AWS Storage Gateway（S3 File Gateway）をAL2→AL2023に移行してみた

Posted at 2026-06-02

はじめに

AWSは、Storage Gatewayアプライアンスの基盤OSを**Amazon Linux 2（AL2）からAmazon Linux 2023（AL2023）**へ移行するキャンペーンを実施しています。
2026年6月30日を過ぎると、AL2ベースのゲートウェイはソフトウェア更新・セキュリティパッチ・AWSサポートの提供が終了します。

ゲートウェイタイプ	移行前（AL2）	移行後（AL2023）
S3 File Gateway	Version 1.x	Version 2.x
Tape Gateway	Version 2.x	Version 3.x
Volume Gateway	Version 2.x	Version 3.x

本記事では、EC2上で稼働するS3 File Gateway（SMB） を対象に、キャッシュディスク＋Gateway IDを引き継ぐ方式 で実際に移行した手順と、公式ドキュメントだけでは分かりにくかったポイントをまとめます。

対象読者

Storage Gatewayの移行対象を抱えているインフラエンジニア
公式ドキュメントを読んだが、実作業のイメージが湧かない方
EC2ベースのS3 File Gatewayを運用中の方

環境情報

項目	値
ゲートウェイタイプ	S3 File Gateway（SMB）
ホスト	Amazon EC2
移行前バージョン	Version 1.x（AL2ベース）
移行後バージョン	Version 2.x（AL2023ベース）
リージョン	ap-northeast-1
移行方式	キャッシュディスク＋Gateway ID引き継ぎ

背景：なぜ移行が必要なのか

移行タイムライン

日付	イベント
2025/10/28	新規デプロイがデフォルトでAL2023に
2026/01/05	新規AL2ゲートウェイのアクティベーション制限開始
2026/06/30	AL2ゲートウェイのサポート終了（EOL）

移行しないとどうなる？

ゲートウェイ自体は動作し続けますが、セキュリティパッチ・バグ修正・ソフトウェアアップデートは一切提供されません
AWSサポートも終了するため、障害発生時の支援を受けられません

移行が必要かどうかの確認方法

AWSコンソール: ゲートウェイの「詳細」タブに非推奨メッセージが表示される

AWS CLI:

aws storagegateway describe-gateway-information \
  --gateway-arn <your-gateway-arn>

レスポンスに DeprecationDate フィールドがあれば移行対象

AWS Health Dashboard: 「影響を受けるリソース」タブで確認

移行方式の選択

S3 File Gatewayには2つの移行方式があります。

	Method 1: キャッシュディスク＋Gateway ID引き継ぎ	Method 2: 新規キャッシュ＋新規Gateway ID
キャッシュデータ	保持される（再ダウンロード不要）	S3から再ダウンロード
ダウンタイム	1〜2時間	短い（カットオーバー時のみ）
Gateway ID	引き継ぎ（既存と同じ）	新規発行
S3追加コスト	なし	S3データ取得コストが発生する可能性あり
向いているケース	大容量キャッシュ、読み取り重視	書き込み重視、キャッシュ小

今回はGateway IDを変えたくない＋キャッシュ容量が大きいため、Method 1 を採用しました。

💡 Method 1を選んだ理由: Gateway IDが変わらないため、ファイル共有設定やクライアント側のマウント設定（接続先IP、認証情報）を変更せずに済む点が大きいです。

全体フロー

移行の全体フローは以下の通りです。

#	ステップ	概要	ダウンタイム
1	事前確認	ファイル共有ステータス・マウント確認	なし
2	バックアップ取得	CLIで設定情報をJSON保存	なし
3	SGW更新＋業務停止	ソフトウェア更新・ジョブ停止・CachePercentDirty=0確認	開始
4	旧SGW停止・ディスク取り外し	EC2停止・リネーム・EBSデタッチ	↓
5	新SGW作成	AL2023で新EC2起動	↓
6	旧ディスクアタッチ	旧ルートディスク＋キャッシュアタッチ	↓
7	マイグレーション実行	curl → 旧ルート取り外し → 再起動 → SMBパスワード再設定	↓
8	旧SGW削除	旧EC2削除	↓
9	ENIアタッチ	新SGWにENIをアタッチ	終了
10	動作確認	マウント・ファイル配信テスト	なし
11	事後作業	旧ルートディスク削除	なし

Step 1〜3: 事前準備

Step 1: 事前確認

Storage Gatewayコンソールで対象ゲートウェイのファイル共有ステータスが「利用可能」であることを確認します。

また、クライアントサーバーからSMBマウントが正常にできることを確認しておきます。

Step 2: バックアップ取得

⚠️ Storage GatewayはAMIからの復元ができないため、設定情報をバックアップする。

# 1. ゲートウェイ情報のバックアップ
aws storagegateway describe-gateway-information \
  --gateway-arn arn:aws:storagegateway:ap-northeast-1:[AWSアカウントID]:gateway/[GatewayID] \
  > describe-gateway-information_backup.json

# 2. SMB設定のバックアップ
aws storagegateway describe-smb-settings \
  --gateway-arn arn:aws:storagegateway:ap-northeast-1:[AWSアカウントID]:gateway/[GatewayID] \
  > describe-smb-settings_backup.json

# 3. SMBファイル共有設定のバックアップ
aws storagegateway describe-smb-file-shares \
  --file-share-arn-list \
    arn:aws:storagegateway:ap-northeast-1:[AWSアカウントID]:share/[FileShareID-1] \
    arn:aws:storagegateway:ap-northeast-1:[AWSアカウントID]:share/[FileShareID-2] \
  > describe-smb-file-shares_backup.json

Step 3: SGW更新＋業務停止＋ダーティキャッシュ確認

ソフトウェア更新: Storage Gatewayコンソールで「今すぐ更新」が表示されていたら実行。
業務停止: 対象SGWに書き込むアプリケーション・ジョブをすべて停止
CachePercentDirty = 0 の確認: コンソール > 対象ゲートウェイ > 「モニタリング」タブで確認

⚠️ CachePercentDirty が0でない状態で進めると、キャッシュ上の未同期データが失われる可能性があります。

Step 4〜9: 移行

Step 4: 旧SGW EC2の停止・ディスク取り外し

4.1 旧SGW EC2を停止

aws ec2 stop-instances --instance-ids [旧SGWインスタンスID]

旧SGWの名前を sgw_old にリネームし、新旧を区別できるようにします。

4.2 EBSボリュームをすべてデタッチ

ルートディスクとキャッシュディスクの両方をデタッチします。

# ルートディスクのデタッチ
aws ec2 detach-volume --volume-id [旧ルートディスクのボリュームID]

# キャッシュディスクのデタッチ
aws ec2 detach-volume --volume-id [旧キャッシュディスクのボリュームID]

📝 以下の情報を必ず控えてください。後のステップで使います。

ルートディスクのボリュームID（→ Step 6, 7.4 で使用）

キャッシュディスクのボリュームID（→ Step 6 で使用）

ゲートウェイID sgw-XXXXXXXX（→ Step 7.1 で使用）

Step 5: 新SGW EC2の作成

🔴 EC2コンソールから直接インスタンスを起動するのではなく、Storage Gatewayコンソールから作成ウィザード経由で起動します。ただし、Storage Gatewayのアクティベーションは行いません。

5.1 Storage Gatewayコンソールでゲートウェイ作成を開始

Storage Gateway コンソール > ゲートウェイの作成 で以下を設定し、「次へ」：

設定項目	値
ゲートウェイ名	`sgw_new`
ゲートウェイタイプ	Amazon S3 ファイルゲートウェイ
ホストプラットフォーム	Amazon EC2

5.2 「インスタンスの起動」からEC2を作成

ウィザード内の「EC2インスタンスを起動」ボタンをクリックし、EC2の設定画面に遷移します。

設定項目	値	備考
名前	`sgw`
AMI	ウィザードが指定する最新AL2023 AMI	自動選択される
インスタンスタイプ	旧SGWと同じ
キーペア	旧SGWと同じ
VPC / サブネット	旧SGWと同じ
セキュリティグループ	旧SGWと同じ
パブリックIPの自動割り当て	無効
ストレージ	ルートディスクのみ	キャッシュディスクは追加しない（後で旧のをアタッチ）

EC2を起動します。

新SGWが起動したら、プライベートIPをコピーし、踏み台等からポート80への疎通を確認します。

# PowerShellから実行
Test-NetConnection [新SGWのプライベートIP] -Port 80

5.3 SGWウィザードに戻って確認画面まで進む

Storage Gatewayコンソールのウィザードに戻ります。

「上記のすべてのステップを完了し、EC2インスタンスを起動しました。」にチェック → 次へ
IPアドレスに新SGWのプライベートIPを入力
エンドポイントのオプションを設定 → 次へ

5.4 ⚠️ 確認画面で止める — アクティベーションしない！

確認画面（アクティベーション画面）が表示されますが、何もクリックせず、画面を閉じます。

🔴 ここでアクティベーションしてしまうと、新しいGateway IDが発行され、旧ゲートウェイのIDを引き継ぐMethod 1の移行ができなくなります。やり直しが非常に面倒なので、最大限の注意を。

Step 6: 旧ディスクを新SGWにアタッチ

公式では「旧ゲートウェイからディスクを外して新インスタンスにアタッチ」とだけ書かれていますが、これを読んで「新SGWのルートディスクを外して旧ルートをルートとしてアタッチするのか？」と思うかもしれません。

実際には、新SGWのルートディスクはそのまま残し、旧ルートディスクはセカンダリデバイスとしてアタッチします。

6.1 旧ルートディスクを「セカンダリ」としてアタッチ

# /dev/xvda（ルート）ではなく /dev/xvdf など別のデバイス名でアタッチ
aws ec2 attach-volume \
  --volume-id [旧ルートディスクのボリュームID] \
  --instance-id [新SGWインスタンスID] \
  --device /dev/xvdf

後続の移行用 curl コマンドを実行すると、マイグレーションAPIが旧ルートディスクからゲートウェイ設定を自動的に読み取って移行してくれるため、ルートに差し替える必要はありません。

6.2 旧キャッシュディスクをアタッチ

aws ec2 attach-volume \
  --volume-id [旧キャッシュディスクのボリュームID] \
  --instance-id [新SGWインスタンスID] \
  --device /dev/sdb

6.3 アタッチ確認

EC2コンソール > 対象インスタンス > 「ストレージ」タブで、以下の3つのボリュームがアタッチされていることを確認します。

デバイス名	内容
`/dev/xvda`	新SGWのルートディスク（そのまま残す）
`/dev/xvdf`	旧SGWのルートディスク（セカンダリとしてアタッチ）
`/dev/sdb`	旧SGWのキャッシュディスク

Step 7: マイグレーション実行

7.1 curlコマンドでマイグレーション開始

curl "http://[新SGWのプライベートIP]/migrate?gatewayId=[旧SGWのゲートウェイID]"

成功すると以下のメッセージが返ります：

Successfully migrated Storage Gateway.

📝 ゲートウェイIDは sgw-XXXXXXXX 形式です。sgw- のプレフィックスを含めてそのまま指定します。

7.2 ゲートウェイステータスの確認

Storage Gatewayコンソールで、対象ゲートウェイのステータスが 「実行中」 になることを確認します。

最大10分程度かかることがあるので焦らず待ちます。ブラウザを何度かリロードして確認してください。

7.3 新SGWを一旦停止

aws ec2 stop-instances --instance-ids [新SGWインスタンスID]

7.4 旧ルートディスクのみデタッチ

マイグレーション完了後、セカンダリとしてアタッチしていた旧ルートディスクのみをデタッチします（Step 4.2でメモしたボリュームIDを使用）。

# 旧ルートディスクのデタッチ（⚠️ キャッシュディスクは外さない！）
aws ec2 detach-volume --volume-id [旧ルートディスクのボリュームID]

⚠️ キャッシュディスクは絶対に外さないでください。 キャッシュを外すとS3からの再ダウンロードが必要になり、追加コスト＋長時間のダウンタイムが発生します。

この時点でのボリューム構成：

デバイス名	内容
`/dev/xvda`	新SGWのルートディスク
`/dev/sdb`	旧SGWのキャッシュディスク（引き継ぎ）

7.5 新SGWを再起動

aws ec2 start-instances --instance-ids [新SGWインスタンスID]

7.6 SMBゲスト認証パスワードの再設定

🔴マイグレーション後、SMBのゲストパスワードがリセットされます。再設定しないとクライアントからマウントできません。

Storage Gatewayコンソールで以下を実施：

対象ゲートウェイを選択
アクション > SMB設定の編集
「ゲストアクセス設定」でパスワードを入力して保存

Step 8: 旧SGW削除

8.1 旧SGW EC2（`_old`）の情報をメモ

EC2 > インスタンス画面から旧 Storage Gateway を選択します。

インスタンスIDをメモする
「ネットワーキング」タブを選択し、ENIのインターフェイスIDをメモする

8.2 ENIの終了時の動作を変更

ENIをクリックして詳細画面に遷移し、以下を実施します：

アクション > 終了時の動作を変更 をクリック
「インスタンスの削除時に削除」の有効化チェックを外す
保存

⚠️ 設定反映されるまでに時間がかかる場合があります。反映を確認してから次のステップに進んでください。

これにより、EC2インスタンスを削除してもENIが残り続けるようになります。

8.3 旧SGW EC2を削除（Terminate）

「インスタンスの状態」>「インスタンスを終了（削除）」を実行します。

Step 9: ENIを新SGWにアタッチ

EC2 > インスタンス画面から新 Storage Gatewayを選択し、以下を実施：

「アクション」>「ネットワーキング」>「ネットワークインターフェイスをアタッチ」を選択
VPCを選択
Step 8.2で控えた旧SGWのENIを選択
「アタッチ」を実行

これで新SGWがセカンダリENIとして旧SGWのIPアドレスを持つようになり、クライアントからは従来通りのIPでアクセスできます。

Step 10: 動作確認

ファイル共有ステータス確認

Storage Gatewayコンソールで、すべてのファイル共有のステータスが 「利用可能」 であることを確認します。

SMBマウント確認

クライアントサーバーから、旧SGWのIPアドレス（ENIで引き継いだIP）でマウントできることを確認します。

⚠️ 旧SGWに利用したIPで動作確認を実施してください。新SGWのプライマリIPではなく、ENIでアタッチした旧IPで接続できることがポイントです。

# SMBマウント（旧IPを使用）
net use Y: \\[旧SGWのプライベートIP]\[共有名] /user:smbguest [パスワード]

# マウント確認
dir Y:\

テストファイルの書き込み・読み取りが正常にできることを確認します。

アンマウント

動作確認が完了したら、テスト用のマウントを解除します。

net use Y: /delete

確認チェックリスト

テスト項目	確認内容	期待結果
ファイル共有ステータス	コンソールで確認	「利用可能」
SMBマウント	旧IPで `net use`	成功
テストファイル書き込み	SGW共有への書き込み → S3同期	正常
テストファイル読み取り	S3上のファイルをSGW共有から取得	正常
CachePercentDirty	送信後に収束	0

Step 11: 事後作業

旧ルートディスクの削除

Step 7.4でデタッチした旧ルートディスクは、動作確認が十分に完了した後に削除します。

aws ec2 delete-volume --volume-id [旧ルートディスクのボリュームID]

注意点・ハマりどころまとめ

🔴 1. 旧ルートディスクはセカンダリとしてアタッチ

公式ドキュメントには「旧ゲートウェイからディスクを外して新インスタンスにアタッチ」としか書かれていないため、新SGWのルートを外して旧ルートを差し替えるのかと思いがちです。

実際には：

新SGWのルートディスクはそのまま残す
旧ルートは /dev/xvdf 等の別デバイス名でセカンダリとしてアタッチ
curl /migrate 実行で、マイグレーションAPIが旧ルートからゲートウェイ設定を自動読み取り
移行完了後に旧ルートをデタッチして完了

🔴 2. アクティベーションは絶対にしない

SGWコンソールの作成ウィザードは、ポート80の疎通確認まで進めますが、最後のアクティベーション画面で止めて閉じます。
アクティベーションすると新しいGateway IDが発行されてしまい、Method 1（旧ID引き継ぎ）の移行ができなくなります。

🔴 3. SMBゲストパスワードはリセットされる

公式に明記されていませんが、マイグレーション後にSMBのゲストパスワードが空になります。
再設定しないと、クライアントからのマウントが**「アクセスが拒否されました」**で失敗します。

🟡 4. CachePercentDirtyは必ず0で

移行前に CachePercentDirty が0でない状態で進めると、S3に未同期のデータが失われるリスクがあります。
ジョブ停止後、メトリクスが0に収束するまで必ず待ってから次のステップに進んでください。

🟡 5. AL2への切り戻しは不可

AWS公式が明言していますが、AL2023に移行後、AL2ゲートウェイに戻すと運用上の問題が発生する可能性あります。移行は一方通行です。

参考ドキュメント

ドキュメント	URL
Storage Gateway AL2→AL2023 移行キャンペーン	https://docs.aws.amazon.com/ja_jp/storagegateway/latest/vgw/al2-to-al2023-migration.html
S3 File Gateway 移行ガイド	https://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/migrate-data.html
ゲートウェイアプライアンスリリースノート	https://docs.aws.amazon.com/filegateway/latest/files3/release-notes.html
DescribeGatewayInformation API	https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_DescribeGatewayInformation.html

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up