すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:サーバーグループの作成と管理

最終更新日:Mar 26, 2026

Application Load Balancer (ALB) のサーバーグループは、クライアントリクエストを 1 つ以上のバックエンドサーバーにルーティングします。ALB インスタンスを使用するには、サーバーグループを作成し、それにバックエンドサーバーを追加する必要があります。

構成計画

サーバーグループを作成する前に、ビジネス要件に基づいて主要な構成を決定してください。サーバーグループタイプは作成後に変更できないため、バックエンドサービスのデプロイメントに基づいてタイプを選択してください。

サーバーグループタイプ

サーバーグループタイプ

バックエンドサービスタイプ

説明

参照

サーバー

Elastic Compute Service (ECS)、ENI、および Elastic Container Instance (ECI) インスタンス

バックエンドサーバーは、サーバーグループと同じ Virtual Private Cloud (VPC) に存在する必要があります。

IP

IP アドレス

  • リモート IP 有効化:バックエンドサーバーがサーバーグループの VPC にない場合 (別の VPC またはオンプレミス IDC の IP アドレスなど) にこのオプションを使用します。次の CIDR ブロックがサポートされています:10.0.0.0/8、100.64.0.0/10、172.16.0.0/12、および 192.168.0.0/16。

  • リモート IP 無効化:サーバーグループの VPC CIDR ブロック内の IP アドレスのみがサポートされています。

Function Compute

Function Compute

Function Compute はアクティブ化されており、ALB インスタンスと同じリージョンに存在する必要があります。

ALB インスタンスのバックエンドサーバーとして Function Compute の関数を追加する

重要

ALB インスタンスのバックエンドサーバーがリリースされるか、そのプライベート IP アドレスが変更されると、ALB はバックエンドサーバーを自動的に更新しません。サービス障害を防ぐためには、まずバックエンドサーバーを ALB サーバーグループから削除する必要があります。

バックエンドプロトコルとスケジューリングアルゴリズム

バックエンドプロトコル

ユースケース

HTTP (デフォルト)

ほとんどの Web アプリケーションシナリオ。HTTP、HTTPS、および QUIC リスナーに適しています。

HTTPS

ALB インスタンスとバックエンドサーバー間の暗号化された通信が必要です。HTTPS および HTTP リスナーに適しています。

gRPC

gRPC プロトコルを使用するバックエンドサービス。HTTP/2 が有効な HTTPS リスナーが必要です。

スケジューリングアルゴリズム

ユースケース

重み付きラウンドロビン

汎用シナリオ。重み比率に基づいてリクエストを均等に分散します。

重み付き最小接続数

長期間の接続または変動するリクエスト処理時間を持つシナリオ。重みとリアルタイム接続の両方を考慮し、負荷の低いサーバーを優先します。

一貫性ハッシュ

キャッシュヒット最適化など、リクエストアフィニティが必要なシナリオ。ソース IP または URL パラメーターに基づいて、同じ特性を持つリクエストを同じバックエンドサーバーにルーティングします。

アルゴリズムロジックの詳細については、「負荷分散スケジューリングアルゴリズム」をご参照ください。

次の表は、リスナープロトコル、バックエンドプロトコル、およびヘルスチェックプロトコル間の互換性を示しています。

リスナープロトコル

バックエンドプロトコル

サーバーグループタイプ

ヘルスチェックプロトコル

HTTP

HTTP および HTTPS

サーバー、IP、および Function Compute

Function Compute サーバーグループでは、バックエンドプロトコルまたはヘルスチェックプロトコルの構成は不要です。

HTTP、HTTPS、TCP、および gRPC

Basic ALB インスタンスは HTTPS ヘルスチェックをサポートしていません。

HTTPS

HTTP、HTTPS、および gRPC

gRPC には、HTTP/2 が有効な HTTPS リスナーが必要です。
Basic ALB インスタンスの HTTPS リスナーは、HTTP および gRPC バックエンドプロトコルのみをサポートしています。

QUIC

HTTP

サーバーグループの作成と削除

コンソール

サーバーグループの作成

  1. ALB コンソールの [サーバーグループ] ページに移動します。

  2. 上部のナビゲーションバーで、リージョンを選択し、サーバーグループの作成 をクリックします。次のパラメーターを設定し、作成 をクリックします。

    • サーバーグループタイプ:バックエンドサービスのデプロイ方法に基づいて、タイプを選択します。

      • サーバー: ECS、ENI、またはECIインスタンスをバックエンドサーバーとして使用します。これらのインスタンスは、サーバーグループと同じVPC内にある必要があります。

      • IP: バックエンドサーバーとして IP アドレスを使用します。VPC 内の IP アドレスをサポートしています。リモート IP を有効にすると、他の VPC またはオンプレミスの IDC の IP アドレスも追加できます。

      • Function Compute:Function Compute をバックエンドサービスとして使用します。Function Compute は有効化されており、ALB インスタンスと同じリージョンにある必要があります。

    • サーバーグループ名: サーバーグループのカスタム名を入力します。

    • VPC: このサーバーグループが属する VPC です。この VPC 内のバックエンドサーバーのみ、このサーバーグループに追加できます。

      IP タイプサーバーグループでリモート IP を有効にする場合、バックエンドサーバーはこの VPC に限定されませんが、VPC ネットワークから到達可能である必要があります。
      Function Compute サーバーグループの場合、このパラメーターを設定する必要はありません。
    • バックエンドサーバープロトコル: ALB インスタンスとバックエンドサーバー間の通信プロトコルを選択します。

      • HTTP(デフォルト): HTTP、HTTPS、および QUIC リスナーに適しています。ALB インスタンスとバックエンドサーバー間の通信には HTTP が使用されます。

      • HTTPS:HTTPS および HTTP リスナーに適しています。ALB インスタンスとバックエンドサーバー間の通信には、暗号化のために HTTPS を使用します。

      • gRPC: HTTPS リスナーに適しています。ALB インスタンスとバックエンドサーバー間の通信では、gRPC プロトコルを使用します。

      Basic ALB インスタンスの HTTPS リスナーは、HTTP および gRPC バックエンドプロトコルのみをサポートしています。
      Function Compute サーバーグループの場合、このパラメーターを設定する必要はありません。
    • スケジューリングアルゴリズム: リクエストのディストリビューション戦略を選択します。

      • 重み付けラウンドロビン: 重み比率に基づいてリクエストを分散します。重みの高いバックエンドサーバーには、より多くのリクエストが送られます。

      • 重み付け最小接続: リクエストを重みとリアルタイム接続数の両方に基づいて配信します。重みが同じサーバーの中で、現在の接続数が最も少ないサーバーが次のリクエストを受け取ります。

      • コンシステントハッシュ: 同じ特性を持つリクエストをハッシュ係数に基づいて同じバックエンドサーバーにルーティングします。

        ハッシュ要素の選択

        • 送信元 IP: クライアントのソース IP アドレスに基づいてハッシュ化されます。

        • URL 設定: 指定された URL パラメーターの値に基づいてハッシュ化されます。「指定された URL」を入力する必要があります。

      Function Compute タイプサーバーグループの場合、このパラメーターは不要です。
    • タグとリソースグループ:オプション。サーバーグループの分類および管理に使用されます。

      • タグキータグ値: サーバーグループをキーと値のペアでタグ付けします。

      • リソースグループ: サーバーグループが所属するリソースグループ。デフォルト: デフォルトのリソースグループ。

    • バックエンドの持続的接続: デフォルトで有効になっています。有効にすると、ALB インスタンスはバックエンドサーバーとの TCP 持続的接続を維持し、既存の接続を再利用して遅延を削減し、バックエンドサーバーの負荷を軽減します。

      Function Compute タイプサーバーグループの場合、このパラメーターは不要です。
    • ヘルスチェック: デフォルトで有効になっています。バックエンドサーバーの可用性を検出します。

      Function Compute タイプサーバーグループの場合、ヘルスチェックはデフォルトで無効です。有効にすると、ヘルスチェックプローブは Function Compute リクエストとしてカウントされ、料金が発生します。
      • ヘルスチェックの設定: 右側の 編集 をクリックして設定を展開します。パラメーターの説明については、「ALB のヘルスチェック」をご参照ください。

      • ヘルスチェックの選択と読み込み:既存のヘルスチェックテンプレートを選択し、その構成をロードします。

        将来の使用のために、関連付けられていないヘルスチェックテンプレートを作成できます。
        各サーバーグループは 1 つのヘルスチェックのみをサポートします。

サーバーグループの削除

サーバーグループは、リスナー転送ルールに関連付けられていない場合にのみ削除できます。サーバーグループを削除しても、そのバックエンドサーバーには影響しません。

ALB コンソールの[サーバーグループ]ページに移動します。対象のサーバーグループを見つけ、操作 列で更多 > 削除を選択し、OK をクリックします。

API

  • CreateServerGroup をコールして、サーバーグループを作成します。

  • 指定されたサーバーグループを削除するには、DeleteServerGroup を呼び出します。

バックエンドサーバーの追加と削除

バックエンドサーバーを追加する前に、アプリケーションがそのサーバーにデプロイされていることを確認してください。

重要
  • ALB は特定の IP アドレスを使用してバックエンドサーバーと通信し、ヘルスチェックを実行します。バックエンドサーバーが、`iptables` などのファイアウォールルールや他のセキュリティソフトウェアでこれらのアドレスをブロックしないようにしてください。

    • アップグレードされた ALB インスタンスは、通信に vSwitch の CIDR ブロックからプライベート IP アドレス (ローカル IP) を使用します。これらの IP はインスタンスの詳細ページで確認できます。

    • アップグレードされていない ALB インスタンスは、`100.64.0.0/10` の CIDR ブロックを使用してバックエンドサーバーと通信します。

  • バックエンドサーバーの設定によって、ループが発生する転送パスが作成されないようにしてください。

コンソール

バックエンドサーバーの追加

サーバータイプ

  1. ALB コンソールの[サーバーグループ] ページに移動します。対象のサーバーグループを見つけ、操作 列の バックエンドサーバーの変更 をクリックします。

  2. バックエンドサーバー タブで、バックエンドサーバーの追加 をクリックします。バックエンドサーバーの追加 パネルでサーバーを追加し、次へ をクリックします。

    • ECS インスタンスの追加

      サーバータイプECS/ENI に設定し、対象の ECS インスタンスを選択します。

      利用可能な ECS インスタンスがない場合は、サーバーリストの右上隅にある ECS の購入 をクリックします。
    • ENI の追加

      1. [サーバータイプ] を [ECS/ENI] に設定し、[上級モード] を有効化します。

      2. 対象の ECS インスタンス ID の左側にある 展开符合 アイコンをクリックし、対象の ENI を選択します。

      ENI を追加するには、ENI が ECS インスタンスにバインドされている必要があります。詳細については、「セカンダリ ENI のバインド」をご参照ください。
    • ECI インスタンスの追加

      サーバータイプECI に設定し、対象の ECI インスタンスを選択します。

      利用可能な ECI インスタンスがない場合は、サーバーリストの右上隅にある Elastic Container インスタンスの購入 をクリックします。
  3. ポート/重み ページで、追加したサーバーのポートと重みを設定し、OK をクリックします。

    • ポート:バックエンドサーバーがサービスを提供するポート。

    • 重み:サーバーに分散されるトラフィックの割合。値の範囲は 0 から 100 です。デフォルトは 100 です。

      たとえば、サーバーグループに重みがそれぞれ 100、50、50 の 3 つのサーバーが含まれている場合、リクエストは 2:1:1 の比率で分散されます。重みが 100 のサーバーはリクエストの 50% を受信し、他の 2 つのサーバーはそれぞれ 25% を受信します。

      説明
      • セッション維持が有効になっている場合、バックエンドサーバー間でのリクエストの分散が不均等になることがあります。

      • サーバーの重みが 0 に設定されている場合、そのサーバーは新しいリクエストを受信しなくなります。

      • ヘルスチェックに失敗したサーバーはトラフィックを受信しません。リクエストは、残りの正常なサーバー間で、それぞれの重みの比率に基づいて分散されます。

      • サーバーグループ内のすべてのサーバーが異常な場合でも、ALB はサービスの停止を最小限に抑えるため、サーバーの重みに基づいてトラフィックを分散しようとします。

    一括操作:

    • 複数のサーバーを選択し、リストの下部にある 同じポートを設定同じ重みを設定、または バッチ削除 オプションを使用します。

    • ポートまたは重みの入力ボックスにカーソルを合わせ、下方向へコピー上方向へコピー、または すべてコピー を選択して、現在の値を他のサーバーにすばやくコピーします。

    • ポート または 重み 列ヘッダーの リセット をクリックして、すべてのサーバーポートをクリアするか、すべての重みをデフォルト値に戻します。

Function Compute タイプ

ALB は Function Compute 2.0 と 3.0 の両方をサポートしています。ALB と Function Compute 間の通信は、Alibaba Cloud の内部ネットワークを介して安全に行われます。

使用する前に Function Compute サービスを有効化する必要があります。2024年8月27日以降に登録され、実名認証を完了した Alibaba Cloud アカウントは、有効化せずに直接サービスを使用できます。

制限事項

  1. ALB コンソールの[サーバーグループ] ページに移動します。対象のサーバーグループを見つけ、操作 列の バックエンドサーバーの変更 をクリックします。

  2. バックエンドサーバー タブで、関数の追加 をクリックします。バックエンドサーバーの追加 パネルで、次のいずれかの方法で関数を設定し、OK をクリックします。

    • {value, select, service {サービス} arn {ARN}} other { {value}

      • 関数名:作成済みの関数を選択します。利用可能な関数がない場合は、関数を作成 をクリックして作成できます。詳細については、「関数の作成」をご参照ください。

      • バージョン / エイリアスバージョンを指定 または エイリアスを設定 を選択します。新しく作成された関数には、デフォルトで LATEST バージョンのみが存在します。

    • ARN を使用した設定

      • ARN:対象の関数の ARN を入力します。Function Compute コンソールの関数詳細ページから関数の ARN を取得できます。

IP タイプ

リモート IP が有効でない場合、現在の VPC の CIDR ブロックからの IP アドレスのみ追加できます。リモート IP が有効な場合、他の VPC やオンプレミス IDC からの IP アドレスも追加できます。

説明

制限事項

警告

アップグレードされていない ALB インスタンスは、同じ VPC 内の ALB、NLB、または CLB インスタンスを IP タイプのサーバーグループに追加することをサポートしていません。同じ VPC からこれらのリソースを追加する必要がある場合は、潜在的なサービスの問題を避けるために、アップグレードされた ALB インスタンスを使用していることを確認してください。

アップグレードされたインスタンス

バックエンドサーバーの制限事項

  • プライベート IP アドレスのみがサポートされています。パブリック IP アドレスはサポートされていません。

  • IPv6 が有効な場合、サーバーグループの VPC の CIDR ブロックから IPv6 アドレスのみを追加できます。リモート IP 機能はサポートされていません。

転送設定の制限事項

  • Enterprise Edition トランジットルーターを使用する場合、指定したゾーンの vSwitch 上に ENI が作成されます。この ENI は、VPC からトランジットルーターへのトラフィックの入口として機能します。VPC インスタンスを作成する際は、VPC インスタンスをトランジットルーターに接続するために、指定したゾーンに少なくとも 1 つの vSwitch を作成するようにしてください。詳細については、「トランジットルーターの仕組み」をご参照ください。

  • ALB インスタンスとそのバックエンドサーバー間のトラフィックは、システムルートテーブルを介してのみ転送できます。VPC のカスタムルートテーブルはサポートされていません。

アップグレードされていないインスタンス

バックエンドサーバーの制限事項

転送設定の制限事項

  • リモート IP 転送は、Enterprise Edition トランジットルーターまたは Express Connect を介してサポートされます。Basic Edition トランジットルーターはサポートされていません。

    Enterprise Edition トランジットルーターを使用する場合、指定したゾーンの vSwitch 上に ENI が作成されます。この ENI は、VPC からトランジットルーターへのトラフィックの入口として機能します。VPC インスタンスを作成する際は、VPC インスタンスをトランジットルーターに接続するために、サポートされているゾーンに少なくとも 1 つの vSwitch を作成するようにしてください。詳細については、「Enterprise Edition トランジットルーターでサポートされているリージョンとゾーン」をご参照ください。

  • Cloud Enterprise Network (CEN) インスタンス内では、リージョンごとに 1 つの VPC のみが、クロスリージョンのバックエンドサーバーを使用する 1 つ以上の ALB インスタンスを含むことができます。

    image
    • 同じリージョン内の複数の VPC にある ALB インスタンスは、同じトランジットルーターを使用してバックエンドサービスにアクセスすることはできません。

      image
    • 同じリージョン内の複数の VPC にある ALB インスタンスは、複数のトランジットルーターを使用して同じバックエンドサービスにアクセスすることはできません。

      image
  • ALB インスタンスとそのバックエンドサーバー間のトラフィックは、システムルートテーブルを介してのみ転送できます。VPC のカスタムルートテーブルはサポートされていません。

  1. ALB コンソールの[サーバーグループ] ページに移動し、目的のサーバーグループを見つけて、操作 列の バックエンドサーバーの変更 をクリックします。

  2. バックエンドサーバー タブで、IP アドレスの追加 をクリックします。バックエンドサーバーの追加 パネルで、バックエンドサーバーの IP アドレスを入力し、次へ をクリックします。

    • リモート IP アドレス を有効にすると、`10.0.0.0/8`、`100.64.0.0/10`、`172.16.0.0/12`、`192.168.0.0/16` のプライベート CIDR ブロックから IP アドレスを入力できます。

    • リモート IP アドレス を有効にしない場合、現在の VPC の CIDR ブロックからのみ IP アドレスを入力できます。

    • 複数のバックエンドサーバーを追加するには、IP アドレスの追加 をクリックします。

  3. ポート/重み ページで、ポートと重みを設定し、OK をクリックします。

    • ポート:バックエンドサーバーがサービスを提供するポート。

    • 重み:サーバーに分散されるトラフィックの割合。値の範囲は 0 から 100 です。デフォルトは 100 です。

      たとえば、サーバーグループに重みがそれぞれ 100、50、50 の 3 つのサーバーが含まれている場合、リクエストは 2:1:1 の比率で分散されます。重みが 100 のサーバーはリクエストの 50% を受信し、他の 2 つのサーバーはそれぞれ 25% を受信します。

      説明
      • セッション維持が有効になっている場合、バックエンドサーバー間でのリクエストの分散が不均等になることがあります。

      • サーバーの重みが 0 に設定されている場合、そのサーバーは新しいリクエストを受信しなくなります。

      • ヘルスチェックに失敗したサーバーはトラフィックを受信しません。リクエストは、残りの正常なサーバー間で、それぞれの重みの比率に基づいて分散されます。

      • サーバーグループ内のすべてのサーバーが異常な場合でも、ALB はサービスの停止を最小限に抑えるため、サーバーの重みに基づいてトラフィックを分散しようとします。

    一括操作:

    • 複数のサーバーを選択し、リストの下部にある 同じポートを設定同じ重みを設定、または バッチ削除 オプションを使用します。

    • ポートまたは重みの入力ボックスにカーソルを合わせ、下方向へコピー上方向へコピー、または すべてコピー を選択して、現在の値を他のサーバーにすばやくコピーします。

    • リセットポート または 重み 列ヘッダーでクリックして、すべてのサーバーポートをクリアするか、すべての重みをデフォルト値に戻します。

バックエンドサーバーの削除

サーバーが削除されると、転送されたリクエストは処理されなくなります。

警告

サーバーを直接削除すると、サービスが中断される可能性があります。これを防ぐには、削除する前にサーバーの重みを 0 に設定してください。

  1. ALB コンソールの サーバーグループ ページに移動します。対象のサーバーグループを見つけ、バックエンドサーバーの変更操作 列でクリックします。

  2. バックエンドサーバー タブで、対象のバックエンドサーバーを見つけ、操作 列の 削除 をクリックし、OK をクリックします。

API

  • サーバーグループにバックエンドサーバーを追加するには、AddServersToServerGroup を呼び出します。

  • サーバーグループからバックエンドサーバーを削除するには、RemoveServersFromServerGroup を呼び出します。

セッション維持

ショッピングカートやログインセッションのように、同一クライアントからの複数のリクエストを同一のバックエンドサーバーで処理する必要がある場合は、セッション維持を有効化します。

セッション維持:デフォルトでは無効になっています。有効化すると、Application Load Balancer (ALB) インスタンスは同一クライアントからのリクエストを同一のバックエンドサーバーに分散します。

このパラメーターは、Function Compute タイプのサーバーグループでは不要です。
サーバータイプおよび IP タイプのサーバーグループのみがサポートされます。クロスゾーン負荷分散が無効になっている場合、セッション維持は有効化できません。

コンソール

サーバーグループを作成または編集する際に、[セッション維持] を有効化し、Cookie 処理方式を選択します:

  • Cookie の持続性

    • Cookie の挿入ALB は自動的に Cookie (SERVERID) を生成し、応答に挿入します。この Cookie を含む後続のリクエストは、同じバックエンドサーバーに転送されます。セッション持続性のタイムアウト期間 の有効範囲は 1~86,400 秒です。

    • Cookie の上書きALB はユーザー定義の Cookie の値を書き換えます。Cookie 名を入力します。

API

CreateServerGroup または UpdateServerGroupAttribute を呼び出す際に、StickySessionConfig パラメーターを使用してセッション維持を設定します。

詳細については、「ALB のセッション維持の設定」をご参照ください。

グレースフルスタートとシャットダウン

スロースタート

新しく追加されたバックエンドサーバーは、キャッシュがウォームアップされていない、または接続プールが確立されていないなどの要因により、完全なトラフィック負荷をすぐに処理できない場合があります。スロースタートを有効にすると、Application Load Balancer (ALB) インスタンスは指定された期間にわたって新しいサーバーに送信するリクエスト数を徐々に増やします。これにより、準備が完全でないサーバーがトラフィックスパイクによって過負荷になるのを防ぎます。

スケジューリングアルゴリズムが重み付きラウンドロビンの場合にのみサポートされます。
標準および WAF 強化 ALB インスタンスのみがサポートされます。ベーシック ALB インスタンスはサポートされていません。
Function Compute サーバーグループの場合、このパラメーターを設定する必要はありません。

コンソール

サーバーグループを作成または編集する際に、スロースタート を有効にし、スロースタートの持続時間 を設定します。持続時間は 30~900 秒の間で設定する必要があり、デフォルトは 30 秒です。持続時間が経過すると、通常のトラフィック分散が再開されます。

API

CreateServerGroup または UpdateServerGroupAttribute を呼び出す際に、SlowStartConfig を使用してスロースタートを設定します。

説明

スロースタートの仕組み:

  • サーバーグループ内に既存の正常なバックエンドサーバーがある場合、自動的にスロースタートモードにはなりません。空のサーバーグループに最初に追加されたバックエンドサーバーは、スロースタートモードにはなりません。新しいバックエンドサーバーがスロースタートモードになるのは、サーバーグループにスロースタートモードでない正常なバックエンドサーバーが少なくとも 1 台含まれている場合のみです。

  • スロースタートモードのバックエンドサーバーは、削除されるとこのモードを終了します。同じバックエンドサーバーが再度追加された場合、正常な状態になった後に再びスロースタートモードに入ります。

  • スロースタートモードのバックエンドサーバーは、異常な状態になるとこのモードを終了します。再び正常な状態になると、再度スロースタートモードに入ります。

  • ヘルスチェックが有効な場合、スロースタートはバックエンドサーバーが正常な状態になった後に有効になります。ヘルスチェックが無効な場合、スロースタートはすぐに有効になります。

詳細については、「ALB のスロースタートを使用したグレースフルなサービス起動の実装」をご参照ください。

接続ドレイン

バックエンドサーバーが削除されたり、ヘルスチェックに失敗したりした場合、デフォルトでは、クライアントが能動的に切断するか、セッションがタイムアウトした場合にのみ既存の接続が終了します。接続ドレインを有効にすると、既存の接続は切断される前にタイムアウト期間内に処理を完了でき、スムーズなサービスシャットダウンが保証されます。

標準および WAF 有効 ALB インスタンスでのみサポートされます。ベーシック ALB インスタンスはこの機能をサポートしていません。
Function Compute タイプのサーバーグループの場合、このパラメーターを設定する必要はありません。

コンソール

サーバーグループを作成または編集する際に、グレースフル・シャットダウン を有効にし、グレースフル・シャットダウンのタイムアウト を設定します。タイムアウトは 0~900 秒の範囲で設定できます。値 0 は接続を即座に中断します。デフォルトは 300 秒です。

API

CreateServerGroup または UpdateServerGroupAttribute を呼び出す際に、ConnectionDrainConfig を使用して接続ドレインを設定します。

詳細については、「ALB の接続ドレインを使用してグレースフルにサービスをオフラインにする」をご参照ください。

ゾーン間遅延の低減

デフォルトでは、ALB インスタンスは同一リージョン内の異なるゾーンに配置されたバックエンドサーバー間でトラフィックを分散します。ビジネス要件が遅延の影響を受けやすく、各ゾーンに十分なバックエンドサーバーリソースが確保されている場合は、ゾーン間負荷分散を無効化できます。これにより、トラフィックが同一ゾーン内のバックエンドサーバーのみで分散されるようになり、ゾーン間のネットワーク遅延を低減できます。

この機能は、標準およびWAF有効化済みのALBインスタンスでのみ無効化できます。ベーシックALBインスタンスではサポートされていません。
リモート IP が有効化された IP サーバーグループでは、ゾーン間(AZ 間)負荷分散を無効化できません。
ゾーン間(AZ 間)負荷分散が無効化されている場合、セッション永続性はサポートされません。
Function Compute サーバーグループでは、このパラメーターを設定する必要はありません。

コンソール

サーバーグループを作成または編集する際に、クロスゾーン負荷分散 をオフにします。

API

CreateServerGroup または UpdateServerGroupAttribute を呼び出す際、CrossZoneEnabledfalse に設定してゾーン間負荷分散を無効化します。デフォルト値は true です。

詳細については、「ALB におけるゾーン間負荷分散の無効化によるリクエスト遅延の低減」をご参照ください。

IPv6 バックエンドサーバーの追加

IPv6 サポートを有効にすることで、IPv6 タイプ のバックエンドサーバーをサーバーグループに追加できます。

  • サーバー タイプ および IP タイプ のサーバーグループのみがサポートされています。

  • サーバーグループの VPC で IPv6 が有効になっている必要があります。

  • IPv6 が有効なサーバーグループは、デュアルスタック ALB インスタンス の転送ルールにのみ追加できます。

  • IP タイプ のサーバーグループの場合、ALB インスタンス は スペックアップされたインスタンス である必要があります。この構成は、サーバーグループの VPC からの IPv6 アドレス のみをサポートしており、リモート IP 機能 は利用できません。

コンソール

サーバーグループを作成する際、IPv6 のマウント を有効にします。

API

CreateServerGroup を呼び出す際、Ipv6Enabledtrue に設定して IPv6 サポート を有効にします。

ヘルスチェックの編集

サーバーグループのヘルスチェック設定を変更します。

警告
  • ヘルスチェックを無効化すると、ALB インスタンスがバックエンドサーバーの障害を検出できなくなり、トラフィックが正常なサーバーに自動的にルーティングされません。

  • ヘルスチェックの間隔を長く設定すると、ALB インスタンスが障害発生サーバーを検出するまでの時間が延長されます。

コンソール

  1. ALB コンソールでサーバーグループページに移動します。対象のサーバーグループを見つけ、ヘルスチェックの変更操作列でクリックします。

  2. ヘルスチェックの変更 ダイアログボックスで、必要に応じてヘルスチェックを有効または無効にします。ヘルスチェックを有効にする場合は、ヘルスチェック の横にある 編集 をクリックして、パラメーターを変更します。

API

UpdateServerGroupAttribute を呼び出して、サーバーグループのヘルスチェック設定を更新します。

課金

サーバーグループは無料です。ただし、ALB インスタンスとサーバーグループ内のバックエンドサーバーは、それぞれの課金ルールに基づいて課金されます。

クォータ

クォータ名

説明

デフォルト

最大値

調整可能

alb_quota_loadbalancer_servers_num_basic_edition

Basic ALB インスタンスに追加できるバックエンドサーバーの数

200

400

はい

alb_quota_loadbalancer_servers_num_standard_edition

Standard ALB インスタンスに追加できるバックエンドサーバーの数

1,000

1,500

alb_quota_loadbalancer_servers_num_standardwithwaf_edition

WAF 有効化済み ALB インスタンスに追加できるバックエンドサーバーの数

1,000

1,500

alb_quota_server_added_num

バックエンドサーバー (IP アドレス別) を追加できるサーバーグループの数

200

300

alb_quota_servergroup_attached_num

サーバーグループをアタッチできる転送ルールの数

50

100

alb_quota_server_groups_weight

転送ルールにおける単一サーバーグループの最大重み

100

10,000

アカウントマネージャーにお問い合わせください