Application Load Balancer

ロードバランサーは、クライアントにとって単一の通信先として機能します。クライアントはロードバランサーにリクエストを送信し、ロードバランサーはターゲット (EC2 インスタンスなど) にそれらのリクエストを送信します。ロードバランサーを設定するには、ターゲットグループを作成し、ターゲットグループにターゲットを登録します。さらに、リスナーを作成してクライアントからの接続リクエストがないかチェックし、リスナールールを作成してリクエストをクライアントから 1 つ以上のターゲットグループ内のターゲットにルーティングします。

詳細については、Elastic Load Balancing ユーザーガイド」の「ELB の仕組み」を参照してください。

内容

• ロードバランサーのサブネット

• ロードバランサーのセキュリティグループ

• ロードバランサーの状態

• ロードバランサーの属性

• IP アドレスタイプ

• Application Load Balancer の IP アドレス管理

• IPAM IP アドレスプール

• ロードバランサーの接続

• クロスゾーンロードバランサー

• [DNS 名]

• ロードバランサーの作成

• アベイラビリティーゾーンの更新

• セキュリティグループの更新

• IP アドレスタイプの更新

• IPAM IP アドレスプールを更新する

• ロードバランサーの属性を編集する

• ロードバランサーにタグを付ける

• ロードバランサーの削除

• リソースマップを表示する

• ゾーンシフト

• LCU 予約

• ロードバランサーの統合

ロードバランサーのサブネット

Application Load Balancer を作成するときは、ターゲットを含むゾーンを有効にする必要があります。ゾーンを有効にするには、ゾーン内のサブネットを指定します。ELB は、指定した各ゾーンにロードバランサーノードを作成します。

考慮事項

• 有効な各ゾーンに 1 つ以上の登録済みターゲットが含まれるようにすると、ロードバランサーは最も効果的に機能します。

• ターゲットをアベイラビリティーゾーンに登録したが、ゾーンを有効にしていない場合、登録したターゲットはロードバランサーからのトラフィックを受信しません。

• ロードバランサーで複数のゾーンを有効にする場合、ゾーンは同じタイプでなければなりません。例えば、アベイラビリティーゾーンとローカルゾーンの両方を有効にすることはできません。

• 自分と共有しているサブネットを指定できます。

• ELB は、ロードバランサーを設定したサブネットにネットワークインターフェイスを作成します。これらのネットワークインターフェイスは、サブネットが使用可能な IP アドレスで不足している場合でも、ロードバランサーがメンテナンスアクションを実行できるように予約されています。これらには、説明「ENI reserved by ELB for subnet」があります。

Application Load Balancer では、次の タイプのサブネットがサポートされます。

アベイラビリティーゾーンサブネット

少なくとも 2 つのアベイラビリティーゾーンサブネットを選択する必要があります。以下の制限が適用されます。

• それぞれのサブネットは、異なるアベイラビリティーゾーンに属している必要があります。

• ロードバランサーが正しくスケールできるように、ロードバランサーのアベイラビリティーゾーンサブネットごとに CIDR ブロックを最低でも /27 ビットマスク (例: 10.0.0.0/27) にし、少なくとも各サブネットにつき 8 個の空き IP アドレスを用意してください。これらの 8 個の IP アドレスは、ロードバランサーが必要に応じてスケールアウトできるようにするために必要です。ロードバランサーはこれらの IP アドレスを使用して、ターゲットとの接続を確立します。それらがないと、Application Load Balancer ではノード交換の試行で問題が発生し、失敗状態になる可能性があります。

  注: スケールの試行中に Application Load Balancer サブネットが使用可能な IP アドレスを使い果たした場合、Application Load Balancer は不十分なキャパシティで実行されます。この間、古いノードは引き続きトラフィックを処理しますが、スケーリングの試行が停止すると、接続の確立を試行する際に 5xx エラーまたはタイムアウトが発生する可能性があります。

ローカルゾーンサブネット

ローカルゾーンサブネットを指定できます。ローカルゾーンサブネットでは、以下の機能はサポートされていません。

• ターゲットとしての Lambda 関数

• 相互 TLS 認証

• AWS WAF 統合

Outpost サブネット

1 つの Outpost サブネットを指定できます。以下の制限が適用されます。

• オンプレミスのデータセンターに Outpost をインストールして設定しておく必要があります。Outpost と AWS リージョンの間に信頼できるネットワーク接続が必要です。詳細については、「AWS Outposts ユーザーガイド」を参照してください。

• ロードバランサーでは、ロードバランサーノードの Outpost に 2 つの large インスタンスが必要です。サポートされているインスタンスタイプを以下の表に示します。ロードバランサーは必要に応じてスケールし、一度に 1 サイズずつノードのサイズ変更を行います (large から xlarge に変更、xlarge から 2xlarge に変更、あるいは 2xlarge から4xlarge に変更)。ノードを最大のインスタンスサイズにスケールした後、追加の容量が必要な場合は、4xlarge インスタンスをロードバランサーノードとして追加します。ロードバランサーをスケールするのに十分なインスタンス容量または使用可能な IP アドレスがない場合、ロードバランサーは AWS Health Dashboard にイベントを報告し、ロードバランサーの状態は active_impaired になります。

• インスタンス ID または IP アドレスでターゲットを登録できます。Outpost の AWS リージョンにターゲットを登録する場合、ターゲットは使用されません。

• 以下の機能はサポートされていません。

  • AWS Global Accelerator 統合

  • ターゲットとしての Lambda 関数

  • 相互 TLS 認証

  • スティッキーセッション

  • ユーザー認証

  • AWS WAF 統合

Application Load Balancer は、Outpost の c5/c5d、m5/m5d、または r5/r5d インスタンスにデプロイできます。次の表は、ロードバランサーが Outpost で使用できるインスタンスタイプごとのサイズと EBS ボリュームを示しています。

インスタンスタイプとサイズ	EBS ボリューム (GB)
c5/c5d
large	50
xlarge	50
2xlarge	50
4xlarge	100
m5/m5d
large	50
xlarge	50
2xlarge	100
4xlarge	100
r5/r5d
large	50
xlarge	100
2xlarge	100
4xlarge	100

ロードバランサーのセキュリティグループ

セキュリティグループは、ロードバランサーとの間で許可されているトラフィックを制御するファイアウォールとして機能します。インバウンドトラフィックとアウトバウンドトラフィックの両方を許可するポートとプロトコルを選択できます。

ロードバランサーに関連付けられたセキュリティグループのルールは、リスナーポートとヘルスチェックポートの両方における両方向のトラフィックを許可する必要があります。リスナーをロードバランサーに追加するとき、またはターゲットグループのヘルスチェックポートを更新するときは必ず、セキュリティグループルールを見直し、新しいポートで両方向のトラフィックが許可されていることを確認する必要があります。詳細については、「推奨ルール」を参照してください。

ロードバランサーの状態

ロードバランサーの状態は次のいずれかです。

provisioning

ロードバランサーはセットアップ中です。

active

ロードバランサーは完全にセットアップされており、トラフィックをルーティングする準備ができています。

active_impaired

ロードバランサーはトラフィックをルーティングしていますが、スケールするのに必要なリソースがありません。

failed

ロードバランサークラウドをセットアップできませんでした。

ロードバランサーの属性

Application Load Balancer は属性を編集することで設定できます。詳細については、「ロードバランサーの属性を編集する」を参照してください。

ロードバランサーの属性は以下のとおりです。

access_logs.s3.enabled

Amazon S3 に保存されたアクセスログが有効かどうかを示します。デフォルトは false です。

access_logs.s3.bucket

アクセスログの Amazon S3 バケットの名前。この属性は、アクセスログが有効になっている場合は必須です。詳細については、「アクセスログの有効化」を参照してください。

access_logs.s3.prefix

Amazon S3 バケットの場所のプレフィックス。

client_keep_alive.seconds

クライアントのキープアライブの値 (秒単位)。デフォルト値は 3600 秒です。

deletion_protection.enabled

削除保護が有効化されているかどうかを示します。デフォルトは false です。

idle_timeout.timeout_seconds

アイドルタイムアウト値 (秒単位)。デフォルト値は 60 秒です。

ipv6.deny_all_igw_traffic

ロードバランサーへのインターネットゲートウェイ (IGW) アクセスをブロックし、インターネットゲートウェイ経由の内部ロードバランサーへの意図しないアクセスを防止します。インターネット向けロードバランサーでは false、内部ロードバランサーでは true に設定されます。この属性は、IGW 以外のインターネットアクセス (ピアリング、Transit Gateway、 AWS Direct Connect、 など) を妨げません Site-to-Site VPN。

routing.http.desync_mitigation_mode

アプリケーションにセキュリティ上のリスクをもたらす可能性があるリクエストをロードバランサーで処理する方法を指定します。指定できる値は、monitor、defensive、および strictest です。デフォルトは defensive です。

routing.http.drop_invalid_header_fields.enabled

有効ではないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるか (true)、ターゲットにルーティングされるか (false) を示します。デフォルトは false です。ELB では、HTTP フィールド名レジストリで説明されているように[-A-Za-z0-9]+、有効な HTTP ヘッダー名が正規表現 に準拠している必要があります。それぞれの名前は英数字またはハイフンで構成されます。このパターンに適合しない HTTP ヘッダーをリクエストから削除したい場合は、true を選択します。

routing.http.preserve_host_header.enabled

Application Load Balancer が HTTP リクエストに Host ヘッダーを保持し、変更を加えずターゲットに送信するかどうかを示します。指定できる値は true および false です。デフォルトは false です。

routing.http.x_amzn_tls_version_and_cipher_suite.enabled

ネゴシエートされた TLS バージョンと暗号スイートに関する情報を含む 2 つのヘッダー (x-amzn-tls-version および x-amzn-tls-cipher-suite) が、ターゲットに送信される前にクライアントのリクエストに追加されるかどうかを指定します x-amzn-tls-version ヘッダーには、クライアントとネゴシエートされた TLS プロトコルのバージョンに関する情報があり、x-amzn-tls-cipher-suite ヘッダーには、クライアントとネゴシエートされた暗号スイートに関する情報があります。どちらのヘッダーも OpenSSL 形式です。この属性に指定できる値は true と false です。デフォルトは false です。

routing.http.xff_client_port.enabled

X-Forwarded-For ヘッダーが、クライアントがロードバランサーへの接続に使用したソースポートを保持するかどうかを指定します。指定できる値は true および false です。デフォルトは false です。

routing.http.xff_header_processing.mode

Application Load Balancer がターゲットにリクエストを送信する前に、HTTP リクエストの X-Forwarded-For ヘッダーを変更、保持、または削除できるようにします。指定できる値は、append、preserve、および remove です。デフォルトは append です。

• 値が append の場合、Application Load Balancer は、(ラストホップの) クライアント IP アドレスを HTTP リクエストの X-Forwarded-For ヘッダーに追加してからターゲットに送信します。

• 値が preserve の場合、Application Load Balancer は、HTTP リクエストの X-Forwarded-For ヘッダーを保持し、変更を加えずにターゲットに送信します。

• 値が remove の場合、Application Load Balancer は、HTTP リクエストの X-Forwarded-For ヘッダーを削除してからターゲットに送信します。

routing.http2.enabled

クライアントが HTTP/2 を使用してロードバランサーに接続できるかどうかを示します。true の場合、クライアントは HTTP/2 または HTTP/1.1 を使用して接続できます。false の場合、クライアントは HTTP/1.1 を使用して接続する必要があります。デフォルトは true です。

waf.fail_open.enabled

リクエストを転送できない場合に AWS WAF、有効なロードバランサーがターゲットにリクエストをルーティングできるようにするかどうかを示します AWS WAF。指定できる値は true および false です。デフォルトは false です。

注記

routing.http.drop_invalid_header_fields.enabled 属性は HTTP 非同期保護を提供するために導入されました。routing.http.desync_mitigation_mode 属性は、アプリケーションの HTTP 非同期からのより包括的な保護を提供するために追加されました。両方の属性を使用する必要はなく、アプリケーションの要件に最も適した属性を選択できます。

IP アドレスタイプ

インターネット向けや内部のロードバランサーへのアクセスにクライアントが使用できる IP アドレスのタイプは、ユーザーが設定できます。

Application Load Balancer は次のタイプの IP アドレスをサポートしています。

ipv4

クライアントは IPv4 アドレス (192.0.2.1 など) を使用してロードバランサーに接続する必要があります。

dualstack

クライアントは、IPv4 アドレス (192.0.2.1 など) と IPv6 アドレス (たとえば、2001:0db8:85a3:0:0:8a2e:0370:7334) の両方を使用してロードバランサーに接続できます。

dualstack-without-public-ipv4

クライアントは IPv6 アドレス (2001:0db8:85a3:0:0:8a2e:0370:7334 など) を使用してロードバランサーに接続する必要があります。

考慮事項

• ロードバランサーは、ターゲットグループの IP アドレスのタイプに基づいてターゲットと通信します。

• ロードバランサーのデュアルスタックモードを有効にすると、ELB はロードバランサーの AAAA DNS レコードを提供します。IPv4 アドレスを使用してロードバランサーと通信するクライアントは、A DNS レコードを解決します。IPv6 アドレスを使用してロードバランサーと通信するクライアントは、AAAA DNS レコードを解決します。

• インターネットゲートウェイを経由する内部デュアルスタックロードバランサーへのアクセスがブロックされ、意図しないインターネットアクセスを防止します。ただし、IGW 以外のインターネットアクセス (ピアリング、Transit Gateway AWS Direct Connect、 など) は妨げられません Site-to-Site VPN。

• Application Load Balancer 認証は、ID プロバイダー (IdP) または Amazon Cognito エンドポイントに接続する場合のみ IPv4 をサポートします。パブリック IPv4 アドレスがないとロードバランサーは認証プロセスを完了することができず、HTTP 500 エラーが発生します。

詳細については、「Application Load Balancer の IP アドレスタイプの更新」を参照してください。

Application Load Balancer の IP アドレス管理

Application Load Balancer は、EC2 のパブリック IPv4 アドレスプールのパブリック Elastic IPv4 アドレスを使用します。 EC2 IPv4 これらの IP アドレスは、 AWS コンソールで describe-addresses CLI、API、または Elastic IPsEIP) セクションを表示すると、 AWS アカウントに表示されます。各 ALB 関連 IP アドレスには、service_managed 属性が「ALB」に設定されています。

これらの IPs はアカウントに表示されますが、Application Load Balancer サービスによって完全に管理され、変更または解放することはできません。Application Load Balancer は、使用されなくなった IP をパブリック IPv4 アドレスプールにリリース IPs します。

CloudTrail は、AllocateAddress」など、Application Load Balancer の EIP に関連する API コールをログに記録します。これらの API コールは、サービスプリンシパル「elasticloadbalancing.amazonaws.com」によって呼び出されます。

注記

注: Application Load Balancer によって割り当てられた IPs は、アカウントの EIP 制限にはカウントされません。

IPAM IP アドレスプール

IPAM IP アドレスプールは、Amazon VPC IP Address Manager (IPAM) を使用して作成する連続した IP アドレス範囲 (または CIDR) のコレクションです。Application Load Balancer で IPAM IP アドレスプールを使用すると、ルーティングとセキュリティのニーズに応じて IPv4 アドレスを整理できます。IPAM IP アドレスプールを使用すると、パブリック IPv4 アドレス範囲の一部またはすべてを に取り込み AWS 、Application Load Balancer で使用することができます。EC2 インスタンスを起動して Application Load Balancer を作成する場合、IPAM IP アドレスプールは常に優先されます。IP アドレスが使用されなくなったら、すぐに再び使用できます。

開始するには、IPAM IP アドレスプールを作成します。詳細については、「IP アドレスを IPAM に移行する」を参照してください。

考慮事項

• IPAM IPv6 アドレスプールはサポートされません。

• IPAM IPv4 アドレスプールは、内部ロードバランサーまたは dualstack-without-public-ipv4 IP アドレスタイプではサポートされていません。

• ロードバランサーで現在使用されている IPAM IP アドレスプールの IP アドレスを削除することはできません。

• 別の IPAM IP アドレスプールへの移行中、既存の接続はロードバランサーの HTTP クライアントのキープアライブ期間に従って終了します。

• IPAM IP アドレスプールは、複数のアカウント間で共有できます。詳細については、「IPAM の統合オプションを設定する」を参照してください。

• ロードバランサーでの IPAM IP アドレスプールの使用には追加料金はかかりません。ただし、使用する階層によっては、IPAM に関連する料金が発生する場合があります。

  IPAM IP アドレスプールにこれ以上割り当て可能な IP アドレスがない場合、ELB は代わりに AWS マネージド IPv4 アドレスを使用します。 AWS マネージド IPv4 アドレスの使用には追加料金がかかります。これらのコストを回避するには、既存の IPAM IP アドレスプールに IP アドレス範囲を追加できます。

  詳細については、「Amazon VPC の料金」を参照してください。

ロードバランサーの接続

リクエストを処理するとき、ロードバランサーは 2 つの接続を保持します。1 つはクライアントとの接続、もう 1 つはターゲットとの接続です。ロードバランサーとクライアント間の接続はフロントエンド接続とも呼ばれます。ロードバランサーとターゲット間の接続はバックエンド接続とも呼ばれます。

クロスゾーンロードバランサー

クロスゾーン負荷分散は、Application Load Balancer のデフォルト状態でオンになっており、ロードバランサーレベルでは変更できません。詳細については、「Elastic Load Balancing ユーザーガイド」の「クロスゾーン負荷分散」を参照してください。

クロスゾーン負荷分散は、ターゲットグループレベルでオフにすることができます。詳細については、「クロスゾーン負荷分散をオフにする」を参照してください。

[DNS 名]

各 Application Load Balancer は次の構文でデフォルトのドメインネームシステム (DNS) 名を受け取ります。name-id.elb.region.amazonaws.com 例えば、my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com です。

覚えやすい DNS 名を使用したい場合は、カスタムドメイン名を作成してそれをお使いの Application Load Balancer の DNS 名に関連付けます。クライアントがこのカスタムドメイン名を使用してリクエストを生成すると、DNS サーバーはこれを Application Load Balancer の DNS 名として解決します。

最初に、認定ドメイン名レジストラにドメイン名を登録します。次に、ドメインレジストラなどの DNS サービスを使用して、Application Load Balancer にリクエストをルーティングするための DNS レコードを作成します。詳細については、DNS サービスのドキュメントを参照してください。例えば、DNS サービスとして Amazon Route 53 を使用する場合は、Application Load Balancer をポイントするエイリアスレコードを作成します。詳細については、Amazon Route 53 デベロッパーガイドの ELB ロードバランサーへのトラフィックのルーティングを参照してください。

Application Load Balancer には、有効なアベイラビリティーゾーンごとに 1 つの IP アドレスがあります。これらは Application Load Balancer ノードの IP アドレスです。Application Load Balancer の DNS 名はこれらのアドレスとして解決されます。例えば、Application Load Balancer のカスタムドメイン名が example.applicationloadbalancer.com であるとします。以下の dig または nslookup コマンドを使用して、Application Load Balancer ノードの IP アドレスを調べます。

Linux または Mac

$ dig +short example.applicationloadbalancer.com

Windows

C:\> nslookup example.applicationloadbalancer.com

Application Load Balancer には、そのノードの DNS レコードがあります。次の構文の DNS 名 (az.name-id.elb.region.amazonaws.com) を使用すると、Application Load Balancer ノードの IP アドレスを調べることができます。

Linux または Mac

$ dig +short us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com

Windows

C:\> nslookup us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com