Load Balancer の信頼性

この記事には、Load Balancer の固有の信頼性に関する推奨事項、可用性ゾーンを使用した Load Balancer リージョンの回復性、およびリージョン間のディザスター リカバリーとビジネス継続性に関する詳細情報が含まれています。

Azure における信頼性のアーキテクチャ概要については、「Azure の信頼性」を参照してください。

信頼性に関する推奨事項

このセクションには、Azure Virtual Machines の回復性と可用性を実現するためのレコメンデーションが含まれています。 各レコメンデーションは、次の 2 つのカテゴリのいずれかに分類されます:

• 正常性項目には、構成項目などの領域と、Azure リソースの構成設定、他のサービスへの依存関係など、Azure ワークロードを構成する主要コンポーネントの適切な機能をカバーします。

• リスク項目は、可用性と回復の要件、テスト、監視、デプロイ、その他の項目など、未解決のままである場合に環境で問題が発生する可能性が高まる領域をカバーします。

信頼性に関する推奨事項の優先順位マトリックス

各推奨事項は、次の優先順位マトリックスに従ってマークされます。

Image	優先度	説明
	高	直ちに修正が必要です。
	Medium	3 から 6 か月以内に修正してください。
	低	確認が必要です。

信頼性に関する推奨事項の概要

カテゴリ	Priority	推奨事項
可用性		Standard Load Balancer がゾーン冗長であることを確認する
		バックエンド プールに 2 つ以上のインスタンスが含まれていることを確認する
システムの効率		運用ワークロードにアウトバウンド規則の代わりに NAT Gateway を使用する
		Standard Load Balancer SKU を使用する

可用性

Standard Load Balancer がゾーン冗長であることを確認する

可用性ゾーンをサポートするリージョンでは、ゾーン冗長を使用して Standard Load Balancer をデプロイする必要があります。 ゾーン冗長のある Load Balancer は、ゾーン障害が発生しても存続できる単一のフロントエンド IP アドレスによってトラフィックを提供できます。 フロントエンド IP は、ゾーンに関係なく、すべての (影響を受けない) バックエンド プール メンバーに到達するために使用できます。 可用性ゾーンが失敗する場合は、リージョン内の残りのゾーンが正常なままである限り、データ パスは存続する可能性があります。 詳細については、「ゾーン冗長ロード バランサー」を参照してください。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

バックエンド プールに 2 つ以上のインスタンスが含まれていることを確認する

バックエンドに 2 つ以上のインスタンスを使用して Load Balancer をデプロイします。 単一のインスタンスでは、単一障害点になってしまいます。 スケールを構築するために、ロード バランサーを Virtual Machine Scale Sets とペアにすることをお勧めします。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

システムの効率

運用ワークロードにアウトバウンド規則の代わりに NAT Gateway を使用する

アウトバウンド規則では、バックエンド プール内の各仮想マシン インスタンスに固定量の SNAT ポートが割り当てられます。 この割り当て方法では、特にトラフィック パターンが不均等なために特定の仮想マシンで大量の送信接続が送信された場合に、SNAT ポート枯渇が発生する可能性があります。 運用ワークロードの場合、Standard Load Balancer または任意のサブネット デプロイと Azure NAT Gateway を組み合わせることをお勧めします。 NAT Gateway は、サブネット内のすべての仮想マシン インスタンスに SNAT ポートを動的に割り当て、SNAT ポート枯渇のリスクを低減します。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Standard Load Balancer SKU を使用する

Standard SKU Load Balancer　は、可用性ゾーンとゾーンの回復性をサポートしていますが、Basic SKU ではサポートされていません。 あるゾーンがダウンしても、ゾーンの冗長性を備えた Standard Load Balancer が影響を受けることはなく、デプロイはリージョン内ゾーン障害が発生しても耐えることができます。 さらに、Standard Load Balancer はリージョン間の負荷分散をサポートしているため、リージョンで障害が発生してもアプリケーションが影響を受けることはありません。

Note

Basic ロード バランサーにはサービス レベル アグリーメント (SLA) がありません。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

Azure Load Balancer は、可用性ゾーンのシナリオをサポートしています。 Standard Load Balancer を使用することで、リソースをゾーンに一致させて、複数のゾーンに分散させることにより、シナリオ全体の可用性を向上させることができます。 このドキュメントを読んで、これらの概念と基本的なシナリオの設計ガイダンスを理解してください

ゾーン冗長を含む Load Balancer をデプロイすることをお勧めしますが、Load Balancer はゾーン冗長、ゾーン ベース、非ゾーンのいずれでも問題ありません。 ロード バランサーの可用性ゾーンの選択は、フロントエンド IP のゾーン選択と同義です。 パブリック ロード バランサーの場合、ロード バランサーのフロントエンドのパブリック IP がゾーン冗長である場合、ロード バランサーもゾーン冗長になります。 ロード バランサーのフロントエンドのパブリック IP がゾーンである場合、ロード バランサーも同じゾーンに指定されます。 ロード バランサーのゾーン関連プロパティを構成するには、必要なフロントエンドの適切な種類を選択します。

Note

ゾーンごとにロード バランサーを用意する必要はありません。複数のフロントエンド (ゾーンまたはゾーン冗長) をそれぞれのバックエンド プールに関連付けた単一のロード バランサーを用意することで目的を果たすことができます。

前提条件

• Load Balancer を含む可用性ゾーンを使用するには、可用性ゾーンをサポートするリージョンにロード バランサーを作成する必要があります。 可用性ゾーンをサポートしているリージョンを確認するには、サポートされているリージョンの一覧を参照してください。

• 可用性ゾーンをサポートするには、ロード バランサーとパブリック IP の両方に対して Standard SKU を使用します。

• Basic SKU タイプはサポートされていません。

• リソースを作成するには、ネットワーク共同作成者ロール以上が必要です。

制限事項

• 作成済みのリソースに対して、ゾーンを変更、更新、作成することはできません。
• 作成済みのリソースをゾーン ベースからゾーン冗長に、またはその逆に更新することはできません。

ゾーン冗長ロード バランサー

可用性ゾーンがあるリージョンでは、Standard Load Balancer は、単一の IP アドレスによって処理されるトラフィックでゾーン冗長にすることができます。 単一のフロントエンド IP アドレスは、ゾーンの障害が発生した後も存続します。 フロントエンド IP は、ゾーンに関係なく、すべての (影響を受けない) バックエンド プール メンバーに到達するために使用できます。 リージョン内の残りのゾーンが正常なままである限り、最大 1 つの可用性ゾーンが失敗し、データ パスが存続する可能性があります。

フロントエンドの IP アドレスは、複数の可用性ゾーンで複数の独立したインフラストラクチャ展開によって同時に処理されます。 再試行または再確立は、ゾーンの障害による影響を受けない他のゾーンで成功します。

Note

VM 1、2、3 は同じサブネットに属することができ、図に示すように、必ずしも別々のゾーンに存在する必要はありません。

ロード バランサーのバックエンド プール内のメンバーは、通常、ゾーン仮想マシンなどの単一のゾーンに関連付けられます。 運用ワークロードの一般的な設計では、複数のゾーン リソースをもつようにします。 たとえば、ロード バランサーのバックエンドのゾーン 1、2、3 から仮想マシンを配置して、ゾーン冗長フロントエンドを設けると、この設計原則が満たされます。

ゾーン ロード バランサー

単一ゾーンを保証されたフロントエンドにすることができます。これは、"ゾーン ベース" と呼ばれます。 このシナリオでは、リージョン内の 1 つのゾーンがすべての受信フローまたは送信フローを処理します。 フロントエンドは、ゾーンの正常性に左右されます。 データ パスは、それが保証されたゾーン以外のゾーンのエラーによっては影響を受けません。 ゾーン ベースのフロントエンドを使って、可用性ゾーンごとに IP アドレスを公開することができます。

さらに、各ゾーン内の負荷分散されたエンドポイントに対して、ゾーン フロントエンドを直接使用することもできます。 この構成を使ってゾーンごとに負荷分散されたエンドポイントを公開し、各ゾーンを個別に監視することができます。 パブリック エンドポイントの場合は、これらを Traffic Manager などの DNS 負荷分散製品と統合して、1 つの DNS 名を使用できます。

パブリック ロード バランサー フロントエンドの場合は、パブリック IP に zones パラメーターを追加します。 このパブリック IP は、それぞれの規則で使用されるフロントエンド IP 構成によって参照されます。

内部ロード バランサー フロントエンドの場合は、内部ロード バランサーのフロントエンド IP 構成に zones パラメーターを追加します。 ゾーン フロントエンドは、サブネット内の IP アドレスを特定のゾーンに対して保証します。

非ゾーン ロード バランサー

ロード バランサーは、"ゾーンなし" フロントエンドを使用して、非ゾーン構成で作成することもできます。 これらのシナリオでは、パブリック ロード バランサーはパブリック IP またはパブリック IP プレフィックスを使い、内部ロード バランサーはプライベート IP を使います。 このオプションによって、冗長性は保証されません。

Note

Basic SKU から Standard SKU にアップグレードされるすべてのパブリック IP アドレスは、"ゾーンなし" の種類になります。 Azure portal でパブリック IP アドレスをアップグレードする方法について説明します。

SLA の機能強化

可用性ゾーンは物理的に分離されており、電源、ネットワーク、冷却を個別に提供するため、SLA (サービス レベル アグリーメント) を向上させることができます。 詳細については、「オンライン サービスのサービス レベル アグリーメント (SLA)」を参照してください。

可用性ゾーンが有効になっているリソースを作成する

Load Balancer を使用してゾーン内または複数のゾーンの VM の負荷を分散する方法の詳細については、「クイック スタート: VM の負荷を分散するパブリック ロード バランサーを作成する」をご覧ください。

Note

• 作成済みのリソースに対して、ゾーンを変更、更新、作成することはできません。
• 作成済みのリソースをゾーン ベースからゾーン冗長に、またはその逆に更新することはできません。

フォールト トレランス

仮想マシンはクラスター内の別のサーバーにフェールオーバーでき、VM のオペレーティング システムは新しいサーバーで再起動されます。 お客様は、ディザスター リカバリー、復旧計画での仮想マシンの集約、ディザスター リカバリー訓練の実行に関するフェールオーバー プロセスを参照して、フォールト トレランス ソリューションが成功することを確認する必要があります。

詳細については、サイトの回復プロセスに関するページを参照してください。

ゾーン ダウン エクスペリエンス

ゾーンの冗長性は、データ プレーンやコントロール プレーンがヒットレスであることを意味するものではありません。 ゾーン冗長なフローは任意のゾーンを使うことができ、ユーザーのフローはリージョン内で正常なすべてのゾーンを使います。 ゾーンで障害が発生した場合、正常なゾーンを使用しているトラフィック フローは影響を受けません。

ゾーンで障害が発生したときにゾーンを使用しているトラフィック フローは影響を受ける可能性がありますが、アプリケーションは復旧できます。 Azure がゾーンの障害に対して収束した場合、トラフィックは、再送信時にリージョン内の正常なゾーンで継続されます。

障害シナリオに対するアプリケーションの回復性を向上させるには、Azure クラウド設計パターンに関する記事を参照してください。

複数のフロントエンド

複数のフロントエンドを使用すると、複数のポートまたは IP アドレスでトラフィックを負荷分散できます。 アーキテクチャを設計するときは、ゾーン冗長が複数のフロントエンドとどのように相互に作用するかを考慮してください。 常にすべてのフロントエンドが障害に対する回復性を備えることを目標とする場合は、フロントエンドとして割り当てられるすべての IP アドレスがゾーン冗長でなければなりません。 フロントエンドのセットが 1 つのゾーンに関連付けられることが目的である場合は、そのセットのすべての IP アドレスをその特定のゾーンに関連付ける必要があります。 ロード バランサーを各ゾーンに設ける必要はありません。 代わりに、各ゾーン フロントエンド、またはゾーン フロントエンドのセットを、その特定の可用性ゾーンの一部であるバックエンド プール内の仮想マシンに関連付けることができます。

安全なデプロイ手法

障害シナリオに対するアプリケーションの回復性を向上させるには、Azure クラウド設計パターンに関する記事を参照してください。

可用性ゾーン サポートに移行する

可用性ゾーンを使用するようにリージョンが拡張されている場合、既存の IP は、ロード バランサー フロントエンドに使用される IP のように、非ゾーンのままです。 アーキテクチャで新しいゾーンを利用できるようにするには、新しいフロントエンド IP を作成することをお勧めします。 作成後は、新しいゾーン冗長フロントエンドで既存の非ゾーン フロントエンドを置換できます。 VM を可用性ゾーンのサポートに移行する方法については、「Load Balancer を可用性ゾーンのサポートに移行する」を参照してください。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

Azure Standard Load Balancer では、リージョン間の負荷分散がサポートされ、次のような geo 冗長高可用性シナリオを実現できます。

• 複数のリージョンから発信された受信トラフィック。
• 次の最適なリージョンのデプロイへの即時グローバル フェールオーバー。
• 超低遅延を使用した、最も近い Azure リージョンへのリージョン間の負荷分散。
• 1 つのエンドポイントの背後でスケールアップまたはスケールダウンする機能。
• 静的なエニーキャスト グローバル IP アドレス
• クライアント IP の保持
• 学習曲線のない、既存のロード バランサーに基づくソリューション

リージョン間ロード バランサーのフロントエンド IP 構成は静的であり、ほとんどの Azure リージョンにわたって公開されます。

Note

リージョン間ロード バランサー上の負荷分散規則のバックエンド ポートは、リージョンの標準ロード バランサー上の負荷分散規則またはインバウンド NAT 規則のフロントエンド ポートと一致している必要があります。

複数リージョンの地域でのディザスター リカバリー

リージョン冗長

リージョン間ロード バランサーを既存のリージョン ロード バランサーにシームレスにリンクすることで、リージョンの冗長性を構成します。

1 つのリージョンで障害が発生した場合、トラフィックは次の最も近い正常なリージョンのロード バランサーにルーティングされます。

リージョン間ロード バランサーの正常性プローブによって、リージョン別ロード バランサーの可用性に関する情報が 5 秒ごとに収集されます。 1 つのリージョン ロード バランサーの可用性が 0 に落ちると、リージョン間ロード バランサーによって失敗が検出されます。 その後、そのリージョン ロード バランサーはローテーションから外されます。

超低遅延

geo 近接の負荷分散アルゴリズムは、ユーザーの地理的な場所と、お客様のリージョン デプロイに基づいています。

クライアントから開始されたトラフィックは、最も近い参加リージョンに到達し、Microsoft のグローバル ネットワーク バックボーンを経由して、最も近いリージョン デプロイに到達します。

たとえば、リージョン間ロード バランサーと、次の Azure リージョンの標準ロード バランサーがあるとします。

• 米国西部
• 北ヨーロッパ

フローがシアトルから開始された場合、トラフィックは米国西部に入ります。 このリージョンは、シアトルから最も近い参加リージョンです。 トラフィックは、最も近いリージョンのロード バランサー (米国西部) にルーティングされます。

Azure のリージョン間ロード バランサーでは、ルーティングの決定に geo 近接負荷分散アルゴリズムが使用されます。

リージョン ロード バランサーの構成済み負荷分散モードは、geo 近接に複数のリージョン ロード バランサーが使用されている場合に、最終的なルーティングを決定するために使用されます。

詳細については、「Azure Load Balancer の分散モードを構成する」を参照してください。

エグレス トラフィックは、リージョン ロード バランサーで設定されたルーティング設定に従います。

1 つのエンドポイントの背後でスケールアップまたはスケールダウンする機能

リージョン間ロード バランサーのグローバル エンドポイントを顧客に公開すると、中断せずにグローバル エンドポイントの背後にあるリージョン デプロイを追加または削除できるようになります。

静的なエニーキャスト グローバル IP アドレス

リージョン間ロード バランサーには静的パブリック IP が付属しています。これにより、IP アドレスを同じままにすることができます。 静的 IP の詳細については、こちらを参照してください

クライアント IP の保持

リージョン間ロード バランサーは、レイヤー 4 のパススルー ネットワーク ロード バランサーです。 このパススルーによって、パケットの元の IP が保持されます。 元の IP は、仮想マシン上で実行するコードで使用できます。 この保持機能により、IP アドレスに固有のロジックを適用できます。

フローティング IP

フローティング IP は、グローバル IP レベルとリージョン IP レベルの両方で構成できます。 詳細については、「Azure Load Balancer の複数のフロントエンド」を参照してください

Azure リージョン間の Load Balancer に構成されたフローティング IP は、バックエンドのリージョン ロードバランサー上のフローティング IP 構成とは独立して動作することにご注意ください。 リージョン間のロード バランサーでフローティング IP が有効な場合は、適切なループバック インターフェイスをバックエンド VM に追加する必要があります。

正常性プローブ

Azure のリージョン間ロード バランサーでは、トラフィックの分散先を決定するときに、バックエンドのリージョン ロード バランサーの正常性が使用されます。 ユーザーがリージョン ロード バランサーに正常性プローブを設定した場合、リージョン間ロード バランサーによる正常性チェックは、5 秒ごとに自動的に行われます。

既存の Azure Load Balancer でリージョン間ソリューションを構築する

リージョン間ロード バランサーのバックエンド プールには、1 つ以上のリージョン ロード バランサーが含まれています。

既存のロード バランサーのデプロイをリージョン間ロード バランサーに追加して、高可用性のリージョン間デプロイを実現します。

ホーム リージョンは、リージョン間ロード バランサーまたはグローバル層のパブリック IP アドレスがデプロイされる場所です。 このリージョンは、トラフィックのルーティング方法には影響しません。 ホーム リージョンがダウンしても、トラフィック フローは影響を受けません。

ホーム リージョン

• 米国中部
• 東アジア
• 米国東部 2
• 北ヨーロッパ
• 東南アジア
• 英国南部
• US Gov バージニア州
• 西ヨーロッパ
• 米国西部

Note

リージョン間ロード バランサーまたはグローバル層のパブリック IP をデプロイできるのは、一覧表示されたホーム リージョンのいずれかに限られます。

参加リージョンは、ロード バランサーのグローバル パブリック IP が公開されている場所です。

ユーザーが開始したトラフィックは、Microsoft のコア ネットワークを経由して、最も近い参加リージョンに到達します。

リージョン間ロード バランサーによって、トラフィックが適切なリージョン ロード バランサーにルーティングされます。

参加リージョン

• オーストラリア東部
• オーストラリア南東部
• インド中部
• 米国中部
• 東アジア
• 米国東部
• 米国東部 2
• 東日本
• 米国中北部
• 北ヨーロッパ
• 米国中南部
• 東南アジア
• 英国南部
• US DoD Central
• US DoD East
• US Gov アリゾナ
• US Gov テキサス
• US Gov バージニア州
• 米国中西部
• 西ヨーロッパ
• 米国西部
• 米国西部 2

Note

バックエンド リージョン ロード バランサーは、一般公開されている任意の Azure リージョンにデプロイでき、参加リージョンのみに限定されません。

制限事項

• リージョン間のフロントエンド IP 構成はパブリックのみです。 現在、内部フロントエンドはサポートされていません。

• リージョン間ロード バランサーのバックエンド プールにプライベートまたは内部ロード バランサーを追加することはできません

• 現時点では、NAT64 変換はサポートされていません。 フロントエンド IP とバックエンド IP は、同じ種類 (v4 または v6) である必要があります。

• UDP トラフィックは、IPv6 用のリージョン間ロード バランサーではサポートされていません。

• ポート 3 の UDP トラフィックは、リージョン間の Load Balancer ではサポートされていません

• アウトバウンド規則は、リージョン間ロード バランサーではサポートされていません。 アウトバウンド接続には、リージョン ロード バランサーまたは NAT ゲートウェイのアウトバウンド規則を利用してください。

料金と SLA

リージョン間ロード バランサーは、Standard ロード バランサーの SLA を共有します。

次のステップ

• Azure での信頼性
• 「チュートリアル:Azure portal を使用してリージョン間ロード バランサーを作成する」を参照して、リージョン間ロードバランサーを作成する。
• リージョン間ロード バランサーについてさらに詳しく学習する。
• Azure Load Balancer についてさらに詳しく学習する。