こんにちは、やまぐちです。
概要
今回は、AWS Application Migration Service（以下 MGN）を利用する際のネットワーク要件について記載していきます。
用語の説明
本編に入る前に本ブログで扱う MGN に関しての用語について簡単に記載しておきます。
| 用語 | 説明 |
|---|---|
| ソースサーバー | オンプレミス側環境にある移行元サーバーを指します。 |
| レプリケーションサーバー | ソースサーバーのデータをレプリケーションするサーバー |
| テストインスタンス/カットオーバーインスタンス | AWS 環境に移行されたサーバー テストインスタンスは、主に動作確認を行うサーバーで、カットオーバーインスタンスは、動作確認後に本番サーバーとしてデプロイされたサーバー |
ネットワーク要件について
MGN を利用するためには、オンプレミス側（ソースサーバー）と AWS 側でネットワーク設定を行う必要があります。
以下ドキュメントの内容に沿って記載していきます。
docs.aws.amazon.com
オンプレミス側
オンプレミス側では以下へアクセスできるように設定を行う必要があります。
| 送信先 | ポート |
|---|---|
| レプリケーションサーバー | 1500 (TCP） |
MGN のリージョン固有のコンソールアドレスmgn.<REGION>.amazonaws.com |
443 (TCP） |
| 以下の S3 バケット ・ https://aws-mgn-clients-<REGION>.s3.<REGION>.amazonaws.com/・ https://aws-mgn-clients-hashes-<REGION>.s3.<REGION>.amazonaws.com/・ https://aws-mgn-internal-<REGION>.s3.<REGION>.amazonaws.com/・ https://aws-mgn-internal-hashes-<REGION>.s3.<REGION>.amazonaws.com/・ https://aws-application-migration-service-<REGION>.s3.<REGION>.amazonaws.com/・ https://aws-application-migration-service-hashes-<REGION>.s3.<REGION>.amazonaws.com/・ https://amazon-ssm-<REGION>.s3.<REGION>.amazonaws.com/ |
443 (TCP） |
ソースサーバーがインターネットに接続できる場合ですと、特に考慮することはないのですが、実稼働しているサーバーの場合そういったケースはほとんどないと考えられます。
インターネットへ接続できる場合は、プロキシを介しているケースが多いと思います。
セキュリティの観点から、インターネットへ抜ける経路が制限されていたり、外部への経路がないケースがほとんどだと思います。
そのため、以下のように Direct Connect 経由での通信経路を確保する形となります。
レプリケーションサーバーへのアクセス（TCP 1500）
ソースサーバーからレプリケーションサーバーへ TCP 1500 で通信ができるように、ファイアウォールなどの設定を見直す必要があります。
AWS 側としては、レプリケーションサーバーのセキュリティグループでソースサーバーからの通信を許可する必要がありますが、オンプレミス側で行う設定はこの点くらいかなと思います。
Route53 Resolver へのアクセス（TCP/UDP 53）
ソースサーバーが VPC エンドポイントのプライベート DNS 名の名前解決ができるように、Route53 Resolver inbound endpoint へ向けて通信ができるように設定します。
ただ、名前解決ができれば問題ないので構築の手間があるのであれば host ファイルに VPC エンドポイントのレコードを書いてあげる方法でも通信は可能です。
Route53 Resolver を作成するにせよ、しないにせよ以下を名前解決して VPC エンドポイントのプライベート IP が返っくれば要件は満たせていることになります。
mgn.<region>.amazonaws.com
s3.<region>.amazonaws.com
VPC エンドポイントへのアクセス（TCP 443）
ソースサーバーが MGN と S3 へアクセスできるように、VPC エンドポイントの ENI へ TCP 443 で通信ができるようにファイアウォール等を設定します。
オンプレミス経由の通信となるので S3 のエンドポイントが「ゲートウェイ」ではなく、「インターフェイス」としており、パブリック IP ではなくプライベート IP で S3 へアクセスします。
プロキシを利用している場合の注意点
余談として以下のような構成で VPC エンドポイントへの経路がプロキシを介してしまい通信がうまくいかないケースがあるかもしれません。
その場合は MGN Agent の実行がエラーで進まない形となるので、以下のいずれかを実施することで事態を回避できるかもしれません。
*.amazonaws.comはプロキシを経由しないように除外設定を入れておく。- ソースサーバーから直接上記接続先へアクセスできるのようになります。
- VPC エンドポイントのセキュリティグループでプロキシからの通信を許可する。
- プロキシ経由でのアクセスを前提とした設定となります。
MGN Agent の実行でエラーになった際には、CloudTrail で MGN Agent を実行した IAM ユーザの accessKeyId で検索をかけることで、ソースサーバーから MGN へのアクセス履歴を確認できます。
API はSendClientLogsForMgnなどを確認するとソース IP アドレスがわかるので Proxy を経由してきて上手くいっていないのかどうかの判断を行う根拠になります。
AWS 側
主に以下構成図の点線赤枠で囲った箇所の作成が必要です。
Route 53 Resolver
ソースサーバーから VPC エンドポイントの名前解決ができるようにインバウンドエンドポイントを作成します。
オンプレミス側の章でも記載しましたが、host ファイルに VPC エンドポイントのレコードを登録するなどでも対応は可能です。
ただし、公式ドキュメントには Route 53 Resolver の記載があるので作成することが推奨なのは間違いないかと思います。
VPC エンドポイント
コストの観点からレプリケーションサーバーが利用する S3 用 VPC エンドポイントは「ゲートウェイ」を利用します。
※もちろん「インターフェイス」のエンドポイントを利用して S3 にアクセスする形でも問題ないです。
また、「プライベート DNS 名」は有効にしておかないと、レプリケーションが終了せずに進まない場合があるので注意が必要です。
レプリケーションサーバー用のセキュリティグループ
赤枠では囲ってないですが、レプリケーションサーバー用のセキュリティグループを手動で作成する場合は作成が必要です。
手動で作成する場合と強調したのは、レプリケーションテンプレートで「常に Application Migration Service セキュリティグループを使用」にチェックを入れると自動的に適切なセキュリティグループが作成されるので特段考慮は不要というかたちになるためです。
起動後設定を利用する場合の注意点について
以下のブログでも記載していますが、MGN の起動後設定を実施すると SSM Agent がテストインスタンス/カットオーバーインスタンスにインストールされ、指定したアクションを実施します。
blog.serverworks.co.jp
そのため、テストインスタンス/カットオーバーインスタンスから SSM へ接続できる状態にしておかないとアクションが完了せずにタイムアウトしてしまします。
SSM を利用するための前提条件は以下ですが、SSM Agent はプリインストールされていたり、インスタンスプロファイルのアタッチは MGN 側で実施してくれるので1点目の「SSM への接続経路があること」を満たした状態でテストインスタンス/カットオーバーインスタンスへの移行を行う必要があります。
- SSM への接続経路があること
- SSM Agent がインストールされていること
AmazonSSMManagedInstanceCoreを含んだインスタンスプロファイルが、インスタンスにアタッチされている
テストインスタンス/カットオーバーインスタンスをプライベートサブネットに配置する場合は以下の VPC エンドポイントを作成します。
- ec2messages.region.amazonaws.com
- ssm.region.amazonaws.com
- ssmmessages.region.amazonaws.com
まとめ
MGN を利用する前の事前準備として、ネットワーク構成を把握することは大切なのでぜひ本ブログをご参考にいただけますと嬉しいです。
特にオンプレミス側での設定も必要になってくるので整理してから移行をした方が、余計なトラベルなく進められるかなと考えております。
それではまたどこかで～
