Azure Load BalancerのSKU比較！BasicとStandardの違いと2026年推奨設定を完全解説

1. Azure Load Balancerとは？

1. Azure Load Balancerとは？

Azure Load Balancer（アジュール・ロードバランサー）とは、Microsoftが提供するクラウドプラットフォーム「Azure」における、レイヤー4（トランスポート層）の負荷分散サービスです。インターネットからの通信や、仮想ネットワーク内の通信を、背後にある複数の仮想マシン（Virtual Machines）に効率よく振り分ける役割を担います。

例えば、1台のサーバーだけでWebサイトを運営していると、アクセスが急増した際に処理が追いつかなくなったり、そのサーバーが故障した際にサイトが見られなくなったりします。ロードバランサーを導入することで、複数のサーバーで処理を分担し、1台が故障しても他のサーバーが処理を引き継ぐ「高可用性（こうかようせい）」を実現できます。

2. SKU（価格レベル）の基本概念と2026年の現状

2. SKU（価格レベル）の基本概念と2026年の現状

Azureのサービスには「SKU（エスケーユー）」という、サービスの種類やグレードを表す単位があります。ロードバランサーには「Basic」と「Standard」という2つのSKUが存在してきました。しかし、2026年現在、クラウドインフラのセキュリティ向上と機能拡張の観点から、大きな方針転換が行われています。

Basic SKUの廃止：実は、MicrosoftはBasic SKUのロードバランサーの廃止を進めています。新規の構築では基本的にStandardを選択することが強く推奨されており、既存の環境もStandardへの移行が必須となっています。これは、Standardの方がセキュリティが高く、より複雑なネットワーク構成に対応できるためです。

3. BasicとStandardの機能・性能の違い

3. BasicとStandardの機能・性能の違い

初心者の方向けに、2つの違いを表で整理しました。特にセキュリティとスケールの面で大きな差があります。

最も大きな違いは「デフォルトのセキュリティ」です。Basicは設定なしで通信を通してしまいますが、Standardは「ネットワークセキュリティグループ（NSG）」を設定しない限り、全ての通信を遮断します。これにより、うっかりサーバーをインターネットに晒してしまうリスクを減らせます。

4. Azure CLIを使用したLoad Balancerの作成例

4. Azure CLIを使用したLoad Balancerの作成例

実際にStandardロードバランサーを作成する際のコマンド例を見てみましょう。Azure CLI（コマンドライン・インターフェース）を使うと、ブラウザで操作するよりも素早く正確に設定できます。

az network lb create --resource-group MyResourceGroup --name MyStandardLB --sku Standard --public-ip-address MyPublicIP
{
  "FullyQualifiedIds": "/subscriptions/.../MyStandardLB",
  "Information": "Standard Load Balancer created successfully."
}

このように、--sku Standardを指定することが2026年の標準的な構築手順となります。次に、作成されたロードバランサーの設定を確認するコマンドです。

az network lb show --resource-group MyResourceGroup --name MyStandardLB --query "sku"
{
  "name": "Standard",
  "tier": "Regional"
}

5. 2026年における推奨設定とベストプラクティス

5. 2026年における推奨設定とベストプラクティス

現在のクラウド環境でロードバランサーを運用する場合、単に「動けば良い」というわけではありません。以下の設定を組み合わせることが推奨されます。

• 可用性ゾーンの活用：サーバーを異なるデータセンター（ゾーン）に配置し、Standardロードバランサーでそれらを束ねます。これにより、一つのデータセンターが停電してもサービスを継続できます。
• アウトバウンドルールの設定：サーバーからインターネットへ通信する際のIPアドレスを固定し、セキュリティを強化します。
• 診断設定の有効化：「Azure Monitor」と連携させ、どのサーバーにどれくらい通信が流れているか、エラーが出ていないかを可視化します。

また、C#などのプログラムからAzureのリソース情報を取得する場合のサンプルコードを紹介します。これは、自動化ツールなどでロードバランサーの状態をチェックする際に役立ちます。

using System;

class AzureResourceChecker
{
    static void Main()
    {
        string lbName = "Standard-LB-01";
        string skuType = "Standard";

        if (skuType == "Standard")
        {
            Console.WriteLine($"リソース名: {lbName} は推奨設定のSKUです。");
        }
        else
        {
            Console.WriteLine("警告: SKUをStandardにアップグレードしてください。");
        }
    }
}

リソース名: Standard-LB-01 は推奨設定のSKUです。

6. ネットワークセキュリティグループ（NSG）との連携

6. ネットワークセキュリティグループ（NSG）との連携

Standard SKUを使用する場合、NSGの設定は「必須」です。ロードバランサー自体にはファイアウォールのような細かい拒否設定がないため、バックエンドの仮想マシン側にNSGを適用します。SQLデータベースなどへのアクセスを制限する際も、この組み合わせが基本となります。

例えば、データベースサーバーのアクセス権限を管理するテーブル構成を考えてみましょう。

id | server_name | allowed_port | security_level
---+-------------+--------------+----------------
1  | WebServer01 | 80           | High
2  | WebServer02 | 443          | High
3  | DBServer01  | 1433         | Critical
4  | AppServer01 | 8080         | Medium

特定のポートだけを許可する設定を確認するSQLクエリの例です。

SELECT server_name, allowed_port
FROM network_settings
WHERE security_level = 'High';

server_name | allowed_port
------------+--------------
WebServer01 | 80
WebServer02 | 443

7. 正常性プローブの設定方法

7. 正常性プローブの設定方法

ロードバランサーは、裏側にいるサーバーが元気に動いているかどうかを常にチェックしています。これを「正常性プローブ（せいじょうせいぷろーぶ）」と呼びます。もし、あるサーバーが応答しなくなった場合、ロードバランサーはそのサーバーへの振り分けを自動的に停止します。

C#でプローブの結果をシミュレーションするロジックを書いてみます。初心者の学習用として、条件分岐（if文）を使ってサーバーの状態を判定するコードです。

using System;

class HealthProbeSimulator
{
    static void CheckServerStatus(int statusCode)
    {
        // HTTPステータスコードが200なら正常
        if (statusCode == 200)
        {
            Console.WriteLine("サーバーは健全です。通信を継続します。");
        }
        else if (statusCode >= 500)
        {
            Console.WriteLine("サーバーエラーを検知しました。切り離しを開始します。");
        }
        else
        {
            Console.WriteLine("不明なステータスです。再試行します。");
        }
    }

    static void Main()
    {
        CheckServerStatus(200);
        CheckServerStatus(503);
    }
}

サーバーは健全です。通信を継続します。
サーバーエラーを検知しました。切り離しを開始します。

8. BasicからStandardへの移行の重要性

8. BasicからStandardへの移行の重要性

なぜここまでStandardへの移行が叫ばれているのでしょうか。それは、現代のサイバー攻撃が巧妙化しているからです。Basic SKUは「可用性セット」という古い仕組みに依存しており、最新の「可用性ゾーン」を利用できません。可用性ゾーンは、物理的に離れた場所にデータを分散させるため、大規模な災害対策（DR）にも有効です。

2026年には、Basic SKUを利用し続けることは運用のリスクだけでなく、Azureの公式サポート対象外となる可能性も極めて高いため、早期の計画的な移行が求められます。移行ツールやスクリプトも公開されているため、それらを活用して安全に環境を整えましょう。

9. 初心者がハマりやすい注意点

9. 初心者がハマりやすい注意点

最後に、設定時によくある失敗例をいくつか挙げます。

• IPアドレスの不一致：Standardロードバランサーには、Standard SKUのパブリックIPアドレスを組み合わせる必要があります。BasicのIPは使えません。
• NSGの許可漏れ：Standardに変えた途端に通信ができなくなった場合、ほとんどがNSGで通信を許可していないことが原因です。
• 価格の違い：Basicは一部無料の枠がありましたが、Standardは利用料が発生します。ただし、それに見合うだけの高い信頼性と機能が得られます。

これらのポイントを抑えておけば、Azureでのネットワーク構築はぐっと楽になります。まずは小さなテスト環境から、Standardロードバランサーを触ってみることをおすすめします。

まとめ

まとめ

本記事では、Azure Load Balancerの基本的な役割から、2026年現在におけるSKU選択の重要性、そして具体的な設定方法までを詳しく解説してきました。 Azure Load Balancerは、クラウド環境においてシステムの可用性とスケーラビリティを担保するための要となるサービスです。 特に、従来のBasic SKUが廃止に向かっている現状を踏まえ、Standard SKUへの移行と新規採用は避けて通れない課題となっています。

Standard SKUを選択することで、デフォルトでの高いセキュリティ、可用性ゾーン（AZ）への対応、そして高いSLA（稼働保証）を享受できます。 これからAzureを学ぶ方や、既存のシステムの運用を見直す方は、以下のポイントを再確認してください。

• SKUの選択：新規構築時は必ず「Standard」を選択し、既存のBasic環境は早期にリプレースを計画すること。
• セキュリティの担保：Standard SKUはデフォルトで通信が遮断されるため、ネットワークセキュリティグループ（NSG）の適切な設定が必須。
• 可用性の向上：可用性ゾーンを活用し、物理的な障害に対して強いインフラ構成を目指すこと。
• 監視と診断：正常性プローブを活用し、サーバーの異常を検知して自動的に切り離す仕組みを構築すること。

実践的な管理用SQLクエリの例

運用管理において、どのロードバランサーがどのリソースに関連付けられているかをデータベースで管理する場合の例です。 まず、現在の管理テーブルの状態を確認します。

id | lb_name           | sku_type | region       | target_resource
---+-------------------+----------+--------------+------------------
1  | Web-Front-LB      | Standard | East Asia    | WebApp-VM-Pool
2  | DB-Internal-LB    | Standard | East Asia    | SQL-Server-Cluster
3  | Legacy-App-LB     | Basic    | Japan East   | Legacy-VM-Group
4  | Global-Proxy-LB   | Standard | West US      | Proxy-Servers
5  | Test-Env-LB       | Basic    | Japan West   | Sandbox-VM

次に、早急に移行が必要な「Basic」SKUを使用しているロードバランサーを抽出するSQLを実行します。

SELECT lb_name, region, target_resource
FROM load_balancer_inventory
WHERE sku_type = 'Basic';

実行結果は以下の通りです。

lb_name       | region     | target_resource
--------------+------------+------------------
Legacy-App-LB | Japan East | Legacy-VM-Group
Test-Env-LB   | Japan West | Sandbox-VM

このように、インベントリ情報を適切に管理し、古いSKUを特定してStandardへ移行することが、2026年のインフラエンジニアには求められます。

C#によるリソース属性チェックの応用

自動化スクリプト等で、構築されたロードバランサーが組織のセキュリティポリシー（Standard SKU必須）に準拠しているかを判定するロジックです。

using System;
using System.Collections.Generic;

class AzurePolicyChecker
{
    static void Main()
    {
        var lbList = new List<LoadBalancerInfo>
        {
            new LoadBalancerInfo { Name = "LB-PROD-01", Sku = "Standard" },
            new LoadBalancerInfo { Name = "LB-DEV-01", Sku = "Basic" }
        };

        Console.WriteLine("--- Azureリソース監査開始 ---");
        foreach (var lb in lbList)
        {
            if (lb.Sku == "Standard")
            {
                Console.WriteLine($"[OK] {lb.Name}: セキュリティ基準を満たしています。");
            }
            else
            {
                Console.WriteLine($"[警告] {lb.Name}: SKUが不適切です。Standardへの変更が必要です。");
            }
        }
    }
}

class LoadBalancerInfo
{
    public string Name { get; set; }
    public string Sku { get; set; }
}

--- Azureリソース監査開始 ---
[OK] LB-PROD-01: セキュリティ基準を満たしています。
[警告] LB-DEV-01: SKUが不適切です。Standardへの変更が必要です。