翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Application Load Balancer
*ロードバランサー*は、クライアントにとって単一の通信先として機能します。クライアントはロードバランサーにリクエストを送信し、ロードバランサーはターゲット (EC2 インスタンスなど) にそれらのリクエストを送信します。ロードバランサーを設定するには、[ターゲットグループ](load-balancer-target-groups.md)を作成し、ターゲットグループにターゲットを登録します。さらに、[リスナー](load-balancer-listeners.md)を作成してクライアントからの接続リクエストがないかチェックし、リスナールールを作成してリクエストをクライアントから 1 つ以上のターゲットグループ内のターゲットにルーティングします。
詳細については、*Elastic Load Balancing ユーザーガイド*の [How Elastic Load Balancing works](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html) を参照してください。
**Topics**
+ [ロードバランサーのサブネット](#subnets-load-balancer)
+ [ロードバランサーのセキュリティグループ](#load-balancer-security-groups)
+ [ロードバランサーの状態](#load-balancer-state)
+ [ロードバランサーの属性](#load-balancer-attributes)
+ [IP アドレスタイプ](#ip-address-type)
+ [Application Load Balancer の IP アドレス管理](#w2aab7c21)
+ [IPAM IP アドレスプール](#ip-pools)
+ [ロードバランサーの接続](#load-balancer-connections)
+ [クロスゾーンロードバランサー](#cross-zone-load-balancing)
+ [[DNS 名]](#dns-name)
+ [ロードバランサーの作成](create-application-load-balancer.md)
+ [アベイラビリティーゾーンの更新](load-balancer-subnets.md)
+ [セキュリティグループの更新](load-balancer-update-security-groups.md)
+ [IP アドレスタイプの更新](load-balancer-ip-address-type.md)
+ [IPAM IP アドレスプールを更新する](load-balancer-ip-pools.md)
+ [ロードバランサーの属性を編集する](edit-load-balancer-attributes.md)
+ [ロードバランサーにタグを付ける](load-balancer-tags.md)
+ [ロードバランサーの削除](load-balancer-delete.md)
+ [リソースマップを表示する](view-resource-map.md)
+ [ゾーンシフト](zonal-shift.md)
+ [LCU 予約](capacity-unit-reservation.md)
+ [ロードバランサーの統合](load-balancer-integrations.md)
## ロードバランサーのサブネット
Application Load Balancer を作成するときは、ターゲットを含むゾーンを有効にする必要があります。ゾーンを有効にするには、ゾーン内のサブネットを指定します。Elastic Load Balancing は、指定した各ゾーンにロードバランサーノードを作成します。
**考慮事項**
+ 有効な各ゾーンに 1 つ以上の登録済みターゲットが含まれるようにすると、ロードバランサーは最も効果的に機能します。
+ ターゲットをアベイラビリティーゾーンに登録したが、ゾーンを有効にしていない場合、登録したターゲットはロードバランサーからのトラフィックを受信しません。
+ ロードバランサーで複数のゾーンを有効にする場合、ゾーンは同じタイプでなければなりません。例えば、アベイラビリティーゾーンとローカルゾーンの両方を有効にすることはできません。
+ 自分と共有しているサブネットを指定できます。
+ Elastic Load Balancing は、ロードバランサーを設定したサブネットにネットワークインターフェイスを作成します。これらのネットワークインターフェイスは、サブネットが使用可能な IP アドレスで不足している場合でも、ロードバランサーがメンテナンスアクションを実行できるように予約されています。これらには、説明「ENI reserved by ELB for subnet」があります。
Application Load Balancer では、次の タイプのサブネットがサポートされます。
**Topics**
+ [アベイラビリティーゾーンサブネット](#availability-zones)
+ [ローカルゾーンサブネット](#local-zones)
+ [Outpost サブネット](#outposts)
### アベイラビリティーゾーンサブネット
少なくとも 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 ユーザーガイド](https://docs.aws.amazon.com/outposts/latest/userguide/)」を参照してください。
+ ロードバランサーでは、ロードバランサーノードの Outpost に 2 つの `large` インスタンスが必要です。サポートされているインスタンスタイプを以下の表に示します。ロードバランサーは必要に応じてスケールし、一度に 1 サイズずつノードのサイズ変更を行います (`large` から `xlarge` に変更、`xlarge` から `2xlarge` に変更、あるいは `2xlarge` から`4xlarge` に変更)。ノードを最大のインスタンスサイズにスケールした後、追加の容量が必要な場合は、`4xlarge` インスタンスをロードバランサーノードとして追加します。ロードバランサーをスケールするのに十分なインスタンス容量または使用可能な IP アドレスがない場合、ロードバランサーは [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) にイベントを報告し、ロードバランサーの状態は `active_impaired` になります。
+ インスタンス ID または IP アドレスでターゲットを登録できます。Outpost の AWS リージョンにターゲットを登録する場合、ターゲットは使用されません。
+ 以下の機能はサポートされていません。
+ AWS Global Accelerator 統合
+ ターゲットとしての Lambda 関数
+ 相互 TLS 認証
+ スティッキーセッション
+ ユーザー認証
+ AWS WAF 統合
+ ターゲットオプティマイザ
+ ヘルスチェックログ
+ 接続ログ
+ キャパシティーユニットの予約
+ JWT 検証
+ 自動ターゲット重み
+ FIPS セキュリティポリシー
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 | |
## ロードバランサーのセキュリティグループ
*セキュリティグループ*は、ロードバランサーとの間で許可されているトラフィックを制御するファイアウォールとして機能します。インバウンドトラフィックとアウトバウンドトラフィックの両方を許可するポートとプロトコルを選択できます。
ロードバランサーに関連付けられたセキュリティグループのルールは、リスナーポートとヘルスチェックポートの両方における両方向のトラフィックを許可する必要があります。リスナーをロードバランサーに追加するとき、またはターゲットグループのヘルスチェックポートを更新するときは必ず、セキュリティグループルールを見直し、新しいポートで両方向のトラフィックが許可されていることを確認する必要があります。詳細については、「[推奨ルール](load-balancer-update-security-groups.md#security-group-recommended-rules)」を参照してください。
## ロードバランサーの状態
ロードバランサーの状態は次のいずれかです。
`provisioning`
ロードバランサーはセットアップ中です。
`active`
ロードバランサーは完全にセットアップされており、トラフィックをルーティングする準備ができています。
`active_impaired`
ロードバランサーはトラフィックをルーティングしていますが、スケールするのに必要なリソースがありません。
`failed`
ロードバランサークラウドをセットアップできませんでした。
## ロードバランサーの属性
Application Load Balancer は属性を編集することで設定できます。詳細については、「[ロードバランサーの属性を編集する](edit-load-balancer-attributes.md)」を参照してください。
ロードバランサーの属性は以下のとおりです。
`access_logs.s3.enabled`
Amazon S3 に保存されたアクセスログが有効かどうかを示します。デフォルトは `false` です。
`access_logs.s3.bucket`
アクセスログの Amazon S3 バケットの名前。この属性は、アクセスログが有効になっている場合は必須です。詳細については、「[アクセスログの有効化](enable-access-logging.md)」を参照してください。
`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` です。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-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 アドレスのタイプに基づいてターゲットと通信します。
+ ロードバランサーのデュアルスタックモードを有効にすると、Elastic Load Balancing がロードバランサーの 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 アドレスタイプの更新](load-balancer-ip-address-type.md)」を参照してください。
## Application Load Balancer の IP アドレス管理
Application Load Balancer は、EC2 のパブリック IPv4 アドレスプールのパブリック Elastic IPv4 アドレスを使用します。 [EC2 IPv4 ](https://docs.aws.amazon.com/awsec2/latest/userguide/using-instance-addresing.html) これらの IP アドレスは、 AWS コンソールで [describe-addresses ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-addresses.html) 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 に移行する](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam.html)」を参照してください。
**考慮事項**
+ IPAM IPv6 アドレスプールはサポートされません。
+ IPAM IPv4 アドレスプールは、内部ロードバランサーまたは `dualstack-without-public-ipv4` IP アドレスタイプではサポートされていません。
+ ロードバランサーで現在使用されている IPAM IP アドレスプールの IP アドレスを削除することはできません。
+ 別の IPAM IP アドレスプールへの移行中、既存の接続はロードバランサーの HTTP クライアントのキープアライブ期間に従って終了します。
+ IPAM IP アドレスプールは、複数のアカウント間で共有できます。詳細については、「[IPAM の統合オプションを設定する](https://docs.aws.amazon.com/vpc/latest/ipam/choose-single-user-or-orgs-ipam.html)」を参照してください。
+ ロードバランサーでの IPAM IP アドレスプールの使用には追加料金はかかりません。ただし、使用する階層によっては、IPAM に関連する料金が発生する場合があります。
IPAM IP アドレスプールにこれ以上割り当て可能な IP アドレスがない場合、Elastic Load Balancing は代わりに AWS マネージド IPv4 アドレスを使用します。 AWS マネージド IPv4 アドレスの使用には追加料金がかかります。これらのコストを回避するには、既存の IPAM IP アドレスプールに IP アドレス範囲を追加できます。
詳細については、「[Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/)」を参照してください。
## ロードバランサーの接続
リクエストを処理するとき、ロードバランサーは 2 つの接続を保持します。1 つはクライアントとの接続、もう 1 つはターゲットとの接続です。ロードバランサーとクライアント間の接続はフロントエンド接続とも呼ばれます。ロードバランサーとターゲット間の接続はバックエンド接続とも呼ばれます。
## クロスゾーンロードバランサー
クロスゾーン負荷分散は、Application Load Balancer のデフォルト状態でオンになっており、ロードバランサーレベルでは変更できません。詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[クロスゾーン負荷分散](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)」を参照してください。
クロスゾーン負荷分散は、ターゲットグループレベルでオフにすることができます。詳細については、「[クロスゾーン負荷分散をオフにする](edit-target-group-attributes.md#cross_zone_console_disable)」を参照してください。
## [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 ロードバランサーへのトラフィックのルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)を参照してください。
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}}
```