翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Classic Load Balancer の設定
Classic Load Balancer を作成したら、設定を変更できます。例えば、ロードバランサーの属性、サブネット、セキュリティグループを更新できます。ロードバランサーの属性
[Connection Draining](config-conn-drain.md)
有効になっている場合、ロードバランサーは、登録解除されたインスタンスや異常なインスタンスからトラフィックを移動する前に、既存のリクエストを完了させることができます。
[クロスゾーンロードバランサー](enable-disable-crosszone-lb.md)
有効になっている場合、ロードバランサーは、アベイラビリティゾーンに関係なく、リクエストトラフィックをすべてのインスタンスに均等にルーティングします。
[Desync 軽減モード](config-desync-mitigation-mode.md)
アプリケーションにセキュリティ上のリスクをもたらす可能性があるリクエストをロードバランサーで処理する方法を指定します。指定できる値は、`monitor`、`defensive`、および `strictest` です。デフォルトは `defensive` です。
[アイドルタイムアウト](config-idle-timeout.md)
有効になっている場合、ロードバランサーは、指定された期間、接続をアイドル状態にしたままにします (データは接続を介して送信されません)。デフォルト値は 60 秒です。
[スティッキーセッション](elb-sticky-sessions.md)
Classic Load Balancer は、期間ベースのセッションとアプリケーションベースのセッションの両方の接続維持をサポートします。ロードバランサーの詳細
[セキュリティグループ](elb-vpc-security-groups.md)
ロードバランサーのセキュリティグループは、リスナーポートとヘルスチェックポートでインバウンドトラフィックを許可する必要があります。
[サブネット](elb-manage-subnets.md)
ロードバランサーの機能は、追加のサブネットにまで拡大できます。
[Proxy Protocol](enable-proxy-protocol.md)
有効にすると、インスタンスに送信される接続情報を含むヘッダーが追加されます。
[タグ](add-remove-tags.md)
タグを追加して、ロードバランサーを分類できます。
# Classic Load Balancer でのアイドル接続のタイムアウト設定
クライアントが Classic Load Balancer を通じて行うリクエストごとに、ロードバランサーは 2 つの接続を維持します。フロントエンド接続は、クライアントとロードバランサーの間にあります。バックエンド接続は、ロードバランサーと登録済み EC2 インスタンスの間にあります。ロードバランサーには、その接続に適用される設定済みのアイドルタイムアウト期間があります。アイドルタイムアウトが経過するまでデータが送受信されなかった場合、ロードバランサーは接続を閉じます。ファイルのアップロードなどの長いオペレーションで、完了までの時間を確保するため、各アイドルタイムアウト期間が経過するまでに少なくても 1 バイトのデータを送信し、必要に応じてアイドルタイムアウトの長さを増やします。
HTTP および HTTPS リスナーを使用する場合は、インスタンスで HTTP キープアライブのオプションを有効にすることをお勧めします。インスタンスのウェブサーバー設定で キープアライブを有効にできます。キープアライブを有効にすると、ロードバランサーはキープアライブタイムアウトが期限切れになるまでバックエンド接続を再利用できます。ロードバランサーでインスタンスへの接続を確実に閉じるには、HTTP キープアライブ時間の設定をロードバランサーのアイドルタイムアウト設定よりも大きい値に設定する必要があります。
TCP キープアライブのプローブはペイロードのデータを送信しないため、ロードバランサーが接続を終了する妨げにはならないことに注意してください。
**Topics**
+ [コンソールを使用したアイドルタイムアウトの設定](#config-idle-timeout-console)
+ [を使用してアイドルタイムアウトを設定する AWS CLI](#config-idle-timeout-awscli)
## コンソールを使用したアイドルタイムアウトの設定
Elastic Load Balancing では、ロードバランサーのアイドルタイムアウトはデフォルトで 60 秒に設定されています。アイドルタイムアウトに別の値を設定するには、次の手順を使用します。
**コンソールを使用してロードバランサーのアイドルタイムアウトを設定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[トラフィックの設定]** セクションで、**[アイドルタイムアウト]** の値を入力します。アイドルタイムアウトの範囲は 1～4,000 秒です。
1. **[Save changes]** (変更の保存) をクリックします。
## を使用してアイドルタイムアウトを設定する AWS CLI
次の [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを使用して、ロードバランサーのアイドルタイムアウトを設定します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":30}}"
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"ConnectionSettings": {
"IdleTimeout": 30
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Classic Load Balancer のクロスゾーン負荷分散の設定
*クロスゾーン負荷分散*を使用すると、Classic Load Balancer の各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンの登録されたインスタンスにリクエストを均等に分散します。クロスゾーン負荷分散が無効の場合は、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録されたインスタンスにのみリクエストを均等に分散します。詳細については、*Elastic Load Balancing ユーザーガイド*の[クロスゾーン負荷分散](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)を参照してください。
クロスゾーン負荷分散により、有効な各アベイラビリティーゾーンに等しい数のインスタンスを維持する必要性が軽減され、1 つ以上のインスタンスの消失を処理するアプリケーションの能力が向上します。ただし、耐障害性を高めるために有効な各アベイラビリティーゾーンにおよそ等しい数のインスタンスを維持することをお勧めします。
クライアントが DNS ルックアップをキャッシュする環境では、着信リクエストがいずれかのアベイラビリティーゾーンを優先する場合があります。クロスゾーン負荷分散を使用すると、リクエスト負荷の不均衡がリージョン内のすべての利用可能なインスタンスに分散されて、不適切に動作しているクライアントによる影響が軽減されます。
Classic Load Balancer の作成時における、クロスゾーン負荷分散のデフォルト状態は、ロードバランサーの作成方法により異なります。API または CLI を使用する場合、クロスゾーン負荷分散はデフォルトで無効化されます。では AWS マネジメントコンソール、クロスゾーン負荷分散を有効にするオプションがデフォルトで選択されています。クロスゾーン負荷分散は、Classic Load Balancer の作成後に、いつでも有効化または無効化できます。
**Topics**
+ [クロスゾーン負荷分散の有効化](#enable-cross-zone)
+ [クロスゾーン負荷分散の無効化](#disable-cross-zone)
## クロスゾーン負荷分散の有効化
Classic Load Balancer のクロスゾーン負荷分散は、任意のタイミングで有効化できます。
**コンソールを使用してクロスゾーン負荷分散を有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[アベイラビリティーゾーンのルーティング設定]** セクションで、**[クロスゾーン負荷分散]** を有効にします。
1. **[Save changes]** (変更の保存) をクリックします。
**を使用してクロスゾーン負荷分散を有効にするには AWS CLI**
1. 次の [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを使用して、ロードバランサーの `CrossZoneLoadBalancing` 属性を `true` に設定します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":true}}"
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": true
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (省略可) 次の [describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) コマンドを使用して、ロードバランサーのクロスゾーン負荷分散が有効になっていることを確認します。
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": true
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
## クロスゾーン負荷分散の無効化
ロードバランサーに対してクロスゾーン負荷分散オプションをいつでも無効にすることができます。
**コンソールを使用してクロスゾーン負荷分散を無効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[アベイラビリティーゾーンのルーティング設定] **セクションで、**[クロスゾーン負荷分散]** を無効にします。
1. **[Save changes]** (変更の保存) をクリックします。
クロスゾーン負荷分散を無効にするには、ロードバランサーの `CrossZoneLoadBalancing` 属性を `false` に設定します。
**を使用してクロスゾーン負荷分散を無効にするには AWS CLI**
1. 次の [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを使用します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":false}}"
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": false
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (省略可) 次の [describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) コマンドを使用して、ロードバランサーのクロスゾーン負荷分散が無効になっていることを確認します。
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": false
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
# Classic Load Balancer の Connection Draining の設定
Classic Load Balancer が、既存の接続を開いたまま、登録解除中のインスタンスまたは異常の発生したインスタンスにリクエストを送信しないようにするには、*Connection Draining* を使用します。これにより、ロードバランサーは、登録解除中のインスタンスまたは異常の発生したインスタンスに対する未処理のリクエストを完了できます。
Connection Draining を有効にするとき、ロードバランサーがインスタンスの登録解除を報告するまで接続を保持する最大時間を指定できます。最大タイムアウト値は 1 ～ 3,600 秒の間で設定できます (デフォルトは 300 秒です)。最大制限時間に達すると、ロードバランサーは登録解除中のインスタンスへの接続を強制的に閉じます。
登録解除するインスタンスに未処理のリクエストやアクティブな接続がない場合、Elastic Load Balancing は直ちに登録解除プロセスを完了します。
未処理のリクエストの処理中、ロードバランサーは登録解除中のインスタンスの状態を `InService: Instance deregistration currently in progress` と報告します。登録解除中のインスタンスが未処理のすべてのリクエストの処理を完了するか、最大制限時間に達すると、ロードバランサーは、インスタンスの状態を `OutOfService: Instance is not currently registered with the LoadBalancer` と報告します。
インスタンスで異常が発生すると、ロードバランサーはインスタンスの状態を `OutOfService` と報告します。異常の発生したインスタンスに対する未処理のリクエストがある場合、それらは完了されます。異常の発生したインスタンスへの接続には、最大制限時間は適用されません。
インスタンスが Auto Scaling グループに属しており、ロードバランサーの Connection Draining が有効になっている場合、Auto Scaling は、スケーリングイベントまたはヘルスチェック交換によりインスタンスを終了する前に、未処理のリクエストが完了するか最大制限時間に達するまで待機します。
ロードバランサーが登録解除中のインスタンスまたは異常の発生したインスタンスへの接続をただちに閉じるように設定するには、Connection Draining を無効にします。Connection Draining が無効になっていると、登録解除中のインスタンスまたは異常の発生したインスタンスに対する未処理のリクエストは完了されません。
**Topics**
+ [Connection Drainingの有効化](#enable-conn-drain)
+ [Connection Drainingの無効化](#disable-conn-drain)
## Connection Drainingの有効化
Connection Draining は、ロードバランサーに対していつでも有効にできます。
**コンソールを使用して Connection Draining を有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[トラフィックの設定]** セクションで、 **[Connection Draining の有効化]** を選択します。
1. (オプション) **[タイムアウト (ドレーニング間隔)]** に、1～3,600 秒の値を入力します。それ以外の場合は、デフォルトの 300 秒が使用されます。
1. **[Save changes]** (変更の保存) をクリックします。
**を使用して接続ドレイニングを有効にするには AWS CLI**
次の [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを使用します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":true,\"Timeout\":300}}"
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": true,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
## Connection Drainingの無効化
Connection Draining は、ロードバランサーに対していつでも無効にできます。
**コンソールを使用して Connection Draining を無効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[トラフィックの設定]** セクションで、**[Connection Draining の有効化]** の選択を解除します。
1. **[Save changes]** (変更の保存) をクリックします。
**を使用して接続ドレイニングを無効にするには AWS CLI**
次の [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを使用します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":false}}"
```
以下に、応答の例を示します。
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Classic Load Balancer のスティッキーセッションの設定
Classic Load Balancer のデフォルトでは、各リクエストは登録済みインスタンスに対し、負荷が最小になるように個別にルーティングされます。*スティッキーセッション*機能 (*セッションアフィニティ*とも呼ばれる) を使用することによって、ロードバランサーがユーザーのセッションを特定のアプリケーションインスタンスにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じインスタンスに送信されます。
スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じインスタンスに一貫してルーティングする期間の決定です。アプリケーションに独自のセッション Cookie がある場合は、Elastic Load Balancing のセッション Cookie を設定し、アプリケーションのセッション Cookie で指定された維持期間を受け入れさせることができます。アプリケーションに独自のセッション Cookie がない場合は、Elastic Load Balancing を設定し、独自の維持期間を指定しながらセッション Cookie を作成させることができます。
Elastic Load Balancing は、AWSELB という名前の Cookie を作成し、セッションをインスタンスにマッピングするために使用します。
**要件**
+ HTTP/HTTPS ロードバランサー。
+ 各アベイラビリティーゾーンに少なくとも 1 つの正常なインスタンスがあること。
**互換性**
+ Cookie の path プロパティの RFC では、アンダースコアが許容されています。ただし、Elastic Load Balancing の URI ではアンダースコアは `%5F` としてエンコードされます。Internet Explorer 7 などの一部のブラウザーでは、アンダースコアを `%5F` としてエンコードする URI が想定されているためです。現在使用されているブラウザーに影響が及ぶ可能性があることを考慮し、Elastic Load Balancing では、引き続きアンダースコア文字を URI エンコードしています。例えば、Cookie にプロパティ `path=/my_path` がある場合、Elastic Load Balancing は転送されたリクエスト内のこのプロパティを `path=/my%5Fpath` に変更します。
+ 期間ベースのセッション維持 Cookie の `secure` フラグや `HttpOnly` フラグを設定することはできません。ただし、これらの Cookie に重要なデータは含まれません。アプリケーション制御によるセッション維持 Cookie に `secure` または `HttpOnly` フラグを設定した場合、AWSELB Cookie にも設定されます。
+ アプリケーション クッキーの `Set-Cookie` フィールドで末尾にセミコロンがある場合、ロードバランサーはそのクッキーを無視します。
**Topics**
+ [期間ベースのセッションの維持](#enable-sticky-sessions-duration)
+ [アプリケーション制御によるセッションの維持](#enable-sticky-sessions-application)
## 期間ベースのセッションの維持
ロードバランサーは、各リスナーへのリクエストごとに特殊な Cookieである AWSELB を使用してインスタンスを追跡します。ロードバランサーがリクエストを受け取ると、まずこの Cookie がリクエスト内にあるかどうかを調べます。ある場合は、Cookie で指定されているインスタンスにリクエストが送信されます。Cookie がない場合は、ロードバランサーが既存の負荷分散アルゴリズムに基いてインスタンスを選択します。同じユーザーの後続のリクエストをそのインスタンスにバインドするために Cookie が応答に挿入されます。スティッキーポリシー設定では、各 Cookie の有効期間を設定する Cookie 期限を定義します。ロードバランサーは、Cookie の有効期限を更新せず、Cookie を使用する前に失効しているかどうかを確認しません。クッキーが期限切れになった後、セッションはスティッキーではなくなります。クライアントは、Cookie の失効時に Cookie ストアから削除する必要があります。
CORS (クロスオリジンリソース共有) リクエストの場合、一部のブラウザは維持を有効にするために `SameSite=None; Secure` を必要とします。この場合、Elastic Load Balancing は別の維持 Cookie として AWSELBCORS を作成します。この Cookie には、元の維持 Cookie と同じ情報に加えて `SameSite` 属性が含まれます。クライアントは両方の Cookie を受け取ります。
インスタンスでエラーや異常が発生した場合、ロードバランサーはそのインスタンスへのリクエストのルーティングを停止し、既存の負荷分散アルゴリズムに基いて新しい正常なインスタンスを選択します。リクエストは、Cookie がなく、セッションが維持されていない場合と同様に、新しいインスタンスにルーティングされます。
クライアントが異なるバックエンドポートを持つリスナーに切り替えた場合、維持設定は失われます。
**コンソールを使用してロードバランサーの期間ベースのスティッキーセッションを有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[リスナー]** タブで、**[リスナーを追加]** を選択します。
1. **[リスナーを管理]** ページで、更新するリスナーを見つけて、**[Cookie の維持設定]** で **[編集]** を選択します。
1. [**Cookie の維持設定**]ポップアップで、**ロードバランサーによって生成**]を選択します。
1. (オプション) **[有効期間]** に Cookie の有効期間を秒単位で入力します。有効期限を指定しない場合、スティッキーセッションはブラウザセッションが終わるまで保持されます。
1. [**変更を保存**] をクリックして、ポップアップウィンドウを閉じます。
1. **変更を保存**を選択してロードバランサーの詳細ページに戻ります。
**を使用してロードバランサーの期間ベースのスティッキーセッションを有効にするには AWS CLI**
1. 次の [create-lb-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-lb-cookie-stickiness-policy.html) コマンドを使用し、Cookie の有効期間を 60 秒に設定して、ロードバランサーが生成する Cookie の維持ポリシーを作成します。
```
aws elb create-lb-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-duration-cookie-policy --cookie-expiration-period 60
```
1. 次の [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) コマンドを使用して、特定のロードバランサーのセッション維持を有効にします。
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-duration-cookie-policy
```
**注記**
`set-load-balancer-policies-of-listener` コマンドは、指定されたロードバランサーのポートに関連付けられた現在の一連のポリシーを置き換えます。このコマンドを使用するたびに、`--policy-names` を指定して有効にするすべてのポリシーを一覧表示します。
1. (オプション) 次の [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) コマンドを使用して、ポリシーが有効化されていることを確認します。
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
応答には、指定したポートのリスナーに対してポリシーが有効になっていることを示す次の情報が出力されます。
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-duration-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
],
...
"Policies": {
"LBCookieStickinessPolicies": [
{
"PolicyName": "my-duration-cookie-policy",
"CookieExpirationPeriod": 60
}
],
"AppCookieStickinessPolicies": [],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
## アプリケーション制御によるセッションの維持
ロードバランサーは、特殊な Cookie を使用して、最初のリクエストを処理したインスタンスにセッションを関連付けますが、ポリシー設定で指定されているアプリケーション Cookie の有効期間に従います。ロードバランサーは、アプリケーションの応答に新しいアプリケーション Cookie が含まれている場合のみ、新しい維持 Cookie を挿入します。ロードバランサー維持 Cookie はリクエストごとに更新されることはありません。アプリケーション Cookie が明示的に削除されるかまたは有効期限切れになると、新しいアプリケーション Cookie が発行されない限り、セッションは sticky ではなくなります。
バックエンドインスタンスによって設定された属性 (`path`、`port`、`domain`、`secure`、`httponly`、`discard`、`max-age`、`expires`、`version`、`comment`、`commenturl`、および `samesite`) が Cookie でクライアントに送信されます。
インスタンスでエラーや異常が発生した場合、ロードバランサーはそのインスタンスへのリクエストのルーティングを停止し、既存の負荷分散アルゴリズムに基いて新しい正常なインスタンスを選択します。ロードバランサーは、セッションが新しい正常なインスタンスで "維持" されていると見なし、エラーが発生したインスタンスが正常な状態に戻っても、継続して新しいインスタンスにリクエストをルーティングします。
**コンソールを使用してアプリケーション制御によるセッション維持を有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[リスナー]** タブで、**[リスナーを追加]** を選択します。
1. **[リスナーを管理]** ページで、更新するリスナーを見つけて、**[Cookie の維持設定]** で **[編集]** を選択します。
1. **[アプリケーションによって生成]** を選択します。
1. **[Cookie 名]** にアプリケーション Cookie の名前を入力します。
1. **[Save changes]** (変更の保存) をクリックします。
**を使用してアプリケーション制御セッションの維持を有効にするには AWS CLI**
1. 次の [create-app-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-app-cookie-stickiness-policy.html) コマンドを使用して、アプリケーションが生成する Cookie の維持ポリシーを作成します。
```
aws elb create-app-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-app-cookie-policy --cookie-name my-app-cookie
```
1. 次の [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) コマンドを使用して、ロードバランサーのセッション維持を有効にします。
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-app-cookie-policy
```
**注記**
`set-load-balancer-policies-of-listener` コマンドは、指定されたロードバランサーのポートに関連付けられた現在の一連のポリシーを置き換えます。このコマンドを使用するたびに、`--policy-names` を指定して有効にするすべてのポリシーを一覧表示します。
1. (省略可) 次の [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) コマンドを使用して、維持ポリシーが有効になっていることを確認します。
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
1. 応答には、指定したポートのリスナーに対してポリシーが有効になっていることを示す次の情報が出力されます。
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-app-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
{
"Listener": {
"InstancePort": 80,
"LoadBalancerPort": 80,
"Protocol": "TCP",
"InstanceProtocol": "TCP"
},
"PolicyNames": []
}
],
...
"Policies": {
"LBCookieStickinessPolicies": [],
"AppCookieStickinessPolicies": [
{
"PolicyName": "my-app-cookie-policy",
"CookieName": "my-app-cookie"
}
],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
# Classic Load Balancer の desync 軽減モードの設定
desync 軽減モードは、HTTP Desync に伴う問題からアプリケーションを保護します。ロードバランサーは、脅威レベルに基づいて各リクエストを分類します。安全なリクエストは許可し、指定した軽減モードで指定されたリスクに対しては軽減処理を行います。Desync 軽減モードの種類は、モニタリングモード、防御モード、厳密モードです。デフォルトは防御モードで、アプリケーションの可用性を維持しながら、HTTP Desync に対する永続的な軽減を提供します。厳密モードに切り替えると、アプリケーションで [RFC 7230](https://tools.ietf.org/html/rfc7230) に準拠するリクエストだけを受信できます。
http\$1desync\$1guardian ライブラリは、HTTP リクエストを分析して、HTTP Desync 攻撃を防ぎます。詳細については、github の [HTTP Desync Guardian](https://github.com/aws/http-desync-guardian) を参照してください。
**Topics**
+ [分類](#desync-mitigation-classification)
+ [モード](#desync-mitigation-modes)
+ [desync 軽減モードの変更](#update-desync-mitigation-mode)
**ヒント**
この設定は、Classic Load Balancers にのみ適用されます。Application Load Balancer に関する情報については、「[Application Load Balancers の Desync 軽減モード](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#desync-mitigation-mode)」を参照してください。
## 分類
分類は次のとおりです。
+ Compliant — リクエストは RFC 7230 に準拠しており、セキュリティ上の既知の脅威はありません。
+ Acceptable — リクエストは RFC 7230 に準拠していませんが、セキュリティ上の既知の脅威はありません。
+ Ambiguous — リクエストは RFC 7230 に準拠しておらず、ウェブサーバーやプロキシごとに処理方法が異なる場合、リスクが生じます。
+ Severe — リクエストは高いセキュリティリスクをもたらしています。ロードバランサーはリクエストをブロックし、クライアントに 400 レスポンスを提供し、クライアント接続を閉じます。
次のリストでは、分類別の問題について説明します。
**Acceptable**
+ ヘッダーに ASCII 以外の文字または制御文字が含まれています。
+ リクエストバージョンに不正な値が含まれています。
+ GET または HEAD リクエストの値を 0 とする Content-Length ヘッダーがあります。
+ リクエスト URI に URL エンコードされていないスペースが含まれています。
**Ambiguous**
+ リクエスト URI に制御文字が含まれています。
+ リクエストに Transfer-Encoding ヘッダーと Content-Length ヘッダーの両方が含まれています。
+ 同じ値を持つ複数の Content-Length ヘッダーがあります。
+ ヘッダーが空であるか、スペースのみを含む行があります。
+ 一般的なテキスト正規化技術を使用して、Transfer-Encoding または Content-Length に正規化できるヘッダーがあります。
+ GET または HEAD リクエストには Content-Length ヘッダーがあります。
+ GET または HEAD リクエストには、Transfer-Encoding ヘッダーがあります。
**Severe**
+ リクエスト URI に NULL 文字またはキャリッジリターンが含まれています。
+ Content-Length ヘッダーに解析できない値または無効な数値が含まれています。
+ ヘッダーに NULL 文字またはキャリッジリターンが含まれています。
+ Transfer-Encoding ヘッダーに不正な値が含まれています。
+ リクエストメソッドの形式が正しくありません。
+ リクエストバージョンの形式が正しくありません。
+ 異なる値を持つ複数の Content-Length ヘッダーがあります。
+ 複数の Transfer-Encoding: chunked ヘッダーがあります。
リクエストが RFC 7230 に準拠していない場合、ロードバランサーは `DesyncMitigationMode_NonCompliant_Request_Count` メトリクスを増分します。詳細については、「[Classic Load Balancer のメトリクス](elb-cloudwatch-metrics.md#loadbalancing-metrics-clb)」を参照してください。
## モード
次の表は、Classic Load Balancers で、リクエストがモードと分類に基づきどのように処理されるかを示しています。
| 分類 | モニタリングモード | 防御モード | 厳密モード |
| --- | --- | --- | --- |
| 準拠 | 許可 | 許可 | 許可 |
| Acceptable | 許可 | 許可 | ブロック |
| Ambiguous | 許可 | 許可¹ | ブロック |
| Severe | 許可 | ブロック | ブロック |
¹ リクエストはルーティングされますが、クライアントとターゲットの接続は閉じられます。
## desync 軽減モードの変更
**コンソールを使用して desync 軽減モードを更新するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[属性]** タブで、**[編集]** を選択します。
1. **[ロードバランサー属性の編集]** ページの **[トラフィックの設定]** で、**[防御的 - 推奨]**、**[最も厳格]**、または **[モニタリング]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
**を使用して非同期緩和モードを更新するには AWS CLI**
[modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) コマンドを、`elb.http.desyncmitigationmode` 属性に `monitor`、`defensive`、`strictest` のいずれかを設定しながら使用します。
```
aws elb modify-load-balancer-attributes --load-balancer-name my-load-balancer --load-balancer-attributes file://attribute.json
```
`attribute.json` の内容は次のとおりです。
```
{
"AdditionalAttributes": [
{
"Key": "elb.http.desyncmitigationmode",
"Value": "strictest"
}
]
}
```
# Classic Load Balancer のプロキシプロトコルを設定する
プロキシプロトコルは、接続をリクエストする送信元から接続がリクエストされる送信先に接続情報を伝達するために使用される、インターネットプロトコルです。Elastic Load Balancing のプロキシプロトコルでは、人間にとって可読性があるヘッダー形式を持つバージョン 1 を使用しています。
デフォルトでは、フロントエンド接続とバックエンド接続の両方で Transmission Control Protocol (TCP) を使用した場合に、Classic Load Balancer がインスタンスにリクエストを転送する際、そのリクエストヘッダーは変更されません。プロキシプロトコルを有効にすると、送信元 IP アドレス、送信先 IP アドレス、ポート番号などの接続情報を含むリクエストヘッダーに、人間が判読できるヘッダーが追加されます。これにより、ヘッダーがリクエストの一部としてインスタンスに送信されます。
**注記**
AWS マネジメントコンソール はプロキシプロトコルの有効化をサポートしていません。
**Topics**
+ [プロキシプロトコルヘッダー](#proxy-protocol)
+ [プロキシプロトコルを有効にするための前提条件](#proxy-protocol-prerequisites)
+ [を使用してプロキシプロトコルを有効にする AWS CLI](#enable-proxy-protocol-cli)
+ [を使用してプロキシプロトコルを無効にする AWS CLI](#proxy-protocol-disable-policy-cli)
## プロキシプロトコルヘッダー
プロキシプロトコルヘッダーは、ロードバランサーでバックエンド接続用に TCP を使用する場合に、クライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアントとインスタンスの間のトラフィックを傍受するため、インスタンス内のアクセスログには、発信元クライアントの IP アドレスでなく、ロードバランサーの IP アドレスが含まれています。リクエストの 1 行めを解析して、クライアントの IP アドレスとポート番号を取得することができます。
IPv6 のヘッダー内のプロキシのアドレスは、ロードバランサーのパブリック IPv6 アドレスです。この IPv6 アドレスは、`ipv6` または `dualstack` で始まるロードバランサーの DNS 名から解決される IP アドレスと一致します。クライアントが IPv4 に接続する場合、ヘッダー内のプロキシのアドレスはロードバランサーのプライベート IPv4 アドレスであるため、DNS ルックアップでは解決できません。
プロキシプロトコルの行は 1 行であり、キャリッジリターンとラインフィード (`"\r\n"`) で終わります。形式は次のとおりです。
```
PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"
```
**例: IPv4**
次に IPv4 のプロキシプロトコルの例を示します。
```
PROXY TCP4 198.51.100.22 203.0.113.7 35646 80\r\n
```
## プロキシプロトコルを有効にするための前提条件
開始する前に、以下を実行します:
+ ロードバランサーが、プロキシプロトコルが有効になっているプロキシサーバーの背後にないことを確認します。プロキシプロトコルがプロキシサーバーとロードバランサーの両方で有効になっていると、ロードバランサーは、プロキシサーバーからのヘッダーが既に追加されているリクエストに別のヘッダーを追加します。インスタンスの設定によっては、このような重複によってエラーが発生する可能性があります。
+ インスタンスでプロキシプロトコル情報を処理できることを確認します。
+ リスナー設定でプロキシプロトコルがサポートされることを確認します。詳細については、「[Classic Load Balancer のリスナー設定](using-elb-listenerconfig-quickref.md)」を参照してください。
## を使用してプロキシプロトコルを有効にする AWS CLI
プロキシプロトコルを有効にするには、タイプ `ProxyProtocolPolicyType` のポリシーを作成し、このポリシーをインスタンスのポートで有効にします。
次の手順を使用して、`ProxyProtocolPolicyType` タイプのロードバランサーの新しいポリシーを作成し、ポート `80` のインスタンスに設定して、そのポリシーが有効になっていることを確認します。
**ロードバランサーの Proxy Protocol を有効にするには**
1. (オプション) 次の [describe-load-balancer-policy-types](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-policy-types.html) コマンドを使用して、Elastic Load Balancing でサポートされているポリシーを一覧表示します。
```
aws elb describe-load-balancer-policy-types
```
応答には、サポートされるポリシータイプの名前と説明が出力されます。`ProxyProtocolPolicyType` タイプの出力は次のとおりです。
```
{
"PolicyTypeDescriptions": [
...
{
"PolicyAttributeTypeDescriptions": [
{
"Cardinality": "ONE",
"AttributeName": "ProxyProtocol",
"AttributeType": "Boolean"
}
],
"PolicyTypeName": "ProxyProtocolPolicyType",
"Description": "Policy that controls whether to include the IP address and port of the originating
request for TCP messages. This policy operates on TCP/SSL listeners only"
},
...
]
}
```
1. 次の [create-load-balancer-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-policy.html) コマンドを使用して、プロキシプロトコルを有効にするポリシーを作成します。
```
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer --policy-name my-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
```
1. 次の [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) コマンドを使用して、新しく作成したポリシーを特定のポートで有効にします。このコマンドは現在有効になっている一連のポリシーを置き換えることに注意してください。したがって、`--policy-names` オプションで、リストに追加するポリシー (`my-ProxyProtocol-policy` など) と現在有効になっているポリシー (`my-existing-policy` など) の両方を指定する必要があります。
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-ProxyProtocol-policy my-existing-policy
```
1. (オプション) 次の [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) コマンドを使用して、プロキシプロトコルが有効になっていることを確認します。
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
応答には、`my-ProxyProtocol-policy` ポリシーがポート `80` に関連付けられていることを示す次の情報が出力されます。
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [
{
"InstancePort": 80,
"PolicyNames": [
"my-ProxyProtocol-policy"
]
}
],
...
}
]
}
```
## を使用してプロキシプロトコルを無効にする AWS CLI
インスタンスに関連付けられているポリシーは無効にすることができ、また後で有効にすることができます。
**プロキシプロトコルをポリシーを無効にするには**
1. 次の [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) コマンドを使用して、`--policy-names` オプションからプロキシプロトコルポリシーを削除して、このポリシーを無効にします。(ただし、`my-existing-policy` など、有効なままにしておく必要のある他のポリシーは残します)。
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-existing-policy
```
有効にする他のポリシーがない場合は、次のとおり `--policy-names` で空の文字列を指定します。
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names "[]"
```
1. (省略可) 次の [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) コマンドを使用して、ポリシーが無効になっていることを確認します。
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
応答には、ポリシーに関連付けられているポートがないことを示す次の情報が出力されます。
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [],
...
}
]
}
```
# Classic Load Balancer へのタグ付け
タグを使用すると、ロードバランサーを目的、所有者、環境などさまざまな方法で分類することができます。
各 Classic Load Balancer に対して複数のタグを付けられます。タグキーは、各ロードバランサーで一意である必要があります。すでにロードバランサーに関連付けられているキーを持つタグを追加すると、そのキーの値が更新されます。
タグが不要になったら、ロードバランサーからタグを削除できます。
**Topics**
+ [タグの制限](#tag-restrictions)
+ [タグの追加](#add-tags)
+ [タグの削除](#remove-tags)
## タグの制限
タグには以下のような基本制限があります。
+ リソースあたりのタグの最大数 – 50
+ キーの最大長 – 127 文字 (Unicode)
+ 値の最大長 – 255 文字 (Unicode)
+ タグのキーと値は大文字と小文字が区別されます。使用できる文字は、UTF-8 で表現できる文字、スペース、および数字と、特殊文字 (\$1、-、=、.、\$1、:、/、@) です。ただし、先頭または末尾にはスペースを使用しないでください。
+ タグ名または値に `aws:` プレフィックスを使用しないでください。このプレフィックスは AWS 使用のために予約されています。このプレフィックスが含まれるタグの名前または値は編集または削除できません。このプレフィックスを持つタグは、リソースあたりのタグ数の制限時には計算されません。
## タグの追加
ロードバランサーにはいつでもタグを追加できます。
**コンソールを使用してタグを追加するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. [**Tags (タグ)**] タブで、[**Manage tags (タグ管理)**] を選択します。
1. **[タグの管理]** ページで、タグごとに **[新しいタグの追加]** をクリックし、各タグのキーと値を指定します。
1. タグの追加を完了したら、**[変更を保存]** を選択します。
**を使用してタグを追加するには AWS CLI**
指定されたタグを追加するには、次の [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/add-tags.html) コマンドを使用します。
```
aws elb add-tags --load-balancer-name my-loadbalancer --tag "Key=project,Value=lima"
```
## タグの削除
タグが不要になったときはいつでも、ロードバランサーからタグを削除できます。
**コンソールを使用してタグを削除するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. [**Tags (タグ)**] タブで、[**Manage tags (タグ管理)**] を選択します。
1. **[タグの管理]** ページで、削除する各タグの横にある **[削除]** を選択します。
1. タグの削除を終了したら、**[変更を保存]** を選択します。
**を使用してタグを削除するには AWS CLI**
指定されたキーを持つタグを削除するには、次の [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/remove-tags.html) コマンドを使用します。
```
aws elb remove-tags --load-balancer-name my-loadbalancer --tag project
```
# Classic Load Balancer のサブネットの設定
サブネットをロードバランサーに追加すると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。ロードバランサーノードは、クライアントからのトラフィックを受け入れ、リクエストを 1 つ以上のアベイラビリティーゾーンにある正常な登録済みのインスタンスに送信します。少なくとも 2 つのアベイラビリティーゾーンに、それぞれ 1 つのサブネットに追加することをお勧めします。これにより、ロードバランサーの可用性が向上します。ロードバランサーのサブネットは、いつでも変更できます。
インスタンスと同じアベイラビリティーゾーンからサブネットを選択します。ロードバランサーがインターネット向けロードバランサーである場合は、バックエンドインスタンス (これがプライベートサブネット内にある場合でも) がロードバランサーからトラフィックを受信できるように、パブリックサブネットを選択する必要があります。ロードバランサーが内部向けロードバランサーである場合、プライベートサブネットを選択することをお勧めします。ロードバランサーのサブネットの詳細については、「[VPC の推奨事項](elb-backend-instances.md#set-up-ec2)」を参照してください。
サブネットを追加するには、ロードバランサーでアベイラビリティゾーンにインスタンスを登録して、その後同じアベイラビリティーゾーンからロードバランサーにサブネットをアタッチします。詳細については、「[Classic Load Balancer に EC2 インスタンスを登録するには](elb-deregister-register-instances.md)」を参照してください。
サブネットを追加したら、ロードバランサーは対応するアベイラビリティーゾーン内の登録済みインスタンスにリクエストをルーティングするようになります。デフォルトでは、ロードバランサーはアベイラビリティーゾーン間でサブネットにリクエストを均等にルーティングします。アベイラビリティーゾーンのサブネットに登録済みのインスタンス間でリクエストを均等にルーティングするには、クロスゾーン負荷分散を有効にします。詳細については、「[Classic Load Balancer のクロスゾーン負荷分散の設定](enable-disable-crosszone-lb.md)」を参照してください。
アベイラビリティーゾーンに正常な登録済みインスタンスが存在しなくなった場合、または登録済みインスタンスのトラブルシューティングや更新を行う場合は、ロードバランサーからサブネットを一時的に削除することをお勧めします。サブネットを削除すると、ロードバランサーはこのアベイラビリティーゾーンの登録済みインスタンスにリクエストをルーティングしなくなります。アベイラビリティーゾーン内の残りのサブネットの登録済みインスタンスには、引き続きリクエストをルーティングします。サブネットを削除しても、そのサブネット内のインスタンスはロードバランサーに登録されたままであることに注意してください。ただし、登録を解除することも選択できます。詳細については、「[Classic Load Balancer に EC2 インスタンスを登録するには](elb-deregister-register-instances.md)」を参照してください。
**Topics**
+ [要件](#elb-subnet-requirements)
+ [コンソールを使用してサブネットを設定する](#add-remove-subnets-console)
+ [CLI を使用してサブネットを設定する](#add-remove-subnets-cli)
## 要件
ロードバランサーのサブネットを更新する場合、以下の要件を満たす必要があります。
+ ロードバランサーには、サブネットが常に少なくとも 1 つ必要です。
+ アベイラビリティーゾーンにつき、多くとも 1 つのサブネットしか追加できません。
+ ローカルゾーンサブネットを追加することはできません。
ロードバランサーからサブネットを追加および削除するための別個の API が存在するため、これらの要件を満たすために新しいサブネットの現在のサブネットを入れ替えるときはオペレーションの順序を慎重に検討する必要があります。さらに、ロードバランサーのすべてのサブネットを入れ替える必要がある場合、別のアベイラビリティーゾーンから一時的にサブネットを追加する必要があります。たとえば、ロードバランサーに単一のアベイラビリティーゾーンがあり、サブネットを別のサブネットに入れかれる必要がある場合、まず 2 番目のアベイラビリティーゾーンからサブネットを追加する必要があります。その後、元のアベイラビリティーゾーンからサブネットを削除し (追加されたサブネットが 1 つ未満にならないようにします)、元のアベイラビリティーゾーンから新しいサブネットを追加した後 (アベイラビリティーゾーンあたりサブネットが 1 つを超えないようにします)、2 番目のアベイラビリティーゾーンからサブネットを削除します (入れ替えの実行に必要な場合のみ)。
## コンソールを使用してサブネットを設定する
次の手順で、 コンソールを使用してサブネットを追加または削除します。
**コンソールを使用してサブネットを設定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[Network mapping]** (ネットワークマッピング) タブで、**[Edit subnets]** (サブネットの編集) を選択します。
1. [**サブネットの編集**] ページの [**ネットワークマッピング**] セクションで、必要に応じてサブネットを追加および削除します。
1. 完了したら、**[変更を保存]** を選択します。
## CLI を使用してサブネットを設定する
AWS CLIを使用してサブネットを追加または削除するには、次の例を使用します。
**CLI を使用してサブネットをロードバランサーに追加するには**
次の [attach-load-balancer-to-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/attach-load-balancer-to-subnets.html) コマンドを使用して、2 つのサブネットをロードバランサーに追加します。
```
aws elb attach-load-balancer-to-subnets --load-balancer-name my-load-balancer --subnets subnet-dea770a9 subnet-fb14f6a2
```
応答には、ロードバランサーのすべてのサブネットが一覧表示されます。例えば、次のようになります。
```
{
"Subnets": [
"subnet-5c11033e",
"subnet-dea770a9",
"subnet-fb14f6a2"
]
}
```
**を使用してサブネットを削除するには AWS CLI**
次の [detach-load-balancer-from-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/detach-load-balancer-from-subnets.html) コマンドを使用して、指定したサブネットを特定のロードバランサーから削除します。
```
aws elb detach-load-balancer-from-subnets --load-balancer-name my-loadbalancer --subnets subnet-450f5127
```
応答には、ロードバランサーの残りのサブネットが一覧表示されます。例えば、次のようになります。
```
{
"Subnets": [
"subnet-15aaab61"
]
}
```
# Classic Load Balancer のセキュリティグループの設定
を使用してロードバランサー AWS マネジメントコンソール を作成する場合は、既存のセキュリティグループを選択するか、新しいセキュリティグループを作成できます。既存のセキュリティグループを選択する場合、ロードバランサーのリスナーポートとヘルスチェックポートの両方で、双方向のトラフィックを許可する必要があります。セキュリティグループを作成する場合、これらのポートのすべてのトラフィックを許可するルールがコンソールによって自動的に追加されます。
[デフォルト以外の VPC] AWS CLI または API を使用してデフォルト以外の VPC にロードバランサーを作成するが、セキュリティグループを指定しない場合、ロードバランサーは VPC のデフォルトのセキュリティグループに自動的に関連付けられます。
[デフォルト VPC] AWS CLI または API を使用してデフォルト VPC にロードバランサーを作成する場合、ロードバランサーの既存のセキュリティグループを選択することはできません。代わりに、ロードバランサー用に指定したポートでのすべてのトラフィックを許可するルールが適用されたセキュリティグループが、Elastic Load Balancing により設定されます。Elastic Load Balancing は、default\$1elb\$1*id* という名前 (例: ) で、 AWS アカウントごとにそのようなセキュリティグループを 1 つだけ作成します`default_elb_fc5fbed3-0405-3b7d-a328-ea290EXAMPLE`。今後デフォルト VPC 内に作成するロードバランサーにも、このセキュリティグループが使用されます。新しいロードバランサーのリスナーポートおよびヘルスチェックポートのトラフィックが許可されるように、セキュリティグループルールを必ず確認してください。ロードバランサーを削除した場合でも、このセキュリティグループは自動的には削除されません。
既存のロードバランサーにリスナーを追加する場合、新しいリスナーポートが両方向で許可されるように、セキュリティグループを確認する必要があります。
**Topics**
+ [ロードバランサーのセキュリティグループの推奨ルール](#recommended-sg-rules)
+ [コンソールを使用したセキュリティグループの割り当て](#assign-sg-console)
+ [を使用してセキュリティグループを割り当てる AWS CLI](#assign-sg-cli)
## ロードバランサーのセキュリティグループの推奨ルール
ロードバランサーのセキュリティグループでは、インスタンスとの通信が許可される必要があります。推奨ルールは、ロードバランサーのタイプ (インターネット向けまたは内部向け) によって異なります。
**インターネット向けロードバランサー**
次の表に、インターネット向けロードバランサーの推奨インバウンドルールを示します。
| ソース | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *リスナー* | ロードバランサーのリスナーポートですべてのインバウンドトラフィックを許可する |
次の表に、インターネット向けロードバランサーの推奨アウトバウンドルールを示します。
| 目的地 | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *インスタンスセキュリティグループ* | TCP | *インスタンスリスナー* | インスタンスリスナーポートでインスタンスへのアウトバウンドトラフィックを許可する |
| *インスタンスセキュリティグループ* | TCP | *ヘルスチェック* | ヘルスチェックポートでインスタンスへのアウトバウンドトラフィックを許可する |
**内部ロードバランサー**
次の表に、内部ロードバランサーの推奨インバウンドルールを示します。
| ソース | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *リスナー* | ロードバランサーのリスナーポートで VPC CIDR からのインバウンドトラフィックを許可する |
次の表に、内部ロードバランサーの推奨アウトバウンドルールを示します。
| 目的地 | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *インスタンスセキュリティグループ* | TCP | *インスタンスリスナー* | インスタンスリスナーポートでインスタンスへのアウトバウンドトラフィックを許可する |
| *インスタンスセキュリティグループ* | TCP | *ヘルスチェック* | ヘルスチェックポートでインスタンスへのアウトバウンドトラフィックを許可する |
## コンソールを使用したセキュリティグループの割り当て
次の手順に従って、ロードバランサーに関連付けられたセキュリティグループの変更を行います。
**コンソールを使用してロードバランサーに割り当てられたセキュリティグループを更新するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ロードバランシング**] で [**ロードバランサー**] を選択します。
1. ロードバランサーの名前を選択して、その詳細ページを開きます。
1. **[セキュリティ]** タブで、**[編集]** を選択します。
1. **[セキュリティグループの編集]** ページの **[セキュリティグループ]** で、必要に応じてセキュリティグループを追加または削除します
最大 5 個のセキュリティグループを追加できます。
1. 完了したら、**[変更を保存]** を選択します。
## を使用してセキュリティグループを割り当てる AWS CLI
次の [apply-security-groups-to-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elb/apply-security-groups-to-load-balancer.html) コマンドを使用して、セキュリティグループをロードバランサーに関連付けます。指定されたセキュリティグループは、以前に関連付けられたセキュリティグループに上書きされます。
```
aws elb apply-security-groups-to-load-balancer --load-balancer-name my-loadbalancer --security-groups sg-53fae93f
```
以下に、応答の例を示します。
```
{
"SecurityGroups": [
"sg-53fae93f"
]
}
```
# Classic Load Balancer のネットワーク ACL の設定
VPC のデフォルトネットワークアクセスコントロールリスト (ACL) では、すべてのインバウンドトラフィックとアウトバウンドトラフィックが許可されます。カスタムネットワーク ACL を作成する場合、ロードバランサーとインスタンスの通信を許可するルールを追加します。
ロードバランサーのサブネットの推奨ルールは、ロードバランサーのタイプ (インターネット向けまたは内部向け) によって異なります。
**インターネット向けロードバランサー**
インターネット向けロードバランサーの推奨インバウンドルールを次に示します。
| ソース | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *リスナー* | ロードバランサーのリスナーポートですべてのインバウンドトラフィックを許可する |
| *VPC CIDR* | TCP | 1024-65535 | 一時ポートで VPC CIDR からのインバウンドトラフィックを許可する |
インターネット向けロードバランサーの推奨アウトバウンドルールを次に示します。
| 目的地 | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *インスタンスリスナー* | インスタンスのリスナーポートですべてのアウトバウンドトラフィックを許可する |
| *VPC CIDR* | TCP | *ヘルスチェック* | ヘルスチェックポートですべてのアウトバウンドトラフィックを許可する |
| 0.0.0.0/0 | TCP | 1024-65535 | 一時ポートですべてのアウトバウンドトラフィックを許可する |
**内部ロードバランサー**
内部ロードバランサーの推奨インバウンドルールを次に示します。
| ソース | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *リスナー* | ロードバランサーのリスナーポートで VPC CIDR からのインバウンドトラフィックを許可する |
| *VPC CIDR* | TCP | 1024-65535 | 一時ポートで VPC CIDR からのインバウンドトラフィックを許可する |
内部ロードバランサーの推奨アウトバウンドルールを次に示します。
| 目的地 | プロトコル | ポート範囲 | コメント |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *インスタンスリスナー* | インスタンスリスナーポートで VPC CIDR へのアウトバウンドトラフィックを許可する |
| *VPC CIDR* | TCP | *ヘルスチェック* | ヘルスチェックポートで VPC CIDR へのアウトバウンドトラフィックを許可する |
| *VPC CIDR* | TCP | 1024-65535 | 一時ポートで VPC CIDR へのアウトバウンドトラフィックを許可する |
# Classic Load Balancer のカスタムドメイン名の設定
各 Classic Load Balancer は、デフォルトのドメインネームシステム (DNS) 名を受け取ります。この DNS 名には、ロードバランサーが作成される AWS リージョンの名前が含まれます。例えば、米国西部 (オレゴン) リージョンで `my-loadbalancer` という名前のロードバランサーを作成した場合、そのロードバランサーは `my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com` などの DNS 名を受け取ります。インスタンスでウェブサイトにアクセスするには、ウェブブラウザーのアドレスフィールドにこの DNS 名を貼り付けます。ただし、この DNS 名は顧客が簡単に記憶して使用できる名前ではありません。
ロードバランサーのデフォルトの DNS 名を `www.example.com` などの覚えやすい DNS 名にするには、カスタムドメイン名を作成し、ロードバランサーの DNS 名に関連付けます。このカスタムドメイン名を使用してクライアントがリクエストを生成すると、DNS サーバーがロードバランサーの DNS 名に解決します。
**Topics**
+ [カスタムドメイン名とロードバランサー名の関連付け](#dns-associate-custom-elb)
+ [ロードバランサーの Route 53 DNS フェイルオーバーを使用する](#configure-dns-failover)
+ [ドメイン名とロードバランサーの関連付けの解除](#dns-disassociate-custom-elb)
## カスタムドメイン名とロードバランサー名の関連付け
まず、まだドメイン名を登録していない場合は、ドメイン名を登録します。インターネットのドメイン名は、Internet Corporation for Assigned Names and Numbers (ICANN) によって管理されています。ドメイン名は、ドメイン名のレジストリを管理する ICANN 認定機関である*ドメイン名レジストラ*を使用して登録します。レジストラのウェブサイトで、ドメイン名の登録に関する詳細な手順と料金情報を確認します。詳細については、以下のリソースを参照してください。
+ Amazon Route 53 を使用してドメイン名を登録するには、*Amazon Route 53 開発者ガイド*の「[Route 53 を使用したドメイン名の登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)」を参照してください。
+ 認定されているレジストラのリストについては、「[List of Accredited Registrars](https://www.icann.org/en/accredited-registrars)」を参照してください。
次に、ドメインレジストラなどの DNS サービスを使用して、ロードバランサーにクエリをルーティングするために CNAME レコードを作成します。詳細については、DNS サービスのドキュメントを参照してください。
前出と別に、DNS サービスとして Route 53 を使用する方法もあります。インターネット上のトラフィックを (ドメイン内で) ルーティングする方法に関する情報を含む*ホストゾーン*と、ドメイン名へのクエリをロードバランサーにルーティングする*エイリアスリソースレコードセット*を作成します。Route 53 では、エイリアスレコードセットの DNS クエリには課金されません。エイリアスレコードセットは、ドメインの Zone Apex (例: `example.com`) のロードバランサーに DNS クエリをルーティングするために使用できます。既存のドメインの DNS サービスを Route 53 に転送する方法については、*Amazon Route 53 開発者ガイド*の「[DNS サービスとして Amazon Route 53 を設定する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html)」を参照してください。
最後に、Route 53 を使用してドメインのホストゾーンとエイリアスレコードセットを作成します。詳細については、*Amazon Route 53 開発者ガイド*の「[ロードバランサーへのトラフィックのルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)」を参照してください。
## ロードバランサーの Route 53 DNS フェイルオーバーを使用する
Route 53 を使用して DNS クエリをロードバランサーにルーティングする場合は、同時に Route 53 によりロードバランサーの DNS フェイルオーバーを設定することもできます。フェイルオーバー設定では、ロードバランサーに登録された EC2 インスタンスのヘルスチェックが Route 53 によって行われ、利用可能かどうかが判断されます。ロードバランサーに正常な EC2 インスタンスが登録されていない場合、またはロードバランサー自体で不具合が発生した場合、Route 53 はそのトラフィックを、別の利用可能なリソース (正常なロードバランサーや、Amazon S3 にある静的ウェブサイトなど) にルーティングします。
例えば、`www.example.com` 用のウェブアプリケーションがあり、異なるリージョンにある 2 つのロードバランサーの背後で冗長なインスタンスを実行するとします。1 つのリージョンのロードバランサーは、主にトラフィックのルーティング先として使用し、もう 1 つのリージョンのロードバランサーは、エラー発生時のバックアップとして使用します DNS フェイルオーバーを設定する場合は、プライマリおよびセカンダリ (バックアップ) ロードバランサーを指定できます。Route 53 は、プライマリロードバランサーが利用可能な場合はプライマリロードバランサーにトラフィックをルーティングし、利用できない場合はセカンダリロードバランサーにルーティングします。
**ターゲットの正常性の評価を使用する**
+ Classic Load Balancer のエイリアスレコードでターゲットの正常性の評価が `Yes` に設定されている場合、Route 53 は `alias target` 値で指定されたリソースの正常性を評価します。Classic Load Balancer の場合、Route 53 はロードバランサーに関連付けられたインスタンスのヘルスチェックを使用します。
+ Classic Load Balancer に登録されているインスタンスの少なくとも 1 つが正常である場合、Route 53 はエイリアスレコードを正常としてマークします。 その後、Route 53 はルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーを使用すると、Route 53 はプライマリレコードを返します。
+ Classic Load Balancer に登録されているすべてのインスタンスに異常がある場合、Route 53 はエイリアスレコードを異常とマークします。その後、Route 53 はルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーが使用されている場合、Route 53 はセカンダリレコードを返します。
詳細については、*Amazon Route 53 開発者ガイド*の「[DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)」を参照してください。
## ドメイン名とロードバランサーの関連付けの解除
ロードバランサーインスタンスからドメイン名の関連付けを解除するには、まずホストゾーンのリソースレコードセットを削除してから、ホストゾーンを削除します。詳細については、*Amazon Route 53 開発者*ガイドの「[レコードの編集](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html)」および「[パブリックホストゾーンの削除](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DeleteHostedZone.html)」を参照してください。