オンプレミスVMをAWSに移行する際に確認すべきこと

こんにちは、クラスメソッドのイ・スジェです。

オンプレミス環境をAWSへ移行しようとすると、まずどのマイグレーションサービスを使うべきか悩むことがあります。しかし、同じ移行でも、サーバーのOSやアプリケーションを丸ごと移すのと、ファイルやデータベースだけを移すのとでは、作業の内容が異なります。

オンプレミス環境の運用を続けながら、バックアップだけをAWSに保管したい場合もあります。そのため、サービスを選ぶ前に、何を移し、何を残すのかを考えておくとよいと思います。

本記事では、サーバーをそのまま移す場合から、データだけを移す場合、オンプレミスとAWSを併用する場合まで見ていきます。それぞれの状況で選べる移行方法や、専用のマイグレーションサービスが役立つ場面を説明しながら、ダウンタイムやライセンスについても触れていきます。

サーバーをそのまま移したい場合

既存のOSやアプリケーションの設定を維持したい場合は、VMイメージをインポートする方法が考えられます。VM Import/Exportでは、仮想化環境からVMイメージをエクスポートしてS3にアップロードし、AMIに変換してからEC2を起動します。

専用のテスト・カットオーバー機能はありませんが、変換したAMIからあらかじめEC2を起動し、事前に検証することはできます。AWS Backupに保存されたVMバックアップがあれば、イメージファイルを直接エクスポートして取り込む代わりに、そのバックアップをEC2やEBSへ復元する方法もあります。

このとき、復元したいのがVM全体なのか、データディスクだけなのかも区別する必要があります。AWS Backupからインスタンスとして復元する場合は、OSを含むVM全体をEC2へ移すため、起動できるかどうかを確認します。VMware Toolsの関連フォルダーは復元時に自動的に除外されるので、必要であれば復元後に再インストールします。

一方、データディスク（非ブートディスク）だけをEBSへ復元し、別のインスタンスに接続するボリューム復元では、移行元のOSが起動できるかどうかを気にする必要はありません。ただし、接続先のインスタンスが、そのファイルシステムやパーティション形式に対応しているかは確認が必要です。

移行中に更新されたデータはどうするのか？

イメージやバックアップから復元する方法には、ある時点のサーバーの状態を移すという共通点があります。移行元のサーバーを稼働させ続けるのであれば、イメージを作成した後の変更をどのように反映するかも考える必要があります。

復元に必要な時間はデータの規模や復元方法によって変わるため、事前のテストで確認しておくとよいでしょう。正確な数値は確認できていませんが、このような仕組みでは、バックアップの頻度を上げても復元時間そのものが大幅に短くなるわけではないと考えています。

移行中に発生する変更も継続して反映したい場合は、イメージを一度取り込むだけでなく、継続的にレプリケーションする方法が必要になります。このような場合に利用できるのが、AWS Transform MGN（旧AWS Application Migration Service）です。エージェントベースの方式では、移行元サーバーにAWS Replication Agentをインストールして初期同期を完了させた後、ブロックレベルの変更をステージング領域へ継続的にレプリケーションしながら、テストとカットオーバーを準備します。

初期同期が完了すると、移行元サーバーを停止せずにテストインスタンスを起動し、繰り返し検証できます。テスト中も、変更データはステージング領域へ継続的にレプリケーションされます。ただし、移行元サーバーごとに同時実行できるジョブは1つに制限されます。

テストとカットオーバーに使用するEC2のサブネットやインスタンスタイプなどは、Launch settingsで別途設定する必要があります。サーバーのデータを複製することと、AWS上でどのような環境で起動するかを決めることは、別の作業というわけです。

ただし、継続的にレプリケーションしているからといって、無停止で切り替えられるわけではありません。カットオーバー前には、移行元サーバーで稼働している業務サービスを停止して新たなデータの変更を防ぎ、レプリケーションの遅延が0であることを確認します。

最後の変更分を反映するまでの時間は、未反映のデータ量やネットワーク・ストレージの性能によって変わります。カットオーバー時には最新の複製データを基に新しいインスタンスを起動するため、実際の切り替えには、インスタンスの起動、接続確認、アプリケーションの検証にかかる時間も別途必要です。

なお、対応するVMware vCenter環境では、個々のVMにエージェントをインストールしないエージェントレス方式も提供されています。この場合も別途MGN vCenter Clientが必要です。また、スナップショットを転送する方式なので、最新のスナップショットを待つことで、カットオーバーに時間がかかる場合があります。

もちろん、既存のOSを必ずそのまま移す必要はありません。AWSに新しいサーバーを構築し、アプリケーションをインストールしてから、必要なデータだけを移す方法もあります。既存の設定を再構成して検証する手間はかかりますが、不要になった構成まで持ち込まずに、新しい環境を整理する機会にもなります。

サポートされる移行経路がないEOLのOSであれば、実質的にはこのような新規構築が必要になります。ただし、MGNには対応するWindows Serverのバージョンをアップグレードする定義済みアクションもあるため、バージョンアップが必要だからといって、必ず新規構築になるわけではありません。

イメージを移せば、ライセンスもそのまま引き継げるのか？

イメージが正常に起動したからといって、確認が終わるわけではありません。VMイメージをそのまま移しても、既存のライセンスまで同じ条件で利用できるとは限りません。

保有しているライセンスを持ち込んで利用する方式を、BYOL（Bring Your Own License）といいます。イメージを移行するだけでBYOLとして利用できるわけではないため、製品ごとの契約条件と、移行方法によるライセンスの扱いを併せて確認する必要があります。

例えば、Windows ServerのイメージをVM Import/Exportでインポートする際にライセンスオプションを指定しなければ、AWSライセンス（License Included）がデフォルトになります。既存のイメージを使用しても、ライセンスは移行元とは異なる方式で適用される場合があるということです。

既存のWindows Serverライセンスを利用するには、BYOLの適用条件やデプロイ環境の制約を別途確認する必要があります。これはWindowsに限った話ではなく、VM Import/ExportでRHELやSUSEのイメージを取り込む場合も、各ディストリビューションのBYOS（Bring Your Own Subscription）の条件を確認します。

ファイルだけを移す場合

サーバーを新しく構築することにした場合や、既存のOSまで移す必要がない場合は、データだけを移行する方法に絞って考えられます。通常のファイルであれば、まず移行元と移行先の間で直接コピーできるかを考えてみるとよいでしょう。例えば、移行先のEC2へSSH接続できる環境なら、SCPなどのツールでファイルを転送できます。

二つのサーバーを直接接続するのが難しければ、S3を中間の保管場所として使う方法もあります。移行元からS3にアップロードし、移行先のEC2でダウンロードする方式です。両方のサーバーがそれぞれS3にアクセスできれば、サーバー同士を直接接続する必要はなく、アップロードとダウンロードのタイミングを分けることもできます。最終的な保管先がS3であれば、ダウンロードせずにアップロードで完了します。

AWS CLIなどのツールでこの作業を実行できますが、S3を経由するだけで移行全体が自動化されるわけではありません。EC2まで移す場合は、アップロードとダウンロードの二つの工程を管理し、中間に保管したファイルのアクセス権限や保管期間も決める必要があります。直接コピーする場合と同様に、ファイルの転送漏れがないか、移行先でも必要な所有権や権限が適用されているかは確認します。

こうした転送を繰り返したり、スケジュールや帯域幅、検証をまとめて管理したりしたい場合は、AWS DataSyncを検討できます。オンプレミスのストレージとAmazon S3、EFS、FSxの間でデータをオンライン転送し、チェックサムで転送データの整合性を検証します。オンプレミスにエージェントをデプロイする準備は必要ですが、転送スケジュールや帯域幅の制限などを設定して作業を管理できます。

DataSyncがロケーション間でデータを転送する区間は、TLSで暗号化されます。ただし、移行元ストレージからデータを読み取る区間や、移行先ストレージに書き込む区間の保護方式は、それぞれのストレージのプロトコルや設定によって異なります。

どの方式を選んでも、移行元のファイルが更新され続けるのであれば、最後の変更分をどう反映するかを決める必要があります。例えば、大部分のファイルを先に移しておき、切り替え時にアプリケーションからの書き込みを一時停止して、最後に同期する進め方です。一度コピーすれば完了するのか、繰り返しの転送や検証まで必要なのかを先に判断すると、直接コピーやS3経由で十分なのか、DataSyncが役立つのかを選びやすくなります。

データベースを移す場合

データベースも、最初から専用のマイグレーションサービスを選ぶ必要があるわけではありません。同じDBエンジンへ移すなら、エンジンが提供する機能でダンプやバックアップを作成し、移行先に転送して復元する方法から検討できます。例えば、PostgreSQLではpg_dumpで論理バックアップを作成し、移行先に復元できます。バックアップファイルは、先ほど説明したように直接転送することも、S3を経由して移すこともできますが、移行先のエンジンやバージョンで復元できる形式かどうかは確認が必要です。

ただし、バックアップ中にDBの運用を続けられることと、データを欠落させずに新しいDBへ切り替えられることは、別の話です。pg_dumpには実行開始時点の一貫性のあるデータが含まれますが、その後の変更まで自動的に反映されるわけではありません。バックアップ時点以降の書き込みを制限するか、変更を別途反映する必要があるため、転送・復元・検証にかかる時間と、許容できる停止時間を併せて考える必要があります。

こうした停止時間を許容できない場合は、まず全体のデータを移し、その後の変更を継続して反映する方法が考えられます。SQL Serverを継続して使う場合は、ライセンス条件を確認して新しいOSにSQL Serverをインストールし、フルバックアップを復元した後、トランザクションログのバックアップを継続的に転送・復元するログ配布（ログシッピング）を検討できます。カットオーバー時に適用する変更を減らし、ダウンタイムを短縮する方法です。

AWS Database Migration Service（DMS）も、初期データとその後の変更を移すための選択肢です。サポートされる移行元と移行先の組み合わせでは、フルロードとCDC（変更データキャプチャ）を利用できるため、稼働中のDBをRDSやAuroraなどのマネージドDBへ移す場合にも活用できます。ログのバックアップを転送・復元するログシッピングに対し、DMSのCDCは移行元の変更内容を読み取り、移行先へ反映します。

データを継続的に反映できる場合でも、最後の切り替えでは書き込みを止めるタイミングを調整し、反映状況を確認する必要があります。既存のバックアップ・復元手順で許容時間内に移行できるのであればその方法を活用し、停止時間を短くしたいのであれば、エンジンのレプリケーション機能やログシッピング、DMSなどを比較するとよいでしょう。

ここまではデータを移す方法について説明しましたが、OracleからPostgreSQLへ移すような異種DB間の移行では、構造や動作を変更する課題も加わります。スキーマ変換が必要になり、ルールベースの変換を生成AIで補助しても、100%の自動変換を期待するのはまだ難しいところです。データがすべて移行されたかだけでなく、アプリケーションのクエリが同じ結果を返すかまで検証する必要があります。

オンプレミス環境の運用を続ける場合

ここまでは、サーバーやデータをAWSへ移す場合を見てきました。しかし、オンプレミス環境の運用をそのまま続けながら、バックアップだけをクラウドに保管したり、必要なストレージだけをAWSと接続したりする場合もあります。

バックアップファイルを別の場所に保管することが目的なら、既存のバックアップツールで作成したファイルをS3へアップロードする方法から考えられます。復旧するときは、そのファイルを取得し、既存のツールと互換性のある環境で復元します。バックアップのスケジュールや保管期間、復旧の検証は、既存のツールや運用手順で管理する必要があります。また、VMのバックアップファイルをS3に保管したからといって、そのままEC2へ復元できるわけではありません。ファイルの保管先と復元方法は別の話です。

VMware環境のバックアップ作業やポリシーをAWS Backupで管理したい場合は、Backup Gatewayを利用できます。vCenter環境に仮想アプライアンスをデプロイすると、VMを検出し、データを暗号化してAWS Backupへ送信します。vSphere 6.7/7.0/8に対応しており、前述のように、このバックアップをEC2へ復元して移行に利用することもできます。既存のバックアップファイルを保管することと、AWS Backupでバックアップ作業を管理することの違いと捉えると分かりやすいと思います。

一方、バックアップの保管ではなく、オンプレミスのアプリケーションからAWSのファイルストレージを継続して利用したい場合は、接続の考え方も変わります。例えば、オンプレミスのLinuxサーバーをSite-to-Site VPNやDirect ConnectでVPCに接続し、EFSをNFSでマウントする方法があります。専用のストレージゲートウェイを置かずにファイルシステムへアクセスする構成ですが、アプリケーションがリモートストレージへのアクセス遅延やネットワーク接続の影響を受ける点は考慮する必要があります。

既存のファイル共有やテープ・ブロックストレージのインターフェイスを活用しながら、ローカルキャッシュも持たせたい場合は、AWS Storage Gatewayを検討できます。ファイル向けのS3 File Gateway、テープ向けのTape Gateway、ブロックストレージ向けのVolume Gatewayがあり、VMware、Hyper-V、KVM、またはEC2に仮想ゲートウェイをデプロイできます。AWSのストレージへ直接接続するか、ゲートウェイを介するかは、アプリケーションが使用するインターフェイスやローカルキャッシュの必要性によって変わります。

ネットワーク経由での移行が難しい場合

データ量が多いからといって、すぐに物理的な搬送が必要になるわけではありません。初期データをあらかじめ分けて転送し、最後に変更分だけを反映できるか、業務時間外に転送量を増やす余地があるかを、まず確認できます。一度きりの移行ではなく、その後もオンプレミスとAWSの間で大量のデータをやり取りするのであれば、Direct Connectなどのネットワーク接続も検討できます。ただし、回線の準備にかかる時間や帯域幅、費用を併せて考える必要があります。

こうした調整をしてもオンライン転送が予定期間内に完了しそうにない場合は、データを物理的に搬送する方法が考えられます。ただし、過去に利用されていたサービスを現在もそのまま選べるとは限りません。

AWS Snowballは2025年11月7日から新規顧客の利用を受け付けておらず、2026年12月31日にはすべての商用リージョンでサービスが終了する予定です。新たに物理転送が必要な場合は、別の方法を検討する必要があります。

この場合の選択肢の一つが、AWS Data Transfer Terminalです。ただし、デバイスが配送される方式ではなく、データを保存した機器をロサンゼルス、ニューヨーク、ミュンヘンなどの指定施設へ自分で持ち込み、100Gbpsクラスの回線で転送する方式です。

現在はAWS Enterprise Supportの利用者のみが利用できます。また、韓国から利用する場合は、施設までの物理的なアクセスにも制約があります。ペタバイト規模のデータや、ネットワーク帯域幅が根本的に不足している環境では検討できますが、提供場所や利用条件が合っているかを先に確認する必要があります。

ここで、物理転送はあくまでデータを運ぶ手段であることも区別しておきたいところです。前述したMGNのエージェントベースの方式は、ネットワークを通じてブロックレベルのレプリケーションを継続するため、Snowballのようにオフラインでデータを運ぶ手段で、このレプリケーション経路を置き換えることはできません。

おわりに

同じ対象を移す場合でも、方法は一つではありません。ファイルを直接コピーしたり、S3を経由して移したりすることもできますし、DBの既存のバックアップ・復元機能だけで移行することもできます。重要なのは特定のサービスを使うかどうかよりも、移行中に更新されるデータと、実際の切り替えに必要な時間をどう扱うかだと思います。

まずは単純なコピーや復元で十分かを判断し、変更の継続的な反映や繰り返し作業の管理が必要であれば、それに合うサービスを選ぶとよいでしょう。一つの環境でも、サーバー、ファイル、DBをそれぞれ異なる方法で移行することがあり、どの方法でも移行後の検証は必要です。

特に、イメージをそのまま移したからといって、既存のライセンスまで同じ条件で利用できるわけではありません。移行方法を選ぶ際には、技術的に移行できるかどうかと、ライセンスの条件を分けて確認しておくとよいと思います。

本記事が、移行方法を検討する際の参考になれば幸いです。各サービスの詳細設定や実際の移行手順については、次の記事で取り上げたいと思います。

参考資料

• VM Import/Export：イメージのインポート・ライセンスに関する考慮事項・ライセンスオプションの指定
• MGNの移行手順：移行の流れ・カットオーバー前の操作・カットオーバーガイド・レプリケーションの遅延とエラー
• MGNの設定と対応方式：移行先インスタンスの設定・エージェントレスレプリケーション・一般的なFAQと名称変更・定義済みアクションとWindowsのアップグレード
• AWSのMicrosoftライセンスに関するFAQ
• AWS Backup：サービス概要とバックアップポリシー・VMの復元・ゲートウェイのインフラストラクチャ設定
• ファイル転送：SCP・AWS CLIによるS3へのアップロードとダウンロード・AWS DataSync
• DataSyncの転送保護：転送中の暗号化・データの整合性検証
• PostgreSQLのダンプと復元
• AWS DMS：サービス紹介・CDC・切り替え手順の例
• SQL Serverのログシッピングを利用した移行
• ハイブリッドストレージ：EFSの接続構成・AWS Storage Gateway
• AWS Direct Connectの概要
• AWS Snowball
• AWS Data Transfer Terminalとは