AWS Application Migration Service（AWS MGN）でオンプレミスサーバーをAWSへ移行する際、インターネットを経由しない閉域構成にしたいケースがあります。このとき迷いやすいのが、S3 VPCエンドポイントとしてGateway型とInterface型のどちらを用意すべきかです。
結論は、通信元を「オンプレミスのソースサーバー」と「AWS上のステージングエリアサブネット」に分けて考えることです。オンプレミスからGateway型を直接利用することはできませんが、VPC内からS3へアクセスする方法はGateway型に限定されず、Interface型も利用できます。
確認日：2026年9月14日。AWS公式ドキュメントでは現在「AWS Transform MGN」と表記されています。本記事ではMGNと略し、主にオンプレミスからEBSを利用する通常の移行構成を扱います。
結論：VPC内からはGateway型・Interface型のどちらも選択できる
| 通信元 | 用途 | 閉域時に検討するS3エンドポイント |
|---|---|---|
| オンプレミスのソースサーバー | Replication Agentインストーラーなどへのアクセス | Interface型 |
| AWSのステージングエリアサブネット | レプリケーションサーバーからS3へのアクセス | Gateway型またはInterface型（DNS・経路・ポリシーなどの要件を満たす構成） |
MGN用のInterface VPCエンドポイントだけを作れば完了、あるいはS3 Gatewayエンドポイントだけあれば完了、とは限りません。
MGNのネットワーク通信を2つに分けて理解する
1. ソースサーバーからAWSサービスへの通信
オンプレミスのソースサーバーに導入したAWS Replication Agentは、MGN APIへTCP 443で継続的に通信します。また、Agentインストーラー取得などのためにS3へのアクセスも考慮が必要です。
オンプレミスからAWSサービスのパブリックエンドポイントへのHTTPS通信を許可しない場合、MGNとS3のInterface VPCエンドポイントをVPC側に作成し、Direct ConnectまたはVPN経由で接続します。
2. ステージングエリアサブネットからS3への通信
MGNがAWS側に作成するレプリケーションサーバーは、ステージングエリアサブネットに配置されます。このサブネットにNAT Gatewayなどのインターネット向け経路がない場合、S3への経路としてGateway VPCエンドポイントを使用できます。
ただし、ステージング側はGateway型が必須、Interface型では利用不可という意味ではありません。S3 Interface型はVPC内からのアクセスにも対応しています。Interface型を利用する場合は、MGNが実際に使用するS3ホスト名が適切なEndpoint ENIへ解決され、そのENIまでの経路・TCP 443・エンドポイントポリシーが必要なアクセスを許可することを確認します。
Gateway型を使う構成例とInterface型を使う場合の違い
AWS Prescriptive Guidanceの閉域構成例は、オンプレミス側にS3 Interface型、ステージング側にS3 Gateway型を使う構成です。本記事でもこの構成例を紹介していますが、S3 Interface型のVPC内利用を否定する一般的な制約として扱うものではありません。
S3のPrivate DNSで「インバウンドResolverエンドポイントのみに対してプライベートDNSを有効にする」を選ぶ場合は、Gateway型の併設が必要です。一方、VPC内のS3通信もInterface型へ向ける場合は、この「インバウンドのみ」の設定を解除し、VPC内にもPrivate DNSが適用される構成を検討します。独自DNSを使う場合は、その転送・名前解決も含めて確認してください。Gateway型が必要になるこのDNS設定の条件と、MGN全体の必須条件を混同しないことが重要です。
閉域MGNの構成要素
以下は、オンプレミス側にInterface型、ステージング側にGateway型を使う構成例の確認項目です。ステージング側もInterface型を使う場合は、S3の経路・DNS・アクセス制御の項目をその構成に合わせて読み替えます。
- MGNのInterface VPCエンドポイント（ソースサーバー・ステージングエリアから接続）
- EC2のInterface VPCエンドポイント（ステージングエリアからEC2 APIへ接続）
- S3のInterface VPCエンドポイント（オンプレミス向け。構成によってはステージング側も利用）
- S3のGateway VPCエンドポイント（この構成例でのステージングサブネット向け）
- Route 53 Resolverインバウンドエンドポイント
- オンプレミスDNSからAWS側への条件付きフォワーダー
- Direct ConnectまたはSite-to-Site VPN
- 必要なTCP 443とレプリケーション通信用ポート
オンプレミス側でAWSサービスのDNS名をInterface VPCエンドポイントのプライベートIPへ解決させるには、DNS設計が重要です。Route 53 Resolverインバウンドエンドポイントを作るだけでなく、オンプレミスDNSから適切に問い合わせを転送する必要があります。
S3エンドポイントポリシーの注意点
ステージングエリアサブネットがインターネットへ出られない場合、Gateway型・Interface型のどちらでも、エンドポイントポリシーを過度に制限すると、レプリケーションサーバーが必要なパッケージを取得できず、処理に失敗する可能性があります。
特に、MGNが利用するOSパッケージリポジトリのS3バケットが許可対象に含まれているか確認してください。バケット名や必要なリソースARNはリージョンやAWSドキュメントの更新によって変わり得るため、構築時点の公式ネットワーク要件を参照するのが安全です。
よくある設計ミス
S3 Gatewayエンドポイントだけでオンプレミスから接続しようとする
Gateway型VPCエンドポイントはVPCのルートテーブルを利用する仕組みであり、オンプレミスから直接利用する用途には対応しません。オンプレミスから閉域でS3へ接続する場合はInterface型を使います。
Interface型だけを作り、ステージング側の経路を確認しない
オンプレミスからのAPI通信が成功しても、ステージングサブネットからS3へ到達できなければ移行処理は完了しません。Gateway型を使う場合は、ステージングサブネットのルートテーブルにS3向けの経路があるか確認します。Interface型を使う場合は、実際のS3ホスト名の名前解決結果、Endpoint ENIへの経路、ENI側SGのTCP 443許可を確認します。Interface型だけであること自体が設計ミスなのではなく、ステージング側から必要なS3接続先へ到達できるかが確認点です。
DNSとセキュリティグループを見落とす
Interface型はENIに設定したセキュリティグループでHTTPSを許可する必要があります。Interface型を使う通信では、DNSが意図したENIのIPを返しているか確認します。S3 Gateway型ではパブリックIPに解決されても利用できるため、両者を混同しないでください。
TCP 443とTCP 1500を別々に確認する
API通信とレプリケーション通信は別経路です。ソースサーバーからMGN APIへはTCP 443、ソースサーバーからステージングエリアのレプリケーションサーバーへはTCP 1500が必要です。MGN用Interfaceエンドポイントに1500番を開けても、レプリケーション先サーバーへの疎通確認にはなりません。
プライベート経路でデータを転送する場合は、レプリケーション設定の「Use private IP」を確認し、パブリックIP作成の設定も閉域要件と合わせます。往路だけでなく、ステージング側からオンプレミスへの戻り経路も確認してください。
S3ポリシーではAL2023リポジトリも確認する
MGN用バケットだけを許可する構成では、Amazon Linux 2023のパッケージ取得が抜ける場合があります。公式の接続要件にあるMGN関連、ハッシュ、SSM、AL2023リポジトリのバケット一覧を、対象リージョンに置き換えて照合してください。
AL2023リポジトリはdual-stack形式のS3ホスト名を使用します。エンドポイントポリシーが許可していても、DNSが返すアドレスと実際のIP経路が一致しなければ接続できません。ポリシーと通信経路を別々に確認します。
試験結果を残すための確認表
| 試験元 | 確認先 | 残す結果 |
|---|---|---|
| ソースサーバー | MGN・S3の実際のホスト名 | 名前解決先、TCP 443の可否、Agent導入ログ |
| ソースサーバー | レプリケーションサーバーのプライベートIP | TCP 1500の可否、レプリケーション開始・進捗 |
| ステージング側 | MGN・EC2・必要なS3バケット | エンドポイント関連付け、SG、ポリシー、起動・変換処理の結果 |
| テスト起動先 | 業務で必要な接続先 | DNS、認証、監視、アプリケーション疎通 |
テストインスタンスの起動成功と業務移行の成功は分けて判定します。閉域環境では、起動後に必要な管理ツール、パッケージ、Active Directoryなどへの経路も試験項目に含めてください。
構築時のチェックリスト
- ソースサーバーからMGN APIの名前解決とTCP 443接続ができる
- ソースサーバーからS3 Interfaceエンドポイントへ接続できる
- ステージング側から必要なS3接続先へ到達できる（Gateway型ならルートテーブル、Interface型ならDNS・ENIへの経路・SGを確認）
- S3エンドポイントポリシーがMGNに必要なバケットを許可している
- Interfaceエンドポイントのセキュリティグループが実際の接続元からのTCP 443を許可している（オンプレミス、およびInterface型を使うステージング側）
- レプリケーション用ポートの通信要件を満たしている
まとめ
AWS MGNの閉域移行で必要なのは、各通信元から必要なS3接続先へアクセスできることです。オンプレミスからGateway型を直接利用することはできませんが、VPC内のステージング側ではGateway型・Interface型のどちらも選択肢になります。オンプレミス側にInterface型、ステージング側にGateway型を使うのは構成例の一つであり、Gateway型が一律必須という意味ではありません。
さらにMGNのInterfaceエンドポイント、DNS転送、ルートテーブル、セキュリティグループ、エンドポイントポリシーを一体で確認すると、Agent導入やレプリケーション開始後の接続トラブルを減らせます。
参考資料
- AWS PrivateLink for Amazon S3（VPC内からのInterface型利用とPrivate DNS設定）
- Network requirements for MGN
- 制限付きレプリケーションのアーキテクチャ
関連記事
DNSによる経路の選ばれ方はS3 Gateway型とInterface型を併用した場合の動作、共有ストレージの経路設計はFSx for ONTAPのルート数の計算を参照してください。
複数アカウントへ移行する場合
アカウントごとの初期設定を揃える際は、MGNのOrganizations連携・Global viewとテンプレートの使い分けも確認してください。既存サーバーへの設定反映と、新規サーバーの標準値を分けて整理できます。
