導入
戦略を決めたら、実際にサーバーやデータベースを運ぶ番です。AWSには工程ごとに専用のサービスが用意されています。
説明
| サービス | 何をするか |
|---|---|
| AWS Migration Hub | 複数の移行ツールの進捗を1か所で追跡するダッシュボード |
| AWS Application Discovery Service | 移行前に、オンプレミスのサーバー構成・依存関係・使用状況を調査する |
| AWS Application Migration Service（MGN） | サーバーをほぼそのままAWSへ移す（Rehostの主役） |
| AWS DMS（Database Migration Service） | データベースを、停止時間を最小限にしながら移行する。移行元を動かしたまま同期できる |
| AWS SCT（Schema Conversion Tool） | 異なる種類のデータベース（例：Oracle → Aurora PostgreSQL）へ移すために、スキーマやコードを変換する |
| AWS DataSync | オンプレミスとAWSのあいだでファイルをオンライン転送・同期する（第4章） |
| AWS Transfer Family | SFTP/FTPS/FTPのまま、保存先だけS3やEFSに置き換えられるようにする |
| AWS Snow Family | 回線では現実的でない大容量データを、物理デバイスで運ぶ（第4章） |
flowchart LR
Disc["Application Discovery Service（調査）"] --> Hub["Migration Hub（進捗の一元管理）"]
Hub --> Srv["Application Migration Service（サーバー移行）"]
Hub --> DB["DMS + SCT（DB移行と変換）"]
Hub --> Data["DataSync / Snow Family（データ移送）"]
同じ種類のデータベース同士（MySQL → RDS for MySQL）ならDMSだけ、種類が違うなら SCT でスキーマを変換してからDMS、という組み合わせが定番です。この2つの役割分担は試験でもよく問われます。
読んでみよう
「調査＝Application Discovery Service」「進捗管理＝Migration Hub」「サーバー移行＝Application Migration Service」「DB移行＝DMS（種類が違えばSCT併用）」。工程と道具の対応で覚えましょう。