Azure Load Balancerのパブリックと内部（Internal）の違いとは？用途に合わせた正しい選び方を徹底解説

1. Azure Load Balancerとは？

1. Azure Load Balancerとは？

Azure Load Balancer（アジュール・ロード・バランサー）とは、Microsoftが提供するクラウドサービス「Azure」における、負荷分散（ふかぶんさん）装置のことです。例えば、あなたのWebサイトにたくさんの人が一気にアクセスしてきたとき、1台のサーバーだけでは処理しきれずにパンクしてしまうかもしれません。そこで、ロードバランサーを導入すると、複数のサーバーにアクセスを均等に振り分けてくれるため、サービスが止まるリスクを減らすことができます。

この仕組みは「可用性（かようせい）」の向上に直結します。可用性とは、システムを継続して利用できる能力のことです。Azureでは、このロードバランサーがレイヤー4（トランスポート層）で動作し、高速かつ低遅延なトラフィック分散を実現します。まずはこの基本を押さえておきましょう。

2. パブリックLoad Balancerの特徴と用途

2. パブリックLoad Balancerの特徴と用途

パブリックLoad Balancer（パブリック・ロード・バランサー）は、その名の通り「パブリック（公衆）」、つまりインターネットの世界に公開されている入口のことです。このロードバランサーには、パブリックIPアドレス（インターネット上の住所）が割り振られます。

主な用途は、不特定多数のユーザーがアクセスするWebサイトや、外部のシステムと通信する必要があるAPIサーバーのフロントエンドです。ユーザーがブラウザで入力したURLは、このパブリックIPに到達し、そこから背後にある仮想マシン（VM）群へ振り分けられます。インターネットからの着信トラフィックを制御するための第一関門と考えると分かりやすいでしょう。

例えば、簡単なWebアプリをインターネットに公開するための設定ファイル（JSON形式のイメージ）を考えてみましょう。

// Azure SDKを使用したパブリックIP作成のイメージ
var publicIpParams = new PublicIPAddressData()
{
    Location = "japaneast",
    PublicIPAllocationMethod = NetworkIPAllocationMethod.Static,
    Sku = new PublicIPAddressSku() { Name = PublicIPAddressSkuName.Standard }
};
// このIPをロードバランサーのフロントエンドに紐付けます

3. 内部（Internal）Load Balancerの特徴と用途

3. 内部（Internal）Load Balancerの特徴と用途

一方で、内部Load Balancer（ないぶロード・バランサー）は、インターネットには一切公開されません。これは「プライベートLoad Balancer」とも呼ばれます。Azureの仮想ネットワーク（VNet）内、あるいはVPNやExpressRoute（専用線）で接続された社内ネットワーク内でのみ有効なプライベートIPアドレスを使用します。

主な用途は、多層構造（n-tier）のアプリケーションにおける「データベース層」や「アプリケーション層」への負荷分散です。例えば、Webサーバーからデータベースへアクセスする際、直接1台のDBサーバーを指定するのではなく、内部ロードバランサーを介すことで、DBサーバーの冗長化（じょうちょうか：予備を用意しておくこと）が可能になります。

セキュリティの観点からも、インターネットに晒したくないサーバー群にはこの内部タイプを使用するのが鉄則です。不必要な露出を避けることで、サイバー攻撃のリスクを大幅に軽減できます。

4. パブリックと内部の決定的な違い

4. パブリックと内部の決定的な違い

最大の違いは「どこからの通信を受け付けるか」という点です。以下の表に主要な違いをまとめました。

例えば、データベースのアクセス権限を管理するSQL文の例を見てみましょう。内部ロードバランサーのIPアドレスからの接続のみを許可する設定が一般的です。

id | server_name | internal_ip   | role
---+-------------+---------------+-----------
1  | DB-VM-01    | 10.0.0.4      | Primary
2  | DB-VM-02    | 10.0.0.5      | Secondary
3  | ILB-FE      | 10.0.0.10     | LoadBalancer

-- ロードバランサーのプライベートIP(10.0.0.10)からのアクセスを許可する例
CREATE USER 'app_user'@'10.0.0.10' IDENTIFIED BY 'secure_password';
GRANT SELECT, INSERT ON my_database.* TO 'app_user'@'10.0.0.10';

5. SKUsの選択：基本（Basic）か標準（Standard）か

5. SKUsの選択：基本（Basic）か標準（Standard）か

Azure Load Balancerを選ぶ際、パブリックか内部かという分類の他に「SKU（エスキュー）」という選択肢があります。これは製品のグレードのようなものです。現在は「Standard（標準）」と「Basic（基本）」の2種類がありますが、本番環境では「Standard」の利用が強く推奨されています。

Standard SKUは、可用性ゾーン（Availability Zones）をサポートしており、データセンター全体がダウンするような大規模な障害にも耐えられる設計が可能です。また、診断ログの出力や、より高度なセキュリティルール（NSGによる制御）を適用できるのも特徴です。Basicは無料で手軽ですが、機能制限が多く、将来的な廃止も予定されているため、学習用以外での利用は避けましょう。

ここで、もしあなたがLinuxサーバーをロードバランサーの配下に置く場合の、簡単な疎通確認コマンドを紹介します。接続がどのサーバーに振り分けられているかを確認する際によく使われます。

curl http://10.0.0.10/hostname.html
Web-Server-01
curl http://10.0.0.10/hostname.html
Web-Server-02

6. 実際の構築ステップと注意点

6. 実際の構築ステップと注意点

ロードバランサーを構築する際は、以下の要素を順番に設定していきます。

• フロントエンドIP構成： 外部または内部からの通信を受け取る窓口。
• バックエンドプール： 通信を振り分ける先の仮想マシン（VM）のグループ。
• 正常性プローブ： 振り分け先のサーバーが生きているか確認する監視機能。
• 負荷分散規則： どのポートに来た通信を、どのポートへ渡すか決めるルール。

特に「正常性プローブ（Health Probe）」の設定は重要です。もしサーバーがフリーズして応答しなくなっても、プローブがそれを検知して自動的にそのサーバーを切り離してくれます。これにより、ユーザーには常に正常なサーバーから応答が返るようになります。初心者が陥りがちなミスとして、ネットワークセキュリティグループ（NSG）の設定で、プローブの通信をブロックしてしまうことがあります。必ずAzureの既定のタグ（AzureLoadBalancer）を許可するようにしましょう。

7. パブリックと内部を組み合わせた「n層アーキテクチャ」

7. パブリックと内部を組み合わせた「n層アーキテクチャ」

実際のビジネス現場では、パブリックLoad Balancerと内部Load Balancerを組み合わせて使います。これを「n層（エヌそう）アーキテクチャ」と呼びます。 例えば、以下のような構成です。

1. ユーザーがインターネットからパブリックLoad Balancerにアクセス。
2. パブリックLoad BalancerがWebサーバー群にトラフィックを分散。
3. Webサーバーが処理の中でデータベースが必要になると、内部Load Balancerにリクエストを送信。
4. 内部Load Balancerがデータベースサーバー群に負荷を分散。

このように役割を分けることで、データベースをインターネットから完全に隠蔽（いんぺい：隠すこと）でき、強固なセキュリティと高い拡張性を両立できるのです。まさに「餅は餅屋」ですね。

8. コストと運用のポイント

8. コストと運用のポイント

最後に、気になるコスト面についてです。内部Load Balancerであっても、Standard SKUを使用する場合は、構成と処理されたデータ量に応じて課金が発生します。ただし、それによって得られる信頼性（SLA 99.99%など）を考えれば、ビジネス利用においては非常に安価な投資と言えます。

運用の際は「メトリック」を監視することが大切です。Azure Monitor（アジュール・モニター）を使えば、現在の接続数やパケット数、さらには正常なバックエンドサーバーの数などをグラフで確認できます。何かがおかしいと感じたときは、まずフロントエンドのIPに対してPingやTest-NetConnectionコマンドを試してみるのがトラブルシューティングの第一歩です。

// C#でロードバランサーの状態を取得する簡易的なイメージ
public async Task CheckLoadBalancerStatus(string resourceGroupName, string lbName)
{
    var loadBalancer = await _client.GetLoadBalancerAsync(resourceGroupName, lbName);
    Console.WriteLine($"Name: {loadBalancer.Name}");
    Console.WriteLine($"Provisioning State: {loadBalancer.ProvisioningState}");
}

まとめ

まとめ

Azure Load Balancer（アジュール・ロード・バランサー）のパブリックと内部（Internal）の違いについて、その基本概念から具体的な活用シーン、さらには実践的な構築のポイントまで詳しく解説してきました。クラウドネイティブなシステム設計において、負荷分散は単なるアクセスの振り分け機能にとどまらず、システムの「可用性」「スケーラビリティ」「セキュリティ」を担保するための極めて重要なコンポーネントです。

パブリックと内部の最適な選択基準

結論として、どちらのロードバランサーを選択すべきかは「トラフィックの起点（どこから通信が来るか）」によって明確に決まります。インターネット上の不特定多数のユーザーを対象とするWebサービスや公開APIの入り口にはパブリックLoad Balancerを配置し、仮想ネットワーク内での多層構造を実現する場合や、データベース層への負荷分散、社内限定の業務アプリケーションなどには内部Load Balancerを活用するのが鉄則です。

また、SKUの選択においては、将来的な拡張性や高可用性を考慮し、最初からStandard（標準）SKUを選択することを強く推奨します。可用性ゾーン（Availability Zones）への対応や、ネットワークセキュリティグループ（NSG）との高度な連携は、エンタープライズレベルのシステム運用において欠かすことができない要素だからです。

実戦で役立つC#による構成確認プログラム

運用フェーズでは、ロードバランサーが正しく構成されているか、またバックエンドプールに何台の仮想マシンが紐付いているかをプログラムから確認したい場面があります。以下は、Azure SDK for .NETを使用して、ロードバランサーのフロントエンドIP構成とバックエンドプールの状態を取得するサンプルコードです。

using Azure.Identity;
using Azure.ResourceManager;
using Azure.ResourceManager.Network;
using System;

public class AzureLbInspector
{
    public async Task ShowLoadBalancerDetails(string subscriptionId, string resourceGroupName, string lbName)
    {
        var client = new ArmClient(new DefaultAzureCredential());
        SubscriptionResource subscription = client.GetSubscriptionResource(new ResourceIdentifier($"/subscriptions/{subscriptionId}"));
        ResourceGroupResource resourceGroup = await subscription.GetResourceGroups().GetAsync(resourceGroupName);
        
        // ロードバランサーのリソースを取得
        LoadBalancerResource loadBalancer = await resourceGroup.GetLoadBalancers().GetAsync(lbName);
        
        Console.WriteLine($"[LB名称]: {loadBalancer.Data.Name}");
        
        // フロントエンドIP構成の確認
        foreach (var frontendIp in loadBalancer.Data.FrontendIPConfigurations)
        {
            string ipType = frontendIp.PublicIPAddress != null ? "パブリック" : "内部(プライベート)";
            Console.WriteLine($" - フロントエンド: {frontendIp.Name} ({ipType})");
        }

        // バックエンドプールの確認
        foreach (var pool in loadBalancer.Data.BackendAddressPools)
        {
            Console.WriteLine($" - バックエンドプール: {pool.Name}");
            Console.WriteLine($"   接続されているネットワークインターフェース数: {pool.LoadBalancerBackendAddresses.Count}");
        }
    }
}

データベース接続管理とSQLによるセキュリティ制御

内部ロードバランサーを利用する最大のメリットの一つは、データベース層を隠蔽しつつ、特定の通信経路のみを許可できる点にあります。例えば、バックエンドのデータベースサーバー側で、ロードバランサーのプライベートIPアドレス（フロントエンドIP）経由の通信のみを厳格に許可する設定を行うことで、セキュリティを飛躍的に高めることができます。

以下に、データベースサーバー（MySQL/MariaDB等の例）において、内部ロードバランサーからの接続状況を確認し、適切な権限を付与する際の手順を示します。

【現在のユーザー接続権限テーブルの状態】

user          | host         | db             | select_priv | insert_priv
--------------+--------------+----------------+-------------+------------
root          | localhost    | mysql          | Y           | Y
admin         | 10.0.0.1     | app_db         | Y           | Y
web_user_tmp  | %            | test_db        | Y           | N

【内部ロードバランサーのIP(10.0.1.5)に権限を集約するSQLの実行】

-- 不要な外部公開アカウントを削除し、内部LB経由のみを許可する
DROP USER 'web_user_tmp'@'%';

-- 内部ロードバランサーのフロントエンドIP(10.0.1.5)専用のユーザーを作成
CREATE USER 'app_backend_svc'@'10.0.1.5' IDENTIFIED BY 'Complex_Password_2026';

-- 特定のデータベースに対してのみ、必要な最小限の権限を付与
GRANT SELECT, INSERT, UPDATE ON business_data.* TO 'app_backend_svc'@'10.0.1.5';

-- 設定を反映
FLUSH PRIVILEGES;

【SQL実行後のユーザー接続権限テーブルの状態】

user             | host         | db             | select_priv | insert_priv
-----------------+--------------+----------------+-------------+------------
root             | localhost    | mysql          | Y           | Y
admin            | 10.0.0.1     | app_db         | Y           | Y
app_backend_svc  | 10.0.1.5     | business_data  | Y           | Y

Linuxコマンドによるヘルスチェックのデバッグ

ロードバランサーが意図通りに動作しない場合、最も疑うべきは「正常性プローブ（Health Probe）」の状態です。バックエンドのLinuxサーバーにログインし、自分自身がロードバランサーからの監視に応答できているかをログで確認したり、手動で疎通を確認したりすることが重要です。

# 指定したIP（内部ロードバランサーのフロントエンドIP）に対してHTTPリクエストを送信し、ヘッダー情報を確認
curl -I http://10.0.1.5/healthcheck.html
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 22
Connection: keep-alive

# Webサーバー(Nginx)のアクセスログを確認し、Azureからのプローブ通信が届いているかチェック
tail -f /var/log/nginx/access.log | grep "168.63.129.16"
168.63.129.16 - - [30/Mar/2026:11:00:01 +0900] "GET /healthcheck.html HTTP/1.1" 200 22 "-" "Azure Health Probe"

※ 168.63.129.16 は、Azureの仮想パブリックIPアドレスであり、ロードバランサーの正常性プローブなどの通信に使用される特殊なアドレスです。これをネットワークセキュリティグループ（NSG）で拒否していないか確認することが、トラブル解決の近道となります。