Application Load Balancer - Elastic Load Balancing
ロードバランサーのサブネットロードバランサーのセキュリティグループロードバランサーの状態ロードバランサーの属性IP アドレスタイプロードバランサーの接続クロスゾーンロードバランサーAWS WAF[DNS 名]

Application Load Balancer

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

詳細については、Elastic Load Balancing ユーザーガイドの How Elastic Load Balancing works を参照してください。

目次

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

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

考慮事項

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

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

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

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

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 エラーまたはタイムアウトが発生する可能性があります。

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

1 つ以上のローカルゾーンサブネットを指定できます。以下の制限が適用されます。

  • ロードバランサーで AWS WAF を使用することはできません。

  • Lambda 関数をターゲットとして使用することはできません。

  • スティッキーセッションやアプリケーションの維持設定は使用できません。

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 リージョンにターゲットを登録した場合、ターゲットは使用されません。

  • ターゲットとしての Lambda 機能、AWS WAF 統合、スティッキーセッション、認証サポート、および AWS Global Accelerator との統合は使用できません。

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、または AWS VPN などを経由）を妨げません。

routing.http.desync_mitigation_mode

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

routing.http.drop_invalid_header_fields.enabled

有効ではないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるか (true)、ターゲットにルーティングされるか (false) を示します。デフォルト: false。Elastic Load Balancing では、HTTP フィールド名レジストリに記載されているとおり、有効な HTTP ヘッダー名が正規表現 [-A-Za-z0-9]+ に準拠している必要があります。それぞれの名前は英数字またはハイフンで構成されます。このパターンに適合しない 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-Forward-For ヘッダーを変更、保持、または削除できるようにします。指定できる値は、append、preserve、および remove です。デフォルト: append。

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

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

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

routing.http2.enabled

HTTP/2 が有効化されているかどうかを示します。デフォルト: 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) の両方を使用してロードバランサーに接続できます。

考慮事項

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

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

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

dualstack-without-public-ipv4

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

考慮事項

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

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

ロードバランサーの接続

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

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

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

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

Application Load Balancer および AWS WAF

Application Load Balancer で AWS WAF を使用して、ウェブアクセスコントロールリスト (ウェブ ACL) のルールに基づいてリクエストを許可またはブロックできます。詳細については、AWS WAF デベロッパーガイドの Working with web ACLs を参照してください。

デフォルトでは、ロードバランサーが AWS WAF から応答を取得できない場合、HTTP 500 エラーが返され、リクエストは転送されません。AWS WAF に接続できない場合でもロードバランサーからターゲットにリクエストを転送する必要があるときは、AWS WAF フェールオープンを有効にできます。ロードバランサーが AWS WAF と統合されているかどうかを確認するには、AWS Management Consoleでロードバランサーを選択し、[統合されたサービス] タブを選択します。

事前定義されたウェブ ACL

AWS WAF 統合を有効にするときは、事前定義されたルールを使って新しいウェブ ACL を自動作成する方法を選択できます。事前定義されたウェブ ACL には、最も一般的なセキュリティ脅威に対処するための保護を提供する 3 つの AWS マネージドルールが含まれています。

  • AWSManagedRulesAmazonIpReputationList - Amazon IP 評価リストルールグループは、通常、ボットやその他の脅威に関連付けられている IP アドレスをブロックします。詳細については「AWS WAF デベロッパーガイド」の「Amazon IP reputation list managed rule group」を参照してください。

  • AWSManagedRulesCommonRuleSet - コアルールセット (DCR) ルールグループは、OWTAK Top 10 で説明されている高リスクで一般的に発生する脆弱性の一部を含む、さまざまな脆弱性の悪用に対する保護を提供します。詳細については、「AWS WAFデベロッパーガイド」の「Core rule set (CRS) managed rule group」を参照してください。

  • AWSManagedRulesKnownBadInputsRuleSet - 既知の不正な入力ルールグループは、無効であることが判明しているリクエストパターンおよび脆弱性の悪用または発見に関連付けられているリクエストパターンをブロックします。詳細については、「AWS WAFデベロッパーガイド」の「Known bad inputs managed rule group」を参照してください。

コンソールを使用して AWS WAF を有効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [統合] タブで [AWS ウェブアプリケーションファイアウォール (WAF)] を展開し、[WAF ウェブ ACL を関連付ける] を選択します。

  5. [ウェブ ACL] で [事前定義されたウェブ ACL を自動作成] を選択するか、既存のウェブ ACL を選択します。

  6. [ルールアクション] で [ブロック] または [カウント] を選択します。

  7. [確認] を選択します。

AWS CLI を使用して、AWS WAF フェールオープンを有効にするには

modify-load-balancer-attributes コマンドを使用します。この場合、waf.fail_open.enabled 属性は true に設定します。

[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