既存サーバをEC2に移すには？AWS移行ツールと実践手順をわかりやすく解説

既存のオンプレミスや仮想サーバをクラウドへ移したいと考えても、「どの移行方法を選ぶべきか」「どんな手順で進めれば安全か」と迷うケースは多いでしょう。アマゾンウェブサービス（AWS）では、既存サーバをAmazon EC2上へ効率的に再現できる移行ツールや支援サービスが整備されています。

本記事では、AWS Application Migration Service（AWS MGN）やAWS VM Import/Exportなど主要ツールの特徴を比較しながら、移行の実践手順と構成の考え方をわかりやすく解説します。

Amazon EC2へのサーバ移行とは

オンプレ／仮想環境からの移行の基本概念

既存のオンプレミス環境や仮想サーバをクラウドへ移行する際は、いくつかの基本方針があります。代表的なのは次の2つです。

■リホスト（Lift & Shift）

既存サーバのOSやアプリケーションをできるだけ変更せず、そのままAmazon EC2へ移す方法です。環境を大きく変えないため、短期間で移行を完了でき、リスクを最小限に抑えられます。

■リプラットフォーム

構成そのものは変えずに、AWSのマネージドサービスへ部分的に最適化する方法です。例えば、ストレージをAmazon EBSへ最適化したり、監視をAmazon CloudWatchへ寄せることで、運用性を高められます。

リプラットフォームは、アプリケーションの構造やコードには手を加えず、周辺のインフラ部分だけをAWSのマネージドサービスへ置き換える移行方式です。リホストより踏み込む一方、全面的な再設計（リファクタリング）ほど大きな変更は伴いません。

例：

• サーバ内で動かしていたDBを Amazon RDS へ移行する

• 既存のファイルサーバを Amazon EFS／Amazon S3 に置き換える

• 自前のメッセージキューを Amazon SQS に変更する

• バッチ処理基盤を、サーバ常駐型から AWS Lambda／AWS Batch に移す

これらの手法を組み合わせながら、段階的にクラウドへ移すのが一般的です。

移行対象としてEC2を選ぶ理由

Amazon EC2は、既存サーバの構成を再現しやすく、移行の難易度を大きく下げられる点がメリットです。次の理由から、移行先として選ばれるケースが多いです。

• OSやミドルウェアを継続利用できるため、アプリ側の修正が不要

• インスタンスタイプやEBSボリュームなど、性能・容量の調整が容易

• 既存のLinux/Windowsの運用ノウハウをそのまま活用でき、運用移行の負担が小さい

• 将来的にECSやLambdaなどへ移行する場合も、EC2が中間ステップとして機能しやすい

AWSの中でも、最も自由度が高く、既存環境との親和性が高いサービスといえます。

移行で得られる主なメリット（コスト・柔軟性・可用性）

Amazon EC2へ移行することで、次のようなメリットを得られます。

1. コスト最適化

サーバ購入や保守契約が不要になり、利用した分だけ支払う従量課金モデルを採用できます。インスタンスサイズを見直すことで、無駄なリソースを削減できます。

2. 柔軟性の向上

CPU・メモリ・ストレージを後から変更できるため、負荷増減に応じて環境を調整できます。また、必要に応じて複数AZ（アベイラビリティーゾーン）に配置し、構成を柔軟に拡張できます。

3. 可用性の強化

マルチAZ構成、EBSスナップショット、Auto Scalingなどを組み合わせることで、オンプレミスでは難しい高可用性を実現できます。

AWSサーバ移行の代表的な手法

AWS Application Migration Service（AWS MGN）

AWS Application Migration Service（AWS MGN）は、既存サーバをAmazon EC2へ最も安全かつ自動化された形で移行できる標準サービスです。AWSが公式に推奨する移行方式であり、現在のLift & Shift移行では中心的な役割を担っています。

特徴

• エージェントを既存サーバにインストールすると、ブロックレベルでレプリケーションを実施

• AWS側に同等の環境を自動生成（複数台構成にも対応）

• テスト環境をワンクリックで起動でき、本番切替のリスクを最小化

対応環境

• 物理サーバ

• VMware仮想マシン

• Hyper-V

• オンプレ・クラウド問わず幅広く対応

メリット

• 既存サーバとほぼ同一構成を自動で再現でき、手作業によるミスを防げる

• レプリケーション中もサーバは稼働し続けるため、ダウンタイムを最小限に抑えやすい

• テスト切替→本番切替のフローが整備されており、移行後の検証が容易

デメリット

• Windowsライセンスなど、一部の環境では追加要件が発生する場合がある

• サーバ側にエージェントをインストールできない環境では利用しづらい

• サーバ構成を整理せず移すと、そのまま“レガシー構成を踏襲する”可能性がある

AWS VM Import/Export

AWS VM Import/Exportは、VMイメージ（仮想マシンイメージ）をAmazon EC2へ持ち込みたい場合に使うサービスです。主に、VMwareやHyper-Vで構築した環境をそのままEC2へ再現したい場合に適しています。VMイメージ単位の移行が必要なケースで有効です。

対応イメージ形式

• VMware（VMDK／OVA）

• Microsoft Hyper-V（VHD／VHDX）

• Citrix Xen（VHD）

適したケース

• OSやアプリを変更せず、既存の仮想マシンをそのままEC2へ移したい

• エージェントインストールが難しい環境

• MGNを使わず、イメージ単位の移行を行いたい企業

メリット

• 既存の仮想マシンをそのまま移行できる

• MGNに比べてシンプルで、管理が容易

デメリット

• レプリケーションやテスト切替などの機能はない

• 移行中は停止が必要になる場合があり、ダウンタイムが発生しやすい

• 多数のサーバ移行には向かない

手動移行（AMI作成／rsyncなど）との比較

AWS MGNやVM Import/Exportを使わずに、手動でEC2へ移行する方法もあります。代表例は次の通りです。

• AMI（Amazon Machine Image）を手動作成して環境を再現する

• rsyncやファイルコピーでアプリデータを移す

• 構成管理（Ansible／Chefなど）でサーバ構築を再現する

メリット

• 自由度が高く、細かい構成調整がしやすい

• 古いOSや特殊構成など、ツールが対応しないケースにも対応可能

デメリット

• 作業負荷が高く、ヒューマンエラーが発生しやすい

• テスト手順・本番切替手順をすべて自前で整える必要がある

• 多数のサーバ移行には不向き

判断基準

• 基本はAWS MGN：自動化・安全性・テスト容易性で最有力

• 仮想マシンをそのまま移したい場合はVM Import/Export

• 特殊構成や小規模環境なら手動移行でも可

Amazon EC2移行の実践ステップ

1. 現状環境の可視化と依存関係の整理

移行の成否は、事前の棚卸しでほぼ決まります。まず、現在のサーバがどのような構成で動いているのかを把握します。

棚卸し項目の例

• OS／ミドルウェアのバージョン（Linux/Windows、Apache、Nginx、IISなど）

• アプリケーション構成（フレームワーク、依存ライブラリ、サービス構成）

• ネットワーク要件（ポート、FW設定、外部接続の有無）

• ストレージ容量・I/O要件

• バックアップ／バッチ処理のスケジュール

特に、外部DB・外部API・ログ管理基盤などの依存関係は、移行後に動作しないトラブルの原因になりやすいため、早期に洗い出すことが重要です。

2. 移行方式の選定

棚卸しが完了したら、どの移行方式を採用するかを決めます。どちらが良いかは、移行スケジュール・リスク許容度・技術的負債の状況で判断します。

リホスト（Lift & Shift）

• 既存環境をそのままEC2へ移す

• ダウンタイムを抑えたい、短期でクラウド化したい場合に最適

• AWS MGNがもっとも適した選択肢

リプラットフォーム

• アプリはそのまま、周辺の構成をAWS向けに最適化

• 例：監視をAmazon CloudWatchに移行、バックアップをAmazon EBSスナップショット化

• 移行後の運用改善まで見据える場合に有効

3. AWS MGNやAWS VM Import/Exportを用いた移行実施

選定した移行方式に基づき、実際の移行作業へ進みます。

AWS MGNを利用する場合

前提条件

• 移行元サーバにエージェントをインストールできること

• ネットワーク要件（通信ポート、プロキシ設定）が満たされていること

流れ

1. AWS側でレプリケーション設定を行う

2. 既存サーバへエージェントを導入

3. ブロックレベルでレプリケーションを開始

4. テスト用のEC2インスタンスを起動

5. テスト完了後、本番カットオーバーを実行

ダウンタイムが最小になるよう設計されており、業務影響を抑えながら移行できます。

AWS VM Import/Exportを利用する場合

前提条件

• 仮想マシンのイメージ（VMDK／OVA／VHDなど）が取得できること

• S3へアップロード可能な環境であること

流れ

1. 仮想マシンイメージをS3へアップロード

2. AWS CLIでVM Importを実行

3. Amazon EC2として起動

4. 動作検証後、必要に応じてチューニング

VM単位で移行するシンプルな手法ですが、テスト切替機能などはありません。

4. テスト運用とパフォーマンス検証

移行後のEC2インスタンスが、期待どおり動作するかを確認します。

チェック項目の例：

• アプリケーションの正常稼働

• 外部APIやDBとの接続確認

• ファイルパスや環境変数の整合性

• CPU／メモリ／I/O性能の確認

• バッチ処理・バックアップジョブの動作

• セキュリティ設定（セキュリティグループ・IAMロール）の整合性

パフォーマンス要件に関しては、インスタンスタイプの見直しやEBSボリュームタイプの最適化を行うことで、大幅に改善する場合があります。

5. 本番切替とDNS更新・監視設定

テストが完了したら、本番切替（カットオーバー）を行います。切替後は、アプリ全体の正常稼働を確認し、必要に応じて性能調整を実施します。

• 旧環境からの最終同期（MGN使用時は自動）

• 旧サーバの停止

• 新EC2インスタンスの起動

• DNS切替（Route 53または既存のDNS）

• Amazon CloudWatchによる監視設定

• AWS CloudTrailによる操作ログ管理

AWS環境構成の考え方

VPC／サブネット／セキュリティグループの基本設計

Amazon EC2を安全に運用するには、まずネットワーク基盤となるAmazon VPCの設計が重要です。ネットワークは移行後の可用性やセキュリティに直結するため、早い段階での設計が不可欠です。

VPC設計の基本

• 開発・検証・本番でVPCを分離し、影響範囲を明確化する

• CIDR設計を早期に決め、将来の拡張（サブネット追加・VPN接続）を見据える

• パブリックサブネット／プライベートサブネットを用途別に分ける

サブネット設計のポイント

• プライベートサブネットにEC2を配置する構成が基本

• インターネット通信はNAT Gateway経由で行わせる

• アプリ層、DB層、管理用EC2など、役割ごとにサブネット分割すると管理性が向上する

セキュリティグループの設計

• 必要最小限のポートのみ許可する“ゼロトラスト的な最小権限”を徹底する

• インバウンドは特定IP・特定サーバからのみ許可

• SSH/RDPは踏み台（Bastion Host）を経由する構成が推奨

IAMとアクセス制御（権限分離）

AWS Identity and Access Management（IAM）は、アカウント内の権限管理を行う基盤です。移行後の運用で事故が起きやすい領域であり、早期に適切な制御を行うことが重要です。最小権限の原則を徹底することで、セキュリティ事故のリスクを減らせます。

IAM設計の基本

• 日常操作はIAMユーザーではなく、IAMロール＋AWS SSO（IAM Identity Center）などを利用する

• 開発者・運用者・管理者でロールを分離し、権限を細かく制御する

• EC2に直接アクセスキーを保存しない。EC2はIAMロールでアクセス権限を取得する

よくあるミス

• 管理者権限（AdministratorAccess）を無条件で付与

• アクセスキーをローカルに保存したまま放置

• 不要ロール・不要ポリシーの整理不足

バックアップ・スナップショット戦略

EC2環境では、データ保護の仕組みを適切に構築しておくことが不可欠です。バックアップは移行後の安定運用に直結するため、構築フェーズで必ず設計しておくべき領域です。

バックアップ方法の例

• Amazon EBSスナップショット：EC2停止なしで取得できる標準的な方法

• AWS Backup：スケジュール管理・世代管理を自動化できる統合サービス

• AMIによるサーバイメージ保存：アプリごと丸ごとバックアップする場合に有効

ポイント

• 本番環境は、日次スナップショット＋週次保管など規則的な運用が必要

• リカバリ時間（RTO）・復旧ポイント（RPO）を先に決めておく

• バックアップは複数AZ・複数世代で保管し、災害対策にも備える

監視・ログ管理（Amazon CloudWatch／AWS CloudTrail）

移行後の運用状況を可視化するために、監視とログ管理の仕組みを整えておきます。

Amazon CloudWatch（監視）

• CPU・メモリ・I/Oなどのメトリクスを監視

• ログ（CloudWatch Logs）を集約し、アプリ・ミドルウェアのログ分析が可能

• アラーム設定で異常検知を自動化

AWS CloudTrail（操作ログ）

• AWSアカウント内の操作履歴をすべて記録

• IAMユーザー／ロールの操作を可視化でき、不正操作の検知に役立つ

構築時のポイント

• CloudWatchアラームは必ず設定しておく（CPU・メモリ・StatusCheckなど）

• CloudTrailログはS3へ保存し、保持期間を明確に定義する

• GuardDutyなどの脅威検知と組み合わせると、より安全な環境になる

移行時に注意すべきポイント

ライセンスやIP制約の確認（Windows／商用アプリ）

移行時に特に注意すべきなのが、OSや商用アプリのライセンス要件とIPアドレス依存です。IPやハードウェア依存のアプリは、もっともつまずきやすいポイントのため、早期の確認が重要です。

Windows Server／SQL Server

• ライセンスモデルがオンプレとAWSで異なる場合がある

• BYOL（Bring Your Own License）ができるか、Amazon EC2のライセンス込みAMIを使うべきかを事前に確認する

• SQL Serverに関しては、Edition／コア数要件の違いにより費用が大きく変わる点にも注意する

商用アプリケーション

• 一部アプリはホスト名／MACアドレス／固定IPなどにライセンスが紐づいている

• EC2への移行後にライセンス再認証が必要になるケースがある

• 再発行手続きやベンダー確認を事前に済ませておくと、切替時のトラブルを避けられる

ダウンタイム最小化とロールバック計画

移行時に業務影響を抑えるには、ダウンタイムとロールバック（旧環境へ戻す）計画の事前準備が不可欠です。特に本番環境の移行では、ロールバックの有無がリスク耐性を左右します。

ダウンタイム最小化の方法

• AWS Application Migration Service（AWS MGN）を利用して、リアルタイムレプリケーションを実施

• データ同期を事前に完了させ、切替時は最小限の停止で済むよう調整

• バッチ処理やDB更新が重なるタイミングを避け、適切なメンテナンス時間を設定する

ロールバック計画

• 切替前の旧環境を一定期間保持する

• EC2移行後に重大障害が発生した際、旧環境へ即戻せる手順を用意する

• 切替手順と同じく、ロールバック手順も事前にドキュメント化する

セキュリティ・ガバナンス（共有責任モデルの理解）

AWSでは、セキュリティはAWSと利用者の共有責任モデルで成り立っています。ここを誤解すると、移行後に重大なセキュリティリスクが発生します。特にEC2はIaaSのため、OS・アプリ層のセキュリティは利用者側の責任が大きくなります。

AWSの責任

• データセンター、ハードウェア、ネットワークなどの物理的セキュリティ

• 仮想化基盤やリージョン全体の可用性・冗長化

利用者の責任

• VPC／サブネット／セキュリティグループなどのネットワーク設定

• IAMユーザー・ロールの管理

• EC2インスタンスのOS・アプリのパッチ適用

• 暗号化・バックアップ・アクセスログ管理

コスト試算と課金構造（EC2課金・ストレージ・通信費）

移行後のコストを正確に見積もるには、AWS特有の課金構造を理解しておく必要があります。移行後にコストが想定以上に増えるケースは珍しくありません。事前の試算と構成最適化が鍵になります。

Amazon EC2の課金ポイント

• インスタンスタイプ（vCPU数・メモリ量）

• 利用時間（秒単位課金、常時稼働でコスト増）

• EBS（ストレージ容量・タイプによるI/O性能）

ネットワーク・通信費

• インターネットへのアウトバウンド通信は課金対象

• 社内ネットワークとの接続（VPN／Direct Connect）も別途費用が発生

コスト最適化の例

• 小さめのインスタンスタイプから開始し、負荷に応じてスケールする

• Savings Plansの活用で長期利用コストを抑える

• 不要なインスタンスの自動停止（EventBridge＋Lambda）を設定する

まとめ

Amazon EC2への移行は、AWSが提供する複数の移行ツールを使うことで、安全かつ効率的に進められます。特にAWS Application Migration Service（AWS MGN）は、レプリケーションやテスト切替が自動化されており、短期間かつ低リスクで移行したいケースに最適です。VMイメージをそのまま移したい場合はAWS VM Import/Export、小規模・特殊構成は手動移行が選択肢になります。

移行の成功には、事前の棚卸し、移行方式の判断、テスト運用、本番切替までの工程を丁寧に進めることが重要です。移行後は、VPC設計、IAMの権限分離、バックアップ、監視・ログ管理など、運用面の基盤を整えておくことで安定稼働が実現できます。

ライセンス制約やコスト構造といった注意点も押さえておけば、EC2移行はクラウド活用に向けた確実な第一歩になります。