AWS Storage Gateway（S3 File Gateway）のキャッシュとゲートウェイID を代替インスタンスへ移行するポイント解説【EOL対応】

こんにちは、近藤（りょう）です！

2026年6月30日をもって、AWS Storage Gateway（SGW）の旧バージョンゲートウェイアプライアンス（S3 File Gateway v1.x）のサポートが終了します。既存環境で旧バージョンを利用している場合は、新しいゲートウェイアプライアンスへの移行が必要となります。

今回、S3 File Gateway を Method 1（キャッシュディスクと既存ゲートウェイIDを移行する方式）で移行する機会があり、事前に検証環境を構築して手順を通しで検証しました。

本記事では、S3 File Gateway の移行に向けて実施した検証の流れと、その中で確認したポイントについて紹介します。

docs.aws.amazon.com

AWS Storage Gateway - S3 File Gateway とは？
S3 File Gateway の移行方式について
検証環境の構築と検証フロー
まとめ

AWS Storage Gateway - S3 File Gateway とは？

AWS Storage Gateway は、オンプレミスや EC2 上のアプリケーションから AWS のストレージサービスを利用できるようにするハイブリッドクラウドストレージサービスです。

複数のゲートウェイタイプがありますが、S3 File Gateway は、NFS および SMB プロトコルによるファイルアクセスでバックエンドストレージとして Amazon S3 を利用できます。

S3 File Gateway は、Amazon EFS や Amazon FSx のようなファイル共有サーバーとしての機能（最大 IOPS やスループットの設定など）を備えておらず、多数のユーザーによる同時利用を想定したサービスではありません。

主にバックアップ、ストレージ容量の拡張、データ移行、アーカイブ、災害対策（DR）などの用途で利用されます。

AWS Storage Gateway - AWS Black Belt Online Seminar

Amazon S3 ファイルゲートウェイの仕組み - AWS Storage Gateway

S3 File Gateway の移行方式について

移行方式として以下の2つが紹介されています。

docs.aws.amazon.com

方式	概要
Method 1	既存のキャッシュディスクとゲートウェイ ID を新インスタンスに引き継ぐ
Method 2	新インスタンスで新規に S3 File Gateway・ファイル共有を作成し、クライアントの接続先を切り替える

Method 1 では、既存のゲートウェイ ID やファイル共有設定をそのまま引き継ぐことができるため、ダウンタイムはありますがクライアント側の設定変更を最小限に抑えられるというメリットがあります。

移行時に旧ゲートウェイを削除してプライベート IP アドレスを解放することで、新しいゲートウェイに同じプライベート IP アドレスを割り当てることもできるので今回は Method 1を実施しました。

検証環境の構築と検証フロー

AWS CDKで検証環境を構築して手順を通しで検証しました。構築した構成と検証の流れを紹介します。

■ 留意事項
v1.x 系の旧 SGW を用意して移行元とすることが理想でしたが、検証環境では旧バージョンの AMI が入手できなかった（アクティベーションできなかった）ため、v2 系 SGW から v2 系 SGW への移行という形で手順を検証しています。

移行手順自体（/migrate エンドポイントの動作・ディスクのアタッチ・AD再参加など）は共通です。

環境構成

リソース	内容
VPC	プライベートサブネット + NAT Gateway
Storage Gateway	EC2インスタンス（m5.large）、SGW 公式 AMI
Windows EC2	SMBクライアント（ドメイン参加済み）
Managed Microsoft AD	rehearsal.local ドメイン
S3	ファイル共有のバックエンド
VPC エンドポイント	SGW 用（Interface）、S3 用（Gateway）

前提：移行元の環境

Storage Gateway をアクティベートし、キャッシュディスクの割り当て、Active Directory への参加、SMB ファイル共有の作成を実施した状態を用意します。

また、Windows クライアントから SMB 共有へアクセスし、ファイルの読み書きが可能であることを事前に確認しています。

移行作業

Method 1の移行の詳細は以下をご確認下さい。

docs.aws.amazon.com

なお、移行作業を開始する前に、CachePercentDirty メトリクスが 0 であることを確認してください。

CachePercentDirty は、キャッシュに書き込まれているがまだ S3 にアップロードされていないデータの割合なので、0 でない状態でインスタンスを停止すると未アップロードのデータが失われます。

1. 旧 SGW の AMI 作成（任意）

切り戻しに備え、旧 SGW の AMI を作成します。ルートボリュームとキャッシュディスクの両方を取得します。

※ 念のためバックアップを取得していますが、移行でエラーが発生した場合は、速やかにAWSサポートに問い合わせをしたほうが良いです。

移行中に問題が発生しています。どうすればよいですか?

2. 旧 SGW インスタンスの停止

旧 SGW インスタンスを停止します。インスタンスが stopped 状態になることを確認します。

3. ルートディスクおよびキャッシュディスクのデタッチ

旧 SGW にアタッチされているルートディスクおよびキャッシュディスクをデタッチします。各ボリュームが旧 SGW から外れていることを確認します。

4. 旧 SGW インスタンスの削除

移行完了後、旧 SGWインスタンスを削除します。インスタンスが terminated 状態になることを確認します。

5. 新 SGW インスタンスの起動

新しい SGW インスタンスを起動します。インスタンスが running 状態になることを確認します。

❯ aws ec2 run-instances \
    --image-id ami-08adc185bfb8e0206 \
    --instance-type m5.large \
    --subnet-id <Subnet 指定> \
    --security-group-ids <SG 指定> \
    --key-name <Key 指定> \
    --private-ip-address 172.18.2.93 \
    --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":80,"VolumeType":"gp3"}}]' \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=SGW-New}]' \
    --query "Instances[0].InstanceId" --output text \
    --region ap-northeast-1

参考：利用した起動した SGW のAMI 情報です。

❯ aws ec2 describe-images \
    --image-ids ami-08adc185bfb8e0206 \
    --query "Images[].{ID:ImageId,Name:Name}" \
    --output table \
    --region ap-northeast-1
----------------------------------------------------------------
|                        DescribeImages                        |
+------------------------+-------------------------------------+
|           ID           |                Name                 |
+------------------------+-------------------------------------+
|  ami-08adc185bfb8e0206 |  aws-storage-gateway-FILE_S3-2.1.7  |
+------------------------+-------------------------------------+

6. 旧 SGW ルートディスクおよびキャッシュディスクのアタッチ

旧 SGW のデタッチしたルートディスクおよびキャッシュディスクを新 SGW インスタンスへアタッチします。

7. マイグレーションの実行

新 SGW の /migrate エンドポイントを実行し、マイグレーションを開始します。
※ 新 SGW へ接続ができるサーバーまたは CloudShell から実行してください。

"http://<新 SGW のIP>/migrate?gatewayId=sgw-XXXXXXXX"

正常に完了すると以下のレスポンスが返却されます。

Successfully migrated Storage Gateway.

参考：マイグレーション実行前の SGWの画面

参考：マイグレーション実行後の SGWの画面

8. 旧 SGW ルートディスクのデタッチと再起動

マイグレーション完了後、旧 SGW ルートディスクをデタッチし、新 SGW インスタンスを再起動します。

9. ドメインの再参加

Storage Gateway をドメインへ再参加させます。

❯ aws storagegateway join-domain \
  --gateway-arn <GatewayARN> \
  --domain-name <DomainName> \
  --user-name <UserName>
{
    "GatewayARN": "<GatewayARN>",
    "ActiveDirectoryStatus": "JOINED"
}

詳細は後述しますが、ステータスが JOINED と表示されていても再参加が必要です。

10. SMB 共有の動作確認

最後に Windows クライアントから SMB 共有へアクセスし、既存ファイルの参照および読み書きができることを確認します。

注意事項

移行完了後は、新しい AL2023 ベースのゲートウェイのみを利用してください。

AWS公式ドキュメントによると、AL2 ベースのゲートウェイと AL2023 ベースのゲートウェイを同時に利用すると運用上の問題が発生する可能性することが記載されています。

移行後も AL2 ベースのゲートウェイを引き続き使用できますか?

移行のポイント

検証時に確認したポイントを紹介します。同様の移行を実施する際の参考になれば幸いです。

ポイント① : マイグレーションURLの形式

Storage Gateway のアクティベーション時は、VPC エンドポイントを利用するために vpcEndpoint パラメータを指定していましたが、 /migrate は、エンドポイント実行時は VPC エンドポイントの指定は不要で、以下のURLのみでマイグレーションを実行できました。

マイグレーション時のコマンド例

http://<新 SGW のIP >/migrate?gatewayId=sgw-XXXXXXXX

参考：アクティベーション時のコマンド例

curl -s "http://< SGW の IP >/?activationRegion=ap-northeast-1&gatewayType=FILE_S3&no_redirect&vpcEndpoint=<VPCエンドポイントDNS名>"

ポイント② : 旧ルートディスクのアタッチが必須

新 SGW インスタンスにディスクをアタッチする際は、キャッシュディスクだけでなく旧ルートディスクも必要です。

マイグレーション処理では旧ルートディスクからゲートウェイ設定を読み取るようなので、一時的に新 SGW へアタッチする必要があります。

マイグレーション完了後、旧ルートディスクはデタッチ可能です。

ポイント③ : 「JOINED」の状態でもドメイン再参加が必須

マイグレーション後に describe-smb-settings で確認すると、ActiveDirectoryStatus は JOINED のまま維持されています。

しかし、AWSドキュメントには以下の記載があります。

ステータスが JOINED でも内部的にはAD認証が正常に機能しないため、必ずドメイン参加してください。

ポイント④ : 切り戻し後もドメインの再参加が必要

移行後に Active Directory へ再参加した後に移行前の AMI からリストアを試してみました。

Storage Gateway の AD ステータスは JOINED と表示されていましたが、AD 認証は正常に機能していませんでした。そのため、切り戻し（AMI リストア）後もドメイン参加が必要です。

AMI から復元したインスタンスはアクティベーション操作なしで既存のゲートウェイ IDとして認識されました。

旧ルートディスクにゲートウェイ設定が保持されているようで、切り戻し時にアクティベーションは不要でしたが、ドメインへの再参加は必要でした。

ポイント⑤ : IP アドレスの引き継ぎ

SMB クライアントの再設定を避けるため、旧 SGW と同じプライベートIPアドレスを新 SGW でも利用したい場合があります。

その場合は、旧 SGW インスタンスを終了してIPアドレスを解放した後、新 SGW インスタンス起動時に同じ IP アドレスを指定します。

まとめ

S3 File Gateway v1.x サポート終了に向けた、Method 1（キャッシュディスクと既存ゲートウェイ IDを移行する方式）の移行手順を検証しました。

検証の中では、ドメイン再参加の必要性や旧ルートディスクの取り扱いなど、事前に確認しておきたいポイントを把握することができました。

S3 File Gateway v1.x のサポート終了まで残りわずかですが、まだ移行が完了していない方の参考になれば幸いです。

AWS Storage Gateway（S3 File Gateway）のキャッシュとゲートウェイID を代替インスタンスへ移行するポイント解説【EOL対応】

AWS Storage Gateway - S3 File Gateway とは？

S3 File Gateway の移行方式について

検証環境の構築と検証フロー

環境構成

前提：移行元の環境

移行作業

1. 旧 SGW の AMI 作成（任意）

2. 旧 SGW インスタンスの停止

3. ルートディスクおよびキャッシュディスクのデタッチ

4. 旧 SGW インスタンスの削除

5. 新 SGW インスタンスの起動

6. 旧 SGW ルートディスクおよびキャッシュディスクのアタッチ

7. マイグレーションの実行

8. 旧 SGW ルートディスクのデタッチと再起動

9. ドメインの再参加

10. SMB 共有の動作確認

注意事項

移行のポイント

ポイント① : マイグレーションURLの形式

ポイント② : 旧ルートディスクのアタッチが必須

ポイント③ : 「JOINED」の状態でもドメイン再参加が必須

ポイント④ : 切り戻し後もドメインの再参加が必要

ポイント⑤ : IP アドレスの引き継ぎ

まとめ

GPT-5.6 vs Claude Fable 5 どこが強くてどこが弱い？ベンチマーク比較

マネジメントコンソールから作るRAG 〜Amazon Bedrock Managed Knowledge Base × AgentCore Gateway〜

Claude Code の Skills と Commands の違いを整理して、効率的に使い分ける

Claude Code更新サブエージェント既定バックグラウンド化・誤承認防止【6/29〜7/12】

AIによるGitHubリポジトリの誤操作を防ごう、ブランチ保護＆パーミッションによる2層防御

AWS Storage Gateway - S3 File Gateway とは？

S3 File Gateway の移行方式について

検証環境の構築と検証フロー

環境構成

前提：移行元の環境

移行作業

1. 旧 SGW の AMI 作成（任意）

2. 旧 SGW インスタンスの停止

3. ルートディスクおよびキャッシュディスクのデタッチ

4. 旧 SGW インスタンスの削除

5. 新 SGW インスタンスの起動

6. 旧 SGW ルートディスクおよびキャッシュディスクのアタッチ

7. マイグレーションの実行

8. 旧 SGW ルートディスクのデタッチと再起動

9. ドメインの再参加

10. SMB 共有の動作確認

注意事項

移行のポイント

ポイント① : マイグレーションURLの形式

ポイント② : 旧ルートディスクのアタッチが必須

ポイント③ : 「JOINED」の状態でもドメイン再参加が必須

ポイント④ : 切り戻し後もドメインの再参加が必要

ポイント⑤ : IP アドレスの引き継ぎ

まとめ

GPT-5.6 vs Claude Fable 5 どこが強くてどこが弱い？ベンチマーク比較

マネジメントコンソールから作るRAG 〜Amazon Bedrock Managed Knowledge Base × AgentCore Gateway〜

Claude Code の Skills と Commands の違いを整理して、効率的に使い分ける

Claude Code更新 サブエージェント既定バックグラウンド化・誤承認防止【6/29〜7/12】

AIによるGitHubリポジトリの誤操作を防ごう、ブランチ保護＆パーミッションによる2層防御

Claude Code更新サブエージェント既定バックグラウンド化・誤承認防止【6/29〜7/12】