オンプレミスからクラウドへの移行以上に、クラウド間移行ではネットワーク設計の粗がそのままダウンタイムや性能劣化につながります。本記事では、AWS から Azure へワークロードを移行する際に、事前に押さえておくべきネットワーク前提条件と具体的な設計・実装のポイントを体系的に解説します。
AWS から Azure へ移行するときのネットワーク前提条件の全体像
AWS から Azure へのクラウド移行では、「コンピュートやストレージのサイズ」以上にネットワーク設計が成否を分けます。特に以下の観点を事前に整理しておかないと、移行フェーズに入ってから「疎通しない」「スループットが出ない」「セキュリティ審査が通らない」といった問題に直面しがちです。
- クラウド間の接続方式（VPN / ExpressRoute / Direct Connect 等）の選定
- VPC と VNet のアドレス設計（CIDR 重複の有無）
- ルーティング方式（静的 / BGP、Transit Gateway 利用有無）
- ポート・プロトコルの開放方針と最小権限設計
- セキュリティレイヤー（SG / NACL / NSG / Firewall / NVA）の役割分担
- 帯域・性能・コストの見積もりと検証方法
- Azure Migrate 等の移行ツールが要求する通信要件
まずは、この全体像をコンパクトな表に整理すると次のようになります。
移行時に確認すべきネットワーク項目一覧
| 項目 | 推奨内容 | 補足 |
|---|---|---|
| 接続方式の選択 | 1. Site-to-Site VPN ・短期間の検証や中小規模の移行向き ・インターネット経由 IPsec トンネル 2. ExpressRoute（専用閉域網） ・大規模・本番移行に推奨 ・帯域が大きく遅延が少ない 3. ExpressRoute + VPN フェイルオーバー ・閉域網障害時のバックアップ経路として VPN を併設 | AWS 側で VPN Gateway または Transit Gateway、Azure 側で Virtual Network Gateway を構成する。ExpressRoute 利用時はキャリア手配が必要。 |
| アドレス設計 | CIDR の重複を必ず回避。AWS VPC と Azure VNet のアドレスレンジが重なるとルーティングが収束せず通信できない。 | 既存の RFC1918 アドレスが競合する場合は、Azure VNet 再設計や NAT ゲートウェイ経由のアクセスを検討。 |
| ルート設定 | AWS 側のルートテーブルで Azure 宛 CIDR を VPN/Direct Connect に向ける。Azure 側は UDR で AWS 宛プレフィックスを VPN/ExpressRoute ゲートウェイに向ける。 | BGP を有効にすると経路の自動広告やフェイルオーバーの実装が容易になる。 |
| ポートとプロトコル | 443/TCP（Azure Migrate・DMS 等）、22/TCP・3389/TCP（管理用）、アプリ固有ポート（80/443/1433/3306 など）、必要に応じて ICMP。 | AWS の Security Group・NACL と Azure NSG 双方で許可する。原則は最小権限。 |
| セキュリティ | クラウド間通信の許可ルールを両クラウドで整合させ、必要に応じて Azure Firewall や NVA でトラフィック検査。 | ExpressRoute 利用時でも、機密度に応じて IPsec over ER などの追加暗号化を検討。 |
| 帯域と性能 | 移行データ量が 10TB 超の場合は ExpressRoute または Azure Data Box の併用を検討し、iperf 等で事前にスループットを計測。 | VPN は暗号化オーバーヘッドにより実効帯域が 30〜50% 程度低下する点に注意。 |
| 移行ツールの通信要件 | Azure Migrate・Database Migration Service・Storage 移行ツール等が利用するポート／エンドポイントを事前に洗い出す。 | 専用サブネットに集約し、トラフィックを可視化するとトラブルシュートが容易。 |
接続方式の選び方：VPN / ExpressRoute / Direct Connect の整理
AWS と Azure 間の接続方式は、コスト・帯域・運用難易度のバランスで決めます。代表的な組み合わせと、どのようなシナリオに向いているかを整理します。
基本パターン別の比較
| 構成パターン | 特徴 | 向いているケース |
|---|---|---|
| AWS Site-to-Site VPN ⇔ Azure VPN Gateway | 初期費用が安く導入が容易。インターネット経由のため遅延・帯域が読みづらい。 | PoC や小規模環境の段階的移行、短期間のデータ同期。 |
| オンプレ ⇔ ExpressRoute ⇔ Azure オンプレ ⇔ Direct Connect ⇔ AWS | 両クラウドともオンプレと閉域網接続。クラウド間通信はオンプレ経由で迂回。 | 既にオンプレ閉域網が整備されており、クラウド間通信は限定的なケース。 |
| AWS VPN/Direct Connect ⇔ キャリア網 ⇔ Azure ExpressRoute | キャリア提供のクラウド間閉域サービスを利用。帯域・SLA が明確。 | 本番系大型システムの段階的移行、長期的なハイブリッドクラウド構成。 |
| ExpressRoute + Site-to-Site VPN フェイルオーバー | 通常は ExpressRoute を利用し、障害時に VPN へ自動切替。BGP/UDR で制御。 | ミッションクリティカルシステム。回線断でも最低限のサービス継続が必要なケース。 |
規模・期間・機密度からの接続方式の決め方
| 要件 | 推奨構成 | ポイント |
|---|---|---|
| データ量 < 1TB、移行期間が 1〜2 か月、小規模 | Site-to-Site VPN のみ | スピード重視。性能要件を満たすか iperf 等でサクッと確認。 |
| データ量 1〜10TB、移行期間 3〜6 か月、中規模 | Site-to-Site VPN + 必要に応じて Azure Data Box | 初回フルコピーは Data Box、増分同期を VPN 経由で行う構成が現実的。 |
| データ量 10TB 超、常時レプリケーション、大規模 | ExpressRoute（キャリア閉域）+ バックアップ VPN | 本番稼働後もハイブリッド利用する前提でネットワークを設計。 |
| 個人情報・機密情報を多く扱う | ExpressRoute / Direct Connect 等の閉域網 + アプリ層での暗号化 | 回線が閉域でも、TLS・DB 暗号化等は標準で有効化しておく。 |
アドレス設計：VPC と VNet の CIDR 重複を徹底回避
クラウド間接続トラブルで最も多いのが「アドレスレンジの重複」です。AWS と Azure を接続する前に、必ず現状と将来計画を含めた CIDR 管理台帳を作成しておきましょう。
NG パターン：よくある CIDR 重複例
| 環境 | CIDR | 問題点 |
|---|---|---|
| AWS VPC-Prod | 10.0.0.0/16 | － |
| Azure VNet-Prod | 10.0.0.0/16 | 完全に重複。VPN/ExpressRoute 接続時にルーティングがループ／ブラックホール化。 |
この場合、AWS 側から 10.0.0.10 に向けた通信が「自分自身の VPC 内なのか、Azure 側なのか」を識別できず、通信が期待通りに流れません。
回避策の例
- Azure 側の VNet を 10.10.0.0/16 など別レンジで再設計する。
- どうしても Azure 側のアドレスを変えられない場合、AWS から Azure へは NAT ゲートウェイ経由で別アドレスに変換してアクセスする。
- 将来追加予定の VNet/VPC 分も含め、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 を全体計画として割り付ける。
シンプルなアドレス設計ルールの例
| アドレス帯 | 利用用途 | 例 |
|---|---|---|
| 10.0.0.0/12 | オンプレミス | 10.0.0.0/16（データセンタ A）、10.1.0.0/16（データセンタ B）など |
| 10.16.0.0/12 | AWS | 10.16.0.0/16（Prod）、10.17.0.0/16（Stg） |
| 10.32.0.0/12 | Azure | 10.32.0.0/16（Prod）、10.33.0.0/16（Stg） |
このように「クラウド／環境ごとに大きめのブロック」を先に決めておくと、後から VNet/VPC を追加しても重複しづらくなります。
ルーティング設計：BGP を前提に考える
AWS と Azure 間のルーティングは、規模が大きくなるほど BGP（Border Gateway Protocol） を使った動的ルーティングが有利です。小規模な PoC であれば静的ルートでも構いませんが、本番移行では次の観点で BGP を検討しましょう。
静的ルートと BGP の比較
| 項目 | 静的ルート | BGP |
|---|---|---|
| 設定の手間 | 少数であれば簡単。プレフィックス追加ごとに手動作業が発生。 | 初期設定はやや複雑だが、以後は経路広告により自動反映。 |
| 冗長構成 | プライマリ／セカンダリの優先度調整を手動で実装。 | AS パス長や MED などの BGP 属性で自動的にフェイルオーバー制御が可能。 |
| 運用コスト | 環境拡張のたびにルート追加・削除が必要。 | ネットワーク追加時も経路広告に乗せるだけで済むケースが多い。 |
AWS 側の代表的なルート設定ポイント
- VPC のルートテーブルに、Azure 側 VNet の CIDR（例：10.32.0.0/16）をターゲット「VPN Gateway（vgw-xxxx）」または「Transit Gateway（tgw-xxxx）」として設定。
- Transit Gateway を利用する場合は、オンプレ・複数 VPC・Azure を一元的に接続するハブとして設計するとシンプル。
- ルート伝播を有効にしておくことで、BGP で受信した Azure 側プレフィックスを自動的に各ルートテーブルに反映させることが可能。
Azure 側の代表的なルート設定ポイント
- Virtual Network Gateway を作成し、VPN または ExpressRoute の接続先として利用。
- VNet のサブネットに対して UDR（User Defined Route） を作成し、AWS 側 CIDR を次ホップ「Virtual Network Gateway」に向ける。
- Azure Firewall や NVA を経由させたい場合は、次ホップを「Virtual Appliance」に設定し、その先で AWS 側への経路を保持する。
ポート・プロトコル設計：移行ツールとアプリの両方を意識する
移行時は「運用開始後には不要になるポート」も一時的に開ける必要があります。特に Azure Migrate などの移行ツールは 443/TCP を前提としており、プロキシ環境や FW の設定に引っかかりがちです。
代表的なポート一覧
| 用途 | プロトコル / ポート | 主な方向 | 補足 |
|---|---|---|---|
| Azure Migrate アプライアンス | TCP 443 | オンプレ / AWS → Azure | Azure Migrate の各種エンドポイントに対するアウトバウンド通信。基本的にインバウンド不要。 |
| Database Migration Service (DMS) | TCP 443 / DB ポート（1433, 3306, 1521 など） | DMS サブネット ⇔ AWS DB / Azure DB | DMS サービスから移行元・移行先 DB へ双方向に接続できることが必要。 |
| ファイルサーバ移行 (Storage Migration 等) | TCP 445, 443 | AWS / オンプレ ⇔ Azure Files / Storage | SMB（445）はセキュリティポリシーでブロックされやすいので事前確認が必須。 |
| 管理用アクセス | TCP 22, 3389 | 管理端末 → AWS/Azure VM | 移行期間だけ接続元 IP を絞って開放し、完了後は閉じる運用が望ましい。 |
| 疎通確認 | ICMP | 相互間 | ping が許可されているとトラブルシュートが非常に楽になるが、セキュリティポリシーとの兼ね合いに注意。 |
| アプリケーション | TCP 80, 443, 8080 など | クライアント → アプリ | 移行後の最終疎通試験で必要となるため、事前にリスト化しておく。 |
ポート開放は、AWS では Security Group（SG）と NACL、Azure では NSG と必要に応じて Azure Firewall / NVA の両方で制御されます。「SG では許可しているが NACL で拒否」「Azure NSG は許可だが NVA でブロック」といった多段構成での見落としが非常に多いため、レイヤーごとの役割分担を明確にしておきましょう。
セキュリティ設計：クラウド間通信をどう守るか
クラウド間通信は、インターネット経由であれ専用線であれ、「どこまで暗号化し、どこで検査するか」の方針を先に決めておくことが重要です。
レイヤーごとの役割イメージ
| レイヤー | AWS 側 | Azure 側 | 役割 |
|---|---|---|---|
| ネットワーク境界 | Internet/VPN Gateway, Transit Gateway | Virtual Network Gateway, ExpressRoute Gateway | クラウド間トンネルの終端。BGP や IPsec の設定ポイント。 |
| L3/L4 制御 | Security Group, NACL | NSG | サブネット単位・NIC 単位での基本的な許可/拒否。 |
| L7 制御・検査 | 各種 NVA（Firewall, WAF 等） | Azure Firewall, Application Gateway, NVA | アプリケーションレベルのフィルタリング・IPS/IDS・TLS 終端。 |
セキュリティポリシー上、ExpressRoute などの閉域網であっても 「暗号化されていないトラフィックを流してはいけない」 というルールがある場合があります。その場合は、アプリケーション層で TLS を有効にするか、IPsec over ExpressRoute のように追加の暗号化を検討します。
よくあるセキュリティ上の落とし穴
- ポートスキャンや脆弱性診断時に、AWS 側 WAF / Azure Firewall で誤検知し、移行ツールの通信までブロックしてしまう。
- 一時的に広く開けたポートを、移行完了後に閉じ忘れて残してしまう。
- 監査ログがクラウドごとにバラバラに保存され、インシデント時に時系列で追いにくい。
これらを避けるために、移行プロジェクト開始時点で「クラウド間通信のセキュリティ要件（開けるポート、暗号化要件、ログ保管先）」を仕様として文書化しておくことをおすすめします。
帯域・性能・コスト：移行前に必ず数字で確認する
「なんとなく VPN でも大丈夫そう」で進めてしまうと、データ同期に想定の数倍時間がかかったり、切替時間内に最終同期が終わらないといった問題が発生します。移行前に、少なくとも次の 3 点は数値で確認しておきましょう。
確認すべき 3 つの指標
- 実効スループット：iperf などで AWS ⇔ Azure 間の帯域を測定。
- レイテンシ：ping、アプリの応答時間。同期方式によってはレイテンシに敏感。
- データ量と同期頻度：フルコピー量、日次・時間ごとの増分量。
例えば、実効 200Mbps の回線で 10TB を一括コピーすると仮定すると、理論上だけでもおおよそ数日単位の時間が必要になります。実際には再送やアプリオーバーヘッドを考慮するとさらに余裕を見込むべきです。そのため、大容量の場合は ExpressRoute や Azure Data Box を組み合わせたハイブリッド方式が現実的です。
コスト観点でのチェックポイント
- VPN / ExpressRoute / Direct Connect などの回線費用と構成機器費用。
- AWS 側のデータ送信（egress）課金、Azure 側の受信/送信課金。
- 移行期間中に二重運用になるリソース（AWS + Azure）のコスト。
「ネットワークのコスト」と「クラウドリソースの二重運用コスト」を天秤にかけると、短期集中で帯域を太くした方がトータルコストが安くなる場面も多々あります。
Azure 移行ツールごとの通信要件を押さえる
Azure にはサーバ、データベース、ファイルサーバなど用途別の移行ツールが用意されています。それぞれが必要とする通信要件を事前に整理しておきましょう。
代表的な移行ツールとネットワーク要件
| ツール | 主な用途 | 必要な通信 | ネットワーク設計のポイント |
|---|---|---|---|
| Azure Migrate（サーバ移行） | VM の検出・評価・レプリケーション | アプライアンス → Azure への 443/TCP アウトバウンド | 専用サブネットを作成し、Azure 側へのアウトバウンドを許可。インバウンドは極力閉じる。 |
| Database Migration Service (DMS) | RDBMS の移行 | DMS サブネット ⇔ 移行元 DB（AWS RDS など）、DMS サブネット ⇔ Azure DB | DB ポート（1433/3306/1521 等）を双方向に許可。DMS サブネットは他と分離。 |
| ストレージ移行（Azure Files など） | ファイルサーバ・NAS の移行 | SMB 445/TCP、HTTPS 443/TCP | 社内ポリシーで SMB が制限されていないか事前確認。必要に応じてプロキシ経由構成。 |
これらのツール用に「移行専用サブネット（隔離された VNet）」を用意し、そこからのみ Azure へのアウトバウンド通信を許可する構成にしておくと、セキュリティレビューが通りやすく、トラフィックの可視化もしやすくなります。
AWS から Azure へのネットワーク実装手順（詳細版）
ここまでの内容を踏まえ、AWS から Azure へ移行する際のネットワーク実装手順をもう少し具体的なステップに落とし込みます。
ステップ 1：現状 AWS 環境の棚卸し
- VPC / サブネットの一覧と CIDR を整理。
- インターネットゲートウェイ、NAT ゲートウェイ、Transit Gateway 等の構成を確認。
- 本番・検証・開発などの環境ごとに、どの通信が Azure 側と相互接続される必要があるかを洗い出す。
- 既にオンプレとの VPN / Direct Connect がある場合、そのトポロジを図で可視化。
ステップ 2：Azure 側アドレス計画・VNet 設計
- 前述の通り、AWS と重複しない CIDR を割り振る。
- アプリケーション単位・セキュリティドメイン単位でサブネットを分割。
- 移行専用サブネット（Azure Migrate / DMS 用など）を明示的に用意。
- 将来的に追加予定の VNet（別リージョン、DR 用）も含めたアドレス計画にしておく。
ステップ 3：ゲートウェイ構成
- AWS 側：
- Site-to-Site VPN の場合は VPN Gateway または Transit Gateway を作成し、対象 VPC をアタッチ。
- 複数 VPC 間で共通の Azure 接続を使う場合は Transit Gateway ハブ構成が管理しやすい。
- Azure 側：
- Virtual Network Gateway（VPN または ExpressRoute）を作成し、対象 VNet に紐づける。
- ExpressRoute の場合は、キャリア経由で Circuit を手配し、ピアリング設定を実施。
ステップ 4：接続確立とルーティング設定
- Site-to-Site VPN の場合、AWS と Azure 双方の VPN 設定で事前共有鍵や BGP パラメータを設定。
- 静的ルートの場合は、AWS ルートテーブルと Azure UDR にそれぞれ相手側 CIDR を登録。
- BGP を用いる場合は、AS 番号・プレフィックスフィルタなどの設計を行い、経路広告を有効化。
- 冗長構成の場合は、メイン回線とバックアップ回線で優先度（ローカルプリファレンスなど）を調整。
ステップ 5：疎通確認と性能試験
- ping / traceroute で基本的な疎通を確認。
- iperf などでスループットを測定し、目標値との差分を確認。
- 必要に応じて TCP ウィンドウサイズや同時スレッド数を調整し、スループットを最適化。
- セキュリティグループや NSG のログを有効化し、ブロックされている通信がないかを確認。
ステップ 6：移行ツールの配置とディスカバリ
- Azure Migrate アプライアンスを、AWS もしくはオンプレにデプロイ。
- 必要なポート（443/TCP など）が開いていることを再確認。
- サーバや DB を検出し、Azure 上の適切な SKU サイズなどを評価。
ステップ 7：本番移行・カットオーバー
- 段階的にレプリケーションを実施し、移行対象サーバの同期が完了していることを確認。
- カットオーバー手順書を作成し、DNS 切り替え・最終同期・ロールバック手順を明文化。
- 本番切替時には、ネットワーク監視（レイテンシ・エラー率）を強化し、問題発生時に即座に切り戻せるようにしておく。
ステップ 8：移行後の最適化とクリーンアップ
- 移行時に一時的に開けたポートやセキュリティグループルールを洗い出し、不要なものを閉じる。
- 不要になった AWS 側リソース（VPN Gateway、テスト用サーバ等）を削除してコストを削減。
- Azure 側も同様に、一時リソースや不要な診断設定を見直して最適化。
運用・監視・IaC：移行後を見据えたベストプラクティス
AWS から Azure へのネットワーク移行はゴールではなく、マルチクラウド／ハイブリッドクラウド運用のスタート地点です。移行後の運用を見据え、次のような点も合わせて設計しておくと、長期的に安定した運用がしやすくなります。
冗長性と可用性
- ExpressRoute は可能な限り Active-Active 構成 とし、回線障害に備える。
- VPN バックアップ経路を用意し、ルーティングで優先度を制御しておく。
- Azure 側では、重要な VNet を複数アベイラビリティゾーンに跨って設計する。
モニタリングとログの統合
- Azure Monitor / Network Watcher で VNet・VPN/ExpressRoute の状態を監視。
- AWS 側では CloudWatch Logs / VPC Flow Logs を活用し、トラフィックの可視化を行う。
- 可能であれば、両クラウドのログを SIEM などに集約して横断的に分析できるようにする。
Infrastructure as Code（IaC）の活用
- Terraform や Bicep、CloudFormation 等を利用して、ネットワーク構成をコード化する。
- 本番環境と検証環境で同じコードを使い、パラメータだけを変えてデプロイすることで、構成差異を最小化。
- Git などで変更履歴を管理し、「誰がいつどのルートやセキュリティルールを変えたのか」を追跡できるようにする。
まとめ：ネットワーク前提条件を固めれば AWS から Azure への移行は怖くない
本記事では、AWS から Azure への移行時に押さえておくべきネットワーク前提条件を、接続方式・アドレス設計・ルーティング・ポート設計・セキュリティ・帯域・移行ツールの観点から整理しました。
- まずは CIDR 重複がないアドレス設計 を固める。
- 移行規模や期間に応じて VPN / ExpressRoute / Direct Connect を選定し、可能であれば BGP を前提に設計する。
- Azure Migrate や DMS など、移行ツールの通信要件 を事前に洗い出し、ポート開放を最小限に抑える。
- 帯域とレイテンシを実測し、数字で移行計画を検証 した上で、本番カットオーバーに臨む。
- 移行後も見据えて、冗長構成・監視・IaC によるネットワーク管理を整える。
これらのポイントを事前に押さえておけば、AWS から Azure へのネットワーク移行は、決して特別な「大事故イベント」ではなく、再現性のある整然としたプロジェクトとして進めることができます。自社の要件に合わせて、ぜひ本記事の内容をチェックリストとして活用してみてください。
コメント