このガイドでは、Azureをアマゾン ウェブ サービス (AWS)、Google Cloud に接続する、または別のクラウド プロバイダーからワークロードを移行するユーザー向けに、Azure ネットワーク設計ガイドを通じてシーケンスされた読み取りパスを提供します。 番号付き手順に従って、Azureと既存のクラウド インフラストラクチャ間のセキュリティで保護された監視された接続を設計します。
検出が最初に来る理由
クロスクラウド ネットワークは、Azureを 1 つ以上の外部クラウド環境に接続します。 AWS または Google Cloud で、Azure サービスへのプライベート接続が必要なワークロードを実行したり、背後に残っているアプリケーションへの接続を維持しながら別のクラウドからAzureにアプリケーションを移行したりする場合があります。 どちらの方法でも、Azure ネットワークは、反対側で完全に制御できないインフラストラクチャと統合する必要があります。
この学習パスは、Azure インフラストラクチャの設計ではなく、探索から始まります。 Azure側を設計する前に、既存のマルチクラウド トポロジを最初にマップします (実行される場所、接続方法、クラウド間のトラフィックのフローを理解します)。 この検出優先アプローチにより、再作業を防ぐことができます。AWS または Google Cloud トポロジを理解せずにAzureネットワークを設計する場合は、IP アドレスの競合、接続のギャップ、セキュリティの盲点が発生するリスクがあります。
ターゲット アーキテクチャでは、AZURE Virtual Wide Area Network (WAN) をトランジット ハブ (AWS トランジット ゲートウェイと同等のAzure) として使用し、AWS Virtual Private Gateway と Google Cloud VPN への IPSec VPN トンネルを使用します。 セキュリティで保護された仮想ハブ内のAzure Firewallは、クラウドとブランチのすべてのトラフィックを検査します。 DNS では、移行中にクラウド境界を越えて名前解決が機能し続けるために、慎重なカットオーバー計画が必要です。
Prerequisites
- 使用可能なAzure ネットワーク サービスの向きについては、Azureネットワーク計画と設計の概要を参照してください。
- AWS と Google Cloud 環境のトポロジ検出を完了します。
- AWS: AWS で AWS 移行ハブまたはワークロード検出を実行して、仮想プライベートクラウド (VPC)、トランジットゲートウェイ、VPC 間接続のインベントリを作成します。
- Google Cloud: ネットワーク インテリジェンス センターを使用して、VPC ネットワーク、Cloud Interconnect の添付ファイル、ファイアウォール規則をマップします。
- クラウド間のトラフィック フローを文書化する: クラウド間で通信するアプリケーション、必要な帯域幅、待機時間の感度、暗号化の要件。
- 重複を識別するために、3 つすべてのクラウドの IP アドレス範囲のインベントリを作成します。
あなたの閲覧経路
次のフェーズでは、クラウド間ネットワークの設計を順番に説明します。
フェーズ 1: 検出
検出から始めます。 Azure インフラストラクチャを設計する前に、マルチクラウド環境を理解してください。
この記事は、設計上の中心的な決定ポイントです。 マルチクラウド トポロジをマップします。どの AWS VPC と Google Cloud VPN がAzureへの接続が必要か、クラウド間のトラフィックフロー、スケールに適合するアーキテクチャ パターン。 クラウド プロバイダー間のサービス マッピング (トランジット ゲートウェイから Virtual WAN、セキュリティ グループからネットワーク セキュリティ グループ、VPC ピアリングから VNet ピアリング) を使用して、既存の設計をAzure用語に変換します。
Virtual WANは、複数の VPC、ブランチ、リージョン、またはクラウド エッジがある場合に推奨されるトランジット モデルです。 Virtual WANは、AWS Transit Gateway と同等のAzureを提供します。自動化されたルーティング、一元化されたセキュリティ、マルチブランチ/マルチリージョンスケールです。 クラウド間の資産がVirtual WANを正当化するかどうか、またはVPN Gatewayを使用したより単純なハブ アンド スポークで十分かどうかを評価します。
フェーズ 2: 基礎
移行されたワークロードまたは接続されたワークロードのランディング ゾーンとして、Azure VNet を設計します。 AWS VPC と Google Cloud VPC の概念からのマップ: VPC サブネットはサブネットAzureになり、可用性ゾーンはAzure可用性ゾーンにマップされ、ルートテーブルも同様のパターンに従います。 Azureに配置されるワークロードのサブネットのサイズ設定に重点を置きます。
4. IP アドレスの計画
3 つのクラウドすべてに重複しないアドレス空間を計画します。 この手順は、クラウド間接続に不可欠です。Azure VNet 範囲が AWS VPC 範囲または Google Cloud VPC 範囲と重複している場合、それらの間に VPN トンネルを確立することはできません。 Azure のアドレス空間を割り当てる前に、すべての環境で使用中の CIDR ブロックをすべて文書化します。
5. ネットワーク セキュリティ グループとアプリケーション セキュリティ グループ
AWS セキュリティ グループと Google Cloud ファイアウォール規則を Azure ネットワーク セキュリティ グループ (NSG) としてミラー化します。 既存の許可規則と拒否規則を NSG 形式に変換します。 アプリケーションセキュリティグループ(ASG)を使用して、AWS セキュリティグループ参照が提供するタグベースのグループをレプリケートします。
フェーズ 3: 接続
6. ハイブリッド接続
暗号化されたクラウド間転送のために、Azureと AWS または Google Cloud の間に IPSec VPN トンネルを設定します。 AZURE VPN GATEWAY (または Virtual WAN VPN 接続) を AWS Virtual Private Gateway と Google Cloud VPN に接続します。 クラウド間トラフィックのニーズに基づいてトンネル帯域幅を選択します。 単一障害点を回避するために、冗長トンネルを計画します。
フェーズ 4: セキュリティ
ワークロードを移行する前に、DNS カットオーバー戦略を計画します。 AWS または Google Cloud のアプリケーションは、移行後にAzureを指す必要があるホスト名を解決します。 クラウド間の名前解決のために、送信エンドポイントを使用する Azure DNS Private Resolver を構成します。 ステップ バイ ステップの移行ガイダンスについては、この記事で後述する DNS カットオーバー チェックリスト を参照してください。
セキュリティで保護された仮想ハブにAzure Firewallをデプロイして、すべてのクロスクラウドおよびブランチ トラフィックを検査します。 Azureと AWS または Google Cloud の間を通過するすべてのパケットは、ログ記録とポリシー適用のためにファイアウォールを通過します。 クラウド間トラフィック パターンと脅威インテリジェンス フィルタリングにネットワーク ルールを使用して、既知の悪意のある宛先をブロックします。
フェーズ 5: 操作
クロスクラウド資産は、すべての接続の両端を制御しないため、トラブルシューティングが困難です。 接続テスト、VPN トンネル診断、パケット キャプチャのAzure Network Watcherを有効にします。 容量要件に照らして、トンネルのアップタイム、クラウド間の待機時間、スループットを監視します。 クロスクラウド アプリケーションの可用性に影響を与えるトンネル切断のアラートを設定します。
条件付き記事
特定の要件に基づいて、次の記事を含めます。
| 状態 | 記事 | 含めるタイミング |
|---|---|---|
| 一般向けアプリケーション | インターネットイングレス | 移行されたアプリケーションがインターネットに接続されている (直接パブリック アクセスが必要) |
| HTTP/HTTPS アプリケーション | Web アプリケーション ファイアウォール | 一般向けの Web アプリケーションにはレイヤー 7 WAF が必要です |
| レイヤー 7 のディストリビューションが必要 | アプリケーションの配信とパフォーマンス | 移行後にグローバルまたはリージョンのトラフィック分散が必要になる |
| パブリック エンドポイント | DDoS 保護 | 一般公開向けサービスにはアップタイム要件がある |
| ハブアンドスポーク優先 | ハブアンドスポーク トポロジ | 複数のクラウドにまたがる環境は、Virtual WAN を導入するほど大規模ではありません |
| 複数リージョンのAzure | マルチリージョン ネットワーク | Azureターゲットは、クラウド間接続を超える複数のリージョンにまたがる |
| VM 管理者アクセス | 開発者と管理者のアクセス | Azureホストされている VM への安全な RDP/SSH アクセスが必要です |
| 一元化されたエグレス | アウトバウンド インターネット アクセス | 一元化されたインターネット エグレス ポリシーは、ターゲット設計の一部です |
| 大規模な VNet 資産 | 一元化されたネットワーク管理 | Azure側は、管理されたマルチサブスクリプション資産に成長します |
| PaaS プライベート エンドポイント | PaaS プライベート アクセス | ターゲット アーキテクチャには、プライベート エンドポイントAzure PaaS サービスが含まれています |
クロスクラウド検出チェックリスト
Azure のネットワークを設計する前に、既存のクラウド サービスを Azure の対応サービスにマッピングします。 このマッピングにより、設計上の決定が迅速になり、期待の不一致が防止されます。
AWS から Azure サービスへのマッピング
| AWS サービス | Azure の同等品 | メモ |
|---|---|---|
| トランジット ゲートウェイ | Azure Virtual WAN | マルチ VPC、マルチリージョン、マルチクラウド用の集中型ルーティング ハブ |
| VPC | Azure 仮想ネットワーク | サブネットとルート テーブルを使用した分離されたネットワーク境界 |
| VPC ピアリング | 仮想ネットワーク ピアリング | 2 つの仮想ネットワーク間の直接接続 |
| セキュリティ グループ | ネットワーク セキュリティ グループ (NSG) | サブネットまたはネットワーク インターフェイス レベルでのステートフル トラフィック フィルタリング |
| ネットワークACL | NSG (サブネット レベル) | Azure NSG は、セキュリティ グループと NACL の両方の機能を組み合わせたもの |
| 仮想プライベート ゲートウェイ | VPN Gateway | IPSec VPN ターミネーション ポイント |
| 直接接続 | Azure ExpressRoute | 専用プライベート接続 (パブリック インターネット経由ではない) |
| Route 53 プライベート ホステッド ゾーン | Azure プライベート DNS ゾーン | 仮想ネットワーク内のプライベート DNS 名前解決 |
| ルートテーブル | ユーザー定義ルート (UDR) | Azureシステム ルートまたは AWS の暗黙的なルートをオーバーライドするカスタム ルーティング |
| エラスティックロードバランサー (ALB/NLB) | Azure Load Balancer/Application Gateway | L4およびL7負荷分散;Application Gateway には、AWS WAF を使用した AWS ALB に似た WAF 機能が用意されています |
| AWS WAF | Azure Web Application Firewall | レイヤー 7 の HTTP/HTTPS 保護 |
| ネットワーク ファイアウォール | Azure Firewall | 脅威インテリジェンスを使用したステートフル ネットワーク ファイアウォール |
Google Cloud から Azure サービスへのマッピング
| Google Cloud サービス | Azure の同等品 | メモ |
|---|---|---|
| VPC ネットワーク | Azure 仮想ネットワーク | Google Cloud のグローバル リソース。Azure のリージョン (リージョン間で VNet ピアリングを使用) |
| クラウド相互接続 | Azure ExpressRoute | 専用プライベート接続 |
| クラウド VPN | VPN Gateway | IPSec VPN トンネル |
| クラウド NAT | Azure NAT ゲートウェイ | プライベート リソースのアウトバウンド インターネット アクセス |
| クラウド ルーター | Azure Route Server | ネットワーク仮想アプライアンスとの動的 BGP ルート交換 |
| Cloud Armor | Azure Web Application Firewall | レイヤー 7 DDoS とアプリケーション保護 |
| ファイアウォールルール | ネットワーク セキュリティ グループ | トラフィック フィルタリング (Google Cloud ルールはグローバルです。Azure NSG はサブネットごとまたは NIC 単位です) |
| クラウド DNS プライベート ゾーン | Azure プライベート DNS ゾーン | ネットワーク内のプライベート名解決 |
| ネットワーク インテリジェンス センター | Azure Network Watcher | ネットワーク監視、診断、トポロジの視覚化 |
DNS切り替えチェックリスト
DNS カットオーバーは、クラウド間移行における最もリスクの高い手順です。 移行中の解決エラーを最小限に抑えるには、このチェックリストに従います。
移行前
- 変更されるすべての DNS レコードの Time to Live (TTL) 値を小さくします。 カットオーバーの少なくとも 48 時間前に TTL を 60 ~ 300 秒に設定します。 この手順により、レコードを更新するときにキャッシュの有効期限が迅速に切れます。
- 移行するインフラストラクチャを指すすべての DNS レコード (サーバーのレコード、サービスの CNAME レコード、メールの MX レコード、サービス検出用の SRV レコード) を文書化します。
- Azure VNet 内の送信エンドポイントを使用して、Azure DNS Private Resolver を構成します。 このリゾルバーは、共存期間中に AWS/Google クラウドホストゾーンのクエリを適切なアップストリーム DNS サーバーに転送します。
- ワークロードを移行する前に、Azure VNet から AWS/Google クラウドホスト名への前方解決と逆解決をテストします。
移行中
- Azureに移動するサービスの CNAME レコードを更新します。 各サービスの移行時に、CNAME をAzure Front Door、Azure Traffic Manager、またはAzure Application Gatewayエンドポイントにポイントします。
- 移行する個々のサーバーのホスト A レコードを更新します。 AWS または Google Cloud の IP アドレスを、DNS ゾーン内Azureプライベート IP アドレスに置き換えます。
- 移行していないゾーンの名前が元のクラウドの DNS サーバーを介して解決を続けることができるように、条件付き転送をアクティブのままにします。
移行後
- オンプレミスクライアント、Azure VNet、残りの AWS または Google Cloud ワークロードなど、すべての場所から解決を確認するには、移行された名前をすべて正しく解決する必要があります。
- 安定した解像度を確認した後、TTL 値を運用環境レベル (3,600 秒以上) に戻します。
- Azure DNSに完全に移行されたゾーンの条件付きフォワーダーを削除します。 フォワーダーは、AWS または Google Cloud に残っているゾーンに対してのみ保持します。
作成した内容
この読み取りパスに従うことで、暗号化された転送、一元化されたファイアウォール検査、監視された接続を使用して、Azureを既存の AWS または Google Cloud 環境に接続しました。 設計には次のものが含まれます。
- マルチクラウド トポロジの検出とサービス マッピング
- Virtual WANまたはハブアンドスポークトランジットアーキテクチャ
- AWS と Google Cloud への IPSec VPN トンネル
- クラウド間トラフィック検査のAzure Firewall
- クラウド間の名前解決のためのプライベート リゾルバーを使用した DNS カットオーバー
- Network Watcher によるトンネルの正常性とパフォーマンスの監視
次のステップ
- リフト アンド シフト ネットワーク パス: オンプレミスのワークロードも Azure IaaS に直接移行している場合
- ネットワーク パスの移行と最新化: Azure展開で PaaS サービスとコンテナーが採用されている場合
- 設計フェーズの概要: Azureネットワーク設計の一般的なフェーズ ベースの概要
- Azure ネットワーク計画と設計の概要: 使用可能なすべてのサービスの機能ベースの探索用