次の方法で共有

IP アドレス指定を計画する

  • [アーティクル]

組織が Azure での IP アドレス指定を計画することが重要です。 計画することにより、IP アドレス空間が、オンプレミスの場所と Azure リージョン間で重複しないことが確認できます。

設計上の考慮事項:

  • オンプレミスと Azure リージョンの間で IP アドレス空間が重複すると、競合の大きな問題が生じます。

  • Azure VPN Gateway により、ネットワーク アドレス変換 (NAT) 機能を使用して、重複するオンプレミス サイトと重複する IP アドレス空間を接続できます。 この機能は、Azure Virtual WAN とスタンドアロンの Azure VPN Gateway で一般提供されています。

    {NAT がVPN Gatewayでどのように動作するかを示す図。}

  • 仮想ネットワークを作成した後で、アドレス空間を追加できます。 仮想ネットワークが仮想ネットワーク ピアリングを介して別の仮想ネットワークに既に接続されている場合、このプロセスでは停止は必要ありません。 代わりに、各リモート ピアリングでは、ネットワーク領域が変更された後に再同期操作が行われる必要があります。

  • Azure では、各サブネット内に 5 つの IP アドレスが予約されています。 仮想ネットワークとそれに含まれるサブネットのサイズを決定するときは、それを考慮してください。

  • 一部の Azure サービスでは、専用のサブネットが必要になります。 このようなサービスとしては、Azure Firewall や Azure VPN Gateway などがあります。

  • サブネットを特定のサービスにデリゲートして、サブネット内にサービスのインスタンスを作成することができます。

設計上の推奨事項:

  • Azure リージョンとオンプレミスの場所の間で、重複しない IP アドレス空間を事前に計画します。

  • RFC 1918 と呼ばれる、プライベート インターネットに対するアドレス割り当てから IP アドレスを使用します。

  • 次のアドレス範囲は使用しません。

    • 224.0.0.0/4 (マルチキャスト)
    • 255.255.255.255/32 (ブロードキャスト)
    • 127.0.0.0/8 (ループバック)
    • 169.254.0.0/16 (リンク ローカル)
    • 168.63.129.16/32 (内部 DNS)

  • 使用できるプライベート IP アドレスに制限がある環境では、IPv6 の使用を検討します。 VNet は IPv4 専用かデュアル スタック IPv4+IPv6 になります。

    IPv4 と IPv6 のデュアル スタックを示す図。

  • /16 のような大規模な仮想ネットワークを作成しません。 これにより、IP アドレス空間が無駄になりません。 クラスレス ドメイン間ルーティング (CIDR) サブネット定義を使用する場合、サポートされる最小の IPv4 サブネットは /29、最大は /2 です。 IPv6 のサブネットは、正確に /64 のサイズである必要があります。

  • 前もって必要なアドレス空間を計画することなく仮想ネットワークを作成することはやめてください。

  • 仮想ネットワークにはパブリック IP アドレスを使用しないでください。パブリック IP アドレスがお客様の組織に属していない場合は特にそうです。

  • 使用するサービスを考慮します。CNI ネットワークを使用した AKS など、予約済み IP (IP アドレス) を持つサービスもいくつかあります

  • IPv4 の枯渇を防ぐには、ルーティング不可能なランディング ゾーン スポーク仮想ネットワーク および Azure Private Link サービスを使用します。

IPv6 に関する考慮事項

環境で IPv6 を採用する組織が増えています。 この導入は、パブリック IPv4 スベース領域の枯渇、プライベート IPv4 の不足、特に大規模なネットワーク内での IPv6 専用クライアントへの接続の必要性によって推進されます。 IPv6 を採用するための普遍的なアプローチはありません。 ただし、IPv6 を計画し、既存の Azure ネットワークに実装する時に従うことができるベスト プラクティスがあります。

Microsoft Cloud Adoption Framework for Azureは、クラウドでシステムを作成する際に考慮すべき事項を理解するのに役立ちます。 持続可能なシステムを設計するためのアーキテクチャのベスト プラクティスについては、Azure ランディング ゾーンの設計ルールに関するページを参照してください。 参照アーキテクチャのデプロイ、図、ガイドなど、お使いのクラウド アーキテクチャに関する詳細な推奨事項とベスト プラクティスについては、IPv に関するアーキテクチャ センター ガイドを参照してください。

設計上の考慮事項:

  • IPv6 の導入を段階的に行います。 ビジネス ニーズに応じて IPv6 を実装します。 Ipv4とIpv6は必要な限り共存できることを覚えておいてください。

  • 仮想マシン(vm)のように、Ipv6を完全にサポートするinfrastructure as a service (iaas)サービスにアプリケーションが依存するシナリオでは、Ipv4とIpv6のネイティブなエンドツーエンドの使用が可能です。 この構成により、変換の複雑さを回避し、サーバーとアプリケーションに最も多くの情報を提供します。

    ipv6アドレスを使用して、インターネットに対応した基本的なskuのazureロードバランサを導入できます。 この構成により、ロードバランサを介してパブリックインターネットとazure vm間のネイティブなエンドツーエンドIpv6接続が可能になります。 このアプローチでは、vmとパブリックインターネット上のIpv6対応クライアント間のネイティブなエンドツーエンドのアウトバウンド接続も容易になります。 この方法では、パス内のすべてのデバイスが IPv6 トラフィックを処理する必要があることに注意してください。

    ネイティブのエンド ツー エンドアプローチは、サーバー間通信またはクライアント間通信に最も役立ちます。 通常、ファイアウォール、Web アプリケーション ファイアウォール、またはリバース プロキシによって保護されるほとんどの Web サービスやアプリケーションでは役に立ちません。

  • サードパーティのサービス、サービスとしてのプラットフォーム (PaaS) サービス、バックエンド ソリューションの組み合わせを使用する一部の複雑なデプロイとアプリケーションでは、ネイティブ IPv6 がサポートされない場合があります。 このような場合は、NAT/NAT64 または IPv6 プロキシ ソリューションを使用して、IPv6 と IPv4 の間の通信を有効にする必要があります。

  • アプリケーションアーキテクチャの複雑さや教育コストなどのその他の要因が重要であると考えられる場合は、バックエンドでipv4のみのインフラストラクチャを使用し続け、サービス配信のためにサードパーティ製ネットワーク仮想アプライアンス(nva)デュアルスタックipv4 / ipv6ゲートウェイを展開することができます。

    NVA を使用する一般的なデプロイは、次のようになります。

    IPv4 専用バックエンドへのアクセスを提供するデュアル スタック IPv4/IPv6 ゲートウェイを示す図。

設計上の推奨事項:

一般的なアーキテクチャの詳細を次に示します。

IPv4 専用バックエンドへのアクセスを提供する IPv4/IPv6 ロード バランサーを示す図。

  • 回復性を高めるため、柔軟なオーケストレーション (VMSS Flex) を備えた Virtual Machine Scale Sets に NVA をデプロイし、パブリック IP アドレス フロントエンドを持つAzure Load-Balancer を介してインターネットに公開します。

    NVA は IPv4 及び IPv6 トラフィックを受け入れ、それを IPv4 専用トラフィックに変換して、アプリケーション サブネット内のアプリケーションにアクセスします。 このアプローチにより、アプリケーション チームの複雑さが軽減され、攻撃対象領域が減少します。

  • グローバル トラフィック ルーティング用の Azure Front Door。

    Azure Front Door の機能には、次に示すように、IPv6 クライアント要求のプロキシと IPv4 専用バックエンドへのトラフィックが含まれます。

    IPv4 専用バックエンドへのアクセスを提供する Azure Front Door を示す図。

NVA アプローチと Azure Front Door アプローチのメイン違いを次に示します。

  • NVAsは、OSI参照モデルのレイヤ4で動作し、プライベートおよびパブリックインターフェイスを使用して、アプリケーションと同じazure仮想ネットワークに展開できます。
  • Azure Front Door はグローバルな Azure PaaS サービスであり、レイヤー 7 (HTTP/HTTPS) で動作します。 アプリケーションバックエンドは、azureフロントドアからのトラフィックのみを受け入れるようにロックダウンできるインターネット対応サービスです。

複雑な環境では、両方を組み合わせて使用できます。 NVA は、リージョンデプロイ内で使用されます。 Azure Front Door は、異なる Azure リージョンまたはその他のインターネットに接続された場所にある 1 つ以上のリージョン デプロイにトラフィックをルーティングするために使用されます。 最適なソリューションを決定するには、Azure Front Door の機能と製品ドキュメントを確認することをお勧めします。

IPv6 仮想ネットワーク CIDR ブロック:

  • サブスクリプション内の既存の Azure デプロイに新しい仮想ネットワークを作成するときに、1 つの IPv6 クラスレス Inter-ドメイン ルーティング (CIDR) ブロックを関連付けることができます。 IPv6 のサブネットのサイズは /64 である事。 このサイズを使用すると、オンプレミス ネットワークへのサブネットのルーティングを有効にした場合に、将来の互換性が確保されます。 一部のルーターでは、/64 IPv6 ルートのみを受け入れます。
  • IPv4 のみをサポートする既存の仮想ネットワークと、IPv4 のみを使用するように構成されたサブネット内のリソースがある場合は、仮想ネットワークとリソースに対して IPv6 サポートを有効にすることができます。 仮想ネットワークはデュアル スタック モードで動作できます。これにより、リソースは IPv4、IPv6、またはその両方を介して通信できます。 IPv4 と IPv6 の通信は互いに独立しています。
  • 仮想ネットワークとサブネットの IPv4 サポートを無効にすることはできません。 IPv4 は、Azure 仮想ネットワークの既定の IP アドレスの指定システムです。
  • IPv6 CIDR ブロックを仮想ネットワークとサブネットまたは BYOIP IPv6 に関連付けます。 CIDR 表記は、IP アドレスとそのネットワーク マスクを表す方法です。 これらのアドレスの形式は次のとおりです。
    • 個々の IPv4 アドレスは 32 ビットで、4 つのグループは 3 桁の 10 進数です。 たとえば、10.0.1.0 のようにします。
    • IPv4 CIDR ブロックには、ピリオドで区切られた 0 から 255 までの 3 桁の 3 桁の 4 つのグループがあり、その後にスラッシュと 0 から 32 までの数値が続きます。 たとえば、10.0.0.0/16 のようにします。
    • 個々の IPv6 アドレスは 128 ビットです。 4 桁の 16 進数の 8 つのグループがあります。 たとえば、2001:0db8:85a3:0000:0000:8a2e:0370:7334 のようにします。
    • IPv6 CIDR ブロックには、4 桁の 16 進数の 4 つのグループがあり、コロンで区切られ、その後に 2 つのコロンが続き、スラッシュと 1 から 128 の数値が続きます。 たとえば、2001:db8:1234:1a00::/64 のようにします。
  • IPv6 トラフィックをルーティングするようにルート テーブルを更新します。 パブリック トラフィックの場合は、サブネットから VPN Gateway または Azure ExpressRoute ゲートウェイにすべての IPv6 トラフィックをルーティングするルートを作成します。
  • セキュリティ グループの規則をアップデートして、IPv6 アドレスのルールを含めます。 これにより、インスタンスとの間で IPv6 トラフィックを送受信できるようになります。 サブネットとの間のトラフィックフローを制御するネットワーク セキュリティ グループルールがある場合、IPv6 トラフィックのルールを含める必要があります。
  • インスタンスの種類が IPv6 をサポートしていない場合は、前述のように、IPv4 から IPv6 に変換されるデュアル スタックを使用するか、NVA をデプロイします。

IP アドレス管理 (IPAM) ツール

IPAM ツールを使用すると、一元管理と可視化が可能になり、IP アドレス空間の重複や競合を防ぐことができるため、Azure での IP アドレス計画に役立ちます。 このセクションでは、IPAM ツールを導入する際の重要な考慮事項と推奨事項について説明します。

設計上の考慮事項:

要件や組織のサイズに応じて、さまざまな IPAM ツールを検討できます。 このオプションは、基本的な Excel ベースのインベントリから、オープンソースのコミュニティ主導のソリューション、高度な機能とサポートを備えた包括的なエンタープライズ製品まで多岐にわたります。

  • 実装する IPAM ツールを評価する際は、次の要素を考慮してください。

    • 組織に最小限必要な機能
    • ライセンスと継続的なメンテナンスを含む総保有コスト (TCO)
    • 監査証跡、ログ記録、ロールベースのアクセス制御
    • Microsoft Entra ID を使った認証と認可
    • API 経由でアクセス可能
    • ネットワーク管理用の他のツールやシステムとの統合
    • アクティブなコミュニティ サポートまたはソフトウェア プロバイダーによるサポートのレベル

  • Azure IPAM などのオープンソースの IPAM ツールの評価を検討してください。 Azure IPAM は、Azure プラットフォーム上に構築された軽量ソリューションです。 Azure テナント内の IP アドレス使用率を自動的に検出し、一元化された UI または RESTful API からすべてを管理できます。

  • 組織の運用モデル、および IPAM ツールの所有権について検討します。 IPAM ツールを実装する目的は、依存関係やボトルネックなしでアプリケーション チームに新しい IP アドレス空間を要求するプロセスを効率化することです。

  • IPAM ツール機能の重要な部分は、IP アドレス空間の使用量を把握し、論理的に整理することです。

設計上の推奨事項:

  • 重複しない IP アドレス空間を予約するプロセスでは、個々のアプリケーション ランディング ゾーンのニーズに基づく異なるサイズの要求に対応する必要があります。

    • たとえば、アプリケーション チームがニーズを簡単に説明できるように、T シャツのサイズ設定を採用することもできます。
      • S - /24 - 256 個の IP アドレス
      • M - /22 1,024 個の IP アドレス
      • L - /20 - 4,096 個の IP アドレス

  • IPAM ツールには、コードとしてのインフラストラクチャ (IaC) アプローチをサポートするために、重複しない IP アドレス空間を予約するための API が必要です。 この機能は、IPAM をサブスクリプション サービス プロセスにシームレスに統合するためにも重要です。これにより、エラーのリスクと手動介入の必要性が軽減されます。

    • IaC アプローチの例として、デプロイ スクリプト機能を備えた Bicep や、IPAM API からデータを動的にフェッチする Terraform データ ソースがあります。

  • Azure リージョンとワークロードのアーキタイプに従って IP アドレス空間を構成して、IP アドレス空間の体系的な配置を作成し、クリーンでトレース可能なネットワーク インベントリを確保します。

  • ワークロードの使用停止プロセスには、使用されなくなった IP アドレス空間の削除を含める必要があります。これは、後で今後の新しいワークロード用に再利用でき、効率的なリソース使用率を促進します。