Elastic Load Balancing éçºèã¬ã¤ã

Transcription

Elastic Load Balancing
開発者ガイド
API Version 2012-06-01
Elastic Load Balancing 開発者ガイド
Elastic Load Balancing: 開発者ガイド
Copyright © 2015 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Abstract
Elastic Load Balancing を使用して、複数の EC2 インスタンス間で、アプリケーショントラフィックの負
荷を自動的に分散します。
The following are trademarks of Amazon Web Services, Inc.: Amazon, Amazon Web Services Design, AWS, Amazon CloudFront,
AWS CloudTrail, AWS CodeDeploy, Amazon Cognito, Amazon DevPay, DynamoDB, ElastiCache, Amazon EC2, Amazon Elastic
Compute Cloud, Amazon Glacier, Amazon Kinesis, Kindle, Kindle Fire, AWS Marketplace Design, Mechanical Turk, Amazon Redshift,
Amazon Route 53, Amazon S3, Amazon VPC, and Amazon WorkDocs. In addition, Amazon.com graphics, logos, page headers, button
icons, scripts, and service names are trademarks, or trade dress of Amazon in the U.S. and/or other countries. Amazon's trademarks
and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause
confusion among customers, or in any manner that disparages or discredits Amazon.
All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected
to, or sponsored by Amazon.
Table of Contents
Elastic Load Balancing とは ........................................................................................................... 1
Elastic Load Balancing のメリット ........................................................................................... 1
Elastic Load Balancing の使用を開始する方法 ............................................................................ 2
関連サービス ........................................................................................................................ 2
Elastic Load Balancing へのアクセス ........................................................................................ 2
料金表 ................................................................................................................................. 3
Elastic Load Balancing の仕組み .............................................................................................. 3
Elastic Load Balancing のアーキテクチャーの概要 ............................................................. 4
概念 .................................................................................................................................... 5
個のロードバランサー ................................................................................................... 6
アベイラビリティーゾーンとリージョン ........................................................................... 6
リクエストルーティング ................................................................................................ 7
EC2 インスタンスの負荷分散の設定 ................................................................................ 8
ヘルスチェック ............................................................................................................. 9
Connection Draining ..................................................................................................... 11
アイドル接続のタイムアウト ......................................................................................... 11
スティッキーセッション ............................................................................................... 12
HTTP メソッド ........................................................................................................... 12
HTTPS Support ........................................................................................................... 13
Proxy Protocol ............................................................................................................ 13
X-Forwarded ヘッダー .................................................................................................. 14
セットアップ .............................................................................................................................. 16
サインアップ ...................................................................................................................... 16
Amazon EC2 を使用する準備を整える .................................................................................... 17
AWS マネジメントコンソールを使用した Elastic Load Balancing へのアクセス ............................ 17
AWS CLI を使用した Elastic Load Balancing へのアクセス ......................................................... 18
はじめに .................................................................................................................................... 19
開始する前に ...................................................................................................................... 19
ロードバランサーのリスナーの設定 ....................................................................................... 20
EC2 インスタンスのヘルスチェックの設定 ............................................................................. 20
VPC でのロードバランサー用のサブネットの選択 .................................................................... 21
VPC でのロードバランサーへのセキュリティグループの割り当て .............................................. 21
ロードバランサーへの EC2 インスタンスの登録 ...................................................................... 22
ロードバランサーの作成と検証 ............................................................................................. 23
（オプション）ロードバランサーを削除する ........................................................................... 23
リスナーの設定 ........................................................................................................................... 24
リスナー ............................................................................................................................ 25
Elastic Load Balancing での TCP/SSL プロトコルの使用 ........................................................... 25
Elastic Load Balancing での HTTP/HTTPS プロトコルの使用 ..................................................... 25
SSL サーバー証明書 ............................................................................................................ 26
SSL ネゴシエーション ........................................................................................................ 26
Elastic Load Balancing でのバックエンドサーバー認証の使用 .................................................... 27
リスナー設定クイックリファレンス ....................................................................................... 27
SSL ネゴシエーション設定 ........................................................................................................... 30
SSL のセキュリティポリシー ................................................................................................ 31
事前定義された SSL セキュリティポリシー ............................................................................. 32
SSL 証明書 ................................................................................................................................. 36
前提条件: 証明書ツールをインストールする ............................................................................ 37
サーバー証明書の作成 .......................................................................................................... 37
署名証明書をアップロードする ............................................................................................. 38
サーバー証明書の確認 .......................................................................................................... 41
ロードバランサーへの SSL 証明書のインストール .................................................................... 41
SSL 証明書の更新 ............................................................................................................... 41
コンソールを使用した SSL 証明書の更新 ........................................................................ 42
AWS CLI を使用した SSL 証明書の更新 .......................................................................... 43
iii
EC2-Classic のロードバランサー ................................................................................................... 44
HTTPS/SSL ロードバランサーの作成 ..................................................................................... 46
前提条件 .................................................................................................................... 46
コンソールを使用した HTTPS/SSL ロードバランサーの作成 .............................................. 46
AWS CLI を使用した HTTPS/SSL ロードバランサーの作成 ................................................ 53
アベイラビリティーゾーンの追加または削除 ........................................................................... 65
AWS マネジメントコンソールを使用したアベイラビリティーゾーンの追加と削除 ............... 65
AWS CLI を使用したアベイラビリティーゾーンの追加と削除 ............................................ 66
EC2-Classic 用セキュリティグループ ..................................................................................... 68
Elastic Load Balancing とバックエンド Amazon EC2 インスタンス間でトラフィックをロッ
クする ....................................................................................................................... 68
インターネットプロトコルバージョン 6（IPv6） ..................................................................... 74
Elastic Load Balancing の IPv6 および CNAME レコード ................................................... 74
Elastic Load Balancing の IPv6 およびホストゾーン .......................................................... 75
VPC のロードバランサー .............................................................................................................. 76
Elastic Load Balancing での VPC の設定 ................................................................................. 76
EC2-VPC 用セキュリティグループ ......................................................................................... 78
コンソールを使用したセキュリティグループの管理 .......................................................... 79
AWS CLI を使用したセキュリティグループの管理 ............................................................ 79
インターネット向けロードバランサーと内部向けロードバランサー ............................................ 80
内部向けロードバランサーの作成 .......................................................................................... 82
前提条件 .................................................................................................................... 82
コンソールを使用した内部向けロードバランサーの作成 .................................................... 82
AWS CLI を使用した内部向けロードバランサーの作成 ...................................................... 84
サブネットの管理 ................................................................................................................ 86
コンソールを使用したサブネットのアタッチとデタッチ .................................................... 86
AWS CLI を使用したサブネットのアタッチとデタッチ ...................................................... 87
ロードバランサーの管理 ............................................................................................................... 89
リスナーの追加と削除 .......................................................................................................... 89
前提条件 .................................................................................................................... 90
コンソールを使用したリスナーの追加と削除 ................................................................... 90
AWS CLI を使用したリスナーの追加と削除 ..................................................................... 92
インスタンスの登録解除と登録 ............................................................................................. 95
コンソールを使用したインスタンスの登録解除と登録 ....................................................... 95
AWS CLI を使用したインスタンスの登録解除と登録 ......................................................... 96
SSL ネゴシエーション設定の更新 .......................................................................................... 98
コンソールを使用した SSL ネゴシエーション設定の更新 .................................................. 98
AWS CLI を使用した SSL ネゴシエーション設定の更新 .................................................... 99
ドメイン名の設定 .............................................................................................................. 103
カスタムドメイン名とロードバランサー名の関連付け ..................................................... 103
ドメイン名とロードバランサーの関連付けの解除 ........................................................... 106
クロスゾーン負荷分散の有効化と無効化 ............................................................................... 106
クロスゾーン負荷分散の有効化 .................................................................................... 107
クロスゾーン負荷分散の無効化 .................................................................................... 108
Connection Draining の有効化と無効化 .................................................................................. 110
コンソールを使用した Connection Draining の有効化と無効化 .......................................... 110
AWS CLI を使用した Connection Draining の有効化と無効化 ............................................ 111
アイドルタイムアウトの設定 ............................................................................................... 113
コンソールを使用したアイドルタイムアウトの設定 ........................................................ 113
AWS CLI を使用したアイドルタイムアウトの設定 .......................................................... 113
Proxy Protocol の設定 ......................................................................................................... 115
AWS CLI を使用した Proxy Protocol の有効化 ................................................................ 116
DNS フェイルオーバーの設定 .............................................................................................. 123
前提条件 .................................................................................................................. 123
コンソールを使用した DNS フェイルオーバーの設定 ...................................................... 124
スティッキーセッションの有効化と無効化 ............................................................................ 127
期間ベースのセッション維持 ....................................................................................... 127
アプリケーション制御によるセッション維持 ................................................................. 131
iv
タグの追加または削除 ........................................................................................................
タグの制限 ...............................................................................................................
コンソールを使用したタグの追加と削除 .......................................................................
AWS CLI を使用したタグの追加と削除 .........................................................................
モニタリングとロギング .............................................................................................................
ロードバランサーの監視 .....................................................................................................
使用可能なメトリックス .............................................................................................
メトリックスの表示 ..................................................................................................
アラームの作成 ........................................................................................................
アクセスログの管理 ...........................................................................................................
ログファイルへのアクセス ..........................................................................................
ログエントリへのアクセス ..........................................................................................
ログ処理 ..................................................................................................................
アクセスログの有効化 ................................................................................................
アクセスログの無効化 ...............................................................................................
アクセスログを保管する Amazon S3 バケットの設定 ......................................................
Elastic Load Balancing API 呼び出しログ ...............................................................................
CloudTrail のイベントログ作成機能の設定 .....................................................................
CloudTrail ログファイルの Elastic Load Balancing イベントエントリ .................................
ロードバランサーへのアクセスの制御 ...........................................................................................
IAM ポリシーを使用したアクセス権限の付与 .........................................................................
IAM ポリシーでのアクションの指定 .............................................................................
IAM ポリシーでのリソースの指定 ................................................................................
IAM ポリシーでの条件キーの指定 .................................................................................
Elastic Load Balancing の IAM ポリシー例 .............................................................................
トラブルシューティング .............................................................................................................
API エラー ........................................................................................................................
CertificateNotFound: 未定義 .........................................................................................
OutofService: 一時的なエラー発生 ................................................................................
HTTP エラー .....................................................................................................................
HTTP 400: BAD_REQUEST ........................................................................................
HTTP 405: METHOD_NOT_ALLOWED .........................................................................
HTTP 408: Request Timeout ........................................................................................
HTTP 502: Bad Gateway .............................................................................................
HTTP 503: Service Unavailable または HTTP 504: Gateway Timeout .................................
レスポンスコードのメトリックス .........................................................................................
HTTPCode_ELB_4XX .................................................................................................
HTTPCode_ELB_5XX .................................................................................................
HTTPCode_Backend_2XX ...........................................................................................
ヘルスチェック .................................................................................................................
インスタンスへの接続がタイムアウトした ....................................................................
Amazon Virtual Private Cloud (Amazon VPC) で起動したインターネット向けロードバラン
サーへの接続がタイムアウトしました ...........................................................................
ヘルスチェックのターゲットページのエラー .................................................................
パブリックキー認証が失敗する ....................................................................................
停止して起動したインスタンスがロードバランサーのヘルスチェックに失敗する ................
インスタンスがロードバランサーからのトラフィックを受信しない ...................................
インスタンスのポートが開いていない ...........................................................................
Auto Scaling グループのインスタンスがロードバランサーのヘルスチェックに失敗する .......
インスタンスの登録 ...........................................................................................................
バックエンドインスタンスの登録に時間がかかりすぎる。 ...............................................
AMI から起動したインスタンスを登録できません。 ........................................................
制限 .........................................................................................................................................
コマンドラインインターフェイス .................................................................................................
タスク 1: コマンドラインインターフェイスをダウンロードする ................................................
v
135
135
135
136
138
139
139
147
148
150
150
151
153
154
158
159
164
164
164
167
168
168
169
170
170
173
174
175
175
175
175
175
176
176
176
177
177
177
177
178
178
178
178
179
179
180
180
180
181
181
181
182
182
182
184
185
185
タスク 2: JAVA_HOME 環境変数を設定する ..........................................................................
タスク 3: AWS_ELB_HOME 環境変数を設定する ....................................................................
タスク 4: AWS_CREDENTIAL_FILE 環境変数を設定する .........................................................
タスク 5: リージョンを設定する ...........................................................................................
タスク 6: インストールを検証する .......................................................................................
ドキュメント履歴 ......................................................................................................................
AWS の用語集 ...........................................................................................................................
vi
186
187
188
189
189
192
199
Elastic Load Balancing のメリット
Elastic Load Balancing とは
Abstract
Elastic Load Balancing を使用して、着信したウェブトラフィックを複数の EC2 インスタンスに自動的に分散させ
ます。
Elastic Load Balancing は受信ウェブトラフィックを自動的に複数の EC2 インスタンスに分散します。
Elastic Load Balancing を使用すると、情報全体の流れを中断することなく、ニーズの変化に応じて EC2
インスタンスを追加および削除することができます。EC2 インスタンスが失敗した場合、Elastic Load
Balancing は自動的に残りの実行中の EC2 インスタンスにトラフィックを再ルーティングします。失
敗した EC2 インスタンスが回復すると、Elastic Load Balancingはそのインスタンスへのトラフィック
も復元します。Elastic Load Balancing はクライアントにとって単一の通信先となるだけでなく、ネッ
トワークへの攻撃に対する最前線の防御機能も持ちます。サーバーがメインワークに集中できるよう
に、暗号化および復号化の作業を Elastic Load Balancing に任せることができます。
詳細については、Elastic Load Balancing を参照してください。
Elastic Load Balancing のメリット
Elastic Load Balancing を使用してアプリケーションへのトラフィックを管理することには、以下のメ
リットがあります。
• 複数のアベイラビリティーゾーンにある EC2 インスタンスにリクエストを分散させて、1 つのイン
スタンスのみが過負荷になるリスクを最小限に抑えます。あるアベイラビリティゾーン全体がオフラ
インになった場合、ロードバランサーは他のアベイラビリティゾーン内のインスタンスにトラフィッ
クをルーティングします。
• 正常なインスタンスにのみリクエストが送信されるように、EC2 インスタンスの状態をロードバラ
ンサーに登録します。インスタンスに不具合が生じた場合、Elastic Load Balancing はそのインスタ
ンスへのトラフィックの送信を停止し、残りの正常なインスタンス全体に負荷を分散します。
• 安全な（HTTPS/SSL）接続を使用しているネットワークで、エンドツーエンドのトラフィック暗号
化をサポートします。
• EC2 インスタンスから暗号化および復号化の作業を引き継いで、ロードバランサーで集中管理しま
す。
• 特定の EC2 インスタンスでユーザーセッションを維持するスティッキーセッションをサポートしま
す。
1
Elastic Load Balancing の使用を開始する方法
• ロードバランサーをドメイン名に関連付けます。インターネットに公開されるコンピュータはロード
バランサーだけなので、ロードバランサーが管理するインスタンスについてパブリックドメイン名を
作成および管理する必要がありません。代わりにロードバランサーのインスタンスのドメインレコー
ドを参照し、必要に応じて規模を拡張または縮小（処理能力を追加または削除）することができま
す。処理能力の拡大または縮小を行うたびにレコードを更新する必要はありません。
• 追加のネットワークおよびセキュリティオプションを提供するように、ロードバランサーに関連付け
られたセキュリティグループをサポートします。
Elastic Load Balancing の使用を開始する方法
• Elastic Load Balancing を検討する前に、AWS にサインアップし、ロードバランサーを作成する準備
をする必要があります。詳細については、「Elastic Load Balancing のセットアップ (p. 16)」を参照
してください。
• 基本的なロードバランサーを作成し、ロードバランサーに EC2 インスタンスを登録する方法を確認
するには、Elastic Load Balancing の使用開始 (p. 19) を参照してください。
• Elastic Load Balancing でサポートされているさまざまな機能の使用方法について理解するには、ロー
ドバランサーの管理 (p. 89) を参照してください。
関連サービス
Elastic Load Balancing は、アプリケーションの可用性とスケーラビリティを高める以下のサービスを
使用します。
• Amazon EC2 — クラウドでアプリケーションを実行する仮想サーバーです。詳細については、Linux
インスタンス用 Amazon EC2 ユーザーガイドまたは Microsoft Windows インスタンスの Amazon
EC2 ユーザーガイドを参照してください。
• Auto Scaling — インスタンスに障害が発生した場合でも必要なインスタンスの実行数を保証し、需
要の変化に応じて自動的にインスタンス数を増減できるようにします。詳細については、Auto Scaling
開発者ガイドを参照してください。
• Amazon CloudWatch — インスタンスの状態を監視し、必要に応じてアクションを取ることができる
ようにします。詳細については、「Amazon CloudWatch 開発者ガイド」を参照してください。.
• Amazon Route 53 — ドメイン名（www.example.com など）を、コンピュータが相互の接続に使用
する数字の IP アドレス（192.0.2.1 など）に変換することで、閲覧者をウェブサイトにルーティン
グするための信頼性が高く、コスト効率のよい方法を提供します。ロードバランサーなどの AWS リ
ソースには、AWS により URL が割り当てられます。ただし、ユーザーが覚えやすい URL を使用す
ることもできます。たとえば、ドメイン名をお客様のロードバランサーにマッピングすることができ
ます。ドメイン名がない場合、利用できるドメインを検索し、Amazon Route 53 を使用してそれを
登録できます。既存のドメイン名がある場合、それを Amazon Route 53 に転送できます。詳細につ
いては、「Amazon Route 53 開発者ガイド」を参照してください。
Elastic Load Balancing へのアクセス
次のインターフェイスのいずれかを使用して、ロードバランサーの作成、アクセス、管理を行うことが
できます。
• AWS マネジメントコンソール — Elastic Load Balancing へのアクセスに使用するウェブインターフェ
イスを提供します。
• AWS コマンドラインインターフェイス（CLI） — Elastic Load Balancing を含むさまざまな AWS 製
品用のコマンドが用意されており、Windows、Mac、および Linux でサポートされています。詳細に
ついては、「AWS コマンドラインインターフェイス」を参照してください。
2
料金表
• AWS SDK — 言語固有の API を提供し、署名の計算、リクエストの再試行処理、エラー処理など、
接続のさまざまな詳細を処理します。詳細については、AWS SDK を参照してください。
• クエリ API — HTTPS リクエストを使用して使用する低レベル API を提供します。クエリ API の使
用は、Elastic Load Balancing の最も直接的なアクセス方法ですが、リクエストに署名するハッシュ
の生成やエラー処理など、低レベルの詳細な作業をアプリケーションで処理する必要があります。詳
細については、「Elastic Load Balancing API Reference」を参照してください。
• Elastic Load Balancing コマンドラインインターフェイス（CLI） — Elastic Load Balancingにアクセ
スするコマンドを提供します。ただし、現在 ELB CLI に新機能は追加されていません。代わりに
AWS CLI を使用することをお勧めします。
• SOAP API — SOAP ウェブサービスメッセージングプロトコルを使用して、Elastic Load Balancing
ウェブサービスへのアクセスを提供します。このインターフェイスは、オペレーションとセキュリ
ティモデルを定義するウェブサービス記述言語（WSDL）ドキュメントによって記述されます。WSDL
で参照する XML スキーマドキュメントでは、SOAP リクエストおよびレスポンス内のデータ型を厳
密に定義しています。詳細については、「Elastic Load Balancing API Reference」を参照してくださ
い。
料金表
Amazon Web Services と併せて、使用した分に応じてお支払いください。Elastic Load Balancing で
は、サービスが稼動する時間に対して 1 時間単位で、またお客様のロードバランサーを経由して転送さ
れるデータ量に応じて GB 単位で課金されます。現在の料金の詳細については、「Elastic Load Balancing
料金表」を参照してください。
AWS アカウントを作成してから 12 か月未満の場合、無料利用枠を使用できます。無料利用枠には、
Amazon EC2 1 か月あたり 750 時間、Elastic Load Balancing 1 か月あたり 750 時間、データ処理 15
GB が含まれます。詳細については、「AWS Free Tier」を参照してください。
Elastic Load Balancing の仕組み
Abstract
Elastic Load Balancing の仕組みの詳細
Elastic Load Balancing（ELB）はロードバランサーとコントローラーサービスの 2 つのコンポーネント
から構成されます。ロードバランサーはトラフィックを監視し、インターネット経由で送信されたリク
エストを処理します。コントローラサービスは、ロードバランサーを監視して、必要に応じてロードバ
ランサーを追加および削除し、またロードバランサーが正常に機能していることを確認します。
ロードバランサーの使用を開始するには、まずロードバランサーを作成する必要があります。Elastic
Load Balancing は、作成する各ロードバランサーの各インスタンスに対して、固有のドメインネーム
システム（DNS）名を自動的に生成します。たとえば、us-east-1aで myLB という名前のロードバラン
サーを作成した場合、そのロードバランサーの DNS 名は
myLB-1234567890.us-east-1.elb.amazonaws.com のようになります。クライアントは、ELB に
よって生成された DNS 名を使用して、ロードバランサーへのアクセスをリクエストできます。
ロードバランサーの DNS 名ではなく www.example.com のようなユーザーが分かりやすいドメイン名
を使用する場合は、カスタムドメイン名を作成して、カスタムドメイン名とロードバランサーの DNS
名を関連付けます。作成したカスタムドメイン名を使用してロードバランサーにリクエストを送ると、
ロードバランサーの DNS 名に解決されます。
クライアントがロードバランサーの DNS 名またはカスタムドメイン名を使用してアプリケーションに
リクエストを送ると、DNS サーバーは 1 つ以上の IP アドレスを返します。クライアントは、提供され
た IP アドレスを使用して、ロードバランサーへの接続を確立します。Elastic Load Balancing の規模が
変更された場合、ロードバランサーの DNS レコードが更新されます。ロードバランサーの DNS レコー
3
Elastic Load Balancing のアーキテクチャーの概要
ドには、60 秒に設定された有効期限（TTL）があります。この設定により、Elastic Load Balancing の
拡張または縮小を伴うイベントに対応して、IP アドレスが迅速に再マッピングされます。
ロードバランサーを作成する際には、着信トラフィックを受け入れ、EC2 インスタンスにリクエスト
をルーティングするよう設定する必要があります。コントローラーはロードバランサーが正しい設定で
動作していることを確認します。
ロードバランサーを作成した後、ロードバランサーに、負荷分散を行う EC2 インスタンスを登録する
必要があります。ロードバランサーは、登録されているインスタンスへの着信トラフィックを監視し、
ルーティングします。インスタンスは、インスタンスに関連付けられた IP アドレスを使用してロード
バランサーに登録されます。
また、ロードバランサーは登録されているインスタンスの状態を監視して、トラフィックが正常なイン
スタンスにルーティングされるよう保証します。ロードバランサーは、不具合のあるインスタンスを検
出すると、そのインスタンスへのトラフィックのルーティングを停止し、インスタンスが正常な状態に
戻るとルーティングを再開します。Elastic Load Balancing は、インスタンスが正常か不具合があるか
に関係なく、指定した設定を使用して、登録されているすべてのインスタンスのヘルスチェックを行い
ます。
Amazon Elastic Compute Cloud（Amazon EC2）では複数のアベイラビリティーゾーンでインスタンス
を起動できます。着信アプリケーショントラフィックは、1 つのアベイラビリティーゾーンの複数のイ
ンスタンスで負荷分散するよう設定することも、同じリージョン内の複数のアベイラビリティーゾーン
の複数のインスタンスで負荷分散するよう設定することも可能です。たとえば、2 つのアベイラビリ
ティーゾーンの複数のインスタンスで負荷分散を行うよう選択した場合、一方のアベイラビリティー
ゾーンのすべてのインスタンスに不具合が生じると、ロードバランサーはもう一方の利用可能ゾーンの
正常なインスタンスにトラフィックをルーティングします。複数のアベイラビリティーゾーンを使用す
る場合は、ロードバランサーに登録されている各アベイラビリティーゾーンで処理能力をほぼ同等に保
つことが重要です。
Elastic Load Balancing で Auto Scaling を使用すると、さまざまなトラフィックレベルに合わせてバッ
クエンドの処理能力を簡単に増減できます。たとえば、ロードバランサーの背後の正常なインスタンス
の数が2つに減った場合に、2つもしくはそれ以上のインスタンスを起動するように宣言する条件を設定
することができます。あるいは、ロードバランサーの待ち時間を監視し、待ち時間が一定期間（3秒な
ど）を超えると処理能力を拡大するように条件を設定することができます。また、時とともに変化する
アプリケーションの処理能力の要件に応じて、AWS Management Console を使用して、ロードバラン
サーが使用するインスタンスの登録または登録解除を行うこともできます。
Amazon Route 53 は、可用性および費用対効果の高い AWS の DNS サービスです。Amazon Route 53
を使用すると、ロードバランサーのカスタムドメイン名をロードバランサーの DNS 名に関連付けるこ
とができます。Amazon Route 53 のエイリアスレコードを使用すると、クライアントが 1 回のリクエ
ストだけでドメイン名を解決できるので、パフォーマンスが向上します。また、エイリアスレコードへ
のクエリは課金されません。
Elastic Load Balancing のアーキテクチャーの概要
Abstract
Elastic Load Balancing のさまざまなコンポーネントが連携して動作するアーキテクチャーを表す図。
以下の図は、Elastic Load Balancing のさまざまなコンポーネントがどのように連携するかを示してい
ます。このセクションの残りでは、アプリケーションで提供される URL をクライアントがリクエスト
したときに発生するイベントの流れを順を追って示します。
4
概念
この例は、ロードバランサーを作成し、カスタムドメイン名を作成し、DNS の CNAME エントリを使
用してロードバランサーをドメイン名に関連付け、ロードバランサーにインスタンスを登録してあるこ
とを前提としています。
1.
クライアントがアプリケーションにアクセスするために DNS に URL リクエストを送信します。
DNS サーバーが DNS 名を返します（たとえば、
myLB-1234567890.us-east-1.elb.amazonaws.com と指定します。
2.
クライアントが DNS サーバーによって送信された DNS 名の解決を求めます。アプリケーション
インスタンスは amazonaws.com ドメインにあるため、DNS エントリは Amazon によって制御さ
れます。Amazon DNS サーバーが1つ以上の IP アドレスを返します。
3.
次にクライアントは、提供された IP アドレスでマシンへの接続を開きます。このアドレスのイン
スタンスは、作成したロードバランサーです。
4.
ロードバランサーが、選択したアベイラビリティーゾーンに登録されているすべての EC2 アプリ
ケーションインスタンスのヘルスチェックを行い、ヘルスチェックの設定で定義されている状態の
しきい値を満たしたインスタンスに対してトラフィックのルーティングを開始します。
5.
ロードバランサーが、前の手順で識別された正常な EC2 アプリケーションインスタンスに対して、
クライアントリクエストをルーティングします。この時点で、クライアントはロードバランサーを
介していずれかの EC2 インスタンスと通信しています。フロントエンド接続（クライアントから
ロードバランサーへ）とバックエンド接続（ロードバランサーからバックエンドインスタンスへ）
の両方で HTTP、HTTPS、TCP、SSL のいずれかのプロトコルを使用するように、ロードバラン
サーリスナーを設定することができます。
Elastic Load Balancing の概念
Abstract
基本的な Elastic Load Balancing の概念について説明します。
Elastic Load Balancing を開始する前に、以下の概念を理解する必要があります。
概念
• 個のロードバランサー (p. 6)
• アベイラビリティーゾーンとリージョン (p. 6)
5
個のロードバランサー
• リクエストルーティング (p. 7)
• EC2 インスタンスの負荷分散の設定 (p. 8)
• ヘルスチェック (p. 9)
• Connection Draining (p. 11)
• アイドル接続のタイムアウト (p. 11)
• スティッキーセッション (p. 12)
• HTTP メソッド (p. 12)
• HTTPS Support (p. 13)
• Proxy Protocol (p. 13)
• X-Forwarded ヘッダー (p. 14)
個のロードバランサー
ロードバランサーは、負荷分散されたアプリケーションに対するすべてのリクエストの送信先です。各
ロードバランサーは複数の EC2 インスタンスにリクエストを分散できます。ロードバランサーは DNS
名と一連のポートによって表されます。ロードバランサーは、EC2 リージョン内の複数のアベイラビ
リティーゾーンに配置することができますが、複数のリージョンに配置することはできません。
特定のリージョン内のロードバランサーを作成または操作するには、対応するリージョンのサービスエ
ンドポイントを使用します。Elastic Load Balancing でサポートされているリージョンおよびエンドポ
イントについては、「リージョンとエンドポイント」を参照してください。
Elastic Load Balancing は、作成する各ロードバランサーのインスタンスに対して自動的に DNS 名を生
成します。通常、DNS 名にはロードバランサーが作成される AWS リージョンの名前が含まれます。
たとえば、us-east-1aで myLB という名前のロードバランサーを作成した場合、そのロードバランサー
の DNS 名は myLB-1234567890.us-east-1.elb.amazonaws.com のようになります。 Elastic Load
Balancing によって生成された DNS を使用して、ロードバランサーと接続します。接続するには、イ
ンターネットに接続したウェブブラウザのアドレスフィールドに、ロードバランサーの DNS 名を貼り
付けます。
ロードバランサー DNS 名の代わりに、www.example.com のようなユーザーが分かりやすいドメイン
名をロードバランサーに使用する場合は、カスタムドメイン名を作成して、そのカスタムドメイン名と
ロードバランサー DNS 名を関連付けます。作成したカスタムドメイン名を使用してロードバランサー
にリクエストを送ると、ロードバランサーの DNS 名に解決されます。
ロードバランサーのカスタムドメイン名の作成および使用の詳細については、ロードバランサーのカス
タムドメイン名の設定 (p. 103)を参照してください。
ロードバランサーを作成する際には、ロードバランサーのリスナーの設定を指定することにより、着信
トラフィックを受け入れるよう設定する必要があります。リスナーは、受信リクエストの接続がないか
を監視するプロセスです。リスナーは、フロントエンド（ロードバランサー）およびバックエンド（バッ
クエンドインスタンス）接続用のプロトコルとポート番号を使用して設定します。Elastic Load Balancing
でサポートされるポートおよびプロトコルについては、「Elastic Load Balancing のリスナー設定 (p. 24)
を参照してください。
アベイラビリティーゾーンとリージョン
あるリージョンの 1 つまたは複数のアベイラビリティーゾーンの EC2 インスタンスで受信したリクエ
ストを分散するよう、Elastic Load Balancing を設定することができます。ロードバランサーは、複数
のリージョン間ではトラフィックを分散しません。
重要なアプリケーションでは、受信トラフィックを複数のアベイラビリティーゾーンに分散することを
お勧めします。複数のアベイラビリティーゾーン間でトラフィックを分散させるためには、使用する予
6
リクエストルーティング
定のすべてのアベイラビリティーゾーンで Amazon EC2 インスタンスを起動し、インスタンスをロー
ドバランサーに登録します。
EC2 インスタンスを登録すると、登録されたインスタンスがあるすべてのアベイラビリティーゾーン
に Elastic Load Balancing によってロードバランサーノードがプロビジョニングされます。ロードバラ
ンサーノードは、登録されたすべてのインスタンスの状態を常に監視し、正常なインスタンスにトラ
フィックをルーティングします。ロードバランサーノードで異常または登録解除されたインスタンスが
検出された場合、ロードバランサーはそれらのインスタンスへのトラフィックのルーティングを停止し
ます。その代わり、リクエストを残りの正常なインスタンスに送信します。
最初のセットアップの後で、インスタンスの可用性をいつでも拡大または縮小することができます。ア
プリケーションの可用性を拡大するには、追加のアベイラビリティーゾーンでインスタンスを起動し、
新しいインスタンスをロードバランサーに登録し、新しいアベイラビリティーゾーンを追加します。新
しいアベイラビリティーゾーンを追加すると、有効なすべてのアベイラビリティーゾーン間で、ロード
バランサーによるトラフィックの均等なルーティングが始まります。インスタンスの可用性を縮小する
には、ロードバランサーに対して有効にされていたアベイラビリティーゾーンを削除します。アベイラ
ビリティーゾーンを削除すると、ロードバランサーは無効にしたアベイラビリティーゾーンにトラフィッ
クをルーティングしなくなり、有効なアベイラビリティーゾーン内の登録された正常なインスタンスに
は引き続きトラフィックをルーティングします。
詳細については、負荷分散するアプリケーションへのアベイラビリティーゾーンの追加または削除 (p. 65)
リクエストルーティング
クライアントがリクエストをロードバランサーに送信する前に、最初にロードバランサーのドメイン名
をドメインネームシステム（DNS）サーバーで解決します。DNS サーバーはクライアントに 1 つ以上
の IP アドレスを返すことで、ロードバランサーのドメイン名を解決します。次に、クライアントは
DNS ラウンドロビンを使用して、特定のアベイラビリティーゾーン内のどのロードバランサーノード
がリクエストを受信するかを決定します。
次に、選択されたロードバランサーノードが、同じアベイラビリティーゾーン内のインスタンスに対し
てリクエストを送信します。ロードバランサーノードは、インスタンスを決定するため、ラウンドロビ
ン（TCP 接続の場合）または最小の未処理のリクエスト（HTTP/HTTPS の接続の場合）のルーティン
グアルゴリズムを使用します。最小の未処理のリクエストのルーティングアルゴリズムでは、未処理の
リクエスト数が最も少ないバックエンドインスタンスが優先されます。
デフォルトでは、ロードバランサーノードは同じアベイラビリティーゾーン内のバックエンドインスタ
ンスにトラフィックをルーティングします。バックエンドインスタンスが各アベイラビリティーゾーン
のリクエストの負荷を確実に処理できるようにするため、各ゾーンにほぼ等しい数のインスタンスが存
在することが重要です。たとえば、アベイラビリティーゾーン us-east-1a に 10 個のインスタンス、ア
ベイラビリティーゾーン us-east-1b に 2 個のインスタンスがある場合でも、トラフィックは 2 つのア
ベイラビリティーゾーンに等分に分散されます。その結果、us-east-1b 内の 2 個のインスタンスは、
us-east-1a 内の 10 個のインスタンスと同じ量のトラフィックを処理しなければならなくなります。ベ
ストプラクティスとして、各アベイラビリティーゾーンのインスタンス数を同等またはほぼ同等にする
ことをお勧めします。したがって、この例では、インスタンス数を us-east-1a で 10 個、us-east-1b で
2 個にする代わりに、各アベイラビリティーゾーンのインスタンス数が 6 個になるようにインスタンス
を分散します。
属するアベイラビリティーゾーンに関係なく、すべてのバックエンドインスタンスにリクエストのトラ
フィックを等分にルーティングするには、ロードバランサーでクロスゾーン負荷分散を有効にします。
クロスゾーン負荷分散では、各ロードバランサーノードが複数のアベイラビリティーゾーンにリクエス
トをルーティングできるため、すべてのゾーンが等分な量のリクエストトラフィックを受け取ります。
クロスゾーン負荷分散により、各ゾーンに等しい数のバックエンドインスタンスを維持する必要性が軽
減され、1 つ以上のバックエンドインスタンスの消失を処理するアプリケーションの能力が向上しま
す。ただし、耐障害性を高めるために各アベイラビリティーゾーンにおよそ等しい数のインスタンスを
維持することをお勧めします。Elastic Load Balancing と別のアベイラビリティーゾーンにある EC2 イ
ンスタンス間のトラフィックによって EC2 データ転送料金は発生しません。
7
EC2 インスタンスの負荷分散の設定
クライアントが DNS ルックアップをキャッシュする環境では、着信リクエスト用にいずれかのアベイ
ラビリティーゾーンが優先される場合があります。クロスゾーン負荷分散を使用すると、リクエスト負
荷におけるこの不均衡が、リージョン内のすべての利用可能なバックエンドインスタンスに拡散し、動
作が不適切なクライアントがアプリケーションに与える影響が軽減されます。
Routing traffic to EC2 instances in EC2-Classic
EC2-Classic で起動されたバックエンドインスタンスと Elastic Load Balancing の間の通信を可能にす
るには、すべてのバックエンドインスタンスに適用されるセキュリティグループの進入ルールを作成し
ます。セキュリティグループルールは、すべての IP アドレス（0.0.0.0/0 CIDR 範囲）からの進入トラ
フィックを許可するか、Elastic Load Balancing からの進入トラフィックのみを許可することができま
す。バックエンド EC2 インスタンスが Elastic Load Balancing からのトラフィックのみを受信できる
ようにするには、すべてのバックエンド EC2 インスタンスで Elastic Load Balancing セキュリティグ
ループのネットワーク進入を有効にします。EC2-Classic で起動される EC2 インスタンスに対するセ
キュリティグループの設定の詳細については、「EC2-Classic でのロードバランサーのセキュリティグ
ループ (p. 68)」を参照してください。
VPC 内にある EC2 インスタンスへのトラフィックのルーティング
VPC にロードバランサーをデプロイする予定がある場合は、VPC のサブネット間でトラフィックが
ルーティングされるようにセキュリティグループのルールとネットワーク ACL を設定してください。
ルールが正しく設定されていない場合は、別のサブネットのロードバランサーノードから他のサブネッ
トのインスタンスにアクセスできない可能性があります。詳細については、「VPC のロードバラン
サー (p. 76)」および「VPC でのロードバランサーのセキュリティグループ (p. 78)」を参照してくださ
い。
ロードバランサーのクロスゾーン負荷分散の有効化と無効化については、「ロードバランサーのクロス
ゾーン負荷分散の有効化または無効化 (p. 106)」を参照してください。
EC2 インスタンスの負荷分散の設定
ロードバランサーを作成したら、そのロードバランサーの EC2 インスタンスを登録する必要がありま
す。EC2 インスタンスは、あるリージョンの 1 つまたは複数のアベイラビリティーゾーンに配置する
ことができます。Elastic Load Balancing は、登録されたすべての EC2 インスタンスに対して定期的に
ヘルスチェックを実行し、登録された正常な EC2 インスタンスのロードバランサーの DNS 名に、受
信したすべてのリクエストを自動的に分散します。EC2 インスタンスのヘルスチェックについては、
「ヘルスチェック (p. 9)を参照してください。
ロードバランサーに登録する EC2 インスタンスすべてに、ウェブサーバー（Apache や Internet
Information Services（IIS）など）がインストールされていることを確認します。
Stop and Start EC2 Instances
インスタンスは、インスタンスに関連付けられた IP アドレスを使用してロードバランサーに登録され
ます。インスタンスを停止して再起動すると、インスタンスに関連付けられている IP アドレスが変わ
ります。このため、ロードバランサーは再起動したインスタンスにトラフィックをルーティングできな
くなります。登録された EC2 インスタンスを停止して起動する場合は、停止したインスタンスをロー
ドバランサーから登録解除した後、再起動したインスタンスを登録することをお勧めします。そうしな
いと、ロードバランサーがヘルスチェックを実行できず、再起動したインスタンスにトラフィックを
ルーティングできない可能性があります。ロードバランサーからインスタンスを登録解除して再登録す
る方法については、ロードバランサーでの EC2 インスタンスの登録解除と登録 (p. 95) を参照してくだ
さい。
EC2 インスタンスへのキープアライブの設定
HTTP および HTTPS のリスナーには、EC2 インスタンスでキープアライブのオプションを有効にする
ことをお勧めします。この操作は、バックエンドインスタンスのウェブサーバー設定、またはカーネル
設定で行うことができます。キープアライブオプション使用すると、ロードバランサーで複数のクライ
アントリクエストのためにバックエンドへの接続を再利用できるようになります。これによってウェブ
8
ヘルスチェック
サーバーの負荷が軽減し、ロードバランサーのスループットが向上します。キープアライブのタイムア
ウトは、ロードバランサーがインスタンスへの接続を確実に閉じることができるように、60 秒以上に
する必要があります。
パス MTU 検出
Elastic Load Balancing では、パス最大送信単位 (MTU) 検出をサポートしています。パス MTU 検出を
正しく機能させるには、インスタンスのセキュリティグループのルールを調整する必要があります。詳
細については、『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「パス MTU 検出のセキュリ
ティグループルール」を参照してください。
ロードバランサーは、EC2 インスタンスの可用性を発見するため、定期的な ping の送信、接続の試
行、またはリクエストの送信により、EC2 インスタンスをテストします。これらのテストは、ヘルス
チェックと呼ばれます。ヘルスチェック時に正常であるインスタンスは "InService" とマークされ、ヘ
ルスチェック時に異常があるインスタンスは "OutOfService" とマークされます。ロードバランサーは、
インスタンスの状態が正常であるか異常であるかにかかわらず、すべての登録されたインスタンスでヘ
ルスチェックを実行します。
ロードバランサーは、正常なインスタンスのみにトラフィックをルーティングします。インスタンスが
異常であると判断した場合、ロードバランサーはそのインスタンスへのトラフィックのルーティングを
中止します。インスタンスが正常な状態に戻ると、ロードバランサーはそのインスタンスへのトラフィッ
クのルーティングを再開します。
ロードバランサーは Elastic Load Balancing（ELB）によって提供されるデフォルトのヘルスチェック
設定、またはユーザーが指定するヘルスチェック設定を使用して、登録されたインスタンスの状態を
チェックします。
ヘルスチェックの設定
ヘルス設定には、登録されているインスタンスのヘルス状態を判断するめに、ロードバランサーが使用
する情報が含まれています。次の表では、ヘルスチェック設定のフィールドについて説明します。
フィールド
説明
ping プロトコル
インスタンスと接続するために使用するコンソール: HTTP
プロトコル。プロトコルは TCP、HTCLI/API/SDK: TCP
TP、HTTPS、SSL のいずれかです。
ping ポート
インスタンスと接続するために使用するコンソール: HTTP:80
ポート。ping ポートは、1～65535 の範
CLI/API/SDK: TCP:80
囲にすることができます。
protocol:port ペアとして指定しま
す。
TCP または SSL プロトコルを指定する
場合、TCP:80 のようにプロトコルと
ポートを含めるだけです。
ロードバランサーは、指定されたポート
でインスタンスとの TCP 接続を開こう
とします。ロードバランサーが、設定さ
れた応答タイムアウト期間内に指定され
たポートでインスタンスに接続できない
場合、インスタンスは異常と見なされま
す。
9
デフォルト値
フィールド
説明
デフォルト値
ping パス
HTTP/HTTPS リクエストを送信する宛
先。
HTTP:80/index.html
HTTP または HTTPS プロトコルを指定
する場合、HTTP:80/index.html のよ
うに、ping ポートと ping パスを含める
必要があります。HTTP GET リクエスト
または HTTPS GET リクエストが、ping
ポートと ping パス上のインスタンスに
発行されます。ロードバランサーが応答
タイムアウト時間内に "200 OK" 以外の
応答を受信した場合、インスタンスは異
常と見なされます。応答に本文が含まれ
ている場合、アプリケーションは Content-Length ヘッダーを 0 以上の値に設
定するか、値を "chunked" に設定した
Transfer-Encoding を指定する必要があ
ります。
応答タイムアウト
ヘルスチェックからの応答を受信すると 5 秒
きの待機時間（2 秒～ 60 秒）です。
HealthCheck 間隔
ヘルスチェックの間隔（5 秒～ 300秒） 30 秒
非正常のしきい値
EC2 インスタンスの異常を診断するまで 2
のヘルスチェックの連続失敗回数
正常のしきい値
EC2 インスタンスが正常であると宣言す 10
るまでのヘルスチェックの連続成功回
数。
ロードバランサーはこのヘルスチェック設定を、「ping ポートと ping パス
http://EC2InstanceIPaddress:80/welcome.html 上の登録されたインスタンスに、30 秒ごとに
リクエストを送信する」と解釈します。インスタンスが応答するための応答タイムアウト期間として 5
秒を許可します。ロードバランサーが 2 回連続して失敗した場合、インスタンスのサービスを停止しま
す。ロードバランサーは、正常な応答を連続して 5 回受信した場合、インスタンスのサービスを再開し
ます。
AWS マネジメントコンソール、configure-health-check AWS CLI コマンド、または ConfigureHealthCheck
アクションを使用して、いつでもヘルスチェック設定を更新できます。
登録されたインスタンスのヘルス状態をチェックするには、AWS マネジメントコンソールで、
describe-instance-health コマンド、または DescribeInstanceHealth アクションを使用します。
ヘルスチェックと Auto Scaling グループ
Auto Scaling グループをロードバランサーに関連付けている場合、ロードバランサーのヘルスチェック
を使用して、Auto Scaling グループのインスタンスのヘルス状態を判断することができます。デフォル
トでは、Auto Scaling グループで各インスタンスのヘルス状態が定期的に判断されます。詳細について
は、『Auto Scaling 開発者ガイド』の「Auto Scaling グループに Elastic Load Balancing ヘルスチェッ
クを追加する」を参照してください。
ヘルスチェックのトラブルシューティング
登録されたインスタンスが、いくつかの理由からロードバランサーのヘルスチェックに失敗する場合が
あります。ヘルスチェックの失敗理由として最も多いのは、EC2 インスタンスがロードバランサーへ
10
Connection Draining
の接続を閉じている場合や、EC2 インスタンスからの応答がタイムアウトになった場合です。考えら
れる原因、および失敗したヘルスチェックの問題を解決するための手順については、「Elastic Load
Balancing のトラブルシューティング: ヘルスチェック設定 (p. 178)を参照してください。
Connection Draining
Connection Drainingを使用すると、ELB ロードバランサーは、既存の接続を開いたままにしながら、
登録解除中のインスタンスまたは異常があるインスタンスへのリクエストの送信を停止します。これに
より、ロードバランサーは、登録解除中または異常があるインスタンス宛の実行中のリクエストを完了
できます。
Connection Drainingはロードバランサーの属性であり、ロードバランサーのすべてのリスナーに適用さ
れます。Connection Drainingは、ロードバランサーに対していつでも有効または無効にできます。ロー
ドバランサーに対してConnection Drainingが有効になっているかどうかを確認するには、
DescribeLoadBalancerAtrributes アクションを使用するか、elb-describe-lb-attributes コマン
ドを使用するか、AWS Management Console で選択したロードバランサーの下のペインにある [Instances]
をクリックします。
ロードバランサーに対してConnection Drainingを有効にした場合、ロードバランサーが接続を閉じる前
に登録解除中のインスタンス宛の実行中のリクエストの処理を続ける最大時間を設定できます。ロード
バランサーは、最大制限時間に達すると、登録解除中のインスタンスへの接続を強制的に閉じます。
実行中のリクエストの処理中には、ロードバランサーは登録解除中のインスタンスの状態を InService:
Instance deregistration currently in progress と報告します。ロードバランサーは、登録
解除中のインスタンスが実行中のリクエストのすべての処理を完了するか、最大制限時間に達するか、
どちらか早いほうの時点で、インスタンス状態を OutOfService: Instance is not currently
registered with the LoadBalancer と報告します。
インスタンスが正常でなくなると、ロードバランサーはインスタンス状態を OutOfService と報告し
ます。正常でないインスタンス宛の実行中のリクエストは完了されます。正常でないインスタンスへの
接続には、最大制限時間は適用されません。
登録解除中のインスタンスまたは正常でないインスタンスの状態を確認するには、DescribeInstanceHealth
アクションまたは elb-describe-instance-health コマンドを使用します。
インスタンスが Auto Scaling グループの一部であり、ロードバランサーに対してConnection Draining
が有効になっている場合、Auto Scaling は実行中のリクエストが完了するか最大制限時間に達するかの
どちらか早いほうまで待ってから、スケーリングイベントまたはヘルスチェック交換によってインスタ
ンスを終了します。Auto Scaling で Elastic Load Balancing を使用する方法については、「Auto Scaling
グループのロードバランシング」を参照してください。
ロードバランサーのConnection Draining属性を有効または無効にする方法のチュートリアルについて
は、「ロードバランサーに対するConnection Drainingの有効化または無効化 (p. 110)」を参照してくだ
さい。
アイドル接続のタイムアウト
クライアントがロードバランサーを通じて行うリクエストごとに、ロードバランサーは 2 つの接続を維
持します。1 つはクライアントとの接続で、もう 1 つはバックエンドインスタンスとの接続です。ロー
ドバランサーは、各接続で、指定された期間に接続でデータが送信されない場合にトリガーされるアイ
ドルタイムアウトを管理します。この時間が経過してもデータが送受信されなかった場合、ロードバラ
ンサーは接続を閉じます。
デフォルトでは、Elastic Load Balancing はクライアントとバックエンドインスタンスへの接続で 60 秒
のアイドルタイムアウト設定を維持します。ロードバランサーのアイドルタイムアウト設定はいつでも
変更できます。
11
スティッキーセッション
HTTP および HTTPS リスナーを使用する場合は、EC2 インスタンスでキープアライブのオプションを
有効にすることをお勧めします。ウェブサーバーの設定または EC2 インスタンスのカーネル設定で、
キープアライブを有効にすることができます。キープアライブは、有効にすると、ロードバランサーで
バックエンドインスタンスへの接続を再利用できるようにします。これにより、インスタンスの CPU
使用率が減ります。ロードバランサーがバックエンドインスタンスへの接続を確実に閉じるようにする
には、キープアライブ時間のインスタンスに設定された値が、ロードバランサーのアイドルタイムアウ
ト設定より大きいことを確認します。
ロードバランサーのアイドルタイムアウト設定のチュートリアルについては、「ロードバランサーに対
するアイドル接続のタイムアウトの設定 (p. 113)」を参照してください。
スティッキーセッション
デフォルトでは、ロードバランサーは負荷が最小になるように、各リクエストを個別にアプリケーショ
ンインスタンスにルーティングします。しかし、スティッキーセッション機能（セッションアフィニ
ティとも呼ばれます）を使用することで、特定のユーザーのセッションを特定のアプリケーションイン
スタンスにバインドさせることができます。これにより、セッション中にそのユーザーから来たリクエ
ストをすべて同じアプリケーションインスタンスに送信することができます。
スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じ
アプリケーションインスタンスにルーティングし続ける期間の決定です。アプリケーションに独自の
セッション Cookie がある場合は、アプリケーションのセッション Cookie で指定された期間に従うセッ
ション Cookie を作成するよう、Elastic Load Balancing を設定することができます。アプリケーション
に独自のセッション Cookie がない場合は、独自の維持期間を指定して、セッション Cookie を作成す
るよう Elastic Load Balancing を設定することができます。維持期間は、ロードバランサーの
HTTP/HTTPS リスナーに対してのみ関連付けることができます。
• 期間ベースのセッション維持を許可する Cookie の作成については、期間ベースのセッション維
持 (p. 127) を参照してください。
• アプリケーション固有のセッション維持を許可する Cookie の作成については、アプリケーション制
御によるセッション維持 (p. 131) を参照してください。
アプリケーションインスタンスは、常に 2 つの Cookie を送受信する必要があります。維持期間を定義
する Cookie と、AWSELB という名前の Elastic Load Balancing の特別な Cookie（アプリケーション
インスタンスへのマッピングが含まれています）の 2 つです。
HTTP メソッド
HTTP メソッド（HTTP 動詞ともいう）は、HTTP リクエストを受信するリソースに対して実行するア
クションを指定します。HTTP リクエストの標準メソッドは、RFC 2616、「 Hypertext Transfer
Protocol-HTTP/1.1」に定義されています。標準メソッドには GET、POST、PUT、HEAD、および
OPTIONS があります。ウェブアプリケーションによっては、HTTP/1.1 メソッドの拡張である新しい
メソッドを必要とします（また、実装する場合もあります）。このような HTTP 拡張は標準外とする
ことができます。HTTP 拡張メソッドの代表的な例には PATCH、REPORT、MKCOL、PROPFIND、
MOVE、および LOCK などがあります。Elastic Load Balancing では、標準 HTTP メソッドも標準外の
HTTP メソッドもすべて受け付けます。
ロードバランサーは、HTTP リクエストを受信すると、誤った形式のリクエストがないかどうかをチェッ
クすると共に、メソッドの長さをチェックします。ロードバランサーへの HTTP リクエスト内のメソッ
ドの長さの合計は、127 文字以下にする必要があります。これら 2 つのチェックを渡す HTTP リクエ
ストは、ロードバランサーによりバックエンド EC2 インスタンスに送信されます。リクエストのメソッ
ドフィールドの形式が誤っている場合は HTTP 400: BAD_REQUEST (p. 175) エラーメッセージが返さ
れます。リクエストのメソッドフィールドの長さが 127 文字を超える場合は、HTTP 405:
METHOD_NOT_ALLOWED (p. 175) エラーメッセージが返されます。
12
HTTPS Support
バックエンド EC2 インスタンスが有効なリクエストを処理する方法は、リクエストに含まれるメソッ
ドを実行し、その応答をクライアントに返信することです。サポートされているメソッドもサポートさ
れていないメソッドも処理するように、バックエンドインスタンスを設定しておく必要があります。
HTTPS Support
HTTPS Support は、暗号化された接続で SSL/TLS プロトコルを使用できるようにするための機能です
（SSL オフロードとも呼ばれます）。この機能により、ロードバランサーとの HTTPS セッションを
開始するクライアント間の接続トラフィック、およびロードバランサーとバックエンドインスタンスの
間の接続のトラフィックを暗号化できるようになります。
ロードバランサーの HTTPS サポートを有効にするには、ロードバランサーに SSL サーバー証明書を
インストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロードバ
ランサーは証明書を使用してリクエストを終了し、次にリクエストを復号化します。
詳細については、Elastic Load Balancing での HTTP/HTTPS プロトコルの使用 (p. 25) を参照してくだ
さい。HTTPS を使用するロードバランサーの作成については、HTTPS/SSL ロードバランサーの作
成 (p. 46) を参照してください。
Proxy Protocol
Proxy Protocol ヘッダーは、TCP/SSL 接続用に設定されたロードバランサーを使用する場合に、クラ
イアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアントとバックエンド
インスタンスの間のトラフィックを傍受するため、バックエンドインスタンス内のアクセスログには、
発信元クライアントの IP アドレスでなく、ロードバランサーの IP アドレスが含まれています。Proxy
Protocol を有効化すると、ロードバランサーはクライアントのポート番号、発信元 IP アドレス、およ
び送信先 IP アドレスなどの接続情報が含まれるヘッダーが追加されるようにします。これにより、ヘッ
ダーがリクエストの一部としてバックエンドインスタンスに送信されます。リクエストの 1 行めを解析
して、クライアントの IP アドレスとポート番号を取得することができます。
Proxy Protocol の行は 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 Proxy Protocol の例を示します。
PROXY TCP4 198.51.100.22
203.0.113.7
35646
80\r\n
IPv6 の Proxy Protocol の行も基本的には同じ形式ですが、相違は TCP6 で始まることと、アドレスが
IPv6 の形式であることです。
次に IPv6 Proxy Protocol の例を示します。
PROXY TCP6 2001:DB8::21f:5bff:febf:ce22:8a2e 2001:DB8::12f:8baa:eafc:ce29:6b2e
35646 80\r\n
クライアントが IPv6 に接続すると、ヘッダー内のプロキシのアドレスはロードバランサーのパブリッ
ク IPv6 アドレスになります。この IPv6 アドレスは、プレフィックスが ipv6 または dualstack であ
るロードバランサー DNS 名から解決される IP アドレスに一致します。クライアントが IPv4 に接続す
ると、ヘッダー内のプロキシのアドレスはロードバランサーのプライベート IPv4 アドレスになるため、
EC2-Classic ネットワーク外の DNS ルックアップでは解決できなくなります。
13
X-Forwarded ヘッダー
Proxy Protocol ヘッダーの有効化については、「Proxy Protocol サポートの有効化または無効化（ロー
ドバランサー） (p. 115)を参照してください。
HTTP リクエストと HTTP レスポンスは、ヘッダーフィールドを使用して HTTP メッセージに関する
情報を送信します。ヘッダーフィールドはコロンで区切られた名前と値のペアであり、キャリッジリ
ターン（CR）とラインフィード（LF）で区切ります。HTTP ヘッダーフィールドの標準セットが RFC
2616 の「Message Headers」で定義されています。アプリケーションで広く使用されている標準以外
の HTTP ヘッダーもあります。標準以外の HTTP ヘッダーには、X-Forwarded というプレフィックス
が付いている場合があります。Elastic Load Balancing は以下の X-Forwarded ヘッダーをサポートし
ています。
X-Forwarded-For
X-Forwarded-For リクエストヘッダーは、HTTP/HTTPS ロードバランサーを使用する場合に、クラ
イアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント/サーバー間のト
ラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスの
みが含まれます。クライアントの IP アドレスを確認するには、X-Forwarded-For リクエストヘッダー
を使用します。Elastic Load Balancing は、クライアントの IP アドレスを X-Forwarded-For リクエ
ストヘッダーに格納し、このヘッダーをサーバーに渡します。
X-Forwarded-For リクエストヘッダーは以下のような形式です。
X-Forwarded-For: clientIPAddress
以下の例は、IP アドレスが X-Forwarded-For のクライアントの 203.0.113.7 リクエストヘッダー
です。
X-Forwarded-For: 203.0.113.7
以下の例は、IPv6 アドレスが X-Forwarded-For のクライアントの
2001:DB8::21f:5bff:febf:ce22:8a2e リクエストヘッダーです。
X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e
リクエストが複数のプロキシを通過する場合、X-Forwarded-For リクエストヘッダー内の
clientIPAddress の後に、リクエストがロードバランサーに達するまでにリクエストの受け渡しに参
加したすべてのプロキシの IP アドレスが順に記載されます。したがって、右端の値は最新のプロキシ
（ロードバランサーから見た）の IP アドレスで、左端の値は発信元クライアントの IP アドレスです。
このような場合、X-Forwarded-For リクエストヘッダーは次の形式になります。
X-Forwarded-For: OriginatingClientIPAddress, proxy1-IPAddress, proxy2-IPAddress
X-Forwarded-Proto
X-Forwarded-Proto リクエストヘッダーを使用すると、クライアントがサーバーへの接続に使用し
たプロトコル（HTTP または HTTPS）を識別することができます。サーバーアクセスログには、サー
バーとロードバランサーの間で使用されたプロトコルのみが含まれ、クライアントとロードバランサー
の間で使用されたプロトコルに関する情報は含まれません。クライアントとロードバランサーの間で使
用されたプロトコルを判別するには、X-Forwarded-Proto リクエストヘッダーを使用します。Elastic
Load Balancing は、クライアントとロードバランサーの間で使用されたプロトコルを
X-Forwarded-Proto リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。
14
アプリケーションやウェブサイトは X-Forwarded-Proto リクエストヘッダーに格納されているプロ
トコルを使用して、適切な URL にリダイレクトする応答を生成できます。
X-Forwarded-Proto リクエストヘッダーは以下のような形式です。
X-Forwarded-Proto: originatingProtocol
次の例には、HTTPS リクエストとしてクライアントから発信されたリクエストの X-Forwarded-Proto
リクエストヘッダーが含まれています。
X-Forwarded-Proto: https
X-Forwarded-Port
X-Forwarded-Port リクエストヘッダーは、HTTP/HTTPS ロードバランサーとクライアントの接続に
使用されるポートを識別するために役立ちます。
15
サインアップ
Elastic Load Balancing のセットアッ
プ
Abstract
Elastic Load Balancing を初めて使用する際の準備を整えるには、次の各ステップを実行します。
Elastic Load Balancing を使用するためのセットアップを行うには、次のタスクを実行します。
タスク
• アマゾンウェブサービス（AWS）にサインアップ (p. 16)
• Amazon EC2 を使用する準備を整える (p. 17)
• AWS マネジメントコンソールを使用した Elastic Load Balancing へのアクセス (p. 17)
• AWS CLI を使用した Elastic Load Balancing へのアクセス (p. 18)
アマゾンウェブサービス（AWS）にサインアッ
プ
AWS にサインアップすると、Elastic Load Balancing を含むすべてのサービスに対して AWS アカウン
トが自動的にサインアップされます。料金が発生するのは、お客様が使用したサービスの分のみです。
すでに AWS アカウントをお持ちの場合は次のタスクに進んでください。AWS アカウントをお持ちで
ない場合は、次に説明する手順にしたがってアカウントを作成してください。
サインアップして AWS アカウントを作成するには
1.
http://aws.amazon.com/ を開き、 Sign Up をクリックします。
2.
画面上の指示に従ってください。
サインアップ手順の一環として、通話呼び出しを受け取り、電話のキーパッドを用いて PIN を入
力することが求められます。
16
Amazon EC2 を使用する準備を整える
Amazon EC2 を使用する準備を整える
Amazon EC2 をまだ使用していない場合は、Amazon EC2 のドキュメントで説明されているタスクを
完了してください。詳細については、EC2 インスタンスに使用する予定のオペレーティングシステム
に応じて『Linux インスタンス用 Amazon EC2 ユーザーガイド』の「Amazon EC2 でのセットアップ」
または『Microsoft Windows インスタンスの Amazon EC2 ユーザーガイド』の「Amazon EC2 でのセッ
トアップ」を参照してください。
AWS マネジメントコンソールを使用した Elastic
Load Balancing へのアクセス
AWS Management Console は Elastic Load Balancing や他の AWS 製品へのアクセスに使用できるポイ
ントアンドクリック型のウェブベースインターフェイスです。このコンソールを使用して、Elastic Load
Balancing およびその他の AWS API に対するリクエストを実行することができます。
Elastic Load Balancing リソースには、AWS Management Console の EC2 コンソールを使用してアク
セスできます。
EC2 コンソールを使用して Elastic Load Balancing にアクセスするには
1.
2.
AWS マネジメントコンソールにサインインをしたあと、https://console.aws.amazon.com/ec2/ に
ある Amazon EC2 コンソールを開きます。
ナビゲーションバーで、ロードバランサーのリージョンを選択します。作成した各ロードバラン
サーは、指定したリージョンに関連付けられます。お客様の居住地に関係なく、使用できるリー
ジョンはどれでも選択できます。
3.
左のナビゲーションペインの [NETWORK & SECURITY] で、[Load Balancers] をクリックします。
選択したリージョンにロードバランサーがない場合、ロードバランサーページは次のように表示さ
れます。
17
AWS CLI を使用した Elastic Load Balancing へのアクセス
AWS マネジメントコンソールを使用してロードバランサーを作成する方法については、「Elastic Load
Balancing の使用開始 (p. 19)」を参照してください。
AWS CLI を使用した Elastic Load Balancing への
アクセス
AWS CLI は、Elastic Load Balancing を含むさまざまな AWS 製品用のコマンドを備えており、Windows、
Mac、および Linux でサポートされています。
AWS CLI の使用を開始するには、「AWS Command Line Interface ユーザーガイド」を参照してくだ
さい。Elastic Load Balancing 用のコマンドの詳細については、「AWS CLI elb」を参照してください。
AWS CLI は、Elastic Load Balancing 用に推奨されたコマンドラインインターフェイスです。元の Elastic
Load Balancing コマンドラインインターフェイス (ELB CLI) はまだ利用できますが、ELB CLI バージョ
ン 1.0.35.0（14/7/24 付）以降にリリースされた新機能は、AWS CLI のみに含まれています。詳細につ
いては、「Elastic Load Balancing API ツール」を参照してください。
18
開始する前に
Elastic Load Balancing の使用開始
Abstract
Elastic Load Balancing を使用する基本的な負荷分散タスクを開始します。
このチュートリアルでは、ポイントアンドクリック型のウェブベースインターフェイスである AWS マ
ネジメントコンソールを使った Elastic Load Balancing の使用方法を実践的に説明します。ここでは、
パブリック HTTP トラフィックを受信し、このトラフィックをインスタンスに送信する外部ロードバ
ランサーを作成します。
EC2-Classic や VPC で使用するためのロードバランサーを作成できます。このチュートリアルで説明
するタスクの一部は、VPC でのロードバランサーにのみ適用されます。
タスク
• 開始する前に (p. 19)
• ロードバランサーのリスナーの設定 (p. 20)
• EC2 インスタンスのヘルスチェックの設定 (p. 20)
• VPC でのロードバランサー用のサブネットの選択 (p. 21)
• VPC でのロードバランサーへのセキュリティグループの割り当て (p. 21)
• ロードバランサーへの EC2 インスタンスの登録 (p. 22)
• ロードバランサーの作成と検証 (p. 23)
• （オプション）ロードバランサーを削除する (p. 23)
開始する前に
• 「Elastic Load Balancing のセットアップ (p. 16)」の各ステップを実行します。
• ロードバランサーに登録する EC2 インスタンスを起動します。これらのインスタンスのセキュリティ
グループでは、ポート 80 の HTTP アクセスを許可していることを確認してください。
• EC2 インスタンスを VPC で実行する場合は、パブリックサブネットでそれらのインスタンスを起動
• ロードバランサーに登録する EC2 インスタンスに、ウェブサーバー（Apache や Internet Information
Services (IIS) など）をインストールします。
19
ロードバランサーのリスナーの設定
ロードバランサーのリスナーを設定するには
1.
2.
https://console.aws.amazon.com/ec2/）にある Amazon EC2 コンソールを開きます。
ナビゲーションバーで、ロードバランサーのリージョンを選択します。EC2 インスタンス用に選
択したリージョンと同じリージョンを必ず選択してください。
3.
4.
5.
ナビゲーションペインの [NETWORK & SECURITY] にある [Load Balancers] をクリックします。
[Create Load Balancer] をクリックします。
[Define Load Balancer] ページで、以下を実行します。
a.
[Load Balancer name] に、ロードバランサーの名前を入力します。
選択したロードバランサー名は、最大 32 文字の英数字またはハイフンを使用し、ロードバラ
ンサーのセット内で一意である必要があります。
b.
c.
d.
6.
[Create LB inside] で、インスタンス用に選択したネットワークと同じネットワークを選択し
ます（EC2-Classic または特定の VPC）。
[デフォルト VPC] デフォルト VPC を選択したときに、デフォルトのサブネット以外のサブ
ネットを選択する必要がある場合は、[Enable advanced VPC configuration] を選択します。
その他のフィールドはデフォルト値のままにしておきます。
[Continue] をクリックして、ウィザードの次のページに移動します。
EC2 インスタンスのヘルスチェックの設定
Elastic Load Balancing は、ロードバランサーの EC2 インスタンスについて、ヘルスチェックを自動的
に実行します。問題のあるインスタンスを検出した場合、Elastic Load Balancing はそのインスタンス
へのトラフィックの送信を停止し、トラフィックのルートを正常なインスタンスに変更します。このス
テップでは、ロードバランサーのヘルスチェックをカスタマイズします。
インスタンスのヘルスチェックを設定するには
1.
[Configure Health Check] ページで、以下を実行します。
a.
[Ping Protocol] の設定はデフォルト値 HTTP のままにしておきます。
b.
[Ping Port] の設定はデフォルト値 80 のままにしておきます。
c.
[Ping Path] フィールドのデフォルト値を半角のスラッシュ（「/」）で置き換えます。これに
より、Elastic Load Balancing は、ヘルスチェッククエリをウェブサーバーのデフォルトのホー
ムページ（index.html や default.html など）に送信できるようになります。
20
VPC でのロードバランサー用のサブネットの選択
d.
2.
VPC でのロードバランサー用のサブネットの選択
ロードバランサーの可用性を向上させるには、2 つ以上のサブネットを異なるアベイラビリティーゾー
ンで選択します。
Note
ネットワークとして EC2-Classic を選択した場合、またはデフォルト VPC を所有していて
[Enable advanced VPC configuration] を選択しなかった場合は、ウィザードにこのページは表
示されません。次のステップに進んでください。
ロードバランサー用のサブネットを選択するには
1.
[Select Subnets] ページの [Available Subnets] で、サブネットを選択します。選択したサブネット
が、[Selected Subnets] の下に移動されます。
2.
VPC でのロードバランサーへのセキュリティグ
ループの割り当て
VPC でロードバランサーを作成した場合は、ポートへのインバウンドトラフィックを許可するセキュ
リティグループを割り当てる必要があります。このポートは、ロードバランサーとロードバランサーの
ヘルスチェック用に指定したポートです。
21
ロードバランサーへの EC2 インスタンスの登録
Note
ネットワークとして EC2-Classic を選択した場合、ウィザードにこのページは表示されませ
ん。次のステップに進んでください。EC2-Classic の場合、Elastic Load Balancing によって、
ロードバランサーにセキュリティグループが自動的に割り当てられます。
ロードバランサーにセキュリティグループを割り当てるには
1.
[Assign Security Groups] ページで [Create a new security group] を選択します。
2.
セキュリティグループの名前と説明を入力するか、デフォルトの名前と説明をそのまま使用しま
す。この新しいセキュリティグループには、ロードバランサーで使用するように設定したポートへ
のトラフィックを許可するルールが含まれます。ヘルスチェック用に別のポートを指定した場合
は、[Add Rule] をクリックして、そのポートへのインバウンドトラフィックを許可するルールを追
加する必要もあります。
3.
ロードバランサーへの EC2 インスタンスの登録
ロードバランサーは、ロードバランサーに登録されたインスタンスにトラフィックを分散します。イン
スタンスをロードバランサーに登録するには、次の 2 つの方法があります。
• インスタンスを手動で登録します。
• インスタンスの起動時にインスタンスを自動的に登録するように、Auto Scaling をセットアップしま
す。詳細については、『Auto Scaling 開発者ガイド』の「スケーリングとロードバランシングを使用
するアプリケーションのセットアップ」を参照してください。
インスタンスをロードバランサーに手動で登録するには、次の手順に従います。
EC2 インスタンスをロードバランサーに手動で登録するには
1.
[Add EC2 Instances] ページの [Add Instances to Load Balancer] で、ロードバランサーに登録する
インスタンスを選択します。
2.
3.
[Continue] をクリックします。必要に応じてロードバランサーにタグを追加できます。追加しない
場合は、[Continue] を再度クリックして、ウィザードの [Review] ページに移動します。
22
ロードバランサーの作成と検証
ロードバランサーの作成と検証
ロードバランサーを作成する前に、選択した設定を確認します。ロードバランサーを作成した後で、イ
ンスタンスにトラフィックを送信するかどうかを確認できます。
ロードバランサーの作成を完了するには
1.
[Review] ページで設定を確認します。初期設定を変更する必要がある場合は、対応する編集リンク
をクリックします。
2.
3.
4.
[Create] をクリックし、ロードバランサーを作成します。
ロードバランサーが作成されたことが通知されたら、[Close] をクリックします。
新しいロードバランサーを選択します。
5.
下のペインで、[Description] タブの [Status] 行を確認します。この行が一部のインスタンスが実行
されていないことを示している場合、インスタンスはまだ登録中の可能性があります。詳細につい
ては、「Elastic Load Balancing のトラブルシューティング: インスタンスの登録 (p. 182)」を参照
少なくとも 1 つの EC2 インスタンスが InService であることを確認したら、ロードバランサー
をテストできます。[DNS Name] フィールドの文字列をコピーし、インターネットに接続したウェ
ブブラウザのアドレスフィールドに貼り付けます。(例,
my-lb-1234567890.us-west-2.elb.amazonaws.com.) ロードバランサーが実行中の場合は、
HTTP サーバーのデフォルトページが表示されます。
6.
（オプション）ロードバランサーを削除する
ロードバランサーが利用可能になると、ロードバランサーの実行時間に応じて 1 時間ごと、または 1
時間未満の時間について課金されます。不要になったロードバランサーは削除できます。ロードバラン
サーが削除されると、ロードバランサーの課金も停止されます。
ロードバランサーを削除するには
1.
2.
3.
4.
5.
ロードバランサーを選択します。
[Actions] をクリックし、[Actions] ドロップダウンボックスで [Delete] をクリックします。
確認を求めるメッセージが表示されたら、[Yes, Delete] をクリックします。
6.
（オプション）ロードバランサーを削除しても、そのロードバランサーに関連付けられた EC2 イ
ンスタンスは実行し続けます。また、それらのインスタンスの実行時間に応じて 1 時間ごと、また
は 1 時間未満の時間について課金されます。インスタンスの停止や終了の詳細については、『Linux
インスタンス用 Amazon EC2 ユーザーガイド』の「インスタンスの停止と起動」または「インス
タンスの終了」を参照してください。
23
Elastic Load Balancing のリスナー設
定
Abstract
一般的なウェブアプリケーション通信は、ハードウェアとソフトウェアの複数のレイヤーを通過しま
す。各レイヤーは固有の通信機能を提供します。通信機能のコントロールはあるレイヤーから次のレイ
ヤーへと順番に渡されます。開放型システム間相互接続（OSI）は、これらのレイヤーでプロトコルと
呼ばれる通信の標準形式を実装するためのモデルフレームワークを定義します。OSI モデルのレイヤー
については、http://en.wikipedia.org/wiki/OSI_model を参照してください。
Elastic Load Balancing を使用する場合、レイヤー 4 とレイヤー 7 の 2 つのレイヤーに関する基本的な
理解が必要です。レイヤー4はトランスポートレイヤーで、ロードバランサーを介したクライアントと
バックエンドインスタンスとの間の Transmission Control Protocol（TCP）接続を記述します。レイ
ヤー4はロードバランサーで設定可能な一番下のレベルです。レイヤー 7 はアプリケーションレイヤー
で、クライアントからロードバランサー、およびロードバランサーからバックエンドインスタンスへの
ハイパーテキスト転送プロトコル（HTTP）および HTTPS（セキュアな HTTP）接続の使用について記
述します。
Secure Sockets Layer（SSL）プロトコルの知識も必要です。SSL プロトコルは、インターネットなど
の安全性が低いネットワーク上での機密データの暗号化に主に使用されます。SSL プロトコルは、ク
ライアントとバックエンドサーバーの間のセキュアな接続を確立し、クライアントとバックエンドサー
バーの間で受け渡しされるすべてのデータのプライバシーと完全性を保証します。
目次
• リスナー (p. 25)
• Elastic Load Balancing での TCP/SSL プロトコルの使用 (p. 25)
• Elastic Load Balancing での HTTP/HTTPS プロトコルの使用 (p. 25)
• SSL サーバー証明書 (p. 26)
• SSL ネゴシエーション (p. 26)
• Elastic Load Balancing でのバックエンドサーバー認証の使用 (p. 27)
• Elastic Load Balancing リスナー設定クイックリファレンス (p. 27)
24
リスナー
リスナー
Elastic Load Balancing の使用を開始する前に、ロードバランサーのリスナーを設定する必要がありま
す。リスナーとは接続リクエストをリッスンするプロセスです。リスナーは、フロントエンド（クライ
アントからロードバランサー）およびバックエンド（ロードバランサーからバックエンドインスタン
ス）接続用のプロトコルとポート番号を使用して設定します。
Elastic Load Balancing では、HTTP、HTTPS（セキュア HTTP）、TCP、SSL（セキュア TCP）の各
プロトコルを使用することができます。HTTPS プロトコルは、HTTP レイヤー経由のセキュアな接続
を確立するために SSL プロトコルを使用します。SSL プロトコルは、TCP レイヤー経由のセキュアな
接続を確立する場合にも使用することができます。
HTTPS/SSL 接続と HTTP/TCP 接続の両方に使用できるポートは、25、80、443、465、587、および
1024-65535 です。
フロントエンド接続とバックエンド接続用のプロトコルは別々に指定できます。フロントエンド接続と
バックエンド接続は同じレイヤーを使用する必要があります。たとえば、フロントエンド接続が TCP
または SSL プロトコルを使用する場合は、バックエンド接続のプロトコルも TCP または SSL になり
ます。また、ロードバランサーのフロントエンド接続が HTTP または HTTPS を使用する場合は、バッ
クエンド接続のプロトコルも HTTP または HTTPS になります。
デフォルトでは、ロードバランサーはフロントエンド接続とバックエンド接続にポート 80 で HTTP プ
ロトコルを使用するよう設定されています。デフォルト設定は変更できます。
Elastic Load Balancing での TCP/SSL プロトコル
の使用
フロントエンド接続とバックエンド接続の両方に TCP（layer 4）を使用する場合、ロードバランサー
はヘッダーを変更せずにバックエンドインスタンスにリクエストを転送します。リクエストを受け取っ
たロードバランサーは、ヘルスチェック設定で指定されたポートを使ってバックエンドインスタンスに
対する TCP 接続を開こうと試みます。ロードバランサーが、設定された応答タイムアウト期間内に指
定されたポートでインスタンスに接続できない場合、インスタンスは異常と見なされます。
ロードバランサーはクライアントとバックエンドインスタンスの間のトラフィックを傍受するため、
バックエンドインスタンス内のアクセスログには、発信元クライアントの IP アドレスでなく、ロード
バランサーの IP アドレスが含まれています。Proxy Protocol を有効にして、クライアントのポート番
号、発信元 IP アドレス、および送信先 IP アドレスなどの接続情報が含まれるヘッダーが追加されるよ
うにします。これにより、ヘッダーがリクエストの一部としてバックエンドインスタンスに送信されま
す。接続情報を取得するには、リクエストの 1 行めを解析します。Proxy Protocol の有効化について
は、「Proxy Protocol サポートの有効化または無効化（ロードバランサー） (p. 115)を参照してくださ
い。
この設定では、スティッキーセッション用の Cookie や X-Forwarded-* ヘッダー用の Cookie は挿入さ
れません。
Elastic Load Balancing での HTTP/HTTPS プロト
コルの使用
フロントエンド接続とバックエンド接続の両方に HTTP（レイヤー7）を使用する場合、ロードバラン
サーはリクエストのヘッダーを解析して接続を終了した後、バックエンドインスタンスにリクエストを
再送します。これは Elastic Load Balancing のデフォルト設定です。
25
SSL サーバー証明書
バックエンドインスタンスを使って接続するために、HTTP GET リクエストまたは HTTPS GET リク
エストが、ヘルスチェック設定で指定された ping ポートと ping パス上のインスタンスに対して発行さ
れます。ロードバランサーが応答タイムアウト時間内に "200 OK" 以外の応答を受信した場合、インス
タンスは異常と見なされます。
HTTP/HTTPS ロードバランサーの背後にあるあらゆる登録された正常なインスタンスについて、Elastic
Load Balancing は 1 つ以上の TCP 接続を開いて維持します。この事前にオープンされた接続によっ
て、HTTP/HTTPS リクエストを受信できる接続が常に確立されていることが保証されます。
HTTP リクエストと HTTP レスポンスは、ヘッダーフィールドを使用して HTTP メッセージに関する
情報を送信します。Elastic Load Balancing は X-Forwarded-For ヘッダーをサポートしています。
ロードバランサーはクライアント/サーバー間のトラフィックをインターセプトするので、サーバーア
クセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認
するには、X-Forwarded-For リクエストヘッダーを使用します。詳細については、
「X-Forwarded-For (p. 14)」を参照してください。
HTTP/HTTPS を使用するときは、ロードバランサーでスティッキーセッションを有効にできます。ス
ティッキーセッションは、ユーザーのセッションを特定のバックエンドインスタンスに結び付けます。
これにより、セッション中にそのユーザーから来たリクエストをすべて同じバックエンドインスタンス
に送信することができます。スティッキーセッションの詳細については、「スティッキーセッショ
ン (p. 12)」を参照してください。
ロードバランサーはすべての HTTP 拡張機能をサポートしているわけではありません。予期しないメ
ソッド、応答コード、またはその他の標準でない HTTP 1.0/1.1 実装のためにロードバランサーがリク
エストを終了できない場合、TCP リスナーを使用する必要がある場合もあります。
SSL サーバー証明書
フロントエンドリスナーに HTTPS または SSL を使用する場合、ロードバランサーに SSL 証明書をイ
ンストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロードバラ
ンサーは証明書を使用して接続を終了し、クライアントからのリクエストを復号化します。
SSL プロトコルは、X.509 証明書（SSL サーバー証明書）を使用して、クライアントとバックエンド
インスタンスの両方を認証します。X.509 証明書は、認証機関 (CA) によって発行された IDENTITY デ
ジタルフォームで、識別情報、有効期間、パブリックキー、シリアルナンバー、発行者のデジタル署
名が含まれます。
ロードバランサーに SSL 証明書をインストールする前に、証明書を作成し、CA に証明書に署名しても
らってから、AWS Identity and Access Management (AWS IAM) サービスを使用して証明書をアップ
ロードする必要があります。
SSL 証明書には有効期間が記載されています。証明書は、有効期間が終了する前に差し替える必要が
あります。SSL 証明書を作成する方法については、「Elastic Load Balancing の SSL 証明書 (p. 36)」
を参照してください。詳細については、「ロードバランサーの SSL 証明書の更新 (p. 41)」を参照して
ください。
SSL ネゴシエーション
Elastic Load Balancing によって、事前定義された SSL ネゴシエーション設定を持つセキュリティポリ
シーが提供されます。クライアントとロードバランサーの間に接続が確立されたとき、これらの設定が
SSL ネゴシエーションに使用されます。SSL ネゴシエーション設定は幅広いクライアントとの互換性
を提供し、暗号という強力な暗号アルゴリズムを使用します。ただし、ネットワーク上のすべてのデー
タを暗号化する必要があるようなユースケースでは、特定の暗号しか使用できない場合があります。一
部のセキュリティコンプライアンス基準 (PCI、SOX など) では、セキュリティの基準を確実に満たす
ために、クライアントからの特定のプロトコルと暗号のセットを要求する場合があります。このような
26
Elastic Load Balancing でのバックエンドサーバー認証の使
用
場合、Elastic Load Balancing は、特定の要件に基づいて、プロトコルと暗号に異なる設定を選択する
ためのオプションを提供します。ノード数によりますが、暗号とプロトコルは 30 秒以内に有効になる
必要があります。
フロントエンド接続に SSL/HTTPS プロトコルを使用する場合は、事前定義されたセキュリティポリ
シーのいずれかを使用したり、カスタムセキュリティポリシーを作成したりすることができます。Elastic
Load Balancing によって使用される事前定義された SSL ネゴシエーション設定については、「Elastic
Load Balancing の SSL ネゴシエーション設定 (p. 30)」を参照してください。暗号とプロトコルの設定
方法については、「ステップ 2: SSL セキュリティポリシーの設定 (p. 48)」を参照してください。
Elastic Load Balancing でのバックエンドサーバー
認証の使用
SSL プロトコルを使用する際、ロードバランサーでの接続を終了したくない場合は、クライアントか
らロードバランサーへの接続に TCP プロトコルを使用し、ロードバランサーからバックエンドアプリ
ケーションへの接続に SSL プロトコルを使用し、すべてのバックエンドインスタンス処理リクエスト
に証明書をインストールします。
バックエンドに HTTPS/SSL 接続を使用する場合は、バックエンドインスタンスで認証を有効化できま
す。この認証は、バックエンドインスタンスが暗号化された通信のみを受け入れ、バックエンドインス
タンスに適切な証明書が使用されていることを確認するために使用できます。
自己署名証明書を含め、バックエンドインスタンスに任意の証明書をインストールできます。
詳細については、「Elastic Load Balancing リスナー設定クイックリファレンス (p. 27)」を参照してく
ださい。
Elastic Load Balancing リスナー設定クイックリ
ファレンス
次の表に、ロードバランサーを設定するために使用できるリスナー設定をまとめています。
HTTP/HTTPS 負荷分散
ご利用用途
フロントエンドフロントエンドバックエンド
プロトコル
のオプション設プロトコル
定
基本的な HT- HTTP
TP ロードバラ
ンサー
NA
HTTP
バックエンドの注意事項
オプション設定
NA
• デフォルト設
定
• X-ForwardedFor (p. 14)
ヘッダーをサ
ポートしま
す。
• スティッキー
セッショ
ン (p. 12) を
サポート。
27
リスナー設定クイックリファレンス
ご利用用途
プロトコル
定
安全なウェブ HTTPS
サイトまたは
アプリケー
ション（Elastic Load Balancing を使用し
て SSL 復号化
をオフロー
ド）
Elastic Load
HTTP
Balancing の
SSL ネゴシエー
ション設
定 (p. 30)
NA
• スティッキー
セッショ
ン (p. 12) を
サポート。
ヘッダーをサ
ポートしま
す。
• Elastic Load
Balancing の
SSL 証明
書 (p. 36) が
ロードバラン
サーにインス
トールされて
いる必要があ
ります。
安全なウェブ HTTPS
サイトまたは
アプリケー
ション（Elastic Load Balancing でエンド
ツーエンド暗
号化を使用し
て、X-Forward
ヘッダーとス
ティッキー
セッションを
提供）
Elastic Load
HTTPS
Balancing の
SSL ネゴシエー
ション設
定 (p. 30)
バックエンド認 • スティッキー
証
セッショ
ン (p. 12) を
サポート。
ヘッダーをサ
ポートしま
す。
• Elastic Load
Balancing の
SSL 証明
書 (p. 36) が
ロードバラン
サーと登録さ
れたインスタ
ンスにインス
トールされて
いる必要があ
ります。
以下のクイックリファレンスは、標準的な TCP/SSL ロードバランサーのユースケースのリスナー設定
オプションをまとめたものです。
28
リスナー設定クイックリファレンス
TCP/SSL 負荷分散
ご利用用途
プロトコル
定
基本的な TCP
ロードバラン
サー
TCP
NA
NA
TCP
• 基本的な
TCP 負荷分
散
ヘッダーをサ
ポートしま
す。
安全なウェブ SSL
サイトまたは
アプリケー
ション（Elastic Load Balancing を使用し
て SSL 復号化
をオフロー
ド）
Elastic Load
TCP
Balancing の
SSL ネゴシエー
ション設
定 (p. 30)
NA
安全なウェブ SSL
サイトまたは
アプリケー
ション（Elastic Load Balancing でエンド
ツーエンド暗
号化を使用）
Elastic Load
SSL
Balancing の
SSL ネゴシエー
ション設
定 (p. 30)
バックエンド認 • Proxy Pro証
tocol (p. 13)
ヘッダーをサ
ポートしま
す。
• Elastic Load
Balancing の
SSL 証明
書 (p. 36) が
ロードバラン
サーと登録さ
れたインスタ
ンスにインス
トールされて
いる必要があ
ります。
29
ヘッダーをサ
ポートしま
す。
• Elastic Load
Balancing の
SSL 証明
書 (p. 36) が
ロードバラン
サーにインス
トールされて
いる必要があ
ります。
Elastic Load Balancing の SSL ネゴ
シエーション設定
Abstract
事前に定義された SSL を使用して、クライアントとロードバランサーの SSL 接続をネゴシエートします。
Elastic Load Balancing は、セキュリティポリシーと呼ばれる Secure Socket Layer (SSL) ネゴシエー
ション設定を使用して、クライアントとロードバランサーとの SSL 接続をネゴシエートします。セキュ
リティポリシーは、SSL プロトコル、SSL 暗号、およびサーバーの優先順位オプションを組み合わせ
たものです。ロードバランサーの SSL 接続を設定する方法については、「Elastic Load Balancing のリ
スナー設定 (p. 24)」を参照してください。
SSL Protocols
Secure Sockets Layer (SSL) と Transport Layer Security (TLS) はインターネットなどの安全性の低い
ネットワーク上での機密データの暗号化に使用される暗号プロトコルです。TLS プロトコルは SSL プ
ロトコルの新しいバージョンです。Elastic Load Balancing のドキュメントでは、SSL プロトコルも
TLS プロトコルも SSL プロトコルと呼びます。
SSL プロトコルは、クライアントとサーバーの間の安全な接続を確立し、クライアントとロードバラ
ンサーの間で受け渡しされるすべてのデータのプライバシーを保証します。
Elastic Load Balancing は、以下のバージョンの SSL プロトコルをサポートします。
• TLS 1.2
• TLS 1.1
• TLS 1.0
• SSL 3.0
• SSL 2.0
SSL Ciphers
SSL 暗号とは、暗号化キーを使用してコード化されたメッセージを作成する暗号化アルゴリズムです。
SSL プロトコルは、複数の暗号化アルゴリズムを使用し、インターネットを介してデータを暗号化し
ます。Elastic Load Balancing でサポートされる SSL 暗号および SSL プロトコルについては、「事前
定義された SSL セキュリティポリシー (p. 32)」を参照してください。
30
SSL のセキュリティポリシー
Server Order Preference
Elastic Load Balancing では、クライアントとロードバランサー間の接続をネゴシエートするために、
サーバーの優先順位オプションをサポートしています。SSL 接続ネゴシエーションのプロセスで、ク
ライアントとロードバランサーでは、それぞれサポートされる暗号とプロトコルのリストが優先される
順に表示されます。デフォルトでは、クライアントのリストで最初にロードバランサーの暗号と一致し
た暗号が SSL 接続用に選択されます。サーバーの優先順位をサポートするようにロードバランサーが
設定されていると、ロードバランサーはクライアントの暗号リストに含まれている暗号と最初に一致す
る暗号を、ロードバランサーのリストから選択します。このようにして、SSL 接続に使用される暗号
がロードバランサーによって決定されます。サーバーの優先順位を有効にしない場合は、クライアント
で設定された暗号の順序がクライアントとロードバランサー間の接続のネゴシエーションに使用されま
す。
Elastic Load Balancing で使用される暗号の順序については「事前定義された SSL セキュリティポリ
シー (p. 32)」を参照してください。
目次
• Elastic Load Balancing での SSL のセキュリティポリシー (p. 31)
• Elastic Load Balancing での事前定義された SSL のセキュリティポリシー (p. 32)
Elastic Load Balancing での SSL のセキュリティ
ポリシー
Abstract
ロードバランサーの SSL ネゴシエーションを設定します。
セキュリティポリシーによって、クライアントとロードバランサー間の SSL ネゴシエーションでサポー
トされる暗号とプロトコルが決まります。Elastic Load Balancing では、事前に定義されたセキュリティ
ポリシーまたはカスタムセキュリティポリシー使用するようにロードバランサーを設定できます。
事前に定義されたセキュリティポリシー
事前に定義された SSL ネゴシエーション設定を使用できます。この設定は Elastic Load Balancing に用
意されており、暗号とプロトコルが有効になっています。事前に定義されたセキュリティポリシーの名
前には、そのセキュリティポリシーがリリースされた年月に基づくバージョン情報が含まれています。
たとえば、現在の事前定義されたセキュリティポリシーは ELBSecurityPolicy-2015-03 です。古
いポリシーにはこの命名規則に従わないものもありますので、ご注意ください。
新しい設定が利用可能になると、Elastic Load Balancing は新しいバージョンの事前定義されたポリシー
をリリースします。新しいバージョンがリリースされるたびに、最新バージョンの事前定義されたセ
キュリティポリシーを使用して設定を更新できます。
現在、Elastic Load Balancing に用意されている事前定義されたセキュリティポリシーは次のとおりで
す。
• ELBSecurityPolicy-2015-03
• ELBSample-ELBDefaultNegotiationPolicy または ELBSample-ELBDefaultCipherPolicy
• ELBSample-OpenSSLDefaultNegotiationPolicy または ELBSample-OpenSSLDefaultCipherPolicy
31
事前定義された SSL セキュリティポリシー
事前定義されたセキュリティポリシーで有効な SSL プロトコル、SSL 暗号および SSL オプションにつ
いては、「事前定義された SSL セキュリティポリシー (p. 32)」を参照してください。
カスタムセキュリティポリシー
必要な暗号とプロトコルを備えたカスタムネゴシエーション設定を作成できます。一部のセキュリティ
コンプライアンス基準（PCI、SOX など）では、セキュリティの基準を確実に満たすために、特定のプ
ロトコルと暗号のセットを要求する場合があります。このような場合は、それらの基準を満たすカスタ
ムセキュリティポリシーを作成できます。
Elastic Load Balancing でサポートされるプロトコルと暗号については、「事前定義された SSL セキュ
リティポリシー (p. 32)」を参照してください。
セキュリティポリシーの選択やカスタムセキュリティポリシーの作成については、「ステップ 2: SSL
セキュリティポリシーの設定 (p. 48)」を参照してください。
Elastic Load Balancing での事前定義された SSL
のセキュリティポリシー
Abstract
SSL/HTTP のリスナーの SSL ネゴシエーションの事前定義されたセキュリティポリシーについて説明します。
次の表は、使用可能な SSL プロトコルや SSL 暗号など、最新の事前定義されたセキュリティポリシー
の詳細を示しています。[Server Order Preference] が有効なポリシーを選択した場合、ロードバラン
サーは、この一覧で指定された順序で暗号を使用して、クライアントとロードバランサー間の接続をネ
ゴシエートします。それ以外の場合は、ロードバランサーはクライアントが提示した順番で暗号化を使
用します。
事前定義されたセキュリティポリシーの最新バージョンを使用することをお勧めします。
廃止されたものを含むすべての事前定義されたセキュリティポリシーを表示するには、
describe-load-balancer-policies コマンドまたは DescribeLoadBalancerPolicies アクションを使用しま
す。
セキュリティポリシー
2015-03
2015-02
2014-10
2014-01
2011-08
♦
♦
♦
SSL Protocols
Protocol-SSLv2
Protocol-SSLv3
Protocol-TLSv1
♦
♦
♦
♦
Protocol-TLSv1.1
♦
♦
♦
♦
Protocol-TLSv1.2
♦
♦
♦
♦
♦
♦
♦
♦
ECDHE-ECDSA-AES128- GCM-SHA256
♦
♦
♦
♦
ECDHE-RSA-AES128- GCM-SHA256
♦
♦
♦
♦
SSL Options
Server Order Preference
SSL Ciphers
32
2015-03
2015-02
2014-10
2014-01
2011-08
ECDHE-ECDSA-AES128-SHA256
♦
♦
♦
♦
ECDHE-RSA-AES128-SHA256
♦
♦
♦
♦
ECDHE-ECDSA-AES128-SHA
♦
♦
♦
♦
ECDHE-RSA-AES128-SHA
♦
♦
♦
♦
DHE-RSA-AES128-SHA
♦
♦
♦
♦
ECDHE-ECDSA-AES256- GCM-SHA384
♦
♦
♦
♦
ECDHE-RSA-AES256- GCM-SHA384
♦
♦
♦
♦
ECDHE-ECDSA-AES256-SHA384
♦
♦
♦
♦
ECDHE-RSA-AES256-SHA384
♦
♦
♦
♦
ECDHE-RSA-AES256-SHA
♦
♦
♦
♦
ECDHE-ECDSA-AES256-SHA
♦
♦
♦
♦
AES128-GCM-SHA256
♦
♦
♦
♦
AES128-SHA256
♦
♦
♦
♦
AES128-SHA
♦
♦
♦
♦
AES256-GCM-SHA384
♦
♦
♦
♦
AES256-SHA256
♦
♦
♦
♦
AES256-SHA
♦
♦
♦
♦
♦
DHE-DSS-AES128-SHA
♦
♦
♦
♦
♦
♦
♦
CAMELLIA128-SHA
♦
EDH-RSA-DES-CBC3-SHA
♦
DES-CBC3-SHA
♦
♦
ECDHE-RSA-RC4-SHA
♦
♦
RC4-SHA
♦
♦
♦
ECDHE-ECDSA-RC4-SHA
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
♦
DHE-DSS-AES256-SHA
♦
DHE-RSA-CAMELLIA256-SHA
♦
DHE-DSS-CAMELLIA256-SHA
♦
33
2015-03
2015-02
2014-10
2014-01
2011-08
CAMELLIA256-SHA
♦
EDH-DSS-DES-CBC3-SHA
♦
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-CAMELLIA128-SHA
♦
DHE-DSS-CAMELLIA128-SHA
♦
ADH-AES128-GCM-SHA256
ADH-AES128-SHA
ADH-AES128-SHA256
ADH-AES256-GCM-SHA384
ADH-AES256-SHA
ADH-AES256-SHA256
ADH-CAMELLIA128-SHA
ADH-CAMELLIA256-SHA
ADH-DES-CBC3-SHA
ADH-DES-CBC-SHA
ADH-RC4-MD5
ADH-SEED-SHA
DES-CBC-SHA
DHE-DSS-SEED-SHA
DHE-RSA-SEED-SHA
EDH-DSS-DES-CBC-SHA
EDH-RSA-DES-CBC-SHA
IDEA-CBC-SHA
RC4-MD5
SEED-SHA
DES-CBC3-MD5
DES-CBC-MD5
Deprecated SSL Ciphers
RC2-CBC-MD5
34
2015-03
2015-02
2014-10
2014-01
2011-08
PSK-AES256-CBC-SHA
PSK-3DES-EDE-CBC-SHA
KRB5-DES-CBC3-SHA
KRB5-DES-CBC3-MD5
PSK-AES128-CBC-SHA
PSK-RC4-SHA
KRB5-RC4-SHA
KRB5-RC4-MD5
KRB5-DES-CBC-SHA
KRB5-DES-CBC-MD5
EXP-EDH-RSA-DES-CBC-SHA
EXP-EDH-DSS-DES-CBC-SHA
EXP-ADH-DES-CBC-SHA
EXP-DES-CBC-SHA
EXP-RC2-CBC-MD5
EXP-KRB5-RC2-CBC-SHA
EXP-KRB5-DES-CBC-SHA
EXP-KRB5-RC2-CBC-MD5
EXP-KRB5-DES-CBC-MD5
EXP-ADH-RC4-MD5
EXP-RC4-MD5
EXP-KRB5-RC4-SHA
EXP-KRB5-RC4-MD5
Deprecated SSL Ciphers: カスタムポリシーまたは ELBSample-OpenSSLDefaultCipherPolicy で
以前にこれらの暗号を有効にした場合、セキュリティポリシーを最新バージョンに更新することをお勧
めします。
RSA および DSA 方式の暗号は、SSL 証明書の作成に使用される署名アルゴリズムに固有です。SSL
証明書は、セキュリティポリシーで有効にされた暗号に基づいた署名アルゴリズムを使用して作成して
ください。
HTTPS/SSL リスナーの SSL ネゴシエーション設定を更新する手順の詳細については、「ロードバラ
ンサーの SSL ネゴシエーション設定の更新 (p. 98)」を参照してください。
35
Elastic Load Balancing の SSL 証明
書
Abstract
Elastic Load Balancing の SSL 証明書
フロントエンドリスナーに HTTPS または SSL を使用する場合、ロードバランサーに SSL 証明書をイ
ンストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロードバラ
ンサーは証明書を使用して接続を終了し、クライアントからのリクエストを復号化します。
SSL プロトコルは、X.509 証明書 (SSL サーバー証明書) を使用して、クライアントとバックエンドア
プリケーションの両方を認証します。X.509 証明書は、認証機関 (CA) によって発行された IDENTITY
デジタルフォームで、識別情報、有効期間、パブリックキー、シリアルナンバー、発行者のデジタル
署名が含まれます。
ロードバランサーに SSL 証明書をインストールする前に、証明書を作成し、CA に証明書に署名しても
らってから、AWS Identity and Access Management (IAM) サービスを使用して証明書をアップロード
SSL 証明書には有効期間が記載されています。証明書は、有効期間が終了する前に差し替える必要が
あります。証明書を差し替えるには、新しい証明書を作成し、アップロードする必要があります。
デフォルトでは、IAM によって AWS アカウントごとに 20 のサーバー証明書が有効になります。この
制限の詳細と、増加をリクエストする方法については、『IAM を使用する』の「IAM エンティティに関
する制限事項」を参照してください。
SSL サーバー証明書を作成し、IAM にアップロードして、ロードバランサーにインストールするには、
次のタスクを実行します。
タスク
• 前提条件: 証明書ツールをインストールする (p. 37)
•
•
•
•
サーバー証明書の作成 (p. 37)
署名証明書をアップロードする (p. 38)
サーバー証明書の確認 (p. 41)
ロードバランサーへの SSL 証明書のインストール (p. 41)
• ロードバランサーの SSL 証明書の更新 (p. 41)
36
前提条件: 証明書ツールをインストールする
前提条件: 証明書ツールをインストールする
サーバー証明書の作成には、SSL および TLS プロトコルをサポートするツールが必要です。
Linux
OpenSSL は広範な暗号機能を備えたオープンソースツールです。このツールがインストールされてい
るかどうかを確認するには、openssl version を実行します。OpenSSL がインストールされていな
い場合は、インストールする必要があります。詳細については、Linux ディストリビューションのド
キュメントを参照してください。
Windows
使用できるツールには、IIS Manager、SelfSSL、OpenSSL、Windows PowerShell のコマンドレットな
どがあります。これらのツールのいずれかがまだインストールされていない場合は、ツールを選択して
インストールします。
サーバー証明書の作成
SSL サーバー証明書を作成するには、RSA プライベートキーを生成し、証明書署名リクエスト (CSR)
を作成する必要があります。次に、認証機関 (CA) を利用してサーバー証明書に署名するか、CA が証
明書に署名するのを待機しているときに SSL の実装をテストできるように、自己署名証明書を生成し
ます。使用しているツールの指示に従って操作してください。この例では、OpenSSL での手順を示し
ます。また、IIS Manager での手順に関する参照情報も示します。
OpenSSL を使用してサーバー証明書を作成するには
1.
プライベートキーを作成し、安全な場所に保存します。プライベートキーを紛失した場合、その
キーを取得する方法がないためです。
プライベートキーは標準のキーアルゴリズムを使って作成されます。クライアントからロードバラ
ンサーに対する SSL 接続のネゴシエーションを行うときに使用する予定の暗号に基づいて、アル
ゴリズムを選択します。
RSA 方式の暗号
次の genrsa コマンドを使用します。AWS では、1024 ビット、2048 ビット、4096 ビットの RSA
キーをサポートしています。ただし、2048 ビットを指定することをお勧めします。
openssl genrsa -out my-private-key.pem 2048
ECDHE-ECDSA 方式の暗号
次の ecparam コマンドを使用します。
openssl ecparam -name prime256v1 -out my-private-key.pem -genkey
2.
次の req コマンドを使用して、CSR を作成します。
openssl req -sha256 -new -key my-private-key.pem -out csr.pem
コマンドはインタラクティブで実行され、以下の情報の入力が求められます。
37
署名証明書をアップロードする
国名
2 文字の ISO コード（国名コード）。たとえば、US と指定します。
州名
組織が配置されている州の正式名称。略名は使用しないでください。
都市
組織が配置されている都市。
組織名
組織の正式名称。
部門名
（オプション）製品名や部課名のような追加情報。
共通名
CNAME の完全修飾ドメイン名。この名前は、正確に一致する名前を指定する必要がありま
す。たとえば、www.mycompany.com、mycompany.com、または *.mycompany.com などで
す。
E メールアドレス
サーバー管理者の E メールアドレスです。
3.
CA を利用して証明書に署名することも、テスト目的で使用するための自己署名証明書を生成する
こともできます。
• サーバー証明書に適用するために、CSR を CA に送信します。作成した CSR には、お客様を識
別するための情報が含まれています。CA より追加で他の認証情報や識別の根拠となるような情
報を求められる場合があります。CSR が受理されると、CA からパブリック（アイデンティティ）
証明書が返されます。場合によっては、デジタル署名されたチェーン証明書が返されます。AWS
が特定の CA を推奨することはありません。主な CA の一覧については、Third-Party Certificate
Authorities を参照してください。
• 自己署名証明書を作成するには、次のコマンドを使用します。
openssl x509 -req -days 365 -in csr.pem -signkey my-private-key.pem -out
my-certificate.crt
IIS Manager を使用してサーバー証明書を作成するには
IIS Manager を使用して証明書を作成する方法については、Microsoft TechNet ライブラリの「インター
ネットサーバー証明書を要求する」または「自己署名入りサーバー証明書を作成する」を参照してく
ださい。
通常、認証機関 (CA) は、パブリック証明書、1 つ以上の中間証明書、およびルート証明書を送信しま
す。中間証明書とルート証明書は、1 つのバンドルされたファイルとして届く場合と、個々のファイル
として届く場合があります。ファイル名は、購入する SSL 証明書の種類および認証機関によって異な
る可能性があります。パブリック証明書はドメイン固有ファイルです。
前提条件
• プライベートキーが、SSL 接続のネゴシエーション時に使用する予定の暗号に基づいたアルゴリズ
ムで作成されており、PEM 形式である。
• RSA 方式の暗号用に生成されたプライベートキーを変換するには、次のコマンドを使用します。
38
openssl rsa -in my-private-key -outform PEM
• ECDSA-ECDHE 方式の暗号用に生成されたプライベートキーを変換するには、次のコマンドを使
用します。
openssl ecparam -in my-private-key -outform PEM
• プライベートキーはパスワードで暗号化できません。
• CA からサーバー証明書を受け取ったとき、ファイルは、IAM で必要となる PEM 形式になっていな
い場合があります。PEM 形式の詳細については、「pem DESCRIPTION」を参照してください。
• CA から受け取ったサーバー証明書を変換するには、次のコマンドを使用します。
openssl x509 -inform PEM -in my-public-certificate-file
• 証明書チェーンを変換するには、次のコマンドを使用します。
openssl x509 -inform PEM -in my-certificate-chain-file
•
•
•
•
現在の日付が証明書の開始日と終了日の間にある。
パブリックおよびプライベートの証明書ファイルに、証明書が 1 つだけ含まれている。
プライベートキーが証明書のパブリックキーと一致している。
証明書チェーンには、ルート証明書につながる CA のすべての中間証明書が含まれている必要があ
り、オプションで CA のルート証明書で終了する必要があります。通常、中間証明書とルート証明書
はどちらも、適切な順番に並べられたバンドルファイルとして CA によって提供されます。中間証
明書の順番は、CA によって文書化される必要があります。ルート証明書はオプションですが、これ
を含めることで、SSL Checker のようにチェーン全体にわたる信頼性の検証を実行できます。
証明書バンドルが提供されない、または必要な順番で提供されない場合、「RSA プライベートキー
の例 (p. 40)」で示されているように、中間証明書を使用して独自の証明書チェーンファイルを作成
できます。
サーバー証明書のアップロード
PEM 形式の証明書ファイルが準備できたら、次の upload-server-certificate コマンドを使用してそれら
のファイルをアップロードします。
aws iam upload-server-certificate --server-certificate-name my-server-certificate
--certificate-body file://my-public-key-file.pem --private-key file://my-privatekey-file.pem
--certificate-chain file://my-certificate-chain-file.pem
自己署名証明書をアップロードする場合は、証明書チェーンを指定する必要はありません。
証明書をアップロードすると、IAM は証明書を検証します。エラーが発生した場合は、ファイルが前提
条件を満たしているかどうかを確認してから、再度アップロードします。
IAM によって受け入れられるサーバー証明書、プライベートキー、証明書チェーンの例を次に示しま
す。
サーバー証明書の例
39
サーバー証明書はお客様のパブリックキーおよび ID に関連付けられています。証明機関（CA）に CSR
を送信すると、CA はサーバー証明書を返します。
-----BEGIN CERTIFICATE----MIIE+TCCA+GgAwIBAgIQU306HIX4KsioTW1s2A2krTANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSoAYykwOTEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwHhcNMTAxMDA4
MDAwMDAwWhcNMTMxMDA3MjM1OTU5WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
bSBJbmMuMRowGAYDVQQDFBFpYW0uYW1hem9uYXdzLmNvbTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3Xb0EGea2dB8QGEUwLcEpwvGawEkUdLZmGL1rQJZdeeN
3vaF+ZTm8Qw5Adk2Gr/RwYXtpx04xvQXmNm+9YmksHmCZdruCrW1eN/P9wBfqMMZ
X964CjVov3NrF5AuxU8jgtw0yu//C3hWnOuIVGdg76626ggOoJSaj48R2n0MnVcC
AwEAAaOCAdEwggHNMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMEUGA1UdHwQ+MDww
OqA4oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzItY3JsLnZlcmlzaWduLmNvbS9TVlJT
ZWN1cmVHMi5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBSl7wsRzsBBA6NKZZBIshzgVy19
RzB2BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTBABggrBgEFBQcwAoY0aHR0cDovL1NWUlNlY3VyZS1HMi1haWEudmVy
aXNpZ24uY29tL1NWUlNlY3VyZUcyLmNlcjBuBggrBgEFBQcBDARiMGChXqBcMFow
WDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEF
GDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZI
hvcNAQEFBQADggEBALpFBXeG782QsTtGwEE9zBcVCuKjrsl3dWK1dFiq3OP4y/Bi
ZBYEywBt8zNuYFUE25Ub/zmvmpe7p0G76tmQ8bRp/4qkJoiSesHJvFgJ1mksr3IQ
3gaE1aN2BSUIHxGLn9N4F09hYwwbeEZaCxfgBiLdEIodNwzcvGJ+2LlDWGJOGrNI
NM856xjqhJCPxYzk9buuCl1B4Kzu0CTbexz/iEgYV+DiuTxcfA4uhwMDSe0nynbn
1qiwRk450mCOnqH4ly4P4lXo02t4A/DI1I8ZNct/Qfl69a2Lf6vc9rF7BELT0e5Y
123RVWYBAZW00EXAMPLE456RVWYBAZW00EXAMPLE
-----END CERTIFICATE-----
RSA プライベートキーの例
プライベートキーによって、パブリックキーを使って暗号化されたメッセージを解読することができま
す。
-----BEGIN RSA PRIVATE KEY----MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
-----END RSA PRIVATE KEY-----
証明書チェーンの例
40
サーバー証明書の確認
証明書チェーンによって、エンドユーザーのブラウザは、信頼しているルート証明書への証明書チェー
ンを構築できます。その結果、ブラウザはあなたの証明書を暗黙的に信頼できます。
次の例に示すように、証明書チェーンには中間証明書とオプションでルート証明書を含めます。これら
の証明書は、空白行なしに連続して含めます。ルート証明書を含める場合は、証明書チェーンの先頭は
中間証明書で、末尾がルート証明書である必要があります。CA によって提供された中間証明書を使用
します。信頼パスのチェーン内に存在しない中間証明書は含めないでください。
-----BEGIN CERTIFICATE----Intermediate certificate 2
-----END CERTIFICATE---------BEGIN CERTIFICATE----Intermediate certificate 1
-----END CERTIFICATE---------BEGIN CERTIFICATE----Optional: Root certificate
-----END CERTIFICATE-----
サーバー証明書の確認
サーバー証明書のアップロードが完了すると、IAM に保存されている情報の検証を行うことができま
す。それぞれの証明書オブジェクトは、一意の Amazon Resource Name（ARN）および ID を持ってい
ます。
証明書オブジェクトの検証には、次の get-server-certificate コマンドを使用します。
aws iam get-server-certificate --server-certificate-name my-server-certificate
以下に、応答の例を示します。最初の行はサーバー証明書の ARN で、2 行目は ID です。
arn:aws:iam::55555555555:server-certificate/production/my-server-certificate
ASCACexampleKEZUQ4K
ロードバランサーへの SSL 証明書のインストール
SSL 証明書をインストールするには、「リスナーの設定 (p. 47)」を参照してください。
SSL 証明書を更新するには、「ロードバランサーの SSL 証明書の更新 (p. 41)」を参照してください。
ロードバランサーの SSL 証明書の更新
Abstract
このユーザーシナリオでは、ロードバランサーにインストールされた SSL サーバー証明書を更新します。
リスナーに HTTPS/SSL プロトコルを使用している場合は、ロードバランサーに SSL サーバー証明書
がインストールされている可能性があります。SSL 証明書には有効期間が記載されています。証明書
は、有効期間が終了する前に差し替える必要があります。証明書を差し替えるには、初めて証明書を作
成したときと同じステップで、最初に新しい証明書を作成する必要があります。新しい SSL 証明書を
作成する方法については、「Elastic Load Balancing の SSL 証明書 (p. 36)」を参照してください。
41
コンソールを使用した SSL 証明書の更新
AWS Identity and Access Management（IAM）サービスは SSL 証明書を管理します。デフォルトでは、
IAM によって AWS アカウントごとに 20 のサーバー証明書が有効になります。この制限の詳細と、増
加をリクエストする方法については、『IAM を使用する』の「IAM エンティティに関する制限事項」を
参照してください。
SSL 証明書をロードバランサーにインストールする前に、証明書を IAM にアップロードする必要があ
ります。そのためには、Amazon EC2 コンソールの Elastic Load Balancing ウィザード、
upload-server-certificate AWS CLI コマンド、または UploadServerCertificate IAM アクションを使用で
きます。
次の例は、SSL 証明書を更新する方法を示しています。
例
• コンソールを使用した SSL 証明書の更新 (p. 42)
• AWS CLI を使用した SSL 証明書の更新 (p. 43)
コンソールを使用した SSL 証明書の更新
HTTPS ロードバランサーの SSL 証明書を更新するには
1.
2.
3.
4.
5.
6.
7.
下部のペインで、[Listeners] タブを選択します。
[Listeners] ペインで、更新する証明書の [SSL Certificate] 列の [Change] をクリックします。
IAM を使用して SSL 証明書をアップロード済みの場合は、[Select Certificate] ページで [Choose
from an existing SSL Certificates] を選択します。[Certificate Name:] ダイアログボックスをクリッ
クし、証明書を選択します。[Save] をクリックします。
または、SSL 証明書があり、これをアップロードする場合は、[Upload a new SSL Certificate] を選
択します。
アップロードする前に、「署名証明書をアップロードする (p. 38)」に記述されている条件を証明
書が満たしていることを確認してください。
証明書がこの手順に挙げた基準を満たさない場合、アップロード時にエラーが発生する場合があり
ます。新しい SSL 証明書を作成し、AWS Identity and Access Management（IAM）を使用して証
明書をアップロードします。SSL 証明書の作成とアップロードの手順については、「Elastic Load
Balancing の SSL 証明書 (p. 36)」を参照してください。
以下の指示に従い、SSL 証明書のアップロードを続行します。
a.
b.
アップロードする証明書の名前を入力します。
PEM エンコードされたプライベートキーファイルの内容をコピーして [Private Key] ボックス
に貼り付けます。
Note
プライベートキーは、アップロードが完了した後に取得することはできません。
c.
d.
PEM エンコードされたパブリックキー証明書ファイルの内容をコピーして [Public Key
Certificate] ボックスに貼り付けます。
自己署名証明書を使用していて、ブラウザが暗黙的に証明書を受け入れることが重要でない場
合は、このステップをスキップできます。
42
AWS CLI を使用した SSL 証明書の更新
自己署名証明書を使用していない場合は、PEM エンコードされたパブリックキー証明書チェー
ンファイルの内容をコピーして [Certificate Chain] ボックスに貼り付けます。
Note
証明書チェーンの順序は、ルート証明書がチェーンの末尾に来るようにします。証明
書チェーンの順序が異なると、エラーが返されます。
8.
[Save] をクリックします。
AWS CLI を使用した SSL 証明書の更新
HTTPS ロードバランサーの SSL 証明書を更新するには
1.
SSL 証明書があり、IAM を使用してアップロードした場合は、get-server-certificate コマンドを使
用して、証明書の ARN を取得します。
SSL 証明書はあるが、アップロードしていない場合は、「署名証明書をアップロードする (p. 38)」
で説明されている手順を実行します。証明書の ARN を書き留めておきます。
2.
次の set-load-balancer-listener-ssl-certificate コマンドを使用します。
aws elb set-load-balancer-listener-ssl-certificate --load-balancer-name myloadbalancer --load-balancer-port 443 --ssl-certificate-id
arn:aws:iam::012345678901:server-certificate/production/newCert
43
EC2-Classic のロードバランサー
Abstract
ロードバランサーを使用すると、EC2-Classic で起動した EC2 インスタンスへのトラフィックを監視し、ルーティ
ングすることもできます。
アマゾンウェブサービス（AWS）では、EC2-Classic または Virtual Private Cloud（VPC）のいずれか
でインスタンスを起動できます。EC2-Classic で起動された EC2 インスタンスを負荷分散する場合、
EC2-Classic でロードバランサーを作成する必要があります。
このセクションでは、EC2-Classic のインスタンスおよびロードバランサーに固有の情報を示します。
VPC のインスタンスおよびロードバランサーの詳細については、「VPC のロードバランサー (p. 76)」
ロードバランサーの使用を開始する前に、ロードバランサーを作成する必要があります。リスナーを設
定し、ヘルスチェックを設定することでロードバランサーを作成し、バックエンドインスタンスをその
ロードバランサーに登録します。リスナーは、フロントエンド（クライアントからロードバランサー）
およびバックエンド（ロードバランサーからバックエンドインスタンス）接続用のプロトコルとポート
番号を指定して、設定します。ロードバランサーに対して複数のリスナーを設定できます。Elastic Load
Balancing でサポートされるリスナー設定の詳細については、「Elastic Load Balancing のリスナー設
定 (p. 24)」を参照してください。
ロードバランサーを作成すると、デフォルトでは、ロードバランサーはフロントエンド接続とバックエ
ンド接続にポート 80 で HTTP プロトコルを使用するよう設定されています。
Elastic Load Balancing には、クライアントとロードバランサーとの間の接続をネゴシエーションする
セキュリティポリシーと呼ばれる Secure Sockets Layer（SSL）のネゴシエーション設定が用意されて
います。フロントエンド接続に HTTPS/SSL を選択した場合は、定義済みのセキュリティポリシーを使
用することも、カスタムセキュリティポリシーを使用することもできます。フロントエンド接続に
HTTPS または SSL を使用するときは、ロードバランサーに SSL 証明書をインストールする必要があ
ります。バックエンドインスタンスにリクエストを送信する前に、ロードバランサーは証明書を使用し
て接続を終了し、クライアントからのリクエストを復号化します。オプションとしてバックエンドイン
スタンスで認証を有効にすることもできます。HTTPS/SSL ロードバランサーを作成する詳しい手順に
ついては、「HTTPS/SSL ロードバランサーの作成 (p. 46)」を参照してください。
Elastic Load Balancing の特別なソースセキュリティグループを使用して、バックエンド EC2 インスタ
ンスが Elastic Load Balancing からのみトラフィックを受け取るように設定することができます。ロー
ドバランサーとバックエンドインスタンス間の着信トラフィックをロックする方法については、
「EC2-Classic でのロードバランサーのセキュリティグループ (p. 68)」を参照してください。
44
ロードバランサーを作成すると、Elastic Load Balancing は、ロードバランサーの名前とリージョンを
組み合わせたパブリック DNS 名を返します。この基本パブリック DNS 名は IPv4 レコードのみを返し
ます。
Elastic Load Balancing はインターネットプロトコルバージョン 6（IPv6）とインターネットプロトコ
ルバージョン4（IPv4）の両方をサポートしています。
Note
IPv6 サポートは、現在、Amazon VPC（EC2-VPC）のロードバランサーでは使用できません。
クライアントは、ロードバランサーへの接続に IPv4 と IPv6のどちらでも使用できます（EC2-Classic
の場合）。しかし、ロードバランサーとバックエンドインスタンス間の通信には、IPv4 しか使用でき
ません。「dualstack」というプレフィックスの付いた DNS 名を使用すると、クライアントが個々の接
続要件に応じて IPv4 または IPv6 のいずれかを使ってロードバランサーにアクセスできるよう、クライ
アントとロードバランサーとの通信で IPv6 サポートを有効にすることができます。IPv6 サポートの有
効化については、「Elastic Load Balancing での IPv6 の使用 (p. 74)を参照してください。
45
HTTPS/SSL ロードバランサーの作成
HTTPS/SSL ロードバランサーの作成
Abstract
SSL 暗号設定およびバックエンドサーバー認証を使用して HTTPS ロードバランサーを作成する方法について説明
します。
SSL ネゴシエーション設定とバックエンドアプリケーションインスタンス認証を使用して、HTTPS
ロードバランサーを作成できます。
目次
• 前提条件 (p. 46)
• コンソールを使用した HTTPS/SSL ロードバランサーの作成 (p. 46)
• AWS CLI を使用した HTTPS/SSL ロードバランサーの作成 (p. 53)
前提条件
始める前に、以下の前提条件を満たしていることを確認してください。
• アベイラビリティーゾーン内のロードバランサーに登録する EC2 インスタンスを起動します。この
アベイラビリティーゾーンは、ロードバランサー用に使用することを予定しているアベイラビリティー
ゾーンです。これらのインスタンスは、インターネットからリクエストを受信するように設定する必
要があります。
• EC2 インスタンスは、ヘルスチェックの対象に対して、HTTP ステータスコード 200 で応答する必
要があります。詳細については、「ヘルスチェック (p. 9)」を参照してください。
• EC2 インスタンスでキープアライブのオプションを有効にする場合は、キープアライブの設定値を
ロードバランサーのアイドルタイムアウトの設定値以上に設定をすることをお勧めします。ロードバ
ランサーがバックエンドインスタンスへの接続を確実に閉じるようにする場合は、キープアライブ時
間のインスタンスに設定された値が、ロードバランサーのアイドルタイムアウトの設定値より大きい
ことを確認します。詳細については、「アイドル接続のタイムアウト (p. 11)」を参照してください。
• リスナーの HTTPS サポートを有効にするには、SSL 証明書を作成して、それをロードバランサーに
インストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロード
バランサーは証明書を使用してリクエストを終了し、次にリクエストを復号化します。詳細について
は、「Elastic Load Balancing の SSL 証明書 (p. 36)」を参照してください。
コンソールを使用した HTTPS/SSL ロードバランサー
の作成
Abstract
AWS マネジメントコンソールを使い、SSL 暗号設定およびバックエンドサーバー認証を使用して HTTPS ロード
バランサーを作成する方法について説明します。
HTTPS/SSL ロードバランサーを作成するには、次のタスクを実行します。
タスク
• ステップ 1: リスナーの設定 (p. 47)
• ステップ 2: SSL セキュリティポリシーの設定 (p. 48)
• ステップ 3: バックエンドサーバー認証の設定 (p. 49)
• ステップ 4: ヘルスチェックの設定 (p. 49)
• ステップ 5: EC2 インスタンスの登録 (p. 50)
46
コンソールを使用した HTTPS/SSL ロードバランサーの作
成
• ステップ 6: タグの追加（オプション） (p. 51)
• ステップ 7: ロードバランサーの検証 (p. 52)
• ステップ 8: ロードバランサーの削除（オプション） (p. 53)
ステップ 1: リスナーの設定
リスナーとはクライアント接続リクエストをリッスンするプロセスです。リスナーは、フロントエンド
（クライアントからロードバランサー）およびバックエンド（ロードバランサーからバックエンドイン
スタンス）接続用のプロトコルとポート番号を使用して設定します。Elastic Load Balancing でサポー
トされるポート、プロトコル、およびリスナー設定については、「Elastic Load Balancing のリスナー
設定 (p. 24)」を参照してください。
この例では、フロントエンド接続（クライアントからロードバランサー）とバックエンド接続（ロード
バランサーからバックエンドインスタンス）に使用するポートとプロトコルを指定して、ロードバラン
サーに 2 つのリスナーを設定します。最初のリスナーはポート 80 で HTTP リクエストを受け取り、
HTTP を使用してポート 80 のバックエンドアプリケーションインスタンスにリクエストを送信します。
2 つ目のリスナーはポート 443 で HTTPS リクエストを受け取り、HTTPS を使用してポート 443 の
バックエンドアプリケーションインスタンスにリクエストを送信します。
2 番目のリスナーがフロントエンド接続に HTTPS を使用するため、SSL サーバー証明書をロードバラ
ンサーにインストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、
ロードバランサーは証明書を使用してリクエストを終了し、次にリクエストを復号化します。SSL 証
明書をロードバランサーにインストールする前に、証明書を作成し、認証機関 (CA) による署名を証明
書に適用してから、証明書をアップロードする必要があります。SSL 証明書の作成とアップロードの
詳細については、「Elastic Load Balancing の SSL 証明書 (p. 36)」を参照してください。
1.
2.
3.
4.
a.
[Load Balancer name] に、ロードバランサーの名前を入力します。
b.
[Create LB Inside] で [EC2-Classic] を選択します。
c.
最初のリスナーについては、[Listener Configuration] はデフォルト値のままにしておきます。
d.
別のリスナーを追加するには、[Add] をクリックします。[Load Balancer Protocol] 列で、[HTTPS
(Secure HTTP)] を選択します。これにより、[Load Balancer Port]、[Instance Protocol]、お
よび [Instance Port] の各列が更新されます。[Instance Protocol] 列で、[HTTPS (Secure HTTP)]
を選択します。これにより、[Instance Port] 列が更新されます。
[Continue] をクリックします。
e.
47
成
5.
[Select Certificate] ページで、次のいずれかを実行します。
•
•
6.
SSL 証明書がアップロードされている場合は、[Choose from an existing SSL Certificate] を選
択します。[Certificate Name] で証明書を選択します。
署名済みの証明書をアップロードする準備ができている場合は、[Upload a new SSL Certificate]
を選択します。証明書の名前を入力します。[Private Key] に、PEM エンコードされたプライ
ベートキーファイルの内容をコピーして貼り付けます。[Public Key Certificate] に、PEM エン
コードされたパブリックキー証明書ファイルの内容をコピーして貼り付けます。自己署名証明
書を使用しておらず、ブラウザが暗黙的に証明書を受け入れることが重要である場合に限り、
[Certificate Chain] に、PEM エンコードされた証明書チェーンファイルの内容をコピーして貼
り付けます。
ステップ 2: SSL セキュリティポリシーの設定
Elastic Load Balancing には、事前定義された SSL ネゴシエーション設定を持つセキュリティポリシー
が用意されています。事前定義されたセキュリティポリシーのいずれかを選択するか、独自のカスタム
セキュリティポリシーを作成できます。
セキュリティポリシーの詳細については、「Elastic Load Balancing の SSL ネゴシエーション設
48
成
SSL セキュリティポリシーを設定するには
1.
Elastic Load Balancing では、HTTPS/SSL リスナーに対して、デフォルトで最新のセキュリティポ
リシー ELBSecurityPolicy-2015-03 が選択されています。これが推奨される設定です。このポリ
シーでは、SSL 接続のネゴシエーションにサーバーの優先順位（「事前定義された SSL セキュリ
ティポリシー (p. 32)」を参照）を使用します。
[Select a Cipher] ページで、次のいずれかを実行します。
•
（推奨)）[Predefined Security Policy] が選択されており、[ELBSecurityPolicy-2015-03] に設定
されていることを確認します。
•
[Predefined Security Policy] をクリックし、ポリシーを選択します。
•
[Custom Security Policy] をクリックし、プロトコルと暗号を少なくとも 1 つずつ有効にしま
す。[SSL Protocols] で、有効または無効にするプロトコルを 1 つ以上選択します。SSL ネゴ
シエーションにサーバーの優先順位を使用する場合に限り、[SSL Options] の [Server Order
Preference] は選択したままにしておきます。[SSL Ciphers] で、有効または無効にする暗号を
1 つ以上選択します。
Tip
DSA および RSA の暗号は署名アルゴリズムに固有の暗号です。SSL 証明書がすでに
ある場合は、証明書を作成するときに使用した暗号を有効にする必要があります。
2.
ステップ 3: バックエンドサーバー認証の設定
バックエンド接続に HTTPS/SSL を使用する場合は、バックエンドインスタンスで認証を有効にするこ
ともできます。この認証は、バックエンドインスタンスが暗号化された通信のみを受け入れ、バックエ
ンドインスタンスに適切な証明書が使用されていることを確認するために使うことができます。
バックエンド認証を使用せずに続行する場合は、このステップを省略できます。
バックエンドサーバー認証を設定するには
1.
2.
3.
[Enable back-end authentication] を選択します。
[Certificate Name] にパブリックキー証明書の名前を入力します。
[Certificate Body (pem encoded)] に証明書の内容をコピーして貼り付けます。
4.
5.
（オプション）他の証明書を追加するには、[Add another backend certificate] をクリックします。
ステップ 4: ヘルスチェックの設定
Elastic Load Balancing は、指定した設定に基づいて、登録されたそれぞれの EC2 インスタンスのヘル
スチェックを定期的に行います。Elastic Load Balancing で unhealthy インスタンスが検出されると、
そのインスタンスへのトラフィックの送信が停止され、トラフィックのルーティングが healthy インス
タンスに変更されます。ヘルスチェックの設定の詳細については、「ヘルスチェック (p. 9)」を参照
ヘルスチェックを設定するには
1.
[Configure Health Check] ページで、アプリケーションに必要なヘルスチェック設定を行います。
49
成
Elastic Load Balancing は、指定した ping ポートと ping パスにヘルスチェッククエリを送信しま
す。EC2 インスタンスが、ここで指定した ping ポートでトラフィックを受け付けることを確認し
てください。
この例では、ping パスフィールドに 1 つのスラッシュを使用して、Elastic Load Balancing から
ウェブサーバーのデフォルトホームページにリクエストが送信されるようにしています。デフォル
トページの名前は、index.html、default.html、または他の名前でもかまいません。
2.
3.
[Continue] をクリックして、Amazon EC2 インスタンスの登録に進みます。
EC2 インスタンスを登録する手順については、「ステップ 5: EC2 インスタンスの登録 (p. 50)」を
ステップ 5: EC2 インスタンスの登録
ロードバランサーを作成したら、そのロードバランサーに EC2 インスタンスを登録する必要がありま
ことができます。ロードバランサーに登録する EC2 インスタンスの設定の詳細については、「EC2 イ
ンスタンスの負荷分散の設定 (p. 8)」を参照してください。
コンソールを使用して EC2 インスタンスを登録する場合、クロスゾーン負荷分散とConnection Draining
のオプションは、デフォルトで有効になります。いずれかまたは両方のオプションをロードバランサー
に対して指定したくない場合は、無効にできます。CLI または API を使用してインスタンスを登録する
場合、これらのオプションのいずれかまたは両方を有効にするには、明示的に有効にする必要がありま
す。
クロスゾーン負荷分散をロードバランサーに対して有効にした場合、Elastic Load Balancing は、登録
されているすべての EC2 インスタンス間にトラフィックを均等にルーティングします。Connection
Drainingをロードバランサーに対して有効にした場合、ロードバランサーは、インスタンスの登録解除
中に、インスタンス宛の実行中のすべてのリクエストを完了させます。クロスゾーン負荷分散の詳細に
ついては、「リクエストルーティング (p. 7)」を参照してください。Connection Draining の詳細につ
いては、「Connection Draining (p. 11)」を参照してください。
Amazon EC2 インスタンスを追加するには
1.
[Add EC2 Instances] ページにある [Add Instances to Load Balancer] の表で、[Instance] 列のボッ
クスを選択して、ロードバランサーにインスタンスを登録します。
50
成
2.
3.
デフォルト設定を変更するには、[Enable Cross-Zone Load Balancing] ボックスをクリックします。
デフォルト設定を変更するには、[Enable Connection Draining] ボックスをクリックします。
4.
5.
タグを追加するには、[Continue] をクリックします。
タグを追加する手順については、「ステップ 6: タグの追加（オプション） (p. 51)」を参照してく
ださい。
ステップ 6: タグの追加（オプション）
必要に応じてロードバランサーのタグを設定できます。タグを使用すると、ロードバランサーを目的、
所有者、環境などさまざまな方法で分類することができます。
タグを追加するには
現時点でロードバランサーにタグを割り当てない場合は、[Continue] をクリックしてこのステップをス
キップし、ステップ 4 に進みます。
1.
2.
[Add Tags] ページで、タグのキーと値を指定します。
複数のタグを追加するには、[Create Tag] をクリックし、各タグのキーと値を指定し続けます。
51
成
3.
4.
5.
6.
終了したら、[Continue] をクリックしてロードバランサーの詳細を確認します。
[Review] ページで設定を確認します。各設定の編集リンクをクリックして、設定を変更できます。
ロードバランサーの設定を確認したら、[Create] をクリックしてロードバランサーを作成します。
[Create Load Balancer] ウィザードに、新しく作成したロードバランサーのステータスが表示され
ます。ロードバランサーが適切に作成されたことを確認したら、[Close] をクリックします。
ロードバランサーが起動されることを確認するには、「ステップ 7: ロードバランサーの検証 (p. 52)」
ステップ 7: ロードバランサーの検証
新しく作成したロードバランサーが、ロードバランサーページに表示されます。
ロードバランサーの詳細を確認するには
1.
下のペインには、ロードバランサーの詳細が表示されます。詳細が仕様と一致することを確認しま
す。
一部のインスタンスが実行されていないことが [Status] 行の詳細に示されている場合、インスタン
スはまだ登録中であると考えられます。詳細については、Elastic Load Balancing のトラブルシュー
ティング: インスタンスの登録 (p. 182)を参照してください。
2.
少なくとも 1 つの EC2 インスタンスが InService であることが確認されたら、ロードバランサー
をテストすることができます。ロードバランサーをテストするには、[Description] タブに表示され
た [DNS Name] の値をコピーし、インターネット接続したウェブブラウザのアドレスフィールド
に貼り付けます。ロードバランサーが実行中の場合は、HTTP サーバーのデフォルトページが表示
されます。
52
AWS CLI を使用した HTTPS/SSL ロードバランサーの作成
ステップ 8: ロードバランサーの削除（オプション）
ロードバランサーが利用可能になると、ロードバランサーの実行時間に応じて 1 時間ごと、または 1
時間未満の時間について課金されます。不要になったロードバランサーは削除できます。ロードバラン
サーが削除されると、ロードバランサーの課金も停止されます。
ロードバランサーを削除するには
1.
2.
3.
4.
5.
[Actions] をクリックし、[Actions] ドロップダウンボックスで [Delete] をクリックします。
確認を求めるメッセージが表示されたら、[Yes, Delete] をクリックします。
6.
（オプション）ロードバランサーを削除しても、そのロードバランサーに関連付けられた EC2 イ
ンスタンスは実行し続けます。また、それらのインスタンスの実行時間に応じて 1 時間ごと、また
は 1 時間未満の時間について課金されます。インスタンスの停止や終了の詳細については、『Linux
インスタンス用 Amazon EC2 ユーザーガイド』の「インスタンスの停止と起動」または「インス
タンスの終了」を参照してください。
AWS CLI を使用した HTTPS/SSL ロードバランサー
の作成
Abstract
AWS CLI を使い、SSL 暗号設定およびバックエンドサーバー認証を使用して HTTPS ロードバランサーを作成す
る方法について説明します。
以下のステップバイステップの手順は、AWS コマンドラインインターフェイス（AWS CLI）を使用し
た HTTPS/SSL ロードバランサーの作成に役立ちます。
タスク
• ステップ 1: リスナーの設定 (p. 53)
• ステップ 2: SSL セキュリティポリシーの設定 (p. 54)
• ステップ 3: バックエンドサーバー認証の設定 (p. 60)
•
•
•
•
ステップ 4: ヘルスチェックの設定 (p. 62)
ステップ 5: EC2 インスタンスの登録 (p. 62)
ステップ 6: インスタンスの確認 (p. 63)
ステップ 7: ロードバランサーの削除（オプション） (p. 64)
ステップ 1: リスナーの設定
リスナーとはクライアント接続リクエストをリッスンするプロセスです。リスナーは、フロントエンド
（クライアントからロードバランサー）およびバックエンド（ロードバランサーからバックエンドイン
スタンス）接続用のプロトコルとポート番号を使用して設定します。Elastic Load Balancing でサポー
トされるポート、プロトコル、およびリスナー設定については、「Elastic Load Balancing のリスナー
設定 (p. 24)」を参照してください。
この例では、フロントエンド接続（クライアントからロードバランサー）とバックエンド接続（ロード
バランサーからバックエンドインスタンス）に使用するポートとプロトコルを指定して、ロードバラン
サーに 2 つのリスナーを設定します。最初のリスナーはポート 80 で HTTP リクエストを受け取り、
HTTP を使用してポート 80 のバックエンドアプリケーションインスタンスにリクエストを送信します。
53
2 つ目のリスナーはポート 443 で HTTPS リクエストを受け取り、HTTPS を使用してポート 443 の
バックエンドアプリケーションインスタンスにリクエストを送信します。
2 番目のリスナーがフロントエンド接続に HTTPS を使用するため、ロードバランサーに SSL サーバー
証明書をインストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、
ロードバランサーは証明書を使用してリクエストを終了し、次にリクエストを復号化します。ロードバ
ランサーに SSL 証明書をインストールする前に、証明書を作成し、認証機関（CA）に証明書に署名し
てもらってから、AWS Identity and Access Management (AWS IAM) サービスを使用して証明書をアッ
プロードする必要があります。SSL 証明書の作成とアップロードに関する詳細は、「Elastic Load
Balancing の SSL 証明書 (p. 36)」を参照してください。
1.
2.
SSL 証明書があり、IAM を使用してアップロードした場合は、get-server-certificate コマンドを使
用して、証明書の ARN を取得します。
SSL サーバー証明書の作成とアップロードをまだ実行していない場合は、「Elastic Load Balancing
の SSL 証明書 (p. 36)」で説明されている手順を実行します。証明書の ARN を書き留めておきま
す。
次の create-load-balancer コマンドを使用して、リスナーを設定します。
aws elb create-load-balancer --load-balancer-name my-loadbalancer --listeners
"Protocol=http,LoadBalancerPort=80,InstanceProtocol=http,InstancePort=80"
"Protocol=https,LoadBalancerPort=443,InstanceProtocol=https,InstancePort=443,
SSLCertificateId=arn:aws:iam::55555555555:server-certificate/produc
tion/myservercert" --availability-zones us-east-1a
以下に、応答の例を示します。
{
"DNSName": "my-loadbalancer-012345678.us-east-1a.elb.amazonaws.com"
}
3.
DNS 名を安全な場所に保存します。この DNS 名は、ロードバランサーに接続するために必要で
す。
ステップ 2: SSL セキュリティポリシーの設定
Elastic Load Balancing には、ロードバランサーで使用できる、事前定義された SSL ネゴシエーション
設定を持つセキュリティポリシーが用意されています。事前定義されたセキュリティポリシーの 1 つを
選択するか、SSL プロトコルと暗号化を指定し、オプションでサーバーの優先順位を有効化して独自
のカスタムセキュリティポリシーを作成できます。セキュリティポリシーの詳細については、「Elastic
Load Balancing の SSL ネゴシエーション設定 (p. 30)」を参照してください。
Note
ロードバランサーを作成するときに、デフォルトでは、Elastic Load Balancing は事前定義され
たセキュリティポリシーの最新バージョンをロードバランサーに関連付けます。SSL 接続のネ
ゴシエーションのために Elastic Load Balancing によって提供されるデフォルトの設定を使用
することをお勧めします。
54
新しく作成したロードバランサーに事前定義されたセキュリティポリシーが関連付けられてい
ることを確認するには
•
次のオプションを指定して describe-load-balancers コマンドを入力します。
• load-balancer-name = my-test-loadbalancer
コマンドは、次の例のようになります。
aws elb describe-load-balancers --load-balancer-name my-test-loadbalancer
Elastic Load Balancing が次の例のように応答します。
{
"LoadBalancerDescriptions": [
{
"Subnets": [],
"CanonicalHostedZoneNameID": "Z3DZXE0Q79N41H",
"CanonicalHostedZoneName": "my-test-loadbalancer-012345678.useast-1.elb.amazonaws.com",
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::55555555555:servercertificate/production/myservercert",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"ELBSecurityPolicy-2015-03"
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "HTTP",
"InstanceProtocol": "HTTP"
},
"PolicyNames": []
}
],
"HealthCheck": {
"HealthyThreshold": 10,
"Interval": 30,
"Target": "HTTP:80/",
"Timeout": 5,
"UnhealthyThreshold": 2
},
"BackendServerDescriptions": [],
"Instances": [],
"DNSName": "my-test-loadbalancer-012345678.us-east1.elb.amazonaws.com",
"SecurityGroups": [],
55
"Policies": {
"LBCookieStickinessPolicies": [],
"AppCookieStickinessPolicies": [],
"OtherPolicies": [
]
},
"LoadBalancerName": "my-test-loadbalancer",
"CreatedTime": "2014-10-19T03:24:02.650Z",
"AvailabilityZones": [
"us-east-1a"
],
"Scheme": "internet-facing",
"SourceSecurityGroup": {
"OwnerAlias": "amazon-elb",
"GroupName": "amazon-elb-sg"
}
}
]
}
ロードバランサーポート 443 に対して ELBSecurityPolicy-2015-03 が有効になっていることがわ
かります。これは Elastic Load Balancing によって提供される、事前定義されたセキュリティのポリ
シーの最新バージョンです。ロードバランサーに関連付けられた事前定義されたセキュリティポリシー
およびその他のすべてのセキュリティポリシーの現在の設定については、「事前定義された SSL セキュ
リティポリシー (p. 32)」を参照してください。
このセクションでは、デフォルト設定を変更し、新しく作成したロードバランサーを他の事前定義され
たセキュリティポリシーまたはカスタムセキュリティポリシーに関連付けるプロセスについて順を追っ
て説明します。
ロードバランサーを事前定義されたセキュリティポリシーの最新バージョンに関連付ける場合は、この
ステップをスキップします。
以下のステップでは、ロードバランサーの SSL セキュリティポリシーを設定する方法を示しています。
1. Elastic Load Balancing によって提供される事前定義されたセキュリティポリシーのリストを取得し
ます。
2. リストされたセキュリティポリシーの 1 つを指定するか、SSL プロトコル、暗号、およびオプショ
ンを指定してカスタムセキュリティポリシーを作成することで、SSL ネゴシエーションのポリシー
を作成します。
3. ポリシーが作成されたことを確認します。
4. ロードバランサーのポートにポリシーを設定して、ポリシーを有効にします。
5. ロードバランサーのポートにポリシーが設定されたことを確認します。
この例では、ELBSecurityPolicy-2015-03 を使用する SSLNegotiationPolicyType ポリシーを作成するプ
ロセスについて順を追って説明します。
この例には、カスタムセキュリティポリシーの作成手順も含まれます。カスタムセキュリティポリシー
を作成する場合は、ステップ 1 をスキップできます。
1.
次の例のように、describe-load-balancer-policies コマンドを入力し、Elastic Load Balancing によっ
て提供されるすべてのセキュリティポリシーを表示します。
56
aws elb describe-load-balancer-policies
応答には、Elastic Load Balancing によって提供されるすべてのセキュリティポリシーの名前が含
まれます。セキュリティポリシーのタイプはすべて SSLNegotiationPolicyType で、SSL/HTTPS リ
スナーに使用されます。
2.
ELBSecurityPolicy-2015-03 ポリシーでは、SSL 接続のネゴシエーションにサーバーの優先順位を
使用します。表示されたすべてのセキュリティポリシーの現在の設定については、「事前定義され
た SSL セキュリティポリシー (p. 32)」を参照してください。
次のオプションを使用して create-load-balancer-policy コマンドを入力し、事前定義されたセキュ
リティポリシー ELBSecurityPolicy-2015-03 またはカスタムセキュリティポリシーを使用する SSL
ネゴシエーションのポリシーを作成します。
この例では、ロードバランサー my-test-loadbalancer 用に SSLNegotiationPolicyType タイプの
MySSLNegotiationPolicy を作成します。
セキュリティポリシー ELBSecurityPolicy-2015-03 を使用する SSL ネゴシエーションのポリシー
を作成するには、次のオプションを使用します。
• policy-name = MySSLNegotiationPolicy
• policy-type-name = SSLNegotiationPolicyType
• policy-attributes
• AttributeName = Reference-Security-Policy
• AttributeValue = ELBSecurityPolicy-2015-03
aws elb create-load-balancer-policy --load-balancer-name my-test-loadbalancer
--policy-name MySSLNegotiationPolicy --policy-type-name SSLNegotiation
Policy
Type --policy-attributes AttributeName=Reference-Security-Policy,Attribute
Value=
ELBSecurityPolicy-2015-03
また、要件を満たすプロトコルと暗号を有効にすることでカスタムセキュリティポリシーを作成す
るには、次のオプションを使用します。
Note
最低 1 つのプロトコルと 1 つの暗号を有効にしなければなりません。必要な作業は、有効
にする属性を true に設定するだけです。
DSA および RSA の暗号は署名アルゴリズムに固有であり、SSL 証明書を作成するために
使用されます。すでに SSL 証明書がある場合は、証明書を作成するときに使用された暗号
を有効にします。
カスタムポリシー名には、ELBSecurityPolicy- または ELBSample- プレフィックスを
含めることはできません。これらのプレフィックスは、Elastic Load Balancing が事前定義
したセキュリティポリシー名に使用されます。Elastic Load Balancing がカスタムセキュリ
ティポリシー名でこれらのプレフィックスの 1 つを読み取ると、エラーをスローします。
• attributes
57
• AttributeName = ProtocolTLSv1.2
• AttributeValue = true
• AttributeName = DHE-RSA-AES256-SHA256
• [オプション] AttributeName = Server-Defined-Cipher-Order
• [オプション] AttributeValue = true
Note
SSL ネゴシエーションにサーバーの優先順序（事前定義された SSL セキュリティポ
リシー (p. 32)のリストの順番）を使用する場合は、Server-Defined-Cipher-Order
--policy-name MySSLNegotiationPolicy --policy-type-name SSLNegotiationPoli
cyType
--policy-attributes AttributeName=Protocol-TLSv1.2,AttributeValue=true
AttributeName=Protocol-TLSv1.1,AttributeValue=true AttributeName=DHE-RSAAES256-SH
A256,AttributeValue=true AttributeName=Server-Defined-Cipher-Order,Attrib
uteValue=true
3.
次のオプションを指定して describe-load-balancer-policies コマンドを入力し、ポリシーが作成さ
れたことを確認します。
• --policy-names = MySSLNegotiationPolicy
aws elb describe-load-balancer-policies --load-balancer-name my-test-load
balancer --policy-name MySSLNegotiationPolicy
応答には、MySSLNegotiationPolicy の説明が含まれます。
4.
新しく作成したポリシーをロードバランサーのポート 443 で有効にするには、次のオプションを
指定して、set-load-balancer-policies-of-listener コマンドを入力します。
• load-balancer-port = 443
• policy-names = MySSLNegotiationPolicy
58
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-testloadbalancer --load-balancer-port 443 --policy-names MySSLNegotiationPolicy
5.
新しいポリシーがロードバランサーポートに対して有効になっていることを確認するには、次のオ
プションを指定して、describe-load-balancers コマンドを入力します。
{
{
"Subnets": [],
"CanonicalHostedZoneName": "my-test-loadbalancer-34503258.useast-1a.elb.amazonaws.com",
{
"Listener": {
"SSLCertificateId": "arn:aws:iam::55555555555:servercertificate/myservercert",
},
"PolicyNames": [
"MySSLNegotiationPolicy"
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "HTTP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
"DNSName": "my-test-loadbalancer-012345678.us-east-
59
1.elb.amazonaws.com",
"Policies": {
"OtherPolicies": [
"ELBSecurityPolicy-2015-03",
]
},
"CreatedTime": "2014-03-19T03:24:02.650Z",
"us-east-1a"
],
}
}
]
}
6.
ロードバランサーポート 443 に対して MySSLNegotiationPolicy が有効になっていることがわ
かります。
バックエンドサーバー認証の設定手順については、「ステップ 3: バックエンドサーバー認証の設
ステップ 3: バックエンドサーバー認証の設定
バックエンド接続に HTTPS/SSL を使用する場合は、バックエンドインスタンスで認証を有効化するこ
ともできます。この認証は、バックエンドインスタンスが暗号化された通信のみを受け入れ、バックエ
ンドインスタンスに適切な証明書が使用されていることを確認するために使用できます。
バックエンドサーバー認証を有効にしない場合は、このステップをスキップします。
この例では、認証にパブリックキーを使用するパブリックキーポリシーを作成することによって、バッ
クエンドサーバーの認証を有効にします。その後パブリックキーポリシーを使用して、バックエンド
サーバー認証ポリシーを作成します。最後に、バックエンドサーバー認証ポリシーにバックエンドサー
バーポートを設定して、バックエンドサーバー認証を有効にします。この例では、バックエンドサー
バーは、インスタンスポート 443 に設定された SSL/HTTPS プロトコルでリッスンします。
パブリックキーポリシーの値は、バックエンドサーバーがロードバランサーに提示する証明書のパブ
リックキーです。パブリックキーは OpenSSL を使って取得できます。
バックエンドサーバー認証を設定するには
1.
openssl x509 コマンドを入力してパブリックキーを取得します。
openssl x509 -in your X509 certificate PublicKey -pubkey -noout
2.
以下の例のように、create-load-balancer-policy コマンドを入力し、パブリックキーポリシーを作
成します。
60
--policy-name MyPublicKeyPolicy --policy-type-name PublicKeyPolicyType -policy-attributes AttributeName=PublicKey,AttributeValue=MIICiTCCAfIC
CQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
Note
policy-attributes 引数にパブリックキーの値を指定するには、パブリックキーの先頭
の行と末尾の行（「-----BEGIN PUBLIC KEY-----」を含む行と「-----END PUBLIC
KEY-----」を含む行）を削除します。AWS CLI では、policy-attributes 引数の値に
スペース文字を使用できません。
3.
以下の例のように、create-load-balancer-policy コマンドを入力し、MyPublicKeyPolicy を参照
してバックエンドサーバー認証ポリシーを作成します。複数のパブリックキーポリシーを参照でき
ます。複数のパブリックキーポリシーを使用すると、ロードバランサーはすべてのキーをひとつず
つ試して認証を行います。いずれかのパブリックキーがサーバーの証明書に一致すると、認証が成
功します。
--policy-name MyBackendServerAuthenticationPolicy --policy-type-name
BackendServerAuthenticationPolicyType --policy-attributes AttributeName=Pub
licKeyPolicyName,AttributeValue=MyPublicKeyPolicy
4.
以下の例のように、set-load-balancer-policies-for-backend-server コマンドを入力し、
MyBackendServerAuthenticationPolicy をインスタンス（バックエンドサーバー）ポートに
設定します。
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name
my-test-loadbalancer --instance-port 443 --policy-names MyBackendServerAu
thenticationPolicy
5.
以下の例のように、describe-load-balancer-policies コマンドを入力し、my-test-loadbalancer
のために作成されたすべてのポリシーを一覧表示します。
balancer
6.
以下の例のように、describe-load-balancer-policies コマンドを入力し、
MyBackendServerAuthenticationPolicy の詳細を表示します。
61
balancer --policy-names MyBackendServerAuthenticationPolicy
7.
アプリケーションインスタンスのヘルスチェックの設定手順については、「ステップ 4: ヘルス
チェックの設定 (p. 62)」を参照してください。
ステップ 4: ヘルスチェックの設定
Elastic Load Balancing は、指定した設定に基づいて、登録されたそれぞれの Amazon EC2 インスタン
スのヘルスチェックを定期的に行います。Elastic Load Balancing で unhealthy インスタンスが検出さ
れると、そのインスタンスへのトラフィックの送信が停止され、トラフィックのルーティングが healthy
インスタンスに変更されます。Elastic Load Balancing のヘルスチェックの詳細については、「ヘルス
チェック (p. 9)」を参照してください。
ロードバランサーを作成するときに、Elastic Load Balancing によって、デフォルトの設定でバックエ
ンドインスタンスのヘルスチェックが設定されます。デフォルトのヘルスチェック設定はいつでも変更
できます。この例では、バックエンドインスタンスのヘルスチェックを設定します。
デフォルト設定に設定されたバックエンドインスタンスのヘルスチェック設定をそのままにする場合
は、このステップをスキップします。
バックエンドインスタンスのヘルスチェックを設定するには
1.
以下の例のように、configure-health-check コマンドを入力します。
aws elb configure-health-check --load-balancer-name my-test-loadbalancer -health-check Target=HTTP:80/png,Interval=30,Un
healthyThreshold=2,HealthyThreshold=2,Timeout=3
Elastic Load Balancing は以下を返します。
{
"HealthCheck": {
"Interval": 30,
"Target": "HTTP:80/png",
"Timeout": 3,
}
2.
EC2 インスタンスを登録する手順については、「ステップ 5: EC2 インスタンスの登録 (p. 62)」を
ステップ 5: EC2 インスタンスの登録
ロードバランサーを作成したら、そのロードバランサーに EC2 インスタンスを登録する必要がありま
ことができます。ロードバランサーに登録する EC2 インスタンスの設定の詳細については、「EC2 イ
ンスタンスの負荷分散の設定 (p. 8)」を参照してください。
この例では、新しく作成したロードバランサーを Amazon EC2 に登録します。
62
Important
登録できるのは、Pending 状態または Running 状態にあり、Virtual Private Cloud（VPC）内に
ないインスタンスのみです。VPC で Elastic Load Balancing を使用する場合は、VPC のロード
バランサー (p. 76) を参照してください。
Amazon EC2 インスタンスを登録するには
1.
以下の例のように、register-instances-with-load-balancer コマンドを入力します。
aws elb register-instances-with-load-balancer --load-balancer-name my-testloadbalancer
--instances i-4f8cf126 i-0bb7ca62
{
"Instances": [
{
"InstanceId": "i-4f8cf126"
},
{
"InstanceId": "i-0bb7ca62"
}
]
}
2.
ロードバランサーが起動されることを確認するには、「ステップ 6: インスタンスの確認 (p. 63)」
ステップ 6: インスタンスの確認
インスタンスを確認するには
この例では、新しく登録した Amazon EC2 インスタンスの状態をチェックします。登録した EC2 イン
スタンスのいずれかが InService 状態になると、ロードバランサーを使用できるようになります。
1.
新しく登録した Amazon EC2 インスタンスの状態をチェックするには
以下の例のように、describe-instance-health コマンドを入力します。
aws elb describe-instance-health --load-balancer-name my-test-loadbalancer
--instances i-4f8cf126 i-0bb7ca62
{
"InstanceStates": [
{
"InstanceId": "i-4f8cf126",
"ReasonCode": "N/A",
"State": "InService",
"Description": "N/A"
},
63
{
"InstanceId": "i-0bb7ca62",
"ReasonCode": "Instance",
"State": "OutOfService",
"Description": "Instance registration is still in progress"
}
]
}
2.
一部のまたはすべてのインスタンスの [State] フィールドに OutOfService と表示される場合、イン
スタンスが登録中であると考えられます。詳細については、Elastic Load Balancing のトラブル
シューティング: インスタンスの登録 (p. 182) を参照してください。
3.
EC2 インスタンスの少なくとも 1 つが InService であると確認されたら、ロードバランサーをテス
トすることができます。ロードバランサーをテストするには、「ステップ 1: リスナーの設定 (p. 53)」
タスクを完了した後に受け取ったロードバランサーの [DNS Name] をコピーして、インターネッ
トに接続したウェブブラウザのアドレスフィールドに貼り付けます。ロードバランサーが実行中の
場合は、HTTP サーバーのデフォルトページが表示されます。
ステップ 7: ロードバランサーの削除（オプション）
ロードバランサーを削除すると、関連する EC2 インスタンスが自動的に登録解除されます。ロードバ
ランサーが削除されると、ロードバランサーの課金も停止されます。ただし、EC2 インスタンスは引
き続き実行され、利用料金も継続して発生します。
ロードバランサーを削除するには、次の delete-load-balancer コマンドを使用します。
aws elb delete-load-balancer --load-balancer-name my-loadbalancer
EC2 インスタンスを停止するには、stop-instances コマンドを使用します。EC2 インスタンスを終了
するには、terminate-instances コマンドを使用します。
64
アベイラビリティーゾーンの追加または削除
負荷分散するアプリケーションへのアベイラビリ
ティーゾーンの追加または削除
Abstract
ELB ロードバランサーに対してアベイラビリティーゾーンを追加または削除する方法について説明します。
ロードバランサーのアベイラビリティーゾーンのリストはいつでも変更できます。アベイラビリティー
ゾーンを追加すると、ロードバランサーは追加したアベイラビリティーゾーン内のインスタンスにトラ
フィックをルーティングするようになります。詳細については、「アベイラビリティーゾーンとリー
ジョン (p. 6)」を参照してください。
ロードバランサーからアベイラビリティーゾーンを削除すると、ロードバランサーは削除したアベイラ
ビリティーゾーン内のインスタンスにトラフィックをルーティングしなくなります。アベイラビリティー
ゾーンに正常なインスタンスが存在しなくなった場合、アベイラビリティーゾーンのトラフィックが減
少している場合、またはインスタンスのトラブルシューティングや更新を行う場合は、ロードバラン
サーからアベイラビリティーゾーンを一時的に削除することをお勧めします。
目次
• AWS マネジメントコンソールを使用したアベイラビリティーゾーンの追加と削除 (p. 65)
• AWS CLI を使用したアベイラビリティーゾーンの追加と削除 (p. 66)
AWS マネジメントコンソールを使用したアベイラビ
リティーゾーンの追加と削除
EC2 アプリケーションを追加のアベイラビリティーゾーンで実行するように拡張できます。そのため
には、最初にアベイラビリティーゾーンにある EC2 インスタンスをロードバランサーに登録して、ロー
ドバランサーがトラフィックのルーティングを開始したときに、インスタンスがトラフィックを受信で
きるようにします。
アベイラビリティーゾーンをロードバランサーに追加するには
1.
2.
3.
4.
5.
下のペインの [Instances] タブで、[Edit Instances] をクリックします。
[Add and Remove Instances] ページで、新しいアベイラビリティゾーン内のインスタンスを選択し
て、[Save] をクリックします。
新しいアベイラビリティーゾーンの有効化
6.
a.
下のペインで、新しく追加したアベイラビリティーゾーンがリストに表示されていることを確
認します。[Edit Availability Zones] をクリックします。
b.
[Add and Remove Availability Zones] ページで、新しいアベイラビリティーゾーン us-east-1b
が選択されていることを確認します。選択されていない場合は選択します。
c.
アベイラビリティーゾーンをロードバランサーから削除するには
1.
65
AWS CLI を使用したアベイラビリティーゾーンの追加と削
除
2.
3.
4.
下部のペインで、[Instances] タブをクリックします。
5.
[Edit Availability Zones] で、アベイラビリティーゾーンが示されている行を見つけて、[Remove
from Load Balancer] をクリックします。
（オプション）ロードバランサーからアベイラビリティーゾーンを削除しても、アベイラビリティー
ゾーン内のインスタンスはロードバランサーに登録されたままになります。ロードバランサーから
これらのインスタンスを登録解除するには、「ロードバランサーでの EC2 インスタンスの登録解
除と登録 (p. 95)」の手順に従います。
6.
AWS CLI を使用したアベイラビリティーゾーンの追
加と削除
EC2 アプリケーションを追加のアベイラビリティーゾーンで実行するように拡張できます。そのため
には、最初にアベイラビリティーゾーンにある EC2 インスタンスをロードバランサーに登録して、ロー
ドバランサーがトラフィックのルーティングを開始したときに、インスタンスがトラフィックを受信で
きるようにします。
アベイラビリティーゾーンをロードバランサーに追加するには
1.
次の register-instances-with-load-balancer コマンドを使用して、インスタンスを登録します。
aws elb register-instances-with-load-balancer --load-balancer-name my-load
balancer --instances i-3a8cf324, i-2603ca33
{
"Instances": [
{
"InstanceId":
},
{
"InstanceId":
},
{
"InstanceId":
},
{
"InstanceId":
}
]
"i-4f8cf126"
"i-0bb7ca62"
"i-3a8cf324"
"i-2603ca33"
}
2.
（オプション）次の describe-instance-health コマンドを使用して、インスタンスがロードバラン
サーに登録されていることを確認します。
aws elb describe-instance-health --load-balancer-name my-loadbalancer --in
stances i-3a8cf324,i-2603ca33
66
AWS CLI を使用したアベイラビリティーゾーンの追加と削
除
{
"InstanceStates": [
{
"InstanceId": "i-3a8cf324",
"ReasonCode": "N/A",
"State": "InService",
"Description": "N/A"
},
{
"InstanceId": "i-2603ca33",
"ReasonCode": "Instance",
"State": "OutOfService",
"Description": "Instance registration is still in progress"
}
]
}
3.
インスタンスの状態の説明が [Instance registration is still in progress] と表示され
ている場合は、Elastic Load Balancing がインスタンスのヘルスチェックを実行中であることを示
します。ヘルスチェックの実行中でも、新しいアベイラビリティーゾーンの追加手順に進むことが
できます。
次の enable-availability-zones-for-load-balancer コマンドを使用して、アベイラビリティーゾーン
aws elb enable-availability-zones-for-load-balancer --load-balancer-name
my-loadbalancer --availability-zones us-west-2b
{
"us-east-1a",
"us-east-1b"
]
}
アベイラビリティーゾーンをロードバランサーから削除するには
•
次の disable-availability-zones-for-load-balancer コマンドを使用します。
aws elb disable-availability-zones-for-load-balancer --load-balancer-name
my-loadbalancer --availability-zones us-west-2a
{
"us-east-1b"
]
}
67
EC2-Classic 用セキュリティグループ
EC2-Classic でのロードバランサーのセキュリティ
グループ
Abstract
Amazon EC2-classic アプリケーションのセキュリティグループを管理する方法について説明します。
セキュリティグループは、インスタンスのグループ内への着信を許可されたトラフィックを制御する
ファイアウォールとして動作します。Amazon EC2 インスタンスを起動する際、1 つまたは複数のセ
キュリティグループに割り当てることができます。セキュリティグループごとに、グループ内のインス
タンスに着信可能なトラフィックを規定するルールを追加できます。ここで許可しない着信トラフィッ
クはすべて廃棄されます。セキュリティグループのルールはいつでも変更することができます。新しく
作成したルールは、グループ内の既存のインスタンスと将来作成されるインスタンスすべてに対して自
動的に適用されます。Amazon EC2 のセキュリティグループについては、「セキュリティグループの
使用」を参照してください。
Elastic Load Balancing の特別な Amazon EC2 ソースセキュリティグループを使用して、バックエンド
Amazon EC2 インスタンスが Elastic Load Balancing からのみトラフィックを受け取るように設定する
ことができます。この機能には 2 つのセキュリティグループがあります。1 つはソースセキュリティグ
ループで、もう 1 つはバックエンドインスタンスの進入ルールを定義するセキュリティグループです。
ロードバランサーとバックエンドインスタンスとの間のトラフィックをロックするには、着信トラフィッ
クを制限するバックエンドセキュリティグループにルールを追加または修正して、Elastic Load Balancing
が提供する Amazon EC2 ソースセキュリティグループからのトラフィックだけを通すようにします。
Elastic Load Balancing とバックエンド Amazon EC2
インスタンス間でトラフィックをロックする
このセクションでは、ロードバランサーとバックエンド Amazon EC2 インスタンス間でトラフィック
をロックする手順を説明します。
作業を始める前に、必ず『Amazon EC2 ユーザーガイド』の「セキュリティグループの概念」セクショ
ンを読んでください。
下の表は、ロードバランサーとバックエンドインスタンス間のトラフィックをロックする手順の流れを
表したものです。
ロードバランサーとバックエンドインスタンス間のトラフィックをロックする手順
1
Elastic Load Balancing がロードバランサーに提供するソースセキュリティグループの名前を取得
します。
2
Amazon EC2 バックエンドインスタンスが属するセキュリティグループに、ロードバランサーか
らの着信トラフィックを許可する新しいルールを追加します。
3
新しいルールが正しく追加されたか検証します。
4
オプション: バックエンドインスタンスのセキュリティグループから、追加したルールより制約
がゆるやかなものを削除します。
目次
• コンソールを使用する (p. 69)
• AWS CLI の使用 (p. 70)
68
Elastic Load Balancing とバックエンド Amazon EC2 イン
スタンス間でトラフィックをロックする
コンソールを使用する
次の手順に従って、ロードバランサーとバックエンドインスタンス間のトラフィックをロックします。
1.
2.
するには
a.
Amazon EC2 コンソールの [Resources] ページにある [EC2 Dashboard] ペインの [NETWORK
& SECURITY] で、[Load Balancers] をクリックします。
b.
c.
d.
[Load Balancers] ページで、ロードバランサーを選択します。
下のペインには、ロードバランサーの詳細が表示されます。
[Security] タブをクリックします。
e.
[Source Security Group] 列に表示されている名前をコピーします。これは Elastic Load Balancing
がロードバランサーに提供するソースセキュリティグループです。
Amazon EC2 バックエンドインスタンスのセキュリティグループに Elastic Load Balancing ソース
セキュリティグループからの着信トラフィックを許可するルールを追加するには
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
3.
4.
[Load Balancers] ページで、[Navigation] ペインの [Instances] をクリックします。
[My Instances] ページで、ロードバランサーに登録されたインスタンスを選択します。
下ペインにインスタンスの詳細が表示されます。[Description] タブを選択していることを確認
します。
[Security Groups:] フィールドに表示されたセキュリティグループ名を書きとめておきます。
これはバックエンドインスタンスに関連付けられたセキュリティグループです。
[Navigation] ペインで [Security Groups] をクリックします。
[Security Groups] ページで、バックエンドインスタンスに関連付けられたセキュリティグルー
プを選択します。
下ペインにセキュリティグループの詳細が表示されます。
[Inbound] タブをクリックします。[Inbound] タブの下のペインに、そのセキュリティグループ
に属するルールが表示されます。
[Edit] をクリックし、[Add Rule] をクリックします。
[Type] 列で、最後のダイアログボックスをクリックし、プロトコルタイプを選択します。
[Protocol] 列と [Port Range] 列のフィールドに値が入力されます。
[Source:] フィールドをクリックし、[Custom IP] を選択します。空のボックスに、ロードバ
ランサーのソースセキュリティグループ名を入力します。これはステップ 1 で使った名前と同
じです。この例では [amazon-elb/amazon-elb-sg] となります。
[Inbound] タブの下のペインに新しいルールが表示されます。
[オプション] ステップ 2 で追加したルールよりも規制のゆるいルールがセキュリティグループに設
定されている場合は、規制がゆるいルールを削除してください。そのためには、[Edit] をクリック
し、[Edit inbound rules] ページで、規制のゆるいルールがある行の隣の削除アイコンをクリックし
ます。
69
Note
バックエンドインスタンスに直接接続したい場合は、直接接続を許可する着信ルールは削
除しないでください。たとえば、ポート 22（SSH）と 3389（RDP）への着信トラフィッ
クを許可するルールを両方残しておいてもかまいません。
AWS CLI の使用
開始する前に、AWS CLI 環境をインストールして設定する必要があります。詳細については、「AWS
コマンドラインインターフェイスの設定」を参照してください。
1.
するには
以下の例のように、describe-load-balancers コマンドを入力して、ロードバランサーのソースセ
キュリティグループ名を表示します。
Elastic Load Balancing は、指定されたロードバランサーの詳細を返します。
{
{
"Subnets": [],
"CanonicalHostedZoneName": "my-test-loadbalancer-012345678.useast-1.elb.amazonaws.com",
{
"Listener": {
},
"PolicyNames": [
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "HTTP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
70
"Timeout": 5,
},
"Instances": [
{
"InstanceId": "i-315b7e51"
}
],
"DNSName": "my-test-loadbalancer-012345678.us-east1.elb.amazonaws.com",
"Policies": {
"OtherPolicies": [
]
},
"CreatedTime": "2014-03-19T03:24:02.650Z",
"us-east-1a"
],
}
}
]
}
応答の要素には SourceSecurityGroup と OwnerAlias から成る GroupName データ構造が含ま
れます。これはロードバランサーに関連付けられたソースセキュリティグループです。OwnerAlias
と GroupName を書きとめておきます。これは次のステップで使います。
2.
Amazon EC2 バックエンドインスタンスのセキュリティグループに Elastic Load Balancing ソース
セキュリティグループからの着信トラフィックを許可するルールを追加するには
このステップでは AWS EC2 CLI コマンドを使用します。
a.
バックエンドインスタンスのセキュリティグループの名前が分からない場合は、以下の例のよ
うに、describe-instances コマンドを入力し、バックエンドインスタンスのインスタンス ID
を指定します。
aws ec2 describe-instances --instance-ids i-315b7e51
b.
応答の要素には GroupId 要素と GroupName 要素から成る SecurityGroups データ構造が
含まれます。これはインスタンスに関連付けられたセキュリティグループです。GroupName
を書き留めておきます。これは次のステップで使います。
authorize-security-group-ingress コマンドを入力して、バックエンドインスタンスに関連付け
られたセキュリティグループにルールを追加します。
71
以下の例では、authorize-security-group-ingress コマンドにより、ロードバランサー
に関連付けられたソースセキュリティグループを指定して、バックエンドインスタンスのセ
キュリティグループ（MyTestSecurityGroup）に進入ルールを追加します。
aws ec2 authorize-security-group-ingress --group-name MyTestSecurityGroup
--source-security-group-name amazon-elb-sg --source-security-groupowner-id amazon-elb
Amazon EC2 は以下の例のように応答します。
{
"return": "true"
}
3.
バックエンドインスタンスに関連付けられたセキュリティグループに、Elastic Load Balancing ソー
スセキュリティグループからの着信トラフィックを許可する新しいルールが適用されているかを検
証するには、
以下の例のように、describe-security-groups コマンドを入力します。
aws ec2 describe-security-groups --group-names MyTestSecurityGroup
応答の要素には、インスタンスにアクセスする権限が付与されたセキュリティグループをリストす
る UserIdGroupPairs データ構造が含まれます。
{
"SecurityGroups": [
{
"Description": "My ELB Security Group",
"GroupId": "sg-076e2537",
"OwnerId": "012345678901",
"GroupName": "MyTestSecurityGroup",
"IpPermissionsEgress": [],
"IpPermissions": [
{
"IpRanges": [],
"FromPort": -1,
"IpProtocol": "icmp",
"ToPort": -1,
"UserIdGroupPairs": [
{
"GroupName": "amazon-elb-sg",
"GroupId": "sg-5a9c116a",
"UserId": "amazon-elb"
}
]
},
{
"IpRanges": [],
"FromPort": 1,
"IpProtocol": "tcp",
"ToPort": 65535,
72
{
}
]
},
{
"IpRanges": [],
"FromPort": 1,
"IpProtocol": "udp",
"ToPort": 65535,
{
}
]
},
. . . . . .
. . . . . .
4.
（オプション）前の手順で追加したルールよりも規制のゆるいルールがセキュリティグループに設
定されている場合は、revoke-security-group-ingress コマンドを使って規制がゆるいルールを削除
します。たとえば、既存のルールで、CIDR 範囲 0.0.0.0/0（すべての IPv4 アドレス）からの受信
トラフィックを許可している可能性があります。
以下の例では、MyTestSecurityGroup という名前のセキュリティグループから、すべての IPv4
アドレスからの TCP トラフィックを許可するルールを削除します。
aws ec2 revoke-security-group-ingress --group-name MyTestSecurityGroup -protocol tcp --port 80 --cidr 0.0.0.0/0
Amazon EC2 は以下の例のように応答します。
{
"return": "true"
}
Note
バックエンドインスタンスに直接接続したい場合は、直接接続を許可する着信ルールは無
効化しないでください。たとえば、ポート 22（SSH）と 3389（RDP）への着信トラフィッ
クを許可するルールを両方残しておいてもかまいません。
73
インターネットプロトコルバージョン 6（IPv6）
Elastic Load Balancing での IPv6 の使用
Abstract
ロードバランサーでの IPv6 の使用方法について説明します。
Elastic Load Balancing は、EC2-Classic でインターネットプロトコルバージョン 6（IPv6）とインター
ネットプロトコルバージョン 4（IPv4）の両方をサポートしています。クライアントは、EC2-Classic
のロードバランサーへの接続に IPv4 と IPv6 のどちらでも使用できます。クライアントとロードバラン
サーとの通信方法に関係なく、ロードバランサーとバックエンドインスタンス間の通信では、IPv4 の
みが使用されます。つまり、バックエンド Amazon EC2 インスタンスではネイティブの IPv6 サポート
は必要ありません。
Note
現在、IPv6 サポートは VPC（EC2-VPC）のロードバランサーでは使用できません。
Elastic Load Balancing には、ロードバランサー名とリージョンを組み合わせたパブリック DNS 名が用
意されています。たとえば、米国西部（オレゴン）リージョンにある my-lb というロードバランサー
は、my-lb-1234567890.us-west-2.elb. という DNS 名で表すことができます。amazonaws.com。この
基本パブリック DNS 名は IPv4 レコードのみを返します。
基本パブリック DNS 名に加え、Elastic Load Balancing は 2 つの追加パブリック DNS 名を提供しま
す。1つ目は、文字列 ipv6 とロードバランサー名およびリージョンを組み合わせたものです。これは、
ipv6.my-lb-1234567890.us-west-2.elb. のようになります。amazonaws.com「ipv6」のプレフィックス
の付いた DNS 名は、IPv6 レコードのみを返します。2つ目のパブリック DNS 名は、文字列 dualstack
とロードバランサー名およびリージョンを組み合わせたものです。これは、
dualstack.my-lb-1234567890.us-west-2.elb. のようになります。amazonaws.com「dualstack」のプレ
フィックスの付いた DNS 名は、IPv4 と IPv6 レコードの両方を返します。
ほとんどのお客様は、ロードバランサーで IPv6 を有効化するため、「dualstack」プレフィックス付き
の DNS 名の使用を希望するでしょう。「dualstack」プレフィックス付きの DNS 名は IPv6 と IPv4 レ
コードの両方を返すため、クライアントはそれぞれの接続ニーズに応じて、IPv4 と IPv6 のどちらでも
ロードバランサーにアクセスできます。「ipv6」プレフィックス付きの DNS 名は IPv6 アドレスのみを
返すので、このような DNS 名を使用した場合、IPv4 接続のみを使用するクライアントはロードバラン
サーにアクセスできません。
Elastic Load Balancing は、IPv4 または IPv6 のいずれかを使用して接続しているクライアント用に
X-Forwarded-For リクエストヘッダーをサポートしています。クライアントが IPv6 を使用して接続し
ている場合、Elastic Load Balancing はリクエストヘッダーにクライアントの IPv6 アドレスを挿入しま
す。X-Forwarded-For サポートの詳細については、「the section called “概念” (p. 5)」を参照してくだ
さい。
Elastic Load Balancing では、IPv6 でも、IPv4 の場合と同じような方法で、DNS 名をロードバランサー
にマップできます。DNS 名からロードバランサーへのマップに CNAME レコードを使用している場合
は、その方法を継続して使用できます。Amazon Route 53 のホストゾーンを使用している場合は、同
じ Elastic Load Balancing コマンドを使用して、IPv4 と IPv6 の両方のリソースレコードを作成できま
す。
Elastic Load Balancing の IPv6 および CNAME レコー
ド
CNAME レコードを使用して www.example.com のような DNS 名をロードバランサーにマップする際
は、CNAME レコードのエイリアスとして 3 つのパブリック DNS 名のいずれでも使用できます。たと
74
Elastic Load Balancing の IPv6 およびホストゾーン
えば、以下の CNAME レコードは、www.example.com をロードバランサーの IPv4 アドレスにマップ
します。
www.example.com
CNAME
my-lb-1234567890.us-west-2.elb.amazonaws.com
以下の例は、www.example.com をロードバランサーの IPv6 アドレスにマップします。
www.example.com
CNAME
ipv6.my-lb-1234567890.us-west-2.elb.amazonaws.com
IPv4 と IPv6 が混在するアドレス解決を処理する場合は、CNAME レコードで「dualstack」プレフィッ
クスを使用してください。
www.example.com
aws.com
CNAME
dualstack.my-lb-1234567890.us-west-2.elb.amazon
Elastic Load Balancing の IPv6 およびホストゾーン
Amazon Route 53 ホストゾーンを使用してドメイン名や Zone Apex をロードバランサーにマップする
場合は、elb-associate-route53-hosted-zone コマンドを使用して、IPv4、IPv6、またはその両
方で動作するリソースレコードを作成できます。
IPv4 リソースレコードを作成するには、--rr-type パラメータの値として「A」を指定します。この
パラメータのデフォルト値は A であるため、省略することもできます。
elb-associate-route53-hosted-zone myLB --rr-name example.com --rr-type A -hosted-zone-id Z123456789 --weight 100
IPv6 リソースレコードを作成するには、--rr-type パラメータの値として「AAAA」を指定します。
elb-associate-route53-hosted-zone myLB --rr-name example.com --rr-type AAAA -hosted-zone-id Z123456789 --weight 100
デュアルスタックリソースレコードと同等のものを作成するには、--rr-type パラメータに値「A」
を指定するリソースレコードを 1 つと、「AAAA」を指定するリソースレコードを 1 つ作成します。
elb-associate-route53-hosted-zone myLB --rr-name example.com --rr-type A -hosted-zone-id Z123456789 --weight 100
elb-associate-route53-hosted-zone myLB --rr-name example.com --rr-type AAAA -hosted-zone-id Z123456789 --weight 100
Elastic Load Balancing で Amazon Route 53 を使用する方法については、the section called “Option 2:
Amazon Route 53 ホストゾーンの作成” (p. 105) を参照してください。
75
Elastic Load Balancing での VPC の設定
VPC のロードバランサー
Abstract
ロードバランサーを使用すると、Virtual Private Cloud 内で起動した EC2 インスタンスへのトラフィックを監視
し、ルーティングすることもできます。
Amazon Virtual Private Cloud（Amazon VPC）を使用すると、AWS クラウド内の隔離されたプライベー
トセクションに仮想ネットワーク環境を定義できます。この Virtual Private Cloud (VPC) 内では、ロー
ドバランサーや EC2 インスタンスなどの AWS リソースを起動できます。詳細については、「Amazon
VPC ユーザーガイド」を参照してください。
VPC（デフォルトの VPC を含む）内で起動した EC2 インスタンスを負荷分散する場合は、同じ VPC
内にロードバランサーを作成する必要があります。クライアントとロードバランサーの間の通信、およ
び、ロードバランサーとバックエンドインスタンスとの間の通信では、インターネットプロトコルバー
ジョン 4（IPv4）を使用します。インターネットプロトコルバージョン 6（IPv6）は、現在 VPC のロー
ドバランサーでは使用できません。
目次
• Elastic Load Balancing での VPC の設定 (p. 76)
• VPC でのロードバランサーのセキュリティグループ (p. 78)
• インターネット向けロードバランサーと内部向けロードバランサー (p. 80)
• VPC での内部向けロードバランサーの作成 (p. 82)
• ロードバランサー用のサブネットの管理 (p. 86)
VPC 内で ELB ロードバランサーを作成して使用するには、まず VPC 環境を設定する必要があります。
そのためには VPC を作成し、1 つ以上のサブネットを作成し、そのサブネットでインスタンスを起動
します。
Elastic Load Balancing 用に VPC とサブネットを設定する際のヒントをいくつか紹介します。
• インスタンスとロードバランサーを起動するリージョンにインターネットゲートウェイを使う VPC
76
• 新規のお客様の場合、または以前に使用したことのないリージョンを初めて使用する場合は、何もし
なければデフォルト VPC を使用することになります。デフォルト VPC を使うことも、独自 VPC を
作成することもできます。
• インスタンスを起動する各アベイラビリティゾーンにサブネットを作成します。ユースケース、セ
キュリティ要件、運用要件に応じて、インスタンスを起動するサブネットをプライベートサブネット
またはパブリックサブネットにすることができます。
プライベートサブネットで起動されたインスタンスは、インターネットとは通信できません。プライ
ベートサブネット内のインスタンスでアウトバウンドのインターネットアクセスのみを許可する場合
は、パブリックサブネットにネットワークアドレス変換（NAT）インスタンスを配置します。NAT
インスタンスによって、プライベートサブネット内のインスタンスはインターネットへのアウトバウ
ンドトラフィックを開始できますが、インバウンドトラフィックの受信は禁止されます。
• 必要に応じて、ロードバランサー用に別のサブネットを作成することもできます。インスタンスは、
ロードバランサーと同じサブネット内に存在する必要はありません。ロードバランサーとバックエン
ドインスタンスを別のサブネットに配置する予定である場合は、セキュリティグループのルールおよ
びネットワーク ACL を、VPC のサブネット間でトラフィックがルーティングされるように設定して
ください。ルールが正しく設定されていない場合は、別のサブネットのロードバランサーから他のサ
ブネットのインスタンスにアクセスできない可能性があります。
ロードバランサーが正しくスケーリングを行えるように、ロードバランサーを配置するサブネットの
CIDR ブロックを、最低でも /27 ビットマスク（例: 10.0.0.0/27）にし、少なくとも 8 個の空き IP ア
ドレスを用意してください。ロードバランサーを作成してサブネットに配置すると、登録されたイン
スタンスにリクエストを転送するためにトラフィックが通過する必要のあるサブネットが定義されま
す。
Important
インターネット向けロードバランサーを作成する場合は、必ずパブリックサブネット内に設
置してください。パブリックサブネットを作成した後、パブリックサブネットのルートテー
ブルをインターネットゲートウェイに関連付けて、サブネット内のロードバランサーがイン
ターネットと接続できるようにします。
• リンクされた EC2-Classic インスタンスをロードバランサーに登録する予定がある場合は、VPC を
作成後、ClassicLink を有効にしてから、その VPC にロードバランサーを作成します。
最も一般的な VPC シナリオは、「Amazon VPC のシナリオ」に記載されています。これらのシナリオ
は、それぞれシナリオの詳細な説明にリンクされています。説明の最後に、シナリオの実装に関するセ
クションがあり、そのシナリオで VPC を作成する方法の手順が示されています。お客様のユースケー
スに最適なシナリオの手順に従って、VPC 環境を作成することができます。
目的のシナリオが「Amazon VPC のシナリオ」に挙げられてない場合は、『Amazon VPC ユーザーガ
イド』の以下のセクションで説明されている手順に従って VPC 環境を作成できます。
ClassicLink を使用すると、EC2-Classic インスタンスはプライベート IP アドレスを使用して VPC イ
ンスタンスと通信できます。EC2-Classic のインスタンスと VPC のインスタンス間の通信を有効にす
るには、最初に VPC で ClassicLink を有効にしてから、EC2-Classic インスタンスをその VPC とリン
クする必要があります。インスタンスをリンクするには、VPC からセキュリティグループを選択して、
EC2-Classic インスタンスに関連付ける作業も必要です。EC2-Classic インスタンスをリンクすると、
VPC セキュリティグループで許可されている場合は、プライベート IP アドレスを使用して VPC 内の
インスタンスと通信できます。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイ
ド』の「ClassicLink の基礎」および「ClassicLink の使用」を参照してください。
リンクされた EC2-Classic インスタンスをロードバランサーに登録するには、ClassicLink が有効な
VPC にロードバランサーを作成してから、リンクされた EC2-Classic インスタンスを登録する必要が
あります。
77
EC2-VPC 用セキュリティグループ
VPC でのロードバランサーのセキュリティグルー
プ
Abstract
セキュリティグループを使用して、Virtual Private Cloud 内のインスタンスに到達できるトラフィックを制御しま
す。
セキュリティグループは、インスタンスに許可されるトラフィックを制御する仮想ファイアウォールで
す。セキュリティグループは、インスタンスへのインバウンドトラフィックを制御する一連のルール
と、アウトバウンドトラフィックを制御する別の一連のルールを追加して作成します。Amazon VPC
と Amazon EC2 とでは、セキュリティグループの動作に大きな違いがあります。Amazon EC2 では、
Elastic Load Balancing が提供する特別な Amazon EC2 ソースセキュリティグループを使用して、バッ
クエンド Amazon EC2 インスタンスが ELB ロードバランサーからのみトラフィックを受け取るように
設定することができます。ソースセキュリティグループを変更することはできません。VPC では、ロー
ドバランサーに割り当てられたセキュリティグループを制御することができます。セキュリティグルー
プを制御できるため、受け付けるポートとプロトコルも選択可能です。たとえば、ロードバランサーが
ping リクエストに応答できるよう、Internet Control Message Protocol（ICMP）接続を開くことができ
ます（ただし ping リクエストは登録されたインスタンスに転送されません）。ロードバランサーを作
成するときに特定のセキュリティグループを指定しなかった場合、ロードバランサーは VPC のデフォ
ルトセキュリティグループに自動的に所属します。
AWS マネジメントコンソールを使用してデフォルト VPC にロードバランサーを作成する場合、デフォ
ルト VPC に関連付けられたデフォルトセキュリティグループを選択するか、AWS アカウントに関連
付けられた他の既存のセキュリティグループを選択するか、または既存のセキュリティグループを変更
して新しいセキュリティグループを作成することができます。既存のデフォルト以外の既存のセキュリ
ティグループを使用する場合は、ロードバランサーが使用するよう設定したポートへの進入をそのグ
ループが許可することを確認してください。セキュリティグループを作成する場合は、これらのポート
が開くよう、コンソールによって定義されます。
AWS Management Console を使用して作成したセキュリティグループは、ロードバランサーに関連付
けられます。ロードバランサーに関連付けられたセキュリティグループは、削除できません。
AWS CLI または API を使用してデフォルト VPC にロードバランサーを作成する場合、デフォルトセ
キュリティグループ default_elb_special number が 0.0.0.0/0 に対して作成され、ロードバラン
サー用のポートが指定されます。現行の Elastic Load Balancing では、CLI または API を使用する場合
に、ロードバランサーに関連付けるセキュリティグループを選択することはできません。
CLI または API を使用してデフォルト VPC 内にロードバランサー用に作成されるセキュリティグルー
プは、AWS アカウントに関連付けられます。AWS アカウントごとに作成されるセキュリティグループ
は 1 つのみです。これ以後、新しいロードバランサーを作成する呼び出しでは、同じセキュリティグ
ループが再利用されます。既存のロードバランサーにリスナーを追加する場合、ロードバランサーに適
用されているセキュリティグループを確認する必要があります。確認しないと、ロードバランサーでト
ラフィックが受信されない可能性があります。作成するロードバランサーでこのデフォルトのセキュリ
ティグループを使用するが異なるリスナー設定を行いたい場合は、ロードバランサーに適用されている
セキュリティグループを確認し、更新する必要があります。
デフォルト VPC 内のロードバランサーのリスナーを更新する場合は、ロードバランサーに関連付けら
れたセキュリティグループは変更されません。ロードバランサーを削除した場合でも、セキュリティグ
ループは自動的には削除されません。
目次
• コンソールを使用したセキュリティグループの管理 (p. 79)
• AWS CLI を使用したセキュリティグループの管理 (p. 79)
78
コンソールを使用したセキュリティグループの管理
コンソールを使用したセキュリティグループの管理
次の手順に従って、VPC 内のロードバランサーに割り当てられたセキュリティグループの更新やリセッ
トを行います。
ロードバランサーに割り当てられたセキュリティグループを更新するには
1.
2.
3.
VPC 用に作成したロードバランサーを選択します。
4.
5.
下部のペインで、[Security] タブをクリックします。
[Security Groups] ペインで、[Edit] をクリックします。
6.
[Edit security groups] ページで、新しいセキュリティグループを選択し、[Save] をクリックしま
す。
AWS CLI を使用したセキュリティグループの管理
次の apply-security-groups-to-load-balancer コマンドを使用して、追加のセキュリティグループを VPC
内のロードバランサーに割り当てます。
aws elb apply-security-groups-to-load-balancer --load-balancer-name my-loadbal
ancer --security-groups sg-53fae93f
{
"SecurityGroups": [
"sg-fc448899"
"sg-53fae93f"
]
}
79
インターネット向けロードバランサーと内部向けロードバ
ランサー
インターネット向けロードバランサーと内部向け
ロードバランサー
Abstract
VPC 内のインターネット向けロードバランサーと内部向けロードバランサーについて説明します。
VPC でロードバランサーを作成するときに、ロードバランサーを内部向け（プライベート）にするこ
ともインターネット向け（パブリック）にすることもできます。ロードバランサーを内部向けとして設
定する場合は、ロードバランサーのプライベート IP アドレスが含まれる DNS 名が作成されます。内
部向けロードバランサーはインターネットには公開されません。ロードバランサーをインターネット向
けとして設定する場合は、パブリック IP アドレスが含まれる DNS 名が作成されます。DNS レコード
はどちらの場合でもパブリックで解決されます。
内部向けロードバランサーとインターネット向けロードバランサーを併用することで、アプリケーショ
ンの複数の層の間でリクエストを分散することができます。たとえば、フロントエンドに、インター
ネットからリクエストを受信してバックエンドアプリケーションインスタンスに渡すウェブサーバーが
あるとします。VPC に内部向けロードバランサーを作成して、その背後にバックエンドアプリケーショ
ンインスタンスを配置することができます。DNS 名とパブリック IP アドレスを持つインターネット向
けロードバランサーを作成して、それをウェブサーバーの前に配置することができます。ウェブサー
バーは、インターネット向けロードバランサー経由でリクエストを受け取り、そのリクエストを内部向
けロードバランサーに対して実行します。その際、内部向けロードバランサーの DNS 名から解決され
たプライベート IP アドレスが使用されます。内部向けロードバランサーは、リクエストをバックエン
ドアプリケーションインスタンスにルーティングします。この場合もまた、プライベート IP アドレス
が使用されます。インスタンスは内部向けロードバランサーからのリクエストのみを受け付けます。こ
の多階層アーキテクチャのうちパブリック IP アドレスを持つ唯一の部分がインターネット向けロード
バランサーとなるよう、お客様のすべてのインフラストラクチャではプライベート IP アドレスとセキュ
リティグループを使用することができます。
インターネットに接続するインターネット向けロードバランサーの場合、インターネットゲートウェイ
を使用してインターネットに接続されたサブネットにロードバランサーが存在している必要がありま
す。ロードバランサーの背後のアプリケーションインスタンスは、ロードバランサーと同じサブネット
に存在する必要はありません。
次の図は、インターネット向けおよび内部向けのロードバランサーと組み合わせた VPC 内の Elastic
Load Balancing を示します。
80
インターネット向けロードバランサーと内部向けロードバ
ランサー
81
内部向けロードバランサーの作成
VPC での内部向けロードバランサーの作成
Abstract
VPC への内部向けロードバランサーを作成します。
ロードバランサーを VPC 内に作成するとき、内部向け（プライベート）かインターネット向け（パブ
リック）かを設定できます。内部向けロードバランサーはインターネットには公開されません。内部向
けロードバランサーにはプライベート DNS 名とプライベート IP アドレスがあります。インターネッ
ト向けロードバランサーには、パブリック DNS 名とパブリック IP アドレスがあります。多階層アー
キテクチャをサポートするために内部向けロードバランサーとインターネット向けロードバランサーを
使用する方法の詳細については、「インターネット向けロードバランサーと内部向けロードバラン
サー (p. 80)」を参照してください。
目次
• 前提条件 (p. 82)
• コンソールを使用した内部向けロードバランサーの作成 (p. 82)
• AWS CLI を使用した内部向けロードバランサーの作成 (p. 84)
前提条件
ロードバランサー用の VPC を作成していない場合は、作業を開始する前にその VPC を作成する必要
があります。詳細については、「Elastic Load Balancing での VPC の設定 (p. 76)」を参照してくださ
い。
内部向けロードバランサーに登録する EC2 インスタンスを起動します。それらのインスタンスは、ロー
ドバランサー用の VPC 内のプライベートサブネットで起動してください。
Note
アタッチされている Elastic Network Interface (ENI) にインスタンスを登録するとき、ロードバ
ランサーは、インスタンスのプライマリインターフェイス（eth0）のプライマリ IP アドレスに
トラフィックをルーティングします。詳細については、「Elastic Network Interface」を参照し
てください。
コンソールを使用した内部向けロードバランサーの
作成
デフォルトでは、Elastic Load Balancing はインターネット向けロードバランサーを作成します。次の
手順に従って内部向けロードバランサーを作成し、EC2 インスタンスを新しく作成した内部向けロー
内部向けロードバランサーを作成するには
1.
2.
3.
4.
a.
ロードバランサーの名前を入力します。
82
コンソールを使用した内部向けロードバランサーの作成
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
b.
c.
[Create LB inside] で、ロードバランサー用の VPC を選択します。
[Create an internal load balancer] をクリックします。
d.
e.
[Listener Configuration] の設定はデフォルト値のままにしておきます。
[Configure Health Check] ページで、アプリケーションに必要なヘルスチェックを設定してから、
[Select Subnets] ページの [Available Subnets] で、内部向けロードバランサー用のサブネットを選
択し、[Continue] をクリックします。
[Assign Security Groups] ページで [Create a new security group] をクリックします。セキュリティ
グループの名前と説明を入力するか、デフォルトの名前と説明をそのまま使用します。この新しい
セキュリティグループには、ロードバランサーで使用するように設定したポートへのトラフィック
を許可するルールが含まれます。ヘルスチェック用に別のポートを指定した場合は、[Add Rule] を
クリックして、そのポートへのインバウンドトラフィックを許可するルールを追加する必要もあり
ます。[Continue] をクリックします。
[Add EC2 Instances] ページの [Add Instances to Load Balancer] で、ロードバランサーに登録する
インスタンスを選択し、[Continue] をクリックします。
（オプション）必要に応じてロードバランサーにタグを追加できます。追加しない場合は、[Continue]
を再度クリックし、このステップを省略してレビューページに移動します。
[Review] ページで設定を確認します。各設定の編集リンクをクリックして、設定を変更できます。
[Create] をクリックし、ロードバランサーを作成します。
ロードバランサーが作成されたことが通知されたら、[Close] をクリックします。
新しいロードバランサーを選択します。
下部のペインの [Description] タブでは、[DNS Name] と [Scheme] によって、ロードバランサーが
internal であることが示されています。
[Status] 行を確認します。この行が一部のインスタンスが実行されていないことを示している場
合、インスタンスはまだ登録中の可能性があります。詳細については、「Elastic Load Balancing
のトラブルシューティング: インスタンスの登録 (p. 182)」を参照してください。
83
AWS CLI を使用した内部向けロードバランサーの作成
AWS CLI を使用した内部向けロードバランサーの作
成
デフォルトでは、Elastic Load Balancing はインターネット向けロードバランサーを作成します。次の
手順に従って内部向けロードバランサーを作成し、EC2 インスタンスを新しく作成した内部向けロー
内部向けロードバランサーを作成するには
1.
次のように、--scheme オプションを internal に設定して、create-load-balancer コマンドを使
用します。
aws elb create-load-balancer --load-balancer-name my-internal-loadbalancer
--listeners Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,Instan
cePort=80
--subnets subnet-4e05f721 --scheme internal --security-groups sg-b9ffedd5
以下に、応答の例を示します。名前によって、これが内部向けロードバランサーであることが示さ
れている点に注意してください。
{
"DNSName": "internal-my-internal-loadbalancer-786501203.us-east1.elb.amazonaws.com"
}
2.
次の register-instances-with-load-balancer コマンドを使用して、インスタンスを追加します。
aws elb register-instances-with-load-balancer --load-balancer-name my-intern
al-loadbalancer --instances i-4f8cf126 i-0bb7ca62
{
"Instances": [
{
},
{
}
]
}
3.
次の describe-load-balancers コマンドを使用して、内部向けロードバランサーを検証します。
aws elb describe-load-balancers --load-balancer-name my-internal-loadbalancer
以下に、応答の例を示します。DNSName と Scheme によって、これが内部向けロードバランサー
であることが示されている点に注意してください。
84
AWS CLI を使用した内部向けロードバランサーの作成
{
{
"Subnets": [
"subnet-4e05f721"
],
"VPCId": "vpc-5ba9473e",
{
"Listener": {
"InstancePort": 80,
"Protocol": "HTTP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Target": "TCP:80",
"Timeout": 5,
},
"Instances": [
{
},
{
}
],
"DNSName": "internal-my-internal-loadbalancer-786501203.us-east1.elb.amazonaws.com",
"SecurityGroups": [
"sg-b9ffedd5"
],
"Policies": {
"OtherPolicies": []
},
"LoadBalancerName": "my-internal-loadbalancer",
"CreatedTime": "2014-05-22T20:32:19.920Z",
"us-east-1"
],
"Scheme": "internal",
"OwnerAlias": "803981987763",
"GroupName": "ELB Security Group"
}
}
]
}
85
サブネットの管理
ロードバランサー用のサブネットの管理
Abstract
既存のロードバランサーをサブネットにアタッチします。
目次
• コンソールを使用したサブネットのアタッチとデタッチ (p. 86)
• AWS CLI を使用したサブネットのアタッチとデタッチ (p. 87)
コンソールを使用したサブネットのアタッチとデタッ
チ
次の手順に従って、サブネットをロードバランサーにアタッチします。
サブネットをロードバランサーにアタッチするには
1.
2.
3.
4.
5.
6.
[Edit Availability Zones] をクリックします。
[Add and Remove Subnets] ページが表示されます。
7.
[Available Subnets] の表で、[Action] 列のボタンをクリックしてサブネットを選択します。
アベイラビリティゾーンごとに 1 つだけサブネットを選択できます。
8.
9.
選択したサブネットが [Selected Subnets] の表に表示されます。
[Save] をクリックして、サブネットをロードバランサーにアタッチします。
86
AWS CLI を使用したサブネットのアタッチとデタッチ
次の手順に従って、ロードバランサーをサブネットからデタッチします。
サブネットからロードバランサーをデタッチするには
1.
2.
3.
4.
5.
[Edit Availability Zones] をクリックします。
6.
7.
[Add and Remove Subnets] ページの [Selected Subnets] の表で、[Actions] 列のボタンをクリック
して、デタッチするサブネットを選択します。
デタッチしたサブネットは利用可能となり、[Available Subnets] の表に表示されます。
8.
[Save] をクリックして、サブネットをロードバランサーからデタッチします。
AWS CLI を使用したサブネットのアタッチとデタッ
チ
ロードバランサーをサブネットにアタッチするには
1.
以下の例のように、attach-load-balancer-to-subnets コマンドを入力します。
aws elb attach-load-balancer-to-subnets --load-balancer-name my-vpc-loadbal
ancer --subnets subnet-dea770a9 subnet-fb14f6a2
2.
Elastic Load Balancing は、アタッチされたサブネットのリストを返します。
{
"Subnets": [
"subnet-5c11033e",
"subnet-dea770a9",
"subnet-fb14f6a2"
]
}
サブネットからロードバランサーをデタッチするには
1.
以下の例のように、detach-load-balancer-from-subnets コマンドを入力します。
aws elb detach-load-balancer-from-subnets --load-balancer-name my-vpc-load
balancer --subnets subnet-450f5127
2.
Elastic Load Balancing は、ロードバランサーが現在アタッチされているサブネット ID のリストを
返します。
{
"Subnets": [
"subnet-15aaab61"
87
AWS CLI を使用したサブネットのアタッチとデタッチ
]
}
88
リスナーの追加と削除
ロードバランサーの管理
Abstract
Elastic Load Balancing を使用して EC2 インスタンス間でアプリケーションの負荷を分散させる方法に関するユー
ザーシナリオを挙げています。
目次
• ロードバランサーのリスナーの設定 (p. 89)
• ロードバランサーでの EC2 インスタンスの登録解除と登録 (p. 95)
• ロードバランサーの SSL ネゴシエーション設定の更新 (p. 98)
• ロードバランサーのカスタムドメイン名の設定 (p. 103)
• ロードバランサーのクロスゾーン負荷分散の有効化または無効化 (p. 106)
• ロードバランサーに対するConnection Drainingの有効化または無効化 (p. 110)
• ロードバランサーに対するアイドル接続のタイムアウトの設定 (p. 113)
• Proxy Protocol サポートの有効化または無効化（ロードバランサー） (p. 115)
• ロードバランサーに対する DNS フェイルオーバーの設定 (p. 123)
• スティッキーセッションの有効化と無効化 (p. 127)
• ロードバランサーに対するタグの設定 (p. 135)
Abstract
ロードバランサーに対してリスナーの追加またはリスナーの削除を行います。
Elastic Load Balancing は、HTTP、HTTPS（セキュア HTTP）、TCP、および SSL（セキュア TCP）
プロトコルを使用したアプリケーションの負荷分散をサポートします。フロントエンド接続（クライア
ントからロードバランサー）とバックエンド接続（ロードバランサーからバックエンドインスタンス）
のプロトコルは別々に指定できます。フロントエンドとバックエンドの接続の設定は、ロードバラン
サーの作成時に選択します。デフォルトでは、ロードバランサーはどちらの接続にも HTTP を使用す
るよう設定されています。その他の設定の詳細については、「Elastic Load Balancing リスナー設定ク
イックリファレンス (p. 27)」を参照してください。
Elastic Load Balancing は、クライアントとロードバランサーの間の SSL 接続のネゴシエーションに使
用される SSL ネゴシエーション設定を事前定義したセキュリティポリシーを提供します。事前定義さ
89
前提条件
れたセキュリティポリシーのいずれかを選択するか、独自のセキュリティポリシーを作成することがで
きます。詳細については、「Elastic Load Balancing の SSL ネゴシエーション設定 (p. 30)」を参照して
ください。
リスナーの HTTPS サポートを有効にするには、ロードバランサーに SSL サーバー証明書をインストー
ルする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロードバランサーは
証明書を使用してリクエストを終了し、次にリクエストを復号化します。
次の例では、フロントエンド接続とバックエンド接続の両方についてポート 443 で HTTPS リクエスト
を受け付ける既存のロードバランサーに新しいリスナーを追加する方法を示します。リスナーが不要に
なったら、ロードバランサーからリスナーを削除できます。
目次
• 前提条件 (p. 90)
• コンソールを使用したリスナーの追加と削除 (p. 90)
• AWS CLI を使用したリスナーの追加と削除 (p. 92)
前提条件
SSL 証明書がない場合は、SSL 証明書を作成し、アップロードできます。詳細については、「Elastic
Load Balancing の SSL 証明書 (p. 36)」を参照してください。
まだアップロードされていない証明書を使用している場合は、その証明書が「署名証明書をアップロー
ドする (p. 38)」で説明されている基準を満たしていることを確認してください。証明書が基準を満た
していない場合、アップロード時にエラーが発生する場合があります。新しい SSL 証明書を作成し、
アップロードします。
コンソールを使用したリスナーの追加と削除
ロードバランサーにリスナーを追加するには
1.
2.
3.
4.
5.
6.
7.
[Edit] をクリックします。
[Edit Listeners] ダイアログボックスで、[Add ] をクリックします。
[Load Balancer Protocol] 列で、[HTTPS (Secure HTTP)] を選択します。これにより、[Load
Balancer Port]、[Instance Protocol]、および [Instance Port] の各列が更新されます。[Instance
Protocol] 列で、[HTTPS (Secure HTTP)] を選択します。これにより、[Instance Port] 列が更新され
ます。
Elastic Load Balancing では、HTTPS/SSL リスナーに対して、デフォルトで最新のセキュリティポ
リシー ELBSecurityPolicy-2015-03 が選択されています。これが推奨される設定です。このポリ
シーでは、SSL 接続のネゴシエーションにサーバーの優先順位（「事前定義された SSL セキュリ
ティポリシー (p. 32)」を参照）を使用します。
8.
[Cipher] 列で [Change] をクリックし、次のいずれかの操作を行います。
•
（推奨）[Predefined Security Policy] が選択されており、[ELBSecurityPolicy-2015-03] に設定
されていることを確認してから、[Save] をクリックしてください。
90
コンソールを使用したリスナーの追加と削除
•
•
[Predefined Security Policy] をクリックし、ポリシーを選択して、[Save] をクリックします。
[Custom] をクリックし、プロトコルと暗号を少なくとも 1 つずつ有効にします。[SSL Protocols]
で、有効または無効にするプロトコルを 1 つ以上選択します。SSL ネゴシエーションにサー
バーの優先順位を使用する場合に限り、[SSL Options] の [Server Order Preference] は選択し
たままにしておきます。[SSL Ciphers] で、有効または無効にする暗号を 1 つ以上選択します。
Tip
DSA および RSA の暗号は署名アルゴリズムに固有の暗号です。SSL 証明書がすでに
ある場合は、証明書を作成するときに使用した暗号を有効にする必要があります。
9.
証明書をロードバランサーにすでにインストールしており、これを使用し続ける場合は、このス
テップを省略できます。
[SSL Certificate] 列で [Change] をクリックし、次のいずれかの操作を行います。
•
[Choose from an existing SSL Certificate] を選択します。[Certificate Name] で証明書を選択
し、[Save] をクリックします。
•
[Upload a new SSL Certificate] を選択します。証明書の名前を入力します。[Private Key] に、
PEM エンコードされたプライベートキーファイルの内容をコピーして貼り付けます。[Public
Key Certificate] に、PEM エンコードされたパブリックキー証明書ファイルの内容をコピーし
て貼り付けます。自己署名証明書を使用しておらず、ブラウザが暗黙的に証明書を受け入れる
ことが重要である場合に限り、[Certificate Chain] に、PEM エンコードされた証明書チェーン
ファイルの内容をコピーして貼り付けます。
10. （オプション）[Add] をクリックしてその他のリスナーを追加します。
11. [Save] をクリックして、先ほど設定したリスナーを追加します。
ロードバランサーからリスナーを削除するには
1.
2.
3.
4.
5.
[Edit] をクリックします。
91
AWS CLI を使用したリスナーの追加と削除
6.
7.
リスナーの横にある削除アイコンをクリックします。
AWS CLI を使用してロードバランサーにリスナーを追加するには
1.
2.
SSL 証明書の Amazon リソースネーム（ARN）を取得します。たとえば、
arn:aws:iam::55555555555:server-certificate/production/myservercert と指定し
ます。
次の create-load-balancer-listeners をコマンドを使用して、ロードバランサーにリスナーを追加し
ます。
aws elb create-load-balancer-listeners --load-balancer-name my-loadbalancer
--listeners Protocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTPS,In
stancePort=443,SSLCertificateId=arn:aws:iam::55555555555:server-certific
ate/production/myservercert
3.
（オプション）次の describe-load-balancers コマンドを使用して、ロードバランサーの更新後の
詳細を表示できます。
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
{
{
"Subnets": [],
"CanonicalHostedZoneName": "my-loadbalancer-012345678.us-east1.elb.amazonaws.com",
{
"Listener": {
},
"PolicyNames": [
]
},
{
"Listener": {
"InstancePort": 80,
92
"Protocol": "HTTP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
"DNSName": "my-loadbalancer-012345678.us-east-1.elb.amazon
aws.com",
"Policies": {
"OtherPolicies": [
]
},
"LoadBalancerName": "my-loadbalancer",
"CreatedTime": "2014-03-19T03:24:02.650Z",
"us-east-1a"
],
}
}
]
}
AWS CLI を使用してロードバランサーからリスナーを削除するには
1.
次の delete-load-balancer-listeners コマンドを使用します。
aws elb delete-load-balancer-listeners --load-balancer-name my-loadbalancer
--load-balancer-ports 80
2.
（オプション）次の describe-load-balancers コマンドを使用して、ロードバランサーの更新後の
詳細を表示できます。
93
{
{
"Subnets": [],
{
"Listener": {
},
"PolicyNames": [
]
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
aws.com",
"Policies": {
"OtherPolicies": [
]
},
"CreatedTime": "2014-03-19T03:24:02.650Z",
"us-east-1a"
],
}
}
]
}
94
インスタンスの登録解除と登録
ロードバランサーでの EC2 インスタンスの登録解
除と登録
Abstract
ロードバランサーで EC2 インスタンスの登録と登録解除を行います。
Elastic Load Balancing は、関連付けられた IP アドレスを使用して EC2 インスタンスをロードバラン
サーに登録します。EC2-Classic で起動した EC2 インスタンスを停止して開始すると、インスタンス
に関連付けられた IP アドレスが変わります。ロードバランサーは新しい IP アドレスを認識しません。
EC2-Classic で起動した登録済みの EC2 インスタンスを停止してから起動する場合は、停止したイン
スタンスをロードバランサーから登録解除し、再起動したインスタンスを再登録する必要があります。
そうしないと、再起動したインスタンスへのトラフィックをロードバランサーがルーティングできない
可能性があります。
EC2-VPC 内でインスタンスを起動した場合、デフォルトでは、インスタンスに関連付けられた IP アド
レスは、インスタンスを停止して起動しても変わりません。ただし、EC2-VPC インスタンスを停止し
て起動した場合、停止したインスタンスが起動されたことをロードバランサーが認識するまで時間がか
かることがあります。その間、ロードバランサーは再起動したインスタンスに接続されていません。再
起動したインスタンスをロードバランサーに再登録することをお勧めします。
次の例では、停止したバックエンドインスタンスをロードバランサーから登録解除し、再起動したイン
スタンスをロードバランサーに登録します。
例
• コンソールを使用したインスタンスの登録解除と登録 (p. 95)
• AWS CLI を使用したインスタンスの登録解除と登録 (p. 96)
コンソールを使用したインスタンスの登録解除と登
録
停止したバックエンドインスタンスをロードバランサーから登録解除し、再起動したインスタンスを
ロードバランサーに登録することができます。
ロードバランサーからバックエンドインスタンスを登録解除するには
1.
2.
3.
インスタンスを停止します。詳細については、『Linux インスタンス用 Amazon EC2 ユーザーガイ
ド』の「インスタンスの停止と起動」を参照してください。
4.
5.
下部のペインで、[Instances] タブを選択します。
6.
7.
登録解除するインスタンスの [Actions] 列で、[Remove from Load Balancer] をクリックします。
確認を求めるメッセージが表示されたら、[Yes, Remove] をクリックします。
準備ができたら、次のようにしてインスタンスをロードバランサーに登録できます。
ロードバランサーにバックエンドインスタンスを登録するには
1.
95
AWS CLI を使用したインスタンスの登録解除と登録
3.
4.
インスタンスを再度起動します。詳細については、『Linux インスタンス用 Amazon EC2 ユーザー
ガイド』の「インスタンスの停止と起動」を参照してください。
5.
6.
[Edit Instances] をクリックします。
7.
8.
ロードバランサーに追加するインスタンスを選択します。
Save をクリックしてインスタンスを登録します。
2.
停止したバックエンドインスタンスをロードバランサーから登録解除し、再起動したインスタンスを
ロードバランサーに登録することができます。
ロードバランサーからバックエンドインスタンスを登録解除するには
1.
次の stop-instances コマンドを使用して、インスタンスを停止します。
aws ec2 stop-instances --instance-ids i-4e05f721
2.
次の deregister-instances-from-load-balancer コマンドを使用して、ロードバランサーからバック
エンドインスタンスを登録解除します。
aws elb deregister-instances-from-load-balancer --load-balancer-name myloadbalancer --instances i-4e05f721
ロードバランサーに登録されている残りのインスタンスをリスト表示する応答の例を次に示しま
す。
{
"Instances": [
{
}
]
}
準備ができたら、次のようにしてインスタンスをロードバランサーに登録できます。
ロードバランサーにバックエンドインスタンスを登録するには
1.
次の start-instances コマンドを使用して、インスタンスを再起動します。
aws ec2 start-instances --instance-ids i-4e05f721
2.
次の register-instances-with-load-balancer コマンドを使用して、ロードバランサーにバックエンド
インスタンスを登録します。
96
aws elb register-instances-with-load-balancer --load-balancer-name my-load
balancer --instances i-4e05f721
ロードバランサーに登録されているインスタンスをリスト表示する応答の例を次に示します。
{
"Instances": [
{
},
{
"InstanceId": "i-4e05f721"
}
]
}
97
SSL ネゴシエーション設定の更新
ロードバランサーの SSL ネゴシエーション設定の
更新
Abstract
このユーザーシナリオでは、ロードバランサーの SSL ネゴシエーション設定を更新します。
Elastic Load Balancing は、クライアントとロードバランサーの間の SSL 接続のネゴシエーションに使
用される SSL ネゴシエーション設定を事前定義したセキュリティポリシーを提供します。リスナーに
HTTPS/SSL プロトコルを使用している場合、クライアントとロードバランサーの間の SSL 接続のネ
ゴシエーションに、事前定義のセキュリティポリシーのいずれかを使用するか、独自のカスタムセキュ
リティポリシーを使用する可能性が高くなります。
セキュリティポリシーの詳細については、「Elastic Load Balancing の SSL ネゴシエーション設
定 (p. 30)」を参照してください。Elastic Load Balancing で提供されるすべてのセキュリティポリシー
の現在の設定については、「事前定義された SSL セキュリティポリシー (p. 32)」を参照してくださ
い。
セキュリティポリシーを関連付けないで HTTPS/SSL リスナーを作成する場合、Elastic Load Balancing
はロードバランサーに最新バージョン ELBSecurityPolicy-2015-03 を関連付けます。
既存のロードバランサーで、最新のプロトコルと暗号を使用しない SSL ネゴシエーション設定にして
いる場合、ロードバランサーを最新バージョン ELBSecurityPolicy-2015-03 にアップグレードすること
をお勧めします。希望に応じて、カスタム設定を作成できます。ロードバランサー設定をアップグレー
ドする前に、まず新しいセキュリティポリシーをテストすることを強くお勧めします。
次の例では、既存のロードバランサー用の HTTPS/SSL リスナーの SSL ネゴシエーション設定を更新
する方法を示しています。
例
• コンソールを使用した SSL ネゴシエーション設定の更新 (p. 98)
• AWS CLI を使用した SSL ネゴシエーション設定の更新 (p. 99)
コンソールを使用した SSL ネゴシエーション設定の
更新
HTTPS/SSL ロードバランサーの SSL ネゴシエーション設定を更新するには
1.
2.
3.
4.
5.
6.
更新するリスナーの [Cipher] 列の [Change] をクリックします。
[Select a Cipher] ダイアログボックスで、以下のいずれかのオプションを使用してセキュリティポ
リシーを選択します。
•
•
[Predefined Security Policy] をクリックし、リストからいずれかの定義済みポリシーを選択し
て、[Save] をクリックします。
[Custom Security Policy] をクリックし、有効にする 1 つ以上のプロトコルを選択します。次
に、[Server Order Preference] を選択して SSL ネゴシエーション用に事前定義された SSL セ
キュリティポリシー (p. 32) に表示された順序を使用し、有効にする 1 つ以上の暗号を選択し
て（SSL 証明書がある場合は、証明書の作成に使用された暗号を有効にする必要がありま
す）、[Save] をクリックします。
98
AWS CLI を使用した SSL ネゴシエーション設定の更新
AWS CLI を使用した SSL ネゴシエーション設定の更
新
この例では、SSLNegotiationPolicyType ポリシーを作成して、事前定義されたセキュリティポリシーの
最新バージョンである ELBSecurityPolicy-2015-03 を使用する処理について順を追って説明します。
この例には、カスタムセキュリティポリシーの作成手順も含まれます。カスタムセキュリティポリシー
を作成する場合は、ステップ 1 をスキップできます。
1.
次の describe-load-balancer-policies コマンドを使用して、Elastic Load Balancing によって提供さ
れるセキュリティポリシーを一覧表示します。
aws elb describe-load-balancer-policies
応答には、Elastic Load Balancing によって提供されるすべてのセキュリティポリシーの名前が含
まれます。セキュリティポリシーのタイプはすべて SSLNegotiationPolicyType で、SSL/HTTPS リ
スナーに使用されます。
2.
ELBSecurityPolicy-2015-03 ポリシーでは、SSL 接続のネゴシエーションにサーバーの優先順位を
使用します。事前定義されたセキュリティポリシーの現在の設定については、「事前定義された
SSL セキュリティポリシー (p. 32)」を参照してください。
次の create-load-balancer-policy コマンドを使用して、事前定義されたセキュリティポリシー
ELBSecurityPolicy-2015-03 またはカスタムセキュリティポリシーのいずれかを利用する SSL
ネゴシエーションのポリシーを作成します。
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer
--policy-name MySSLNegotiationPolicy --policy-type-name SSLNegotiation
Policy
Type --policy-attributes AttributeName=Reference-Security-Policy,Attribute
Value=ELBSecurityPolicy-2015-03
また、要件を満たすプロトコルと暗号を有効にすることでカスタムセキュリティポリシーを作成す
るには、次のオプションを使用します。
Note
最低 1 つのプロトコルと 1 つの暗号を有効にしなければなりません。必要な作業は、有効
にする属性を true に設定するだけです。
DSA および RSA の暗号は署名アルゴリズムに固有であり、SSL 証明書を作成するために
使用されます。すでに SSL 証明書がある場合は、証明書を作成するときに使用された暗号
カスタムポリシー名には、ELBSecurityPolicy- または ELBSample- プレフィックスを
含めることはできません。これらのプレフィックスは、Elastic Load Balancing が事前定義
したセキュリティポリシー名に使用されます。カスタムセキュリティポリシー名でこれら
のプレフィックスの 1 つを読み取ると Elastic Load Balancing はエラーをスローします。
• attributes
99
• AttributeName = DHE-RSA-AES256-SHA256
• [オプション] AttributeName = Server-Defined-Cipher-Order
• [オプション] AttributeValue = true
Note
SSL ネゴシエーションにサーバーの優先順序（事前定義された SSL セキュリティポ
リシー (p. 32)のリストの順番）を使用する場合は、Server-Defined-Cipher-Order
• load-balancer-name = my-loadbalancer
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer
--policy-name MySSLNegotiationPolicy --policy-type-name SSLNegotiationPoli
cyType
--policy-attributes AttributeName=Protocol-TLSv1.2,AttributeValue=true
AttributeName=Protocol-TLSv1.1,AttributeValue=true AttributeName=DHE-RSAAES256-SH
A256,AttributeValue=true AttributeName=Server-Defined-Cipher-Order,Attrib
uteValue=true
3.
次の describe-load-balancer-policies コマンドを使用して、ポリシーが作成されたことを確認しま
す。
aws elb describe-load-balancer-policies --load-balancer-name my-loadbalancer
--policy-name MySSLNegotiationPolicy
4.
応答には、ポリシーの説明が含まれます。
次の set-load-balancer-policies-of-listener コマンドを使用して、新しく作成したポリシーをロード
バランサーのポート 443 で有効にします。
aws elb set-load-balancer-policies-of-listener --load-balancer-name myloadbalancer --load-balancer-port 443 --policy-names MySSLNegotiationPolicy
5.
次の describe-load-balancers コマンドを使用して、新しいポリシーがロードバランサーのポート
に対して有効になっていることを確認します。
{
{
"Subnets": [],
100
"CanonicalHostedZoneName": "my-loadbalancer-34503258.us-east1a.elb.amazonaws.com",
{
"Listener": {
},
"PolicyNames": [
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "HTTP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
aws.com",
"Policies": {
"OtherPolicies": [
]
},
"CreatedTime": "2014-03-19T03:24:02.650Z",
"us-east-1a"
],
}
}
101
]
}
ロードバランサーポート 443 に対して MySSLNegotiationPolicy が有効になっていることがわ
かります。
102
ドメイン名の設定
ロードバランサーのカスタムドメイン名の設定
Abstract
このユーザーシナリオでは、ロードバランサーが読みやすいカスタムドメイン名を設定します。
作成した各ロードバランサーには、DNS（ドメインネームシステム）名が自動的に付けられます。通
常、DNS 名にはロードバランサーが作成される AWS リージョンの名前が含まれます。たとえば、US
East (N. Virginia) リージョンで myLB という名前のロードバランサーを作成した場合、そのロードバラ
ンサーの DNS 名は myLB-1234567890 のようになります。 us-east-1.elb.amazonaws.comロードバラ
ンサーに接続するには、インターネットに接続したウェブブラウザのアドレスフィールドに、Elastic
Load Balancing で生成された DNS 名を貼り付ける必要があります。
ロードバランサーの DNS 名ではなく www.example.com のようなユーザーが分かりやすいドメイン名
を使用する場合は、カスタムドメイン名を作成して、カスタムドメイン名とロードバランサーの DNS
名を関連付けます。作成したカスタムドメイン名を使用してロードバランサーにリクエストを送ると、
ロードバランサーの DNS 名に解決されます。
ロードバランサーのインスタンスにカスタムドメイン名を使用するには、最初に DNS サービスプロバ
イダにドメイン名を登録する必要があります。
ドメイン名を登録する際は、ドメイン名自体だけでなく、一連のサブドメイン名全体も予約することに
なります。たとえば、example.com をカスタムドメイン名として登録する場合、foo.bar.example.com
や foo.myLB.example.com などのサブドメイン名を作成することができます。この一連のドメインとサ
ブドメイン名は、ゾーンと呼ばれます。予約した example.com などのドメイン名は、ゾーンの階層の
最上部にあるため、Zone Apex と呼ばれます。
カスタムドメイン名を登録したら、カスタムドメイン名をロードバランサー DNS 名に関連付ける必要
があります。
カスタムドメイン名とロードバランサー名の関連付
け
カスタムドメイン名とロードバランサー DNS 名の関連付けには、次のいずれかの方法を使用すること
ができます。
• Option 1: 既存のドメイン名プロバイダでゾーンの正規名（CNAME）レコードを作成します。
CNAME レコードは、ドメイン名が別の CNAME ドメイン名のエイリアスであることを示していま
す。CNAME レコードの作成プロセスは簡単です。ドメイン名登録機関の多くは、ユーザーが自分で
CNAME レコードを作成するためのセルフサービスツールを提供しています。CNAME レコードにつ
いては、Wikipedia の記事「CNAME レコード」を参照してください。
次の例では、エイリアス（www.domain.example.com）を、正規名（ロードバランサーの DNS 名）
と関連付けることによって、CNAME レコードを作成します。
www.domain.example.com CNAME myLB-1234567890.us-east-1.elb.amazonaws.com
EC2-Classic で起動されるロードバランサー用の CNAME レコードは、ロードバランサーインスタン
スの 3 つのパブリック DNS 名のどれを使用しても作成できます。
dualstack.myLB-1234567890.us-east-1.elb.amazonaws.com のような「dualstack」プレ
フィックス付きの DNS 名を使用すると、クライアントは、EC2-Classic のロードバランサーとの接
続に IPv4 または IPv6 接続を使用できます。 IPv6 サポートは、現在、Amazon VPC（EC2-VPC）の
ロードバランサーでは使用できません。
103
カスタムドメイン名とロードバランサー名の関連付け
CNAME レコードを使用して、Zone Apex と Elastic Load Balancing インスタンスを関連付けること
はできません。DNS ルールでは Zone Apex（example.com など）での CNAME レコードの作成が許
可されていません。たとえば、example.com というドメイン名を所有している場合、サブドメイン
名である foo.example.com には CNAME レコードを使用できますが、Zone Apex である
example.com には使用できません。
Zone Apex とロードバランサーの DNS 名を関連付ける場合は、次のオプションを使用します。
• Option 2: DNS サービスとして Amazon Route 53 を使用してドメインを作成します。
Amazon Route 53 は、ドメインに関する情報をホストゾーンに格納します。ホストゾーンとは、DNS
ネームサーバーのゾーンファイルに類似した Amazon Route 53 の概念です。ゾーンファイルと同様、
ホストゾーンにも、ドメイン内のサブドメインや名前と IP アドレスのマッピングといった、ドメイ
ン名に関する情報が含まれます。Amazon Route 53 については、「What is Route 53 and How Does
it Work?」を参照してください。
このオプションを使用して、Zone Apex とロードバランサーの DNS 名を関連付けます。Amazon
Route 53 は、ドメイン（example.com など）のホストゾーンを作成し、エイリアスのリソースレコー
ドのセットを作成するために使用します。エイリアスのリソースレコードのセットには、DNS リソー
スレコードを含むリソースレコードセットに対するポインタが含まれます。たとえば、example.com
のようなドメインのエイリアスリソースレコードセットにより、ロードバランサーインスタンスの
DNS 名を指すことができます。
Zone Apex は、EC2-Classic で起動されたロードバランサーインスタンスの 3 つのパブリック DNS
名のどれにでも関連付けることができます。dualstack をプレフィックスとする DNS 名（たとえ
ば、dualstack.myLB-1234567890.us-east-1.elb.amazonaws.com）を使用すると、クライアントは、
EC2-Classic のロードバランサーとの接続に IPv4 または IPv6 接続を使用できます。IPv6 サポート
は、現在、Amazon VPC（EC2-VPC）のロードバランサーでは使用できません。
ホストゾーンを作成したら、エイリアスリソースレコードセットを作成して、サブドメイン名とロー
ドバランサーインスタンスを関連付けることもできます。
DNS フェイルオーバー: Route 53 を使用し、カスタムドメイン名を作成してロードバランサーに関
連付ける場合は、ロードバランサーに対して DNS フェイルオーバーの有効化を選択することができ
ます。DNS フェイルオーバーを有効化すると、Route 53 は、関連付けられた 1 次および 2 次のロー
ドバランサーインスタンスのヘルスチェックに基づいて、エイリアスレコードセット example.com
へのクエリに応答します。
ロードバランサーに対して DNS フェイルオーバーを有効にするには、「ロードバランサーに対する
DNS フェイルオーバーの設定 (p. 123)」を参照してください。
前提条件
ロードバランサーの DNS 名とカスタムドメイン名の関連付けを始めるには、最初にロードバランサー
を作成する必要があります。基本的なロードバランサーの作成については、「Elastic Load Balancing
の使用開始 (p. 19)」を参照してください。HTTPS/SSL ロードバランサーの作成については、
「HTTPS/SSL ロードバランサーの作成 (p. 46)」を参照してください。
Note
Elastic Load Balancing DNS エントリの有効期限 (TTL) は、60 秒に設定されています。この設
定により、Elastic Load Balancing の拡張または縮小を伴うベントに対応して、IP アドレスが
迅速に再マッピングされます。
104
カスタムドメイン名とロードバランサー名の関連付け
Option 1: サブドメインとロードバランサーの CNAME レコード
の作成
CNAME レコードを作成するには
1.
カスタムドメイン名を DNS プロバイダに登録します。ドメイン名の登録に使用できる登録機関
ウェブサイトの一覧については、ICANN を参照してください。ドメイン名が登録されたという通
知を登録機関から受けるまで待ってください。
2.
サブドメイン名を作成して、ロードバランサーの DNS 名と関連付けます。たとえば、カスタムド
メイン名が example.com の場合、foo.mylb.example.com のようなサブドメイン名を作成すること
ができます。
3.
コンソールを使用して、ロードバランサーのパブリック DNS 名を取得します。
a.
b.
ナビゲーションペインの [NETWORK & SECURITY] にある [Load Balancers] をクリックしま
す。
下のペインには、ロードバランサーの詳細が表示されます。ロードバランサーの DNS 名を書
き留めます。
c.
d.
4.
次の例に示すように、CNAME レコードを作成して、カスタムサブドメイン名とロードバランサー
の DNS 名を関連付けます。
Note
DNS ネームサービスを提供している会社（ドメイン名登録機関）に依頼して、お使いの
ゾーンの CNAME レコードの作成を依頼します。ドメイン名登録機関の多くは、ユーザー
が自分で CNAME レコードを作成するためのセルフサービスツールを提供しています。
www.domain.my-loadbalancer.example.com CNAME my-loadbalancer-1234567890.useast-1.elb.amazonaws.com
Option 2: Amazon Route 53 ホストゾーンの作成
ホストゾーンを作成するには
1.
2.
カスタムドメイン名を DNS プロバイダに登録します。ドメイン名の登録に使用できる登録機関
ウェブサイトの一覧については、ICANN を参照してください。登録機関からドメイン名が登録さ
れたという通知を受けるまで待ってください。
Amazon Route 53 を使用して、カスタムドメイン名のホストゾーンを作成します。詳細な手順に
ついては、「ホストゾーンの作成Amazon Route 53 開発者ガイド」を参照してください。
他の AWS 製品と同様、Amazon Route 53 を使用するための契約や最低契約金はありません。設定
したホストゾーンおよび Route 53 から回答があったクエリ数に対してのみお支払いください。詳
細については、Route 53 料金表を参照してください。
3.
Route 53 は、作成されたホストゾーンごとに 4 つのネームサーバー（NS）レコードを自動的に作
成します。これら 4 つのネームサーバーは委託セットと呼ばれます。ドメインネームシステムがド
メインのクエリを Route 53 ネームサーバーにルーティングし始める前に、Route 53 ネームサー
バーを指すよう登録機関か DNS サービスのネームサーバーレコードを更新しておく必要がありま
す。
105
ドメイン名とロードバランサーの関連付けの解除
ホストゾーンに割り当てられた 4 つのネームサーバーを取得するには、「Getting the Name Servers
for a Hosted Zone」の手順に従います。
4.
Route 53 で割り当てられたネームサーバーを指すよう登録機関か DNS サービスのネームサーバー
レコードを更新するには、「Name Server（NS）Records」の手順に従ってください。
Zone Apex と DNS 名の関連付けに使用するエイリアスリソースレコードセットを作成します。
ドメイン名とロードバランサーの関連付けの解除
ロードバランサーインスタンスからドメイン名の関連付けを解除するには、まずホストゾーンのリソー
スレコードセットを削除してから、ホストゾーンを削除します。
ドメイン名とロードバランサーの関連付けを解除するには
1.
Amazon Route 53 ホストゾーンのエイリアスリソースレコードを削除します。
Amazon Route 53 コンソールの使用については、『Amazon Route 53 開発者ガイド』の「リソー
スレコードセットの作成、変更、および削除」を参照してください。
Note
weight パラメータの値は、rr-name パラメータで指定したリソースレコードセットの作
成に使用した値と一致する必要があります。元のウェイトの値がわからない場合は、Amazon
Route 53 ListResourceRecordSets アクションを使って値を取得することができます。
詳細については、『Amazon Route 53 API Reference』の「 ListResourceRecordSets」を
参照してください。weight パラメータの詳細については、『Amazon Route 53 開発者ガ
イド』の「重み付けされたリソースレコードセットの設定」を参照してください。
2.
ロードバランサー DNS 名に関連付けられているホストゾーンの削除
詳細については、『Amazon Route 53 開発者ガイド』の「ホストゾーンの削除」を参照してくだ
さい。
ロードバランサーのクロスゾーン負荷分散の有効
化または無効化
Abstract
このユーザーシナリオでは、ロードバランサーのクロスロード負荷分散を有効または無効にします。
Elastic Load Balancing には、ロードバランサーに対してクロスゾーン負荷分散を有効または無効にす
るオプションが用意されています。
クロスゾーン負荷分散を使用すると、ロードバランサーノードはすべてのアベイラビリティーゾーン間
でバックエンドインスタンスへのトラフィックをルーティングします。詳細については、アベイラビリ
ティーゾーンとリージョン (p. 6) を参照してください。
このセクションでは、ロードバランサーでクロスゾーン負荷分散を有効または無効にする手順について
説明します。
目次
• クロスゾーン負荷分散の有効化 (p. 107)
106
クロスゾーン負荷分散の有効化
• クロスゾーン負荷分散の無効化 (p. 108)
クロスゾーン負荷分散の有効化
コンソールを使用してクロスゾーン負荷分散を有効にするには
1.
2.
3.
4.
必要に応じ、リージョンを変更します。ナビゲーションバーで、ロードバランサーがあるリージョ
ンを選択します。
5.
6.
下部のペインで、[Cross-Zone Load Balancing: Disabled] 行の [(Edit)] をクリックします。
[Configure Cross-Zone Load Balancing] ダイアログボックスで、[Enable] を選択します。
7.
AWS CLI を使用してクロスゾーン負荷分散を有効にするには
CrossZoneLoadBalancing 属性の値を true に設定して、ロードバランサーの属性を変更する必要が
あります。
1.
次の modify-load-balancer-attributes コマンドを使用します。
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer
--load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":true}}"
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": true
}
},
"LoadBalancerName": "my-loadbalancer"
}
2.
次の describe-load-balancer-attributes コマンドを使用して、クロスゾーン負荷分散がロードバラ
ンサーに対して有効になっていることを確認します。
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
{
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"Enabled": true
107
クロスゾーン負荷分散の無効化
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
ロードバランサーに対してクロスゾーン負荷分散オプションをいつでも無効にすることができます。
ロードバランサーのクロスゾーン負荷分散を無効にするには、ロードバランサーの
CrossZoneLoadBalancing 属性を変更する必要があり、属性の値を false に設定します。
コンソールを使用してクロスゾーン負荷分散を無効にするには
1.
2.
3.
4.
5.
6.
7.
下部のペインで、[Cross-Zone Load Balancing: Enabled] 行の [(Edit)] をクリックします。
[Configure Cross-Zone Load Balancing] ダイアログボックスで、[Disable] を選択します。
AWS CLI を使用してクロスゾーン負荷分散を無効にするには
CrossZoneLoadBalancing 属性の値を false に設定して、ロードバランサーの属性を変更する必要
があります。
1.
--load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":false}}"
{
"Enabled": false
}
},
}
2.
次の describe-load-balancer-attributes コマンドを使用して、クロスゾーン負荷分散がロードバラ
ンサーに対して無効になっていることを確認します。
108
{
"Enabled": false,
"Timeout": 300
},
"Enabled": false
},
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
109
Connection Draining の有効化と無効化
ロードバランサーに対するConnection Drainingの
有効化または無効化
Abstract
ロードバランサーの Connection Draining の設定ついて説明します。
ロードバランサーに対してConnection Drainingを有効または無効にすることができます。Connection
Drainingを使用すると、バックエンドインスタンスが登録解除中または正常でなくなったときに、ロー
ドバランサーは実行中のリクエストの処理を継続しながら、新しいリクエストがインスタンスに送られ
ないようにします。詳細については、「Connection Draining (p. 11)」を参照してください。
Connection Drainingを有効にする場合、ロードバランサーがインスタンスの登録解除を報告する前に接
続を保持しておく最大時間を指定できます。最大タイムアウト値は 1 ～ 3,600 秒の間で設定できます。
最大タイムアウト時間を指定しない場合、デフォルトで、ロードバランサーは登録解除されたインスタ
ンスへの接続を 300 秒後に閉じます。
登録されたインスタンスが登録解除されるか正常でなくなった場合にインスタンスへの接続をただちに
閉じるには、ロードバランサーに対してConnection Drainingを無効にします。Connection Draining属性
が無効になっていると、登録解除中または異常が発生したインスタンスへの処理中のリクエストは完了
しません。
目次
• コンソールを使用した Connection Draining の有効化と無効化 (p. 110)
• AWS CLI を使用した Connection Draining の有効化と無効化 (p. 111)
コンソールを使用した Connection Draining の有効化
と無効化
次の手順に従って、Connection Draining を有効または無効にできます。
コンソールを使用して Connection Draining を有効にするには
1.
2.
3.
4.
5.
6.
[Connection Draining] の横にある [(Edit)] をクリックします。
[Configure Connection Draining] ダイアログボックスで、[Enable Connection Draining] を選択しま
す。
（オプション）[Timeout] フィールドに、最大制限時間を入力します。この値は 1 ～ 3,600 秒の間
で設定できます。
7.
8.
コンソールを使用して Connection Draining を無効にするには
1.
2.
3.
4.
110
AWS CLI を使用した Connection Draining の有効化と無効
化
5.
6.
7.
[Connection Draining] の横にある [(Edit)] をクリックします。
[Configure Connection Draining] ダイアログボックスで、[Enable Connection Draining] の選択を解
除します。
AWS CLI を使用した Connection Draining の有効化
と無効化
Connection Draining を有効にするには、ロードバランサーの ConnectionDraining 属性を true に
設定する必要があります。必要に応じて、Timeout 値を指定できます。
AWS CLI を使用して接続のストリーミングを有効にするには
1.
--load-balancer-attributes "{\"ConnectionDraining\":{\"En
abled\":true,\"Timeout\":300}}"
{
"Enabled": true,
"Timeout": 300
}
},
}
2.
（オプション）次の describe-load-balancer-attributes コマンドを使用して、Connection Draining
がロードバランサーに対して有効になっていることを確認します。
{
"Enabled": true,
"Timeout": 300
},
"Enabled": false
},
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
111
AWS CLI を使用した Connection Draining の有効化と無効
化
}
}
}
Connection Draining を無効にするには、ロードバランサーの ConnectionDraining 属性を false に
設定する必要があります。
AWS CLI を使用して接続のストリーミングを無効にするには
1.
--load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":false}}"
{
"Enabled": false,
"Timeout": 300
}
},
}
2.
次の describe-load-balancer-attributes コマンドを使用して、Connection Draining がロードバラン
サーに対して有効になっていることを確認します。
{
"Enabled": false,
"Timeout": 300
},
"Enabled": false
},
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
112
アイドルタイムアウトの設定
ロードバランサーに対するアイドル接続のタイム
アウトの設定
Abstract
このユーザーシナリオを使用してロードバランサーのアイドル接続のタイムアウトを設定します。
デフォルトでは、Elastic Load Balancing はクライアントとバックエンドインスタンスへの接続につい
て、60 秒のアイドルタイムアウトを設定します。この接続のアイドルタイムアウトの設定は、いつで
も変更できます。アイドルタイムアウトについては、「アイドル接続のタイムアウト (p. 11)」を参照
ロードバランサーのアイドルタイムアウトは、1 ～ 3600 秒の範囲の任意の値に設定できます。
バックエンドインスタンスでキープアライブオプションを有効にしており、ロードバランサーで接続を
閉じるように設定する場合は、バックエンドインスタンスのキープアライブ設定を、ロードバランサー
のアイドルタイムアウト設定よりも大きい値に変更することをお勧めします。
次の例は、ロードバランサーのアイドルタイムアウトを設定する方法を示しています。
例
• コンソールを使用したアイドルタイムアウトの設定 (p. 113)
• AWS CLI を使用したアイドルタイムアウトの設定 (p. 113)
コンソールを使用したアイドルタイムアウトの設定
次の手順に従って、ロードバランサーのアイドルタイムアウトを設定します。
ロードバランサーのアイドルタイムアウトを設定するには
1.
2.
3.
4.
5.
6.
7.
下部のペインで、[Description] タブを選択します。
[Connection Settings] の横にある [(Edit)] をクリックします。
[Configure Connection Settings] ダイアログボックスで、[Idle Timeout] の値を入力します。
AWS CLI を使用したアイドルタイムアウトの設定
次の手順に従って、ロードバランサーのアイドルタイムアウトを設定します。
ロードバランサーのアイドルタイムアウトを設定するには
1.
--load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":30}}"
113
AWS CLI を使用したアイドルタイムアウトの設定
{
"IdleTimeout": 30
}
},
}
2.
（オプション）次の describe-load-balancer-attributes コマンドを使用して、ロードバランサーの
アイドルタイムアウトの設定が更新されていることを確認します。
{
"Enabled": false,
"Timeout": 300
},
"Enabled": false
},
"IdleTimeout": 30
},
"AccessLog": {
"Enabled": false
}
}
}
114
Proxy Protocol の設定
Proxy Protocol サポートの有効化または無効化
（ロードバランサー）
Abstract
このユーザーシナリオでは、ロードバランサーでの Proxy Protocol のサポート、人間が読んで理解できるヘッダー
を有効または無効にします。
フロントエンド接続とバックエンド接続の両方に Transmission Control Protocol（TCP）または Secure
Sockets Layer（SSL）を使用する場合、ロードバランサーは、デフォルトで、リクエストヘッダーを
変更せずにリクエストをバックエンドインスタンスに転送します。Proxy Protocol を有効にすると、発
信元 IP アドレス、送信先 IP アドレス、およびポート番号などの接続情報が含まれる、人間が読んで理
解できるヘッダーが、リクエストヘッダーの先頭に追加されます。これにより、ヘッダーがリクエスト
の一部としてバックエンドインスタンスに送信されます。
Proxy Protocol は、接続をリクエストする送信元から、接続先としてリクエストされた送信先に接続情
報を伝達するために使用されるインターネットプロトコルです。Elastic Load Balancing では Proxy
Protocol のバージョン 1 を使用します。このバージョンでは、人間が読んで理解できるヘッダー形式が
使われます。
Proxy Protocol は、SSL プロトコルまたは TCP プロトコルを使用するポートでのみ有効にすることが
できます。HTTP 以外のプロトコルを使用している場合か、HTTPS を使用していてロードバランサー
で SSL 接続を終了していない場合は、Proxy Protocol を使用してクライアントの発信元 IP を捕捉する
ことができます。
ロードバランサーの前に Proxy Protocol 対応のプロキシサーバーがある場合は、ロードバランサーで
Proxy Protocol を有効にしないでください。Proxy Protocol をプロキシサーバーとロードバランサーの
両方で有効にすると、プロキシサーバーからのヘッダーが既に追加されているリクエストに、さらにも
う 1 つのヘッダ－がロードバランサーにより追加されます。バックエンドインスタンスの設定によって
は、このような重複によってエラーが発生する可能性があります。
以下の図は、ロードバランサーの前にプロキシサーバーがある場合の Proxy Protocol の、正しい有効化
設定と正しくない有効化設定を示しています。
115
AWS CLI を使用した Proxy Protocol の有効化
このセクションでは、Proxy Protocol を有効にしてからバックエンドインスタンスに関連付ける手順に
ついて説明します。現行の Elastic Load Balancing コンソールでは、Proxy Protocol を有効化できませ
ん。
Prerequisites for Enabling Proxy Protocol
有効化を開始する前に、以下の手順が完了していることを確認します。
• フロントエンドリスナーとバックエンドリスナーの両方に SSL プロトコルか TCP プロトコルを指定
して、基本的なロードバランサーを作成した。詳細については、「Elastic Load Balancing の使用開
始 (p. 19)」を参照してください。
• バックエンドインスタンスで Proxy Protocol 情報を処理できることを確認した。
Topics
• AWS CLI を使用した Proxy Protocol の有効化 (p. 116)
Proxy Protocol を有効化するには、タイプ ProxyProtocolPolicyType のポリシーを作成し、作成し
たポリシーをバックエンドインスタンスのポートに設定します。
このチュートリアルでは、my-loadbalancer というロードバランサーに対してタイプ
ProxyProtocolPolicyType の新しいポリシー、EnableProxyProtocol を作成し、その作成した
ポリシーをバックエンドインスタンスのポート 80 に設定して、ポリシーが有効化されたことを確認し
ます。
ポリシーの作成
スナップショットを作成するには
1.
次の describe-load-balancer-policy-types コマンドを使用して、Elastic Load Balancing でサポート
されているすべてのポリシーを一覧表示します。
aws elb describe-load-balancer-policy-types
2.
Elastic Load Balancing の応答には、サポートされているポリシータイプの名前と説明が出力され
ます。次の応答の例は、サポートされているポリシータイプの一部を示しています。
{
"PolicyTypeDescriptions": [
116
{
"PolicyAttributeTypeDescriptions": [
{
"Cardinality": "ONE_OR_MORE",
"AttributeName": "PublicKeyPolicyName",
"AttributeType": "PolicyName"
}
],
"PolicyTypeName": "BackendServerAuthenticationPolicyType",
"Description": "Policy that controls authentication to back-end
server(s) and contains one or more policies, such as an instance of a
PublicKeyPolicyType. This policy can be associated only with back-end
servers that are using HTTPS/SSL."
},
{
{
"Cardinality": "ONE",
"AttributeName": "PublicKey",
"AttributeType": "String"
}
],
"PolicyTypeName": "PublicKeyPolicyType",
"Description": "Policy containing a list of public keys to accept
when authenticating the back-end server(s). This policy cannot be a
pplied directly to back-end servers or listeners but must be part of a
BackendServerAuthenticationPolicyType."
},
{
{
"AttributeName": "CookieName",
"AttributeType": "String"
}
],
"PolicyTypeName": "AppCookieStickinessPolicyType",
"Description": "Stickiness policy with session lifetimes con
trolled by the lifetime of the application-generated cookie. This policy
can be associated only with HTTP/HTTPS listeners."
},
{
{
"Cardinality": "ZERO_OR_ONE",
"AttributeName": "CookieExpirationPeriod",
"AttributeType": "Long"
}
],
"PolicyTypeName": "LBCookieStickinessPolicyType",
"Description": "Stickiness policy with session lifetimes con
trolled by the browser (user-agent) or a specified expiration period. Thi
s policy can be associated only with HTTP/HTTPS listeners."
},
{
{
117
"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 pol
icy operates on TCP/SSL listeners only"
},
{
{
"Cardinality": "ZERO_OR_ONE",
"AttributeName": "Protocol-SSLv2",
"AttributeType": "Boolean"
}
{
..............
}
],
"PolicyTypeName": "SSLNegotiationPolicyType",
"Description": "Listener policy that defines the ciphers and
protocols that will be accepted by the load balancer. This policy can be
associated only with HTTPS/SSL listeners."
}
]
}
新しいポリシー、EnableProxyProtocol を作成するために、ポリシータイプ
ProxyProtocolPolicyType を使用します。
3.
次の create-load-balancer-policy コマンドを使用して、新しいポリシーを作成します。
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer -policy-name EnableProxyProtocol --policy-type-name ProxyProtocolPolicyType
--policy-attributes AttributeName=ProxyProtocol,AttributeValue=True
ポリシーの有効化
ポリシーを有効化するには
•
次の set-load-balancer-policies-for backend-server コマンドを使用して、新しく作成したポリシー
をバックエンドインスタンスのポートに設定します。
my-loadbalancer --instance-port 80 --policy-names EnableProxyProtocol MyPo
licyName2 MyPolicyName3
set-load-balancer-policies-for-backend-server コマンドにより、インスタンスポート
に関連付けられている現在のポリシーセットが上書きされます。ポリシーを有効化するためにこの
コマンドを使用するときは、必ず --policy-names オプションを使用して、有効化したいすべて
のポリシーをリストします。
118
Proxy Protocol が有効化されたことの確認
Proxy Protocol が有効化されたことを確認するには
•
次の describe-load-balancers コマンドを使用して、Proxy Protocol が有効になっていることを確認
します。
{
{
"Subnets": [],
{
"Listener": {
},
"PolicyNames": [
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "TCP",
"InstanceProtocol": "TCP"
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Target": "TCP:443",
"Timeout": 5,
},
"BackendServerDescriptions": [
{
"InstancePort": 80,
"PolicyNames": [
"EnableProxyProtocol"
]
}
119
],
"Instances": [],
aws.com",
"Policies": {
"OtherPolicies": [
"MySSLNegotiationPolicy",
]
},
"CreatedTime": "2014-08-03T02:43:43.860Z",
"us-east-1c"
],
}
}
]
}
BackendServerDescriptions フィールド内の記述により、EnableProxyProtocol ポリシーがイ
ンスタンスのポート 80 に関連付けられたことを確認できます。
ポリシーの無効化
いつでも、バックエンドインスタンスに関連付けられたポリシーを無効化し、後で有効化することがで
きます。引き続き Proxy Protocol ポリシーのバックエンドインスタンスへの関連付けを行う場合は、こ
のステップはスキップしてください。
Proxy Protocol ポリシーを無効化するには
•
set-load-balancer-policies-for-backend-server コマンドを使用し、--policy-names オプションに
Proxy Protocol ポリシー名を指定しないことで、Proxy Protocol ポリシーを無効化します。
Note
set-load-balancer-policies-for-backend-server コマンドにより、インスタン
スポートに関連付けられている現在のポリシーセットが上書きされます。ポリシーを無効
化するためにこのコマンドを使用するときは、必ず --policy-names オプションを使用
して、有効化したいすべてのポリシーをリストすると共に、無効化したいポリシー名を指
定解除します。
instance port 80 用に有効化するポリシーが他にない場合は、次の例に示すように、
--policy-names オプションで空の文字列を使用します。
120
my-loadbalancer --instance-port 80 --policy-names "[]"
instance port 80 に対して Proxy Protocol ポリシー以外のポリシーを有効にするには、次の例
に示すように、--policy-names オプションを使用して他のポリシーを一覧表示します。
aws elb-set-lb-policies-for-backend-server my-loadbalancer --instance-port
80 --policy-names MyPolicyName2 MyPolicyName3
Proxy Protocol ポリシーが無効化されていることを確認するには
1.
次の describe-load-balancers コマンドを使用して、ポリシーが無効になっていることを確認しま
す。
2.
{
{
"Subnets": [],
"CanonicalHostedZoneName": "my-loadbalancer-521886987.us-east1a.elb.amazonaws.com",
{
"Listener": {
},
"PolicyNames": [
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "TCP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
121
"Timeout": 5,
},
"Instances": [],
"DNSName": "my-loadbalancer-521886987.us-east-1a.elb.amazon
aws.com",
"Policies": {
"OtherPolicies": [
]
},
"CreatedTime": "2014-08-03T02:43:43.860Z",
"us-east-1c"
],
}
}
]
}
[BackendServerDescriptions] フィールドが空であることにより、インスタンスのポートがどのポ
リシーにも関連付けられていないことを確認できます。80
122
DNS フェイルオーバーの設定
ロードバランサーに対する DNS フェイルオーバー
の設定
Abstract
このユーザーシナリオでは、ロードバランサーで高い可用性と冗長性を確保するために DNS フェイルオーバーを
有効にします。
ロードバランサーに対して Amazon Route 53 ドメインネームシステム (DNS) フェイルオーバーを有効
にすることで、Elastic Load Balancing の配下で実行されているアプリケーションの高可用性と冗長性
を実現します。Amazon Route 53 は、インフラストラクチャへの高い信頼性でのルーティングを提供
する DNS サービスです。DNS フェイルオーバーを有効化すると、Route 53 は、ヘルスチェック機能
を使用して、ロードバランサーの配下で実行されるアプリケーションの可用性を判定します。ロードバ
ランサーに正常な EC2 インスタンスが登録されていないか、またはロードバランサー自体に不具合が
ある場合、Route 53 は不具合のあるロードバランサーから利用可能な他のロードバランサーにトラ
フィックをルーティングします。
Amazon Route 53 については、「What is Route 53 and How Does it Work?を参照してください。
例を使って、Route 53 の DNS フェイルオーバーがロードバランサーで動作する仕組みを示します。お
客様が www.example.com 用のウェブアプリケーションを持っており、2 つの異なるリージョン（米国
東部(バージニア北部リージョン) と米国西部(オレゴンリージョン)）にある 2 つのロードバランサーの
配下で、冗長なアプリケーションを実行したいとします。www.example.com のトラフィックを第一に
米国東部のロードバランサーにルーティングし、米国西部のロードバランサーは、東部のロードバラン
サーが失敗した場合のバックアップとして使いたいとします。この例では、Route 53 の DNS フェイル
オーバーを使用した場合に DNS サービスでクエリを、ドメイン名、www.example.com にルーティン
グする方法を指定できます。DNS フェイルオーバーを有効化する場合には、プライマリおよびセカン
ダリ（バックアップ）ロードバランサーを指定する必要があります。フェイルオーバーのルーティング
メカニズムを有効化すると、Route 53 は、プライマリロードバランサーが利用可能な場合にはそれに
トラフィックを誘導し、利用可能でない場合にはセカンダリロードバランサーにトラフィック経路を変
更します。
DNS フェイルオーバーを設定するには、ドメイン名 www.example.com をロードバランサーと関連付
ける必要があります。各ロードバランサーには、自動的に作成された DNS 名が設定されます。DNS 名
の例: myLB-1234567890.us-east-1.elb.amazonaws.comRoute 53 を使用することで、ドメイン名
www.example.com に対し、以下のロードバランサーの DNS 名を指すレコードを作成することができ
ます。myLB-1234567890.us-east-1.elb.amazonaws.com
このセクションでは、2 つの異なるリージョンで実行されるロードバランサーに対し、Amazon Route
53 の DNS フェイルオーバーを有効化する手順について説明します。
前提条件
ロードバランサーに対して DNS フェイルオーバーを有効化するには、その前にまずロードバランサー
を作成しておく必要があります。プライマリおよびセカンダリロードバランサーを、できれば 2 つの異
なるリージョンに必ず作成します。基本的なロードバランサーの作成については、「Elastic Load
Balancing の使用開始 (p. 19)」を参照してください。
カスタムドメイン名がまだない場合は、ドメイン名を DNS プロバイダに登録します。ドメイン名の登
録に使用できる登録機関ウェブサイトの一覧については、ICANN.org を参照してください。ドメイン名
が登録されたという通知を登録機関から受けるまで待ってください。
123
コンソールを使用した DNS フェイルオーバーの設定
以下の手順は、Route 53 コンソールを使用して、ロードバランサーに対して DNS フェイルオーバーを
設定する方法を示しています。
1. カスタムドメイン名に対するホストゾーンを作成します。
2. Route 53 ネームサーバーを指すよう、DNS ネームサーバーレコードを更新します。
3. プライマリおよびセカンダリロードバランサーのエイリアスレコードセットを作成します。
カスタムドメイン名に対して Amazon Route 53 ホストゾーン
ホストゾーンには、サブドメインの名前やマッピングなど、ドメイン名に関する情報が格納されます。
カスタムドメイン名 www.example.com に対するホストゾーンを作成するには、Amazon Route 53 開
発者ガイドの Creating a Hosted Zone の手順に従います。
他の AWS 製品と同様、Amazon Route 53 を使用するための契約や最低契約金はありません。設定した
ホストゾーンおよび Route 53 から回答があったクエリ数に対してのみお支払いください。詳細につい
ては、Route 53 料金表を参照してください。
Route 53 ネームサーバーを指すよう、DNS ネームサーバーレ
コードを更新する
Route 53 は、作成されたホストゾーンごとに 4 つのネームサーバー（NS）レコードを自動的に作成し
ます。DNS がドメインのクエリを Route 53 ネームサーバーにルーティングし始める前に、Route 53
ネームサーバーを指すよう登録機関か DNS サービスのネームサーバーレコードを更新しておく必要が
あります。
1.
2.
ホストゾーンに割り当てられたネームサーバーを取得するには、「Getting the Name Servers for a
Hosted Zone」の手順に従います。
Route 53 で割り当てられたネームサーバーを指すよう登録機関か DNS サービスのネームサーバー
レコードを更新するには、「Name Server（NS）Records」の手順に従ってください。
エイリアスリソースレコードセットの作成と DNS フェイルオー
バーの有効化
ドメインに対するホストゾーンを作成したら、ドメインのトラフィックをルーティングする方法を DNS
に指示するプライマリおよびセカンダリエイリアスリソースレコードセットを作成する必要がありま
す。
1.
https://console.aws.amazon.com/route53/ にある Amazon Route 53 コンソールを開きます。
2.
ホストゾーンの行をクリックして、[Go to Record Sets] をクリックします。
124
3.
4.
5.
6.
7.
8.
[Create Record Set] をクリックします。
[Name] ボックスで、このレコードセットのドメイン名を入力するか、またはデフォルト値を使用
します。
[Type] ボックスで [A – Ipv4 address] を選択します。
[Alias] で [Yes] をクリックします。
[Alias Target] フィールドをクリックし、リストからプライマリロードバランサーを選択します。
[Alias Target] で選択または入力した値に基づいて、自動的に [Alias Hosted Zone ID] に値が表示さ
れます。
9. [Routing Policy:] ドロップダウンボックスで [Failover] を選択します。
10. [Failover Record Type:] で [Primary] を選択します。
11. [Set ID: ] で、レコードセットの ID を入力するか、またはデフォルト値を使用します。
12. [Evaluate Target Health] で [Yes] を選択します。
13. [Associate with Health Check] で [No] を選択します。
14. [Create Record Set] をクリックします。
125
15. もう 1 つのエイリアスレコードセットをセカンダリロードバランサー用に作成するため、同じ手順
に従ってください。ただし、以下の点が異なります。
• [Alias Target] フィールドでは、リストからセカンダリロードバランサーを選択します。
• [Failover Record Type:] では [Secondary] を選択します。
• Route 53 を使用してセカンダリロードバランサーの状態を評価する場合、[Evaluate Target Health]
で [Yes] を選択します。セカンダリロードバランサーに不具合がある場合、Route 53 はプライ
マリロードバランサーにトラフィック経路を戻します。[Evaluate Target Health] を [No] に設定
した場合、Route 53 では、セカンダリロードバランサーが正常であるものと見なすので、プラ
イマリロードバランサーに不具合があるときには必ずトラフィックをセカンダリロードバラン
サーにルーティングします。
DNS フェイルオーバーの高度な設定を行う方法については、『Amazon Route 53 開発者ガイド』の
「Managing Resource Availability with Route 53 DNS Failover」を参照してください。
126
スティッキーセッションの有効化と無効化
スティッキーセッションの有効化と無効化
Abstract
このユーザーシナリオでは、特定のアプリケーションインスタンスにユーザーセッションをバインドするためのス
ティッキーセッション（セッションアフィニティとも呼ばれます）を作成します。
デフォルトでは、ロードバランサーは負荷が最小になるように、各リクエストを個別にアプリケーショ
ンインスタンスにルーティングします。しかし、スティッキーセッション機能（セッションアフィニ
ティとも呼ばれます）を使用することで、特定のユーザーのセッションを特定のアプリケーションイン
スタンスにバインドさせることができます。これにより、セッション中にそのユーザーから来たリクエ
ストをすべて同じアプリケーションインスタンスに送信することができます。
スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じ
アプリケーションインスタンスにルーティングし続ける期間の決定です。アプリケーションに独自の
セッション Cookie がある場合は、アプリケーションのセッション Cookie で指定された期間に従うセッ
ション Cookie を作成するよう、Elastic Load Balancing を設定することができます。アプリケーション
に独自のセッション Cookie がない場合は、独自の維持期間を指定して、セッション Cookie を作成す
るよう Elastic Load Balancing を設定することができます。
要件
• HTTP/HTTPS ロードバランサー。
• 各アベイラビリティーゾーンに少なくとも 1 つの正常なアプリケーションインスタンスがあること。
目次
• 期間ベースのセッション維持 (p. 127)
• アプリケーション制御によるセッション維持 (p. 131)
期間ベースのセッション維持
ロードバランサーは、ロードバランサーが生成する特別な Cookie を使って、各リクエストのアプリ
ケーションインスタンスを追跡します。ロードバランサーがリクエストを受け取ると、まずこの Cookie
がリクエスト内にあるかどうかを調べます。ある場合は、Cookie で指定されたアプリケーションイン
スタンスにリクエストが送信されます。Cookie がない場合、ロードバランサーは、既存の負荷分散ア
ルゴリズムに基いてアプリケーションインスタンスを選択します。同じユーザーからの以降のリクエス
トをそのアプリケーションインスタンスにバインドするため、応答に Cookie が挿入されます。スティッ
キーポリシー設定では、各 Cookie の有効期間を設定する Cookie 期限を定義します。Cookie は有効期
限後に自動的に更新されます。
アプリケーションインスタンスでエラーや異常が発生した場合、ロードバランサーはそのインスタンス
へのリクエストのルーティングを中止し、代わりに既存の負荷分散アルゴリズムに基いて新しいインス
タンスを選択します。リクエストは、Cookie がなく、セッションが維持されていない場合と同様に、
新しいインスタンスにルーティングされます。
次の例は、ロードバランサーで生成された HTTP Cookie を使用して、ロードバランサーで期間ベース
のスティッキーセッションを有効にする方法を示しています。HTTPS/SSL ロードバランサーの設定に
ついては、「HTTPS/SSL ロードバランサーの作成 (p. 46)」を参照してください。
例
• コンソールを使用した期間ベースのスティッキーセッションの有効化 (p. 128)
• AWS CLI を使用した期間ベースのスティッキーセッションの有効化 (p. 129)
127
コンソールを使用した期間ベースのスティッキーセッションの
有効化
ロードバランサーで期間ベースのスティッキーセッションを有効にするには
1.
2.
3.
4.
下部のペインで、[Port Configuration:] 行の [(edit)] をクリックします。
5.
[Edit Stickiness ] ページで、[Enable Load Balancer Generated Cookie Stickiness] をクリックしま
す。
[Expiration Period] ボックスに、Cookie の有効期間を秒単位で入力し、[Save] をクリックします。
6.
[Description] ペインの [Port Configuration] 行に、新しく作成された Cookie の維持ポリシーが表示され
ます。
128
AWS CLI を使用した期間ベースのスティッキーセッションの有
効化
開始する前に、AWS CLI 環境をインストールして設定する必要があります。詳細については、「AWS
コマンドラインインターフェイスの設定」を参照してください。
ロードバランサーで期間ベースのスティッキーセッションを有効にするには
1.
次の create-lb-cookie-stickiness-policy コマンドを使用し、Cookie の有効期間を 60 秒に設定して、
ロードバランサーが生成する Cookie の維持ポリシーを作成します。
aws elb create-lb-cookie-stickiness-policy --load-balancer-name my-loadbal
ancer --policy-name MyDurationStickyPolicy --cookie-expiration-period 60
2.
次の set-load-balancer-policies-of-listener コマンドを使用して、ロードバランサーのセッション維
持を有効にします。
aws elb set-load-balancer-policies-of-listener --load-balancer-name myloadbalancer --load-balancer-port 443 --policy-names MyDurationStickyPolicy
Note
set-load-balancer-policies-of-listener コマンドは、指定されたロードバラン
サーのポートに関連付けられた現在の一連のポリシーを置き換えます。ポリシーを有効化
するためにこのコマンドを使用するときは、必ず --policy-names オプションを使用し
て、ポートで有効化するすべてのポリシーをリストします。
3.
次の describe-load-balancers コマンドを使用して、維持ポリシーが有効になっていることを確認
します。
{
{
"Subnets": [],
{
"Listener": {
},
"PolicyNames": [
"MyDurationStickyPolicy",
129
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "TCP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
aws.com",
"Policies": {
"LBCookieStickinessPolicies": [
{
"PolicyName": "MyDurationStickyPolicy",
"CookieExpirationPeriod": 60
}
],
"OtherPolicies": [
]
},
"CreatedTime": "2014-08-03T02:43:43.860Z",
"us-east-1a"
],
}
}
]
}
Listener 443 の PolicyNames フィールドに新しい MyDurationStickyPolicy ポリシーがリ
ストされ、このポリシーが有効になっていることを確認できます。
130
アプリケーション制御によるセッション維持
ロードバランサーは、特別な Cookie を使用して、リクエストを処理した元のサーバーにセッションを
関連付けますが、アプリケーションが生成する Cookie（ポリシー設定で指定した Cookie 名に対応）の
寿命に従います。ロードバランサーは、アプリケーションの応答に新しいアプリケーション Cookie が
含まれている場合のみ、新しい維持 Cookie を挿入します。ロードバランサー維持 Cookie はリクエス
トごとに更新されることはありません。アプリケーション Cookie が明示的に削除されるかまたは有効
期限切れになると、新しいアプリケーション Cookie が発行されない限り、セッションは sticky ではな
くなります。
アプリケーションインスタンスでエラーや異常が発生した場合、ロードバランサーはそのインスタンス
へのリクエストのルーティングを中止し、代わりに既存の負荷分散アルゴリズムに基いて新しい正常な
アプリケーションインスタンスを選択します。ロードバランサーは、セッションが新しい正常なインス
タンスで "維持" されていると見なし、エラーが発生したアプリケーションインスタンスが正常な状態
に戻っても、そのインスタンスにリクエストをルーティングし続けます。ただし、新しいアプリケー
ションインスタンスが以前に処理していなかったセッションに応答するかどうか、およびどのように応
答するかは、そのインスタンスによって異なります。
次の例では、ロードバランサーに対してアプリケーション制御によるスティッキーセッションを有効に
する方法を示しています。HTTPS/SSL ロードバランサーの設定の詳細については、「HTTPS/SSL ロー
ドバランサーの作成 (p. 46)」を参照してください。
例
• コンソールを使用したアプリケーション制御によるスティッキーセッションの有効化 (p. 131)
• AWS CLI を使用したアプリケーション制御によるスティッキーセッションの有効化 (p. 132)
コンソールを使用したアプリケーション制御によるスティッ
キーセッションの有効化
アプリケーション制御によるセッション維持を有効にするには
1.
2.
3.
4.
下部のペインで、[Port Configuration:] 行の [(edit)] をクリックします。
131
5.
6.
[Edit Stickiness ] ページで、[Enable Application Generated Cookie Stickiness] をクリックします。
[Cookie Name] ボックスに Cookie の名前を入力し、[Save] をクリックします。
[Description] ペインの [Port Configuration] 行に、新しく作成された Cookie の維持ポリシーが表示され
ます。
AWS CLI を使用したアプリケーション制御によるスティッキー
セッションの有効化
アプリケーション制御によるセッション維持を有効にするには
1.
次の create-app-cookie-stickiness-policy コマンドを使用して、アプリケーションが生成する Cookie
の維持ポリシーを作成します。
aws elb create-app-cookie-stickiness-policy --load-balancer-name my-loadbal
ancer --policy-name MyAppStickyPolicy --cookie-name MyAppCookie
2.
次の set-load-balancer-policies-of-listener コマンドを使用して、ロードバランサーのセッション維
持を有効にします。
aws elb set-load-balancer-policies-of-listener --load-balancer-name myloadbalancer --load-balancer-port 443 --policy-names MyAppStickyPolicy
Note
set-load-balancer-policies-of-listener コマンドは、指定されたロードバラン
サーのポートに関連付けられた現在の一連のポリシーを置き換えます。ポリシーを有効化
するためにこのコマンドを使用するときは、必ず --policy-names オプションを使用し
て、ポートで有効化するすべてのポリシーをリストします。
3.
次の describe-load-balancers コマンドを使用して、維持ポリシーが有効になっていることを確認
します。
4.
132
{
{
"Subnets": [],
{
"Listener": {
},
"PolicyNames": [
"MyAppStickyPolicy",
]
},
{
"Listener": {
"InstancePort": 80,
"Protocol": "TCP",
},
"PolicyNames": []
}
],
"HealthCheck": {
"Interval": 30,
"Timeout": 5,
},
"Instances": [],
aws.com",
"Policies": {
"AppCookieStickinessPolicies": [
{
"PolicyName": "MyAppStickyPolicy",
"CookieName": "MyAppCookie"
}
],
"OtherPolicies": [
]
133
},
"CreatedTime": "2014-08-03T02:43:43.860Z",
"us-east-1a"
],
}
}
]
}
Listener 443 の PolicyNames フィールドに新しい MyAppStickyPolicy ポリシーがリストさ
れ、このポリシーが有効になっていることを確認できます。
134
タグの追加または削除
ロードバランサーに対するタグの設定
Abstract
タグを使用して、ロードバランサーをさまざまな条件（目的、所有者、環境など）に基づいて分類する方法につい
て説明します。
タグを使用すると、ロードバランサーを目的、所有者、環境などさまざまな方法で分類することができ
ます。
各ロードバランサーに対して最大 10 個のタグを追加できます。タグキーは、各ロードバランサーで一
意である必要があります。すでにロードバランサーに関連付けられているキーを持つタグを追加する
と、そのキーの値が更新されます。
タグが不要になったら、ロードバランサーからタグを削除できます。
目次
• タグの制限 (p. 135)
• コンソールを使用したタグの追加と削除 (p. 135)
• AWS CLI を使用したタグの追加と削除 (p. 136)
タグの制限
タグには以下のような基本制限があります。
•
•
•
•
リソースあたりのタグの最大数 – 10
キーの最大長 – 127 文字（Unicode）
値の最大長 – 255 文字（Unicode）
タグのキーと値は大文字と小文字が区別されます。使用できる文字は、UTF-8 で表現できる文字、ス
ペース、および数字と、特殊文字 +、-、=、.、_、:、/、@ です。ただし、先頭または末尾にはスペー
スを使用しないでください。
• タグの名前または値に aws: プレフィックスは使用しないでください。このプレフィックスは AWS
用に予約されています。このプレフィックスが含まれるタグの名前または値は編集または削除できま
せん。このプレフィックスを持つタグは、リソースあたりのタグ数の制限時には計算されません。
コンソールを使用したタグの追加と削除
ロードバランサーにはいつでもタグを追加できます。
ロードバランサーにタグを追加するには
1.
2.
3.
4.
下部のペインで、[Tags] タブを選択します。
5.
6.
[Add/Edit Tags] をクリックします。
[Add/Edit Tags] ダイアログボックスで、[Create Tag] をクリックし、各タグのキーと値を指定しま
す。
135
AWS CLI を使用したタグの追加と削除
7.
タグを追加した後で、[Save] をクリックします。
タグが不要になったときはいつでも、ロードバランサーからタグを削除できます。
ロードバランサーからタグを削除するには
1.
2.
3.
4.
5.
6.
下部のペインで、[Tags] タブを選択します。
[Add/Edit Tags] をクリックします。
[Add/Edit Tags] ダイアログボックスで、削除するタグの削除アイコンをクリックします。
7.
タグを削除した後、[Save] をクリックします。
タグを追加するには、次の add-tags コマンドを使用します。
aws elb add-tags --load-balancer-name my-loadbalancer --tag Key=pro
ject,Value=lima
次の describe-tags コマンドを使用して、新しいタグが設定されていることを確認します。
aws elb describe-tags --load-balancer-name my-loadbalancer
136
{
"TagDescriptions": [
{
"Tags": [
{
"Value": "lima",
"Key": "project"
},
{
"Value": "digital-media",
"Key": "department"
}
],
}
]
}
タグを削除するには、次の remove-tags コマンドを使用します。
aws elb remove-tags --load-balancer-name my-loadbalancer --tag project
次の describe-tags コマンドを使用して、タグが削除されていることを確認します。
aws elb describe-tags --load-balancer-name my-loadbalancer
{
"TagDescriptions": [
{
"Tags": [
{
"Value": "digital-media",
"Key": "department"
}
],
}
]
}
137
モニタリングとロギング
Abstract
Elastic Load Balancing でキャプチャできるさまざまなログの種類を示します。
Elastic Load Balancing は、ロードバランサーに関する次の情報をキャプチャします。
• CloudWatch メトリックス — Elastic Load Balancing は、ロードバランサーとバックエンドアプリ
ケーションインスタンスに関するデータポイントを Amazon CloudWatch に発行します。CloudWatch
を使用すると、それらのデータポイントについての統計を、順序付けられた時系列データのセット
（メトリックスと呼ばれる）として取得できます。CloudWatch を使用すると、ロードバランサーと
バックエンドインスタンスのメトリックスをモニタリングして、システムのパフォーマンスが期待ど
おりか確認することができます。たとえば、特定のアベイラビリティゾーンで起動されたロードバラ
ンサーの配下にあるすべての異常な EC2 インスタンスのメトリックスを要求したり、ロードバラン
サーとバックエンドインスタンスの間で確立に失敗した接続数のメトリックスを要求したりすること
ができます。
• アクセスログ — Elastic Load Balancing のアクセスログは、ロードバランサーに対するすべてのリク
エストの詳細情報をキャプチャし、それをログファイルとして、指定した Amazon S3 バケットに格
納します。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテンシー、
リクエストのパス、サーバーレスポンスなどの詳細が含まれます。これらのアクセスログを使用し
て、トラフィックパターンの分析や、バックエンドアプリケーションのトラブルシューティングを行
うことができます。
• Elastic Load Balancing API 呼び出し — AWS CloudTrail を使用して、AWS アカウントまたはその代
理によって行われたすべての Elastic Load Balancing API 呼び出しを追跡することができます。
CloudTrail は、指定した Amazon S3 バケットのログファイルにその情報を格納します。CloudTrail
によって収集されたログを使用して、ロードバランサーの動作を監視し、ロードバランサーに対して
行われたリクエストについて、その内容、ソース IP アドレス、実行者、日時などを判断できます。
Elastic Load Balancing のモニタリングおよびログ作成機能を使用して、ロードバランサーの監視、ト
ラフィックパターンの分析、ロードバランサーとバックエンドインスタンスのトラブルシューティング
を実行する方法の詳細については、次のトピックを参照してください。
Topics
• Amazon CloudWatch を使用したロードバランサーの監視 (p. 139)
• Elastic Load Balancing アクセスログ (p. 150)
• AWS CloudTrail を使用した Elastic Load Balancing API 呼び出しのログ作成 (p. 164)
138
ロードバランサーの監視
Amazon CloudWatch を使用したロードバランサー
の監視
Abstract
Amazon CloudWatch によって収集されるメトリックスを使用してロードバランサーを監視します。
Elastic Load Balancing は、ロードバランサーとバックエンドアプリケーションインスタンスに関する
データポイントを Amazon CloudWatch に発行します。CloudWatch を使用すると、それらのデータポ
イントについての統計を、順序付けられた時系列データのセット（メトリックスと呼ばれる）として取
得できます。メトリックスは監視対象の変数、データポイントは時間の経過と共に変わる変数の値と考
えることができます。各データポイントには、タイムスタンプと、オプションで測定単位が関連付けら
れています。たとえば、指定した期間中のロードバランサー配下の正常な EC2 インスタンスの合計数
をメトリックスとすることができます。
Amazon CloudWatch では、Elastic Load Balancing で発行されたメトリックスのデータポイントに基づ
いて統計が提供されます。統計は、指定した期間のメトリックスデータの集計です。使用可能な統計
は、Minimum（min）、Maximum（max）、Sum、Average、および Count です。統計を要求した場
合、返されるデータストリームはメトリックス名とディメンションによって識別されます。ディメン
ションは、メトリックスを一意に識別できるようにする名前/値のペアです。たとえば、特定のアベイ
ラビリティーゾーンで起動されたロードバランサーの配下のすべての正常な EC2 インスタンスの統計
を要求できます。
メトリックスを監視する目的の 1 つは、システムが期待どおりに動作しているかどうかを確認すること
です。メトリックスが許容範囲外になる場合は、CloudWatch アラームを作成して、指定されたメト
リックスを監視し、メトリックスが指定範囲外に達したときにアクションを開始することができます。
たとえば、通知を E メールで送信するアクションを開始できます。
Amazon CloudWatch の詳細については、「Amazon CloudWatch とは」を参照してください。
目次
• 使用可能なメトリックス (p. 139)
• メトリックスの表示 (p. 147)
• アラームの作成 (p. 148)
使用可能なメトリックス
Elastic Load Balancing は、AWS アカウントに関連付けられたすべてのロードバランサーのメトリック
スを Amazon CloudWatch に送信します。デフォルトでは、CloudWatch はこれらのメトリックスを使
用して、ロードバランサーの詳細モニタリングを提供します。詳細モニタリングを明示的に有効化する
必要はありません。
Elastic Load Balancing のメトリックス
次に示す Elastic Load Balancing のメトリックスは、Amazon CloudWatch からのものです。
Elastic Load Balancing は、リクエストがロードバランサーを経由する場合のみ報告します。特定のメ
トリックスにリクエストやデータが存在しない場合は、そのメトリックスは CloudWatch には報告され
ません。ロードバランサーを経由するリクエストがある場合、Elastic Load Balancing が 60 秒間隔でそ
のロードバランサーのメトリックスを測定し、送信します。
注意: Min または Count のような、Amazon CloudWatch を介して得られる統計値は、必ずしも常にす
べてのメトリックスに適用可能であるとは限りません。ただし、コンソール、API、コマンドラインイ
ンターフェイス（CLI）を使って適用可能です。それぞれのメトリックスについて、すべての Elastic
Load Balancing メトリックスで有益な情報を追跡できる推奨統計があります。
139
メトリックス
説明
HealthyHostCount
各アベイラビリティーゾーンの正常なインスタンス数のカウン
ト。連続して成功したヘルスチェック回数のしきい値を満たす
場合は、正常なホストとみなされます。ヘルスチェックで失敗
した回数が不健全のしきい値よりも多い場合は、異常なホスト
とみなされます。クロスゾーンが有効な場合、すべてのアベイ
ラビリティーゾーンの正常なインスタンスの数が算出されます。
推奨統計: average
UnHealthyHostCount
各アベイラビリティーゾーンの異常なインスタンス数のカウン
ト。ヘルスチェックで失敗した回数が不健全のしきい値よりも
多い場合は、異常なホストとみなされます。クロスゾーンが有
効な場合、すべてのアベイラビリティーゾーンの問題のあるイ
ンスタンスの数が算出されます。接続の問題がある、ヘルス
チェックで 200 以外の応答が返された（HTTP または HTTPS
のヘルスチェックの場合）、ヘルスチェック実行時にタイムア
ウトになった、などの理由でインスタンスが異常になる場合が
あります。
RequestCount
受信され、バックエンドインスタンスにルーティングされた、
完了したリクエスト数のカウント。
推奨統計: sum
Latency
リクエストがロードバランサーから送信され、応答を受信する
までの経過時間（秒）を測定する。
HTTPCode_ELB_4XX
リスナーが HTTP または HTTPS プロトコルを使用するよう設
定されている場合、ロードバランサーによって生成される HTTP
4XX クライアントエラーコード数のカウント。リクエストの形
式が不正な場合、または不完全な場合は、クライアントエラー
が生成されます。
推奨統計: sum
HTTPCode_ELB_5XX
リスナーが HTTP または HTTPS プロトコルを使用するよう設
定されている場合、ロードバランサーによって生成される HTTP
5XX クライアントエラーコード数のカウント。このメトリック
スには、バックエンドインスタンスによって生成される応答は
含まれません。
正常なバックエンドインスタンスまたはロードバランサーに登
録されているバックエンドインスタンスがない場合、またはリ
クエストレートがインスタンスまたはロードバランサーの容量
を超える場合、このメトリックスが報告されます。
推奨統計: sum
140
メトリックス
説明
HTTPCode_Backend_2XX
バックエンドインスタンスによって生成される HTTP 応答コー
ド数のカウント。このメトリックスには、ロードバランサーに
よって生成される応答コードは含まれません。
2XX クラスのステータスコードは正常なアクションを表します。
3XX クラスのステータスコードは、ユーザーエージェントのア
クションが必要であることを示します。4XX クラスのステータ
スコードはクライアントエラーを表します。5XX クラスのステー
タスコードはバックエンドサーバーエラーを表します。
推奨統計: sum
BackendConnectionErrors
ロードバランサーと登録されたインスタンス間で正常に確立さ
れなかった接続数のカウント。接続エラーが発生すると、ロー
ドバランサーは再試行するため、このカウントはリクエストレー
トを上回ります。
推奨統計: sum
SurgeQueueLength
登録されたインスタンスへの送信が保留中のリクエストの合計
数のカウント。
推奨統計: max
SpilloverCount
キューがいっぱいのため拒否されたリクエストの合計数のカウ
ント。
推奨統計: sum
Elastic Load Balancing メトリックスのディメンション
リクエストによって返されるメトリックスを絞り込むには、このセクションの表に示されている Elastic
Load Balancing のディメンションを使用します。たとえば、HealthyHostCount メトリックスで
LoadBalancerName と AvailabilityZone のディメンションを使用し、特定の期間を対象として、
指定のアベイラビリティーゾーンの指定のロードバランサーの配下にある正常なインスタンスの平均数
を取得することができます。または、一定期間中のバックエンドインスタンスの状態と数の変化を把握
するため、正常なホストの最小数や問題のあるホストの最大数に達しないかどうかを監視することもで
きます。
Elastic Load Balancing のデータの集計には、次の表に示したディメンションを使用することができま
す。
ディメンション
説明
LoadBalancerName
メトリックスデータを、指定のロードバランサーに接続されている Amazon
EC2 インスタンスのものだけに制限します。
AvailabilityZone
メトリックスデータを、指定のアベイラビリティーゾーンのロードバラン
サーに制限します。
Elastic Load Balancing の統計を測定する方法
Elastic Load Balancing は、トラフィックをバックエンドインスタンスに転送するロードバランサーノー
ドで構成されています。各ロードバランサーノードは、単一のアベイラビリティーゾーン内のインスタ
ンスにトラフィックをルーティングするように指定されており、各ロードバランサーノードは指定され
たアベイラビリティーゾーンのメトリックスを報告します。
141
すべての CloudWatch メトリックスについて、min と max は、個々のロードバランサーノードによっ
て報告された min と max を表します。たとえば、ロードバランサーノードが 2 つあるとします。ノー
ド 1 は、min が 2、max が 10、average が 6 の HealthyHostCount を報告します。ロードバラン
サーノード 2 は、min が 1、max が 5、average が 3 の HealthyHostCount を報告します。これは、
CloudWatch の min が 1 になり、max が 10、average がおよそ 4 になることを意味します。
sum は、特定の期間中にすべてのロードバランサーノードで報告された集計値です。メトリックスには
期間あたり複数のレポートが含まれているため、sum は、RequestCount、HTTPCode_ELB_4XX、
HTTPCode_ELB_5XX、HTTPCode_Backend_2XX,3XX,4XX,5XX、BackendConnectionErrors、
SpilloverCount などのすべてのロードバランサーノードで集計されたメトリックスのみに適用され
ます。
count は測定されたサンプルの数です。メトリックスはサンプリング間隔とイベントに基づいて集計
されるため、通常、count は有用ではありません。たとえば正常/異常ホストのメトリックスで、count
は正常/異常ホストの数ではなく、ロードバランサーノードで収集されたヘルスチェックサンプルの数
に基づきます。レイテンシーのメトリックスでは、件数は報告されたレイテンシーの実際の値ではな
く、各ロードバランサーノードで報告されたサンプルの数です。
次の表は、Elastic Load Balancing によって送信される CloudWatch メトリックスの統計を評価する方
法を説明しています。
Elastic Load Balancing メトリックスの統計
メトリックス名
統計の詳細
HealthyHostCount
UnHealthyHostCount
このメトリックスは AvailabilityZone ディメンションと組み合わ
せて使用します。
average 統計は、ロードバランサーノードによって確認された正常な
インスタンスまたは異常なインスタンスの平均数を示します。正常な
インスタンスまたは異常なインスタンスの合計を取得するには、各ア
ベイラビリティーゾーン（AZ）の平均値を算出します。
Min と max は、指定された期間内に正常または異常な状態にあったイ
ンスタンスの最小数と最大数を表します。短時間の間インスタンスを
異常と判断するロードバランサーノードがあったり、インスタンスを
正常と判断するノードがあったりするため、min と max は誤解を招く
場合があります。
Sum は、この方法では有益な統計ではありません。
Count は、すべてのノードによって報告されるサンプル数で、問題の
トラブルシューティングでは有益な方法ではありません。
例: ロードバランサーに 4 つのバックエンドインスタンスがあり、そ
のうちの 2 つのインスタンスは AZ-1 に、もう 2 つのインスタンスは
AZ-2 にあるとします。AZ-1 には異常なインスタンスと正常なインス
タンスが 1 つずつあり、AZ-2 には正常なインスタンスが 2 つあり、
異常インスタンスはありません。AZ のディメンションは、AZ-1 の正
常なインスタンスの平均数は 1、異常なインスタンスの平均数は 1 で、
AZ-2 の正常なインスタンスの平均数は 2、異常なインスタンスの平均
数は 0 と報告します。リージョン（ロードバランサー）のディメン
ションは、AZ-1 と AZ-2 の正常なインスタンスの平均数は 1.5、AZ-1
と AZ-2 の異常なインスタンスの平均数は 0.5 と報告します。
142
統計の詳細
RequestCount
このメトリックスは通常 LoadBalancerName ディメンションと組み
合わせて使用して、ロードバランサーの合計リクエスト数を表示しま
す。このメトリックスは、1 つのアベイラビリティーゾーン（バック
エンドでリクエストを処理したアベイラビリティーゾーンとは異なる
場合もある）にルーティングされたリクエスト数を測定する場合にも
使用されます。
推奨統計: sum
Sum は、この方法で唯一有益な統計です。
Min, max, と average はどちらも 1 の値を返すため、有益ではあ
りません。
Count は、すべてのロードバランサーによって報告されるサンプル数
で、通常その期間の sum と同じです。
AZ-2 にあるとします。ロードバランサーに 100 件のリクエストが送
信されます。そのうち 60 件のリクエストは AZ-1 に送信され、各イン
スタンスがそれぞれ 30 件ずつリクエストを受信します。40 件のリク
エストは AZ-2 に送信され、各インスタンスがそれぞれ 20 件ずつリク
エストを受信します。AZ のディメンションは、AZ-1 の合計リクエス
ト数は 60 件、AZ-2 の合計リクエスト数は 40 件と報告します。リー
ジョン（ロードバランサー）のディメンションは、合計リクエスト数
を 100 件と報告します。AZ-1 の各インスタンスは 30 件のリクエス
ト、AZ-2 の各インスタンスは 20 件のリクエストを受信します。
Latency
すべてのリクエスト、または 1 つのアベイラビリティーゾーンにルー
ティングされるリクエストについてレイテンシーを表示できます。
average は、バックエンドに送信されたすべてのリクエストの平均で
あるため、最も有益な診断を提供します。
Max は、一部のリクエストに平均を大幅に上回る時間がかかっている
かどうかを判断する上で便利です。
Min は、経過時間が最小のリクエスト/リスポンスであるため、通常は
有益な方法ではありません。
Count は、記録されたサンプル数であるため、RequestCount メトリッ
クスの sum とほぼ等しくなります。
AZ-2 にあるとします。AZ-1 の 1 つのインスタンスに送信されるリク
エストのレイテンシーがより高くなっています。AZ-1 で報告されたレ
イテンシーメトリックスでは、AZ-2 のレイテンシーメトリックスより
も高い値を示します。
143
統計の詳細
HTTPCode_ELB_4XX
合わせて使用して、すべてのロードバランサーノードによって生成さ
れた HTTP 4XX エラーの合計数を表示します。このメトリックスは、
1 つのアベイラビリティーゾーン（バックエンドでリクエストを処理
したアベイラビリティーゾーンとは異なる場合もある）にルーティン
グされたリクエストのエラー数を測定する場合にも使用されます。
推奨統計: sum
Min, max, と average はどちらも 1 の値を返すため、有益ではあ
りません。
例: ロードバランサーで AZ-1 と AZ-2 が有効になっているとします。
クライアントのリクエストに不正なリクエスト URL が含まれていま
す。すべてのアベイラビリティーゾーンでのクライアント HTTP エ
ラーが増加する可能性があります。リージョン（ロードバランサー）
のメトリックスは、各アベイラビリティーゾーンの値の合計となりま
す。
HTTPCode_ELB_5XX
合わせて使用して、すべてのロードバランサーノードによって生成さ
れた HTTP 5XX エラーの合計数を表示します。このメトリックスは、
1 つのアベイラビリティーゾーン（バックエンドでリクエストを処理
したアベイラビリティーゾーンとは異なる場合もある）にルーティン
グされたリクエストのエラー数を測定する場合にも使用されます。
推奨統計: sum
Min, max, と average はどちらもこの方法では有益な統計ではな
く、1 の値を返します。
AZ-1 のインスタンスには高レイテンシーが発生しており、リクエスト
の応答に時間がかかっています。その結果、AZ-1 のロードバランサー
ノードのサージキューがいっぱいになり、スピルオーバーが発生して、
クライアントに 503 エラーを返します（この表の SpilloverCount メト
リックスを参照してください）。AZ-2 が正常に応答し続けると想定し
た場合、リージョン（ロードバランサー）の HTTPCode_ELB_5XX の
sum は AZ-1 の sum と等しくなります。
144
統計の詳細
合わせて使用して、ロードバランサーに登録されているバックエンド
インスタンスによって生成される HTTP 応答コードの合計数を表示し
ます。このメトリックスは、1 つのアベイラビリティーゾーン（バッ
クエンドでリクエストを処理したアベイラビリティーゾーンとは異な
る場合もある）にルーティングされたリクエストのエラー数を測定す
る場合にも使用されます。
推奨統計: sum
Min, max, と average はどちらもこの方法では有益な統計ではな
く、1 の値を返します。
AZ-2 にあるとします。AZ-1 の 1 つのインスタンスに送信されるリク
エストは、HTTP 500 応答を返します。AZ-1 で報告されるメトリック
スにはこれらのエラー応答が含まれ、AZ-2 の値にはこれらのエラー応
答は含まれません。リージョン（ロードバランサー）の合計は、AZ-1
の合計数と等しくなります。
BackendConnectionErrors
すべてのバックエンドインスタンス、または 1 つのアベイラビリティー
ゾーンのバックエンドインスタンスについて、このメトリックスを表
示できます。
推奨統計: sum
Sum は、特定の期間内にすべてのロードバランサーノードによって確
認された接続エラーの合計数を表します。
Sum は、この方法で唯一の有益な統計です。
Average, min, と max は各ロードバランサーノードごとに報告され
るため、通常有益ではありません。min と max の差、ピーク値対平
均、または平均対底値は、1 つのロードバランサーノードが異常値か
どうかを判断する上で有益な場合があります。
Count は、すべてのロードバランサーノードによって報告されるサン
プル数で、通常その期間の合計と等しくなります。
AZ-2 にあるとします。AZ-1 の 1 つのインスタンスに接続しようとす
ると、バックエンド接続エラーが増加します。AZ-1 で報告されるメト
リックスには、試行失敗に対するこれらの接続エラーが含まれますが、
AZ-2 の値にはこれらのエラーは含まれません。リージョン（ロードバ
ランサー）の合計は、AZ-1 の合計数と等しくなります。
145
統計の詳細
SurgeQueueLength
このメトリックスは、1 つのアベイラビリティーゾーン、またはリー
ジョン（全体のロードバランサー）のサージキューサイズを監視する
ために使用されます。
推奨統計: max
Max は、キューに送信されたリクエストのピークを表すため、最も有
益な統計です。最大の値は 1,024 です。いずれかのロードバランサー
ノードのキューが 1,024 件のリクエストでいっぱいになっている場合、
スピルオーバーが発生する可能性があります（この表の SpilloverCount
メトリックスを参照してください）。
Average は、特定の期間内にすべてのロードバランサーノードのキュー
内にあったリクエスト数の平均を表します。Average を min と max
と組み合わせて使用すると、ロードバランサーノードによるキューの
範囲を判断する上で役立ちます。
Sum は、すべてのロードバランサーノード全体で記録されたサンプル
の合計数であるため、有益な統計ではありません。
Min は、任意のサンプルの任意のロードバランサーノードで確認され
た最低値を表すため、通常有益ではありません。
Count は、この方法では有益な統計ではありません。
のサージキューがいっぱいになり、クライアントに応答時間の増加が
発生している可能性があります。これが継続すると、ロードバランサー
にスピルオーバーが発生します（この表のスピルオーバーメトリック
スを参照してください）。AZ-2 が正常に応答し続けると想定した場
合、リージョン（ロードバランサー）の最大は AZ-1 の最大と等しく
なり、同じ期間内の AZ-2 の値は小さくなります（またはメトリック
スがない）。
SpilloverCount
合わせて使用して、ロードバランサーの合計スピルオーバー数を表示
します。このメトリックスは、1 つのアベイラビリティーゾーンにルー
ティングされて拒否されたリクエスト数を測定する場合も使用できま
す。
推奨統計: sum
Sum は、特定の期間内のすべてのロードバランサーノードのレポート
の合計数を表します。
Sum は、この方法で唯一の有益な統計です。
Average, min, と max は各ロードバランサーノードごとに報告さ
れるため、通常スピルオーバーメトリックスには有益ではありません。
Min は、任意のサンプルの任意のロードバランサーノードで確認され
た最低値を表すため、通常有益ではありません。
Count は、この方法では有益な統計ではありません。
のサージキューがいっぱいになり、ロードバランサーのスピルオーバー
が発生します。スピルオーバーメトリックスは増加します。AZ-2 が正
常に応答し続けると想定した場合、リージョン（ロードバランサー）
の合計は AZ-1 の合計と等しくなり、同じ期間内の AZ-2 の値は小さく
なります（またはメトリックスがない）。
146
メトリックスの表示
メトリックスの表示
Elastic Load Balancing ロードバランサーの CloudWatch メトリックスは、EC2 コンソールの [Load
Balancer] ページで直接確認することができます。ロードバランサーのメトリックスは、モニタリング
用のグラフのように表示されます。EC2 コンソールで表示されるメトリックスは、以下のとおりです。
• [Average Latency]
• [Sum Requests]
• [Sum ELB HTTP 4XXs]
• [Sum ELB HTTP 5XXs]
• [Sum HTTP 2XXs]
• [Sum HTTP 4XXs]
• [Sum HTTP 5XXs]
ロードバランサーからメトリックスを確認するには
1.
2.
3.
4.
5.
6.
AWS マネジメントコンソールにサインインをしたあと、https://console.aws.amazon.com/ec2/ に
ある Amazon EC2 コンソールを開きます。
下のペインで、[Monitoring] タブをクリックします。
結果を時間でフィルタリングするには、[Showing data for] ドロップダウンボックスで時間範囲を
選択します。
個々のメトリックスを拡大表示するには、それぞれのグラフをクリックします。
この例で使用されている my-test-loadbalancer ロードバランサーは非アクティブであり、表示専
用です。ロードバランサーがアクティブでリクエストを受信しているときにのみ、モニタリング用のグ
ラフにデータポイントが表示されます。
また、Amazon CloudWatch を使用してロードバランサーのメトリックスを表示することもできます。
詳細については、「Amazon CloudWatch を使用した AWS メトリックスの表示」を参照してください。
コマンドラインインターフェイスを使用してメトリックスを確認するには、mon-list-metrics コマンド
を使用します。
147
アラームの作成
1 つのアラームで、指定した期間中、1 つのメトリックスを監視します。アラームは、メトリックスの
値が定義したしきい値に達したかどうかを監視し、達した場合には 1 つ以上の通知を Amazon Simple
Notification Service（Amazon SNS）トピックに送信します。Amazon SNS は、アプリケーション、エ
ンドユーザー、およびデバイスでリアルタイムに通知を送受信できるようにするウェブサービスです。
詳細については、Getting Started with Amazon Simple Notification Serviceを参照してください。
指定されたメトリックスが定義された範囲に達し、特定期間その範囲に留まると、アラームにより
Amazon SNS に通知が送信されます。アラームには次の 3 つの状態があります。
• OK – これは、メトリックスの値が指定された範囲に留まっている場合のアラームの状態です。
• ALARM – これは、メトリックスの値が指定の範囲外に達し、指定した期間その範囲外に留まっている
場合にアラームがなる状態です。
• INSUFFICIENT_DATA – アラームがこの状態であるということは、メトリックスが準備できていない
か、アラームの状態を決定できる十分なデータが揃っていないことを示します。
アラームの状態が変化するたびに、Amazon CloudWatch は Amazon SNS を使用して、指定された E
メールアドレスに通知を送信します。
ロードバランサーにアラームを作成するには、EC2 コンソールまたは Amazon CloudWatch コンソー
ルで Elastic Load Balancing ウィザードを使用します。このセクションでは、 Elastic Load Balancing
ウィザードを使用してアラームを作成する手順を説明します。Amazon CloudWatch コンソールを使用
したロードバランサーアラームの作成については、「Send Email Based on Load Balancer Alarmを参
照してください。
ロードバランサーにアラームを作成するには
1.
2.
3.
4.
5.
6.
下のペインにある [Monitoring] タブで、[Create Alarm] をクリックします。
[Create Alarm] ダイアログボックスで、アラームの条件を設定します。この例では、連続する 5 分
間においてロードバランサーのレイテンシーが 120 秒を超えた場合にアラームを発するようにし
ます。
デフォルトでは、[Send a notification] の横にあるチェックボックスが選択されています。
SNS トピックをすでに作成しているため再利用したい場合は、リストからそのトピックを選択し
ます。
SNS トピックがまだない場合は、次に従って作成します。
a.
b.
[create topic] をクリックします。
[Send a notification to:] ボックスに、トピック名を入力します。
c.
[With these recipients] ボックスに、通知の受取人のメールアドレスを入力します。各アドレス
をコンマで区切って、最大 10 件のメールアドレスを入力できます。
Note
SNS トピックを購読していないすべての E メール受取人は、その SNS トピックの購
読確認を求めるリンクが記載された E メールを、Amazon SNS から受け取ります。
購読の確認を行わない場合、E メールのアラーム通知は送信されるようになりません。
148
7.
アラームのしきい値を設定します。
a.
[Whenever] ボックスで、[Average] および [Average Latency] を選択します。
b.
[Is] ボックスで、[>] を選択し、「120」を入力して、アラームのしきい値を定義します。
c.
[For at least] ボックスに「1」を入力し、続けて [5 minutes] を選択するか、または独自の評価
期間を定義できます。
Note
期間が短ければ、より高感度のアラームが作成されます。期間が長ければ、メトリッ
クスの短時間でのスパイクを軽減できます。
d.
[Name this alarm] に名前が自動的に表示されます。名前を変更するには新しい名前を入力しま
す。
Important
アラームを作成した後に名前を変更することはできません。
8.
[Create Alarm] をクリックします。
9.
[Alarm created successfully] ダイアログボックスが表示され、アラームが正常に作成されたことを
示します。[Close] をクリックします。
アラームを作成したら、[Monitoring] タブを使用して、そのロードバランサーに設定されたアラームの
概要を確認できます。ここで、アラームを編集することもできます。
149
アクセスログの管理
Elastic Load Balancing アクセスログ
Abstract
Elastic Load Balancing アクセスログを管理する方法について説明します。
Elastic Load Balancing アクセスログは、ロードバランサーに対するすべてのリクエストの詳細情報を
キャプチャします。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテ
ンシー、リクエストのパス、サーバーレスポンスなどの詳細が含まれます。Elastic Load Balancing ア
クセスログを使用して、トラフィックパターンの分析や、バックエンドアプリケーションのトラブル
シューティングを行えます。
アクセスログ作成は、Elastic Load Balancing のオプション機能です。この機能は、デフォルトでは無
効になっています。ログをキャプチャして配信するには、ロードバランサーで明示的に有効にする必要
があります。この機能を有効にした時点から、Elastic Load Balancing がログをキャプチャし、指定し
た Amazon Simple Storage Service (Amazon S3) バケットに保管します。既存のバケットを使うか、新
しいバケットを作成することができます。ログ配信はいつでも無効にできます。
アクセスログに対する追加料金はありません。Amazon S3 のストレージコストは発生しますが、Amazon
S3 にログファイルを送信するために Elastic Load Balancing が使用する帯域については料金は発生し
ません。ストレージコストの詳細については、「Amazon S3 料金表」を参照してください。
ログファイルへのアクセス
Elastic Load Balancing は、指定した間隔で各ロードバランサーノードからログファイルを発行します。
ロードバランサーのアクセスログを有効にするときに、5 分または 60 分の間隔を指定できます。デフォ
ルトでは、Elastic Load Balancing は 60 分間隔でログを発行します。ログは、毎時 0 分を起点として、
指定した間隔で発行されます。たとえば、間隔が 5 分に設定されている場合、ログは毎時 0 分を起点
として 5 分ごとに、つまり 1:05、1:10、1:15 のように発行されます。実際のログ配信は、間隔が 5 分
に設定されている場合は最大 5 分の遅延があり、間隔が 60 分に設定されている場合は最大 15 分の遅
延があります。発行間隔はいつでも変更できます。
ロードバランサーでは、同じ期間について複数のログが発行されることがあります。これは通常、サイ
トのトラフィックが大量である場合、ロードバランサーノードが複数ある場合、およびログ発行間隔が
短い場合に発生します。
Elastic Load Balancing は、次の形式でログファイル名を作成します。
{Bucket}/{Prefix}/AWSLogs/{AWS AccountID}/elasticloadbalancing/{Re
gion}/{Year}/{Month}/{Day}/{AWS Account ID}_elasticloadbalancing_{Region}_{Load
Balancer Name}_{End Time}_{Load Balancer IP}_{Random String}.log
ログファイル名の例は次のようになります。
S3://mylogsbucket/myapp/prod/AWSLogs/123456789012/elasticloadbalancing/us-east1/2014/02/15/123456789012_elasticloadbalancing_us-east-1_my-test-loadbalan
cer_20140215T2340Z_172.160.001.192_20sg8hgm.log
次の表では、前の例の値を使用したログファイル名の形式を説明しています。
パラメータ
説明
値の例
バケット
作成した S3 バケットの名前。
mylogsbucket
150
ログエントリへのアクセス
パラメータ
説明
値の例
プレフィックス
S3 バケットに作成したプレ
フィックス（論理的な階層）。
プレフィックスが指定されてい
ない場合、ログはルートレベル
に配置されます。
myapp/prod
AWS アカウント ID
ロードバランサーに関連付けら
れた AWS アカウント番号。値
はシステムによって自動的に入
力されます。
123456789012
リージョン
ロードバランサーと S3 バケッ
トが配置されているリージョ
ン。これはシステムによって自
動的に入力されます。
us-east-1
年/月/日
ログが配信された日付。値はシ
ステムによって自動的に入力さ
れます。
2014/02/15
ロードバランサー名
ログが収集されるロードバラン
サーの名前。これはシステムに
よって自動的に入力されます。
my-test-loadbalancer
終了時間
ログ作成間隔の終了時点のタイ
ムスタンプ（UTC）（たとえば
終了時間20140215T2340Zに
は、5 分ごとに発行されるログ
の場合、23:35 から 23:40 まで
に作成されたリクエストのエン
トリが格納されます）。
20140215T2340Z
ロードバランサー IP
リクエストを処理したロードバ 172.160.001.192
ランサーノードの IP アドレス。
内部ロードバランサーの場合、
プライベート IP アドレスです。
値はシステムによって自動的に
入力されます。
ランダム文字列
システムによって生成されたラ
ンダム文字列。
20sg8hgm
必要な場合はログファイルを自身のバケットに保管できますが、ログファイルを自動的にアーカイブま
たは削除するにように Amazon S3 ライフサイクルルールを定義することもできます。詳細について
は、『Amazon Simple Storage Service 開発者ガイド』の「オブジェクトのライフサイクル管理」を参
アクセスログファイルには、ログエントリが 1 つ以上含まれます。各ログエントリには、ロードバラン
サーに対する 1 件のリクエストの詳細が含まれます。Elastic Load Balancing は、バックエンドのイン
スタンスに到達しなかったリクエストを含め、ロードバランサーに送信されたすべてのリクエストを記
録します。たとえば、クライアントが誤った形式のリクエストを送信した場合や、応答できる正常に動
作しているインスタンスがない場合も、そのリクエストは記録されます。
ログファイルの各エントリは、次の形式に従います。
151
timestamp elb client:port backend:port request_processing_time backend_pro
cessing_time response_processing_time elb_status_code backend_status_code re
ceived_bytes sent_bytes "request"
ログエントリのすべてのフィールドはスペースで区切られています。1 つのログエントリの例を次に示
します。
2014-02-15T23:39:43.945958Z my-test-loadbalancer 192.168.131.39:2817 10.0.0.1:80
0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/HTTP/1.1"
次の表では、前の例の値を使用したログエントリのフィールドについて説明しています。
フィールド名
説明
フィールド値の
例
timestamp
ロードバランサーがクライアントからリクエストを受け
取った時間（UTC）。ISO 8601 形式が使用されます。
2014-0215T23:39:43.945958Z
elb
ロードバランサーの名前
my-testloadbalancer
client:port
リクエストを送信したクライアントの IP アドレスとポー 192.168.131.39:2817
ト。
backend:port
このリクエストを処理した登録済みインスタンスの IP ア 10.0.0.1:80
ドレス。
request_processing_time
ロードバランサーがリクエストを受け取り、そのリクエス 0.000073
トを登録済みインスタンスに送信した時点からの合計経過
時間（秒単位）
backend_processing_time
HTTP リスナーの場合: ロードバランサーが登録済みイン 0.001048
スタンスにリクエストを送信し、そのインスタンスが応答
ヘッダーの送信を開始した時点からの合計経過時間（秒単
位）。
TCP リスナーの場合: ロードバランサーが登録済みインス
タンスにリクエストの最初のバイトを送信し、そのインス
タンスが最初のバイトを送り返してからの合計経過時間
（秒単位）。
response_processing_time
HTTP リスナーの場合: ロードバランサーが登録済みイン 0.000057
スタンスから応答ヘッダーを受け取り、クライアントへの
応答の送信を開始した時点からの合計経過時間（秒単
位）。この処理時間には、ロードバランサーでの待機時間
と、ロードバランサーからバックエンドへの接続の取得時
間の両方が含まれます。
TCP リスナーの場合: ロードバランサーが登録済みインス
タンスから最初のバイトを受け取り、クライアントへの応
答の送信を開始した時点からの合計経過時間（秒単位）。
elb_status_code
ロードバランサー（HTTP のみ）からの応答のステータス 200
コード
backend_status_code
登録済みインスタンス（HTTP のみ）からの応答のステー 200
タスコード
152
ログ処理
フィールド名
説明
フィールド値の
例
received_bytes
クライアント（リクエスタ）から受け取ったリクエストの 0
サイズ（バイト単位）。
HTTP リスナーの場合: 受信バイト数はリクエストの本文
を表し、ヘッダーを含みません。
TCP リスナーの場合: バイト数にはヘッダーが含まれま
す。
sent_bytes
クライアント（リクエスタ）に返される応答のサイズ（バ 29
イト単位）。
HTTP リスナーの場合: 送信バイト数は応答の本文を表し、
ヘッダーを含みません。
TCP リスナーの場合: バイト数にはヘッダーが含まれま
す。
"request"
クライアントからのリクエスト行は二重引用符で囲まれて
おり、次の形式でログに記録されます。HTTP メソッド +
プロトコル://ホストヘッダー:ポート + パス + HTTP バー
ジョン。
"GET http://www.example.com:
80/HTTP/1.1"
TCP リスナーの場合: URL が入力されない代わりに、ス
ペースで区切られ、末尾がスペースである 3 個のダッシュ
が引用符で囲まれて表示されます（例: "- - - "）。
• ロードバランサーのアクセスログを有効にするには、「アクセスログの有効化 (p. 154)」を参照して
ください
• ロードバランサーのアクセスログを無効にするには、「アクセスログの無効化 (p. 158)」を参照して
ください
ログ処理
ウェブサイトのトラフィックによって、ロードバランサーがギガバイト規模の大量のログファイルを生
成することがあります。このような大量のデータを処理する場合、1 行ごとの処理では対応できない可
能性があるので、並列処理ソリューションを提供する分析ツールを使用する必要があります。次のいず
れかの分析ツールを使用して、ロードバランサーが生成したアクセスログを分析、処理することができ
ます。
Amazon Elastic MapReduce（Amazon EMR）
Amazon EMR を使用すると、Elastic Load Balancing アクセスログのような大量のデータをすばやく効
率的に処理できます。Amazon EMR では、Amazon EC2 インスタンスで Apache Hadoop を実行しま
す。Hadoop は、複数の並列処理コンピュータに計算タスクを分散するフレームワークであり、大量の
データをすばやく処理することができます。詳細については、「Elastic Load Balancing アクセスログ
データの分析」を参照してください。
パートナーソリューション
次のパートナーが提供する統合ソリューションを使用してアクセスログを分析することもできます。
• Splunk
• Sumo Logic
153
アクセスログの有効化
Abstract
アクセスログを有効にする方法について説明します。
ロードバランサーのアクセスログを有効にするには、次の手順を実行します。
1. ロードバランサーのアクセスログを有効にします。
2. ロードバランサーのアクセスログが有効になっていることを確認します。
目次
• AWS Management Console の使用 (p. 154)
• AWS CLI の使用 (p. 155)
• Elastic Load Balancing が Amazon S3 バケットにテストファイルを作成したことの確認 (p. 157)
AWS Management Console の使用
ロードバランサーを特定した後で、ロードバランサーがログを保管する Amazon S3 バケットの名前を
指定する必要があります。Elastic Load Balancing では、コンソールを使用してアクセスログを有効に
するときに、ロードバランサーがバケットに書き込むために必要なアクセス許可を指定してバケットを
作成するためのオプションが用意されています。
既存のバケットを使用するか、独自のバケットを作成する場合は、まず、「アクセスログを保管する
Amazon S3 バケットの設定 (p. 159)」の手順に従います。
このウォークスルーでは、ロードバランサー my-test-loadbalancer を有効にし、60 分ごと（デ
フォルトの間隔）にログをキャプチャして、Elastic Load Balancing によって作成された S3 バケット
my-test-loadbalancer-log に配信します。
コンソールを使用したロードバランサーのアクセスログの有効化
1.
2.
3.
4.
5.
下のペインで、[Access Logs: Disabled] 行の [(Edit)] をクリックします。
6.
[Configure Access Logs] ダイアログボックスで、以下の操作を実行します。
a.
b.
c.
[Enable Access Logs] を選択します。
[Interval] ダイアログボックスはデフォルト設定のままにします。
[S3 Location] フィールドに、プレフィックス（この例では
my-test-loadbalancer-log/myapp を使用）を含めて S3 バケットの名前を入力します。
Note
Elastic Load Balancing にバケットを作成させる場合は必ず、選択したバケット名が
Amazon S3 のすべての既存バケット名の中で一意となるようにしてください。バケッ
トの作成後にバケット名を変更することはできません。バケットの命名規則と表記規
則の詳細については、『Amazon Simple Storage Service 開発者ガイド』の「バケッ
トの制約と制限」を参照してください。
154
d.
Elastic Load Balancing に S3 バケットを作成させる場合は、[Create the location for me] を選
択します。
e.
AWS CLI の使用
アクセスログを有効にするには、ロードバランサーの AccessLog 属性の値を true に変更するか、
Amazon S3 バケット名とプレフィックスなどの別の属性を指定して、属性を変更する必要があります。
前提条件
開始する前に、以下の手順が完了していることを確認します。
• AWS コマンドラインインターフェイス（AWS CLI）の最新バージョンをダウンロードしてインス
トールします。最新の CLI のダウンロードとインストールの手順については、「AWS コマンドライ
ンインターフェイスの設定」を参照してください。
• Amazon S3 バケットを作成または指定し、バケットにバケットポリシーをアタッチします。このバ
ケットポリシーでは、指定した Amazon S3 バケットに書き込むアクセス許可を Elastic Load Balancing
に付与する必要があります。Elastic Load Balancing には、書き込みアクセス許可以外のアクセス許
可を付与しないようにします。バケットを作成してバケットにポリシーをアタッチする手順について
は、「アクセスログを保管する Amazon S3 バケットの設定 (p. 159)」を参照してください。
ロードバランサーのアクセスログを有効にするには
1.
次のオプションを使用して modify-load-balancer-attributes コマンドを入力します。
• load-balancer-attributes
• AccessLog
• Enabled=true
• S3BucketName=my-test-loadbalancer-log
• S3BucketPrefix=myapp
• EmitInterval=60
155
このコマンドでは、入力データが JSON 形式である必要があります。コマンドラインで JSON を
直接入力することも、ファイルに JSON を保存してコマンドラインでファイルを参照することも
できます。
a.
コマンドラインで JSON ファイルを参照するには
以下のように JSON 形式でファイルにパラメータを入力し、JSON 拡張子（.json）を付けて
ファイルを保存します。
{
"AccessLog": {
"Enabled": true,
"S3BucketName": "my-test-loadbalancer-log",
"EmitInterval": 60,
"S3BucketPrefix": "myapp"
}
}
b.
コマンドラインで保存したファイルを参照します。
aws elb modify-load-balancer-attributes --load-balancer-name my-testloadbalancer --load-balancer-attributes file:your-json-file-path.json
または、コマンドラインで JSON を使用します。
Note
次の例では、Windows オペレーティングシステムで JSON 構文を使用して属性を指定し
ます。オペレーティングシステムでの JSON 構文の指定については、「文字列の引用」を
aws elb modify-load-balancer-attributes --load-balancer-name my-test-load
balancer --load-balancer-attributes "{\"AccessLog\":{\"En
abled\":true,\"S3BucketName\":\"my-test-loadbalancer-log\",\"EmitInter
val\":60,\"S3BucketPrefix\":\"myapp\"}}"
2.
{
"AccessLog": {
"Enabled": true,
"EmitInterval": 60,
}
},
156
"LoadBalancerName": "my-test-loadbalancer"
}
3.
以下のパラメータを使用して describe-load-balancer-attributes コマンドを入力し、ロードバラン
サーのアクセスログが有効になっていることを確認します。
aws elb describe-load-balancer-attributes --load-balancer-name my-testloadbalancer
{
"Enabled": false,
"Timeout": 360
},
"Enabled": false
},
"IdleTimeout": 60
},
"AccessLog": {
"S3BucketPrefix": "myapp",
"EmitInterval": 60,
"Enabled": true,
"S3BucketName": "my-test-loadbalancer-log"
}
}
}
ロードバランサーのアクセスログを正常に有効にしました。
Elastic Load Balancing が Amazon S3 バケットにテストファイ
ルを作成したことの確認
ロードバランサーのアクセスログを有効にすると、Elastic Load Balancing が Amazon S3 バケットを検
証し、テストファイルを作成します。S3 コンソールを使用して、Amazon S3 バケットにテストファイ
ルが作成されたことを確認できます。
Elastic Load Balancing が Amazon S3 バケットにテストファイルを作成したことを確認するに
は
1.
2.
ナビゲーションバーで、[Services] をクリックし、[S3] を選択します。
S3 コンソールの [All Buckets] リストで、S3 バケットを選択します。
3.
テストログファイルが表示されるまで、バケットのパスをクリックしていきます。
157
アクセスログの無効化
アクセスログの無効化
Abstract
アクセスログを無効にする方法について説明します。
ロードバランサーのアクセスログのオプションは、いつでも無効にできます。このオプションを無効に
した後、ユーザーがログまたはバケットを削除するまで、アクセスログは Amazon S3 バケットに保持
されたままになります。Amazon S3 バケットの管理については、『Amazon Simple Storage Service コ
ンソールユーザーガイド』の「バケットの使用」を参照してください。
コンソールを使用してアクセスログを無効にするには
1.
2.
3.
4.
5.
6.
7.
下のペインで、[Access Logs: Enabled] 行の [(Edit)] をクリックします。
[Configure Access Logs] ダイアログボックスで、[Disable Access Logs] を選択します。
AWS CLI を使用してアクセスログを無効にするには
AccessLog 属性の値を false に設定して、ロードバランサーの属性を変更する必要があります。
1.
次のオプションを使用して modify-load-balancer-attributes コマンドを入力します。
• AccessLog
• Enabled=false
Note
次の例では、Windows オペレーティングシステムで JSON 構文を使用して属性を指定し
ます。オペレーティングシステムでの JSON 構文の指定については、「文字列の引用」を
aws elb modify-load-balancer-attributes --load-balancer-name my-test-load
balancer --load-balancer-attributes "{\"AccessLog\":{\"Enabled\":false}}"
158
アクセスログを保管する Amazon S3 バケットの設定
{
"AccessLog": {
"EmitInterval": 60,
"Enabled": false,
}
}
}
2.
次の例のように describe-load-balancer-attributes コマンドを入力して、ロードバランサーのアク
セスログが無効になっていることを確認します。次のオプションを使用します。
aws elb describe-load-balancer-attributes --load-balancer-name
loadbalancer
my-test-
{
"IdleTimeout": 60
},
"AccessLog": {
"EmitInterval": 60,
"Enabled": false,
},
"Enabled": false
},
"Timeout": 360,
"Enabled": false
}
}
}
Abstract
アクセスログ用のストレージを設定する方法について説明します。
アクセスログを保管する Amazon S3 バケットを設定するには、次のタスクを実行します。
159
タスク
• Amazon S3 バケットの作成 (p. 160)
• Amazon S3 バケットへのポリシーのアタッチ (p. 160)
Amazon S3 バケットの作成
Amazon S3 バケットは、S3 コンソールを使用して作成できます。バケットがすでにあり、それをアク
セスログの保管に使用する場合は、このステップをスキップして「Amazon S3 バケットへのポリシー
のアタッチ (p. 160)」に進み、バケットにログを書き込むためのアクセス権限を Elastic Load Balancing
に付与します。
Amazon S3 バケットを作成するには
1.
https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。
2.
3.
[Create Bucket] をクリックします。
[Create a Bucket] ダイアログボックスで、以下の作業を行います。
a.
b.
c.
[Bucket Name] ボックスに、バケットの名前を入力します（たとえば
my-test-loadbalancer-log など）。この名前は、Amazon S3 にある既存のすべてのバ
ケット名と異なる必要があります。AWS リージョンによっては、バケット名にその他の制限
があることがあります。詳細は、Amazon Simple Storage Service 開発者ガイドの「Bucket
Restrictions and Limitations」を参照してください。
[Region] ボックスで、ロードバランサーを作成したリージョンを選択します。
[Create] をクリックします。
Amazon S3 バケットへのポリシーのアタッチ
Amazon S3 バケットを作成または指定した後は、バケットにポリシーをアタッチする必要があります。
バケットポリシーは、バケットのアクセス許可を定義するためにアクセスポリシー言語で記述された
JSON ステートメントのコレクションです。各ステートメントには 1 つのアクセス許可に関する情報が
含まれ、一連のエレメントが使用されます。バケットに書き込むためのアクセス権限を Elastic Load
Balancing に付与するためのバケットポリシーを、次のエレメントを使用して作成します。
• Effect—バケットへのアクセスを許可または拒否するかどうかを指定します。
• Principal — アクセスを許可または拒否するユーザーのアカウント ID またはサービス。このポリシー
では、プリンシパルは Elastic Load Balancing です。
次の表に、Elastic Load Balancing のアカウント ID を示します。ロードバランサーとバケットを作成
したリージョンのアカウント ID を使用します。
リージョン
リージョン名
Elastic Load Balancing アカウント ID
us-east-1
US East (N. Virginia)
127311923021
us-west-1
米国西部（北カリフォ
ルニア）
027434742980
us-west-2
米国西部（オレゴン）
797873946194
eu-west-1
欧州 (アイルランド)
156460612806
eu-central-1
欧州 (フランクフルト)
054676820928
160
リージョン
リージョン名
Elastic Load Balancing アカウント ID
ap-northeast-1
アジアパシフィック (東 582318560864
京)
ap-southeast-1
アジアパシフィック (シ 114774131450
ンガポール)
ap-southeast-2
アジアパシフィック
（シドニー）
783225319266
sa-east-1
南米 (サンパウロ)
507241528517
us-gov-west-1*
AWS GovCloud（米
国）
048591011584
cn-north-1**
中国 (北京)
638102146993
* このリージョンには個別のアカウントが必要です。詳細については、「AWS GovCloud（米国）」
** このリージョンには個別のアカウントが必要です。詳細については、「中国 (北京)」を参照してく
ださい。
• Action — 許可または拒否する特定のタイプのアクセスを定義します（読み込みまたは書き込みな
ど）。
• Resource — ポリシーの対象となるオブジェクトの Amazon リソースネーム (ARN) です。このポリ
シーのオブジェクトは Amazon S3 バケットです。
既存のバケットを使用している場合は、そのバケットとロードバランサーが同じリージョンにあるこ
とを確認してください。バケットは、ロードバランサーと同じアカウントに関連付けられている必
要はありません。
Caution
バケットにアタッチされているポリシーがすでに 1 つ以上ある場合は、そのポリシーに Elastic
Load Balancing アクセスログのステートメントを追加します。バケットにアクセスするユー
ザーに適したアクセス許可であることを確認するために、アクセス許可の結果セットを評価す
ることをお勧めします。
バケットにポリシーステートメントをアタッチするには
1.
https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。
2.
3.
Amazon S3 バケットを選択します。
[Properties] タブをクリックします。
4.
5.
[Permissions] をクリックします。
[Add Bucket Policy] をクリックします。
161
6.
[Bucket Policy Editor] ページで、[AWS Policy Generator] をクリックします。
7.
または、ステップ 10 のイメージからポリシーを直接コピーし、コピーしたポリシーを [Bucket
Policy Editor] ページのテキストエリアに貼り付けて、バケット名の正しい名前、プレフィックス、
AWS アカウント ID で置き換えることもできます。ステップ 11 に進みます。
[AWS Policy Generator] ページで、以下の詳細を入力します。
a.
b.
c.
d.
e.
[Select Type of Policy] ダイアログボックスをクリックし、[S3 Bucket Policy] を選択します。
[Effect] フィールドで、[Allow] を選択します。
[Principal] フィールドで、先ほど保存した Elastic Load Balancing アカウント ID を入力しま
す。
[Actions] ダイアログボックスをクリックし、[PutObject] を選択します。
[Amazon Resource Name (ARN)] フィールドに、Amazon S3 バケットの ARN を次の形式で
入力します。
arn:aws:s3:::yourS3bucketname/prefix/AWSLogs/yourAWSAccountID/*
us-gov-west-1 リージョンを使用している場合は、arn:aws:ではなく、arn:aws-us-gov:
の ARN 形式を使用します。
ARN で指定されたアカウント ID（yourAWSAccountID）は、ロードバランサーに関連付けら
れた AWS アカウント ID です。Amazon S3 バケット（yourS3bucketname）は、ロードバ
ランサーと同じアカウントに属していても、別のアカウントに属していてもかまいません。
Important
AWS アカウント ID は、ハイフンを使用せずに指定してください。
8.
f.
[Add Statement] をクリックします。
g.
ポリシーステートメントが表示されます。ポリシーステートメントは、次のイメージのステー
トメントのようになります:
h.
[Generate Policy] をクリックします。
[Policy JSON Document] ページで、生成されたポリシーを選択してコピーします。
162
9. [Close] をクリックしてポリシードキュメントページを閉じます。
10. [Bucket Policy Editor] ページに戻り、コピーしたポリシーをテキストエリアに貼り付けます。
11. [Save] をクリックしてポリシーを保存します。[Save] ボタンが有効でない場合は、Enter を押しま
す。
12. S3 コンソールページの [Permissions] ペインで、[Save] をクリックして Amazon S3 バケットにポ
リシーをアタッチします。
163
Elastic Load Balancing API 呼び出しログ
AWS CloudTrail を使用した Elastic Load Balancing
API 呼び出しのログ作成
Abstract
AWS CloudTrail を使用して Elastic Load Balancing の API 呼び出しをログに記録する方法について説明します。
AWS CloudTrail を使用して、アマゾンウェブサービス（AWS）アカウントまたはその代理による
Elastic Load Balancing（ELB）API 呼び出しをキャプチャすることができます。CloudTrail は、指定し
た Amazon S3 バケットにログファイルとしてその情報を格納します。API 呼び出しは、ELB API、ELB
CLI、ELB コンソール、AWS CLI を使用すると記録されます。CloudTrail によって収集されたログを使
用して、ELB ロードバランサーの動作を監視し、ロードバランサーに対して行われた API 呼び出しに
ついてその内容、ソース IP アドレス、実行者、日時などを判断できます。
AWS CloudTrail の詳細については、「AWS CloudTrail User Guide」を参照してください。
Note
AWS CloudTrail は ELB API 呼び出しのイベントのみを記録します。クライアントによるロー
ドバランサーへのリクエストなど、ロードバランサーで実行されるが、ELB API に含まれてい
ないアクションを監視する場合は、Elastic Load Balancing のアクセスログ機能を使用する必要
があります。詳細については、Elastic Load Balancing アクセスログ (p. 150) を参照してくださ
い。
CloudTrail のイベントログ作成機能の設定
AWS CloudTrail は、サポートされている各リージョンでログエントリを個別に作成し、そのリージョ
ン用に作成された Amazon S3 バケットに保存します。CloudTrail でサポートされるリージョンの詳細
については、「リージョンとエンドポイント – CloudTrail」を参照してください。
CloudTrail は、AWS Management Console、CLI、または API を使用して有効にすることができます。
CloudTrail のログ作成機能を有効にすると、CloudTrail サービスはログファイルを格納する Amazon S3
バケットを作成できるようになります。サポートされているすべてのリージョンで 1 つのログファイル
を共用する場合は、リージョンで作成されたログを 1 つの Amazon S3 バケットに集約することもでき
ます。
CloudTrail を作成する方法については、「証跡の作成と更新」を参照してください。ログの集約につい
ては、「CloudTrail ログファイルの単一の Amazon S3 バケットへの集約」を参照してください。
オプションとして、ログファイルの作成時に Amazon SNS を使用して通知するように CloudTrail を設
定することもできます。CloudTrail は通知を頻繁に送信します。そのため、Amazon SQS キューと組
み合わせて Amazon SNS を使用し、通知をプログラムで処理することをお勧めします。
CloudTrail サービスを使用してもコストは発生しません。ただし、Amazon S3 の標準レートが適用さ
れ、Amazon SNS と Amazon SQS を利用する場合はそのレートも適用されます。料金の詳細は、
Amazon S3 料金表、Amazon SNS 料金表、Amazon SQS 料金表のページを参照してください。
CloudTrail ログファイルの Elastic Load Balancing イ
ベントエントリ
AWS CloudTrail ログファイルは、JSON を使用してフォーマットしたイベント情報を含みます。1 件
のイベントレコードは、1 回の AWS API 呼び出しを表し、アクションをリクエストしたユーザーやリ
クエストの日時など、リクエストされたアクションに関する情報を含みます。
164
CloudTrail ログファイルの Elastic Load Balancing イベント
エントリ
CloudTrail ログファイルは、Elastic Load Balancing API 呼び出しだけでなく、AWS アカウントに関す
るすべての AWS API 呼び出しイベントを含みます。ただし、ログファイルを読み取り、eventSource
要素の値 elasticloadbalancing.amazonaws.com を使用して Elastic Load Balancing API の呼び出
しをスキャンすることができます。CreateLoadBalancer などの特定の ELB API を取得する場合は、
eventName 要素の値で呼び出しをスキャンします。
次の例は、ELB CLI を使用してロードバランサーを作成した後、そのロードバランサーを削除したユー
ザーの CloudTrail ログを示しています。CLI は、userAgent 要素によって識別されます。リクエスト
された API 呼び出し（CreateLoadBalancer と DeleteLoadBalancer）は各レコードの eventName 要素
で確認できます。ユーザーに関する情報（Alice）は userIdentity 要素で確認できます。
{
Records: [
eventVersion: "1.01",
userIdentity:
{
type: "IAMUser",
principalId: "60505EXAMPLE",
arn: "arn:aws:iam::123456789012:user/Alice",
accountId: "123456789012",
accessKeyId: "AKIAIOSFODNN7EXAMPLE"
},
eventTime: "2014-04-01T15:31:48Z",
eventSource: "elasticloadbalancing.amazonaws.com",
eventName: "CreateLoadBalancer",
awsRegion: "us-east-1",
sourceIPAddress: "127.0.0.01",
userAgent: "Amazon CLI/ElasticLoadBalancing API 2012-06-01",
requestParameters:
{
loadBalancerName: "my-test-loadbalancer",
listeners:
[
{
loadBalancerPort: 80,
protocol: "http",
instanceProtocol: "http",
instancePort: 80
}
],
availabilityZones:
[
"us-east-1a"
]
},
responseElements:
{
dNSName: "my-test-loadbalancer-1234567890.elb.amazonaws.com"
},
requestID: "b9960276-b9b2-11e3-8a13-f1ef1EXAMPLE",
eventID: "6f4ab5bd-2daa-4d00-be14-d92efEXAMPLE"
}
]
{
eventVersion: "1.01",
userIdentity:
{
type: "IAMUser",
165
CloudTrail ログファイルの Elastic Load Balancing イベント
エントリ
principalId: "60505EXAMPLE",
arn: "arn:aws:iam::123456789012:user/Alice",
accountId: "123456789012",
accessKeyId: "AKIAIOSFODNN7EXAMPLE"
},
eventTime: "2014-04-01T16:30:30Z",
eventSource: "elasticloadbalancing.amazonaws.com",
eventName: "DeleteLoadBalancer",
awsRegion: "us-east-1",
sourceIPAddress: "127.0.0.02",
userAgent: "Amazon CLI/ElasticLoadBalancing API 2012-06-01",
requestParameters: {
loadBalancerName: "my-test-loadbalancer"
},
responseElements: null,
requestID: "f0f17bb6-b9ba-11e3-9b20-999fdEXAMPLE",
eventID: "4f99f0e8-5cf8-4c30-b6da-3b69fEXAMPLE"
},
. . . . additional entries
]
}
CloudTrail ログファイルのさまざまな要素と値の詳細については、『AWS CloudTrail User Guide』の
「CloudTrail イベントリファレンス」を参照してください。
CloudTrail が統合された Amazon パートナーソリューションを使用して CloudTrail ログファイルの読
み取りと分析を実行することもできます。オプションについては、AWS パートナーのページを参照し
てください。
166
ロードバランサーへのアクセスの制
御
Abstract
Identity and Access Management アクセス権限を使用して、ユーザーが Elastic Load Balancing リソースで実行で
きるアクションを指定します。
AWS ではセキュリティ認証情報を使用して、ユーザーを識別し、AWS リソースへのアクセスを付与し
ます。AWS Identity and Access Management (IAM) の機能を使用して、他のユーザー、サービス、お
よびアプリケーションがお客様の AWS リソースを使用できるようにします。その際、お客様のセキュ
リティ認証情報は共有されません。AWS リソースの完全使用または制限付き使用のどちらを許可する
かを選択できます。
デフォルトでは、IAM ユーザーには、AWS リソースを作成、表示、変更するためのアクセス権限はあ
りません。IAM ユーザーがロードバランサーなどのリソースにアクセスし、タスクを実行できるように
するには、特定のリソースや必要となる API アクションを使用するためのアクセス権限を IAM ユーザー
に付与する IAM ポリシーを作成してから、そのポリシーを IAM ユーザーまたは IAM ユーザーが属する
グループにアタッチする必要があります。ポリシーをユーザーまたはユーザーのグループにアタッチす
る場合、ポリシーによって特定リソースの特定タスクを実行するユーザーの権限が許可または拒否され
ます。
たとえば、IAM を使用して AWS アカウントにユーザーとグループを作成することができます（IAM
ユーザーは、人、システム、またはアプリケーションのいずれかです）。その後、ユーザーとグループ
にアクセス許可を付与すると、指定したリソースに対する特定のアクションを実行できます。
IAM の一般的情報については、「IAM とは何ですか?」を参照してください。. ユーザーとグループの
作成と管理については、「IAM ユーザーとグループ」を参照してください。
目次
• IAM ポリシーを使用したアクセス権限の付与 (p. 168)
• Elastic Load Balancing の IAM ポリシー例 (p. 170)
167
IAM ポリシーを使用したアクセス権限の付与
IAM ポリシーを使用したアクセス権限の付与
IAM ポリシーは 1 つ以上のステートメントで構成される JSON ドキュメントです。各ステートメント
は次のように構成されます。
{
"Version": "2012-10-17",
"Statement":[{
"Effect": "effect",
"Action": "action",
"Resource": "resource-arn",
"Condition": {
"condition": {
"key":"value"
}
}
}]
}
• Effect: effect には、Allow または Deny を指定できます。デフォルトでは、IAM ユーザーにはリソー
スおよび API アクションを使用するアクセス許可がないため、リクエストはすべて拒否されます。
明示的な許可はデフォルトに優先します。明示的な拒否はすべての許可に優先します。
• Action: action は、アクセス権限の付与や拒否の対象となる特定の API アクションです。action の指
定については、IAM ポリシーでのアクションの指定 (p. 168) を参照してください。
• Resource: アクションによって影響を受けるリソースです。一部の Elastic Load Balancing API アク
ションでは、特定のロードバランサーに対して許可または拒否するアクセス権限を制限できます。こ
のステートメントで特定のロードバランサーを指定するには、ロードバランサーの Amazon リソー
スネーム (ARN) を使用する必要があります。詳細については、「IAM ポリシーでのリソースの指
定 (p. 169)」を参照してください。API アクションで特定のロードバランサーを指定することがサポー
トされていない場合は、ワイルドカード（*）を使用して、すべてのロードバランサーを指定します。
• Condition: ポリシーが有効になるタイミングを制御する条件を必要に応じて使用できます。詳細につ
いては、「IAM ポリシーでの条件キーの指定 (p. 170)」を参照してください。
IAM ポリシーでのアクションの指定
IAM ポリシーステートメントの Action 要素では、Elastic Load Balancing に用意された API アクション
を指定できます。次の例に示すように、アクション名の前に小文字の文字列 elasticloadbalancing:
を指定する必要があります。
"Action": "elasticloadbalancing:DescribeLoadBalancers"
1 つのステートメントで複数のアクションを指定するには、次のようにアクションをカンマで区切って
全体を角括弧で囲みます。
"Action": ["elasticloadbalancing:action1","elasticloadbalancing:action2"]
ワイルドカード（*）を使用して複数のアクションを指定することもできます。次の例では、Create
で始まる Elastic Load Balancing のすべての API アクション名を指定します。
"Action": "elasticloadbalancing:Create*"
168
IAM ポリシーでのリソースの指定
Elastic Load Balancing のすべての API アクションを指定するには、次の例のように、ワイルドカード
（*）を使用します。
"Action": "elasticloadbalancing:*"
Elastic Load Balancing の API アクションのリストについては、『Elastic Load Balancing API Reference』
の「アクション」を参照してください。
IAM ポリシーでのリソースの指定
リソースレベルのアクセス許可とは、ユーザーがアクションを実行可能なリソースを指定できることを
意味します。Elastic Load Balancing では、リソースレベルのアクセス権限が部分的にサポートされま
す。つまり、特定の API アクションについて、それらのアクションを使用できるロードバランサーの
ユーザーを制御することができます。
ポリシーステートメントの Resource 要素でロードバランサーを指定するには、Amazon リソースネー
ム (ARN) を使用する必要があります。ロードバランサーの ARN の構文は次のとおりです。
arn:aws:elasticloadbalancing:region:my-account-id:loadbalancer/load-balancername
• region— ロードバランサーのリージョン。Elastic Load Balancing でサポートされているリージョ
ンのリストについては、「リージョンとエンドポイント」を参照してください。
• account-id — ハイフンなしの AWS アカウント ID（たとえば、0123456789012）。
• load-balancer-name — ロードバランサーの名前。すべてのロードバランサーを指定する場合は、
ワイルドカード（*）を使用できます。
特定のロードバランサーへのユーザーアクセスを制御するには、ロードバランサーの ARN を指定し
て、Resource ステートメントを使用します。以下に例を示します。
"Resource": "arn:aws:elasticloadbalancing:us-west-2:123456789012:loadbalancer/myload-balancer"
ただし、次の API アクションでは特定のロードバランサーを指定できません。
• DescribeInstanceHealth
• DescribeLoadBalancerAttributes
• DescribeLoadBalancerPolicyTypes
• DescribeLoadBalancers
• DescribeLoadBalancerPolicies
• DescribeTags
リソースレベルのアクセス権限をサポートしていない API アクションでリソースを指定すると、API 呼
び出しが失敗します。代わりに、リソースレベルのアクセス権限をサポートしていない API アクショ
ンでは、次の Resource ステートメントを使用する必要があります。
"Resource": "*"
169
IAM ポリシーでの条件キーの指定
IAM ポリシーでの条件キーの指定
IAM ポリシーステートメントには、有効になるタイミングを制御する条件を指定するオプションがあり
ます。各条件には 1 つ以上のキーと値のペアが含まれます。AWS には、IAM ユーザーおよびグループ
がロードバランサーを使用する条件を指定する以下のキーが定義されています。
Note
キー名では大文字と小文字が区別されます。
• aws:CurrentTime— 日時条件と共に使用して、リクエスト時刻に基づいてアクセスを制限します
（「日付条件」を参照）。
• aws:EpochTime— 日時条件と共に使用して、エポックつまり UNIX 時間で日付を指定します（「日
付条件」を参照）。
• aws:MultiFactorAuthPresent— API リクエストを実行している IAM ユーザーが多要素認証
（MFA）デバイスを使用して認証されたかどうかを確認するときに使用します。
• aws:MultiFactorAuthAge— リクエストを送信した多要素認証（MFA）済みのセキュリティ認証
情報がどれぐらい前（秒）に発行されたのかを多要素認証（MFA）を使用して確認するときに使用し
ます。他のキーとは異なり、MFAが使用されていない場合、このキーは存在しません（「条件キー」、
「数値条件」、「AWS のデバイスに Multi-Factor Authentication（MFA）を使用」を参照）。
• aws:SecureTransport— リクエストが SSL を使用して送信されたかどうかを確認するときに使用
します（「ブール条件」を参照）。
• aws:SourceIp— リクエスタの IP アドレスを確認するときに使用します（「IP アドレス」を参照）。
お客様が aws:SourceIp を使用していて EC2 インスタンスからリクエストが来た場合、そのインス
タンスのパブリック IP アドレスが評価されます。
• aws:Referer— HTTP リクエストを実行するユーザーを確認するときに使用します。
• aws:UserAgent— リクエストを実行したクライアントアプリケーションを確認するときに文字列条
件を指定して使用します（「文字列条件」を参照）。
• aws:userid— リクエスタのユーザー ID を確認するときに使用します（「文字列条件」を参照）。
• aws:username— 使用可能な場合、リクエスタのユーザー名を確認するときに使用します（「文字
列条件」を参照）。
ロードバランサーへのアクセスをどのように制御するかを決定したら、IAM コンソールを開き、「IAM
ポリシーを管理する」の指示に従って、Elastic Load Balancing の IAM ポリシーを作成します。IAM ポ
リシーのテストについては、「IAM ポリシーをテストする」を参照してください。
Elastic Load Balancing の IAM ポリシー例
次の例では、ロードバランサーへのアクセスについて IAM ユーザーが保持できるアクセス権限を制御
するためのポリシーステートメントを示しています。
例 1: ユーザーが 1 つの特定のロードバランサーで特定の API アクションを使用することを許可する
次のポリシーでは、AWS アカウントに関連付けられたすべてのロードバランサーですべての Describe
API を使用するためのアクセス権限をユーザーに付与し、示されている API アクションを指定のロード
バランサーでのみ使用することをユーザーに許可します。
{
"Version": "2012-10-17",
"Statement": [{
170
"Effect": "Allow",
"Action": "elasticloadbalancing:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:Create*",
"elasticloadbalancing:Delete*",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DisableAvailabilityZonesForLoadBalancer",
"elasticloadbalancing:EnableAvailabilityZonesForLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:Set*"
],
"Resource": "arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbal
ancer/my-load-balancer"
}]
}
例 2: ユーザーが 2 つの特定のロードバランサーで特定の API アクションを使用することを許可する
次のポリシーでは、AWS アカウントに関連付けられたすべてのロードバランサーですべての Describe
API を使用するためのアクセス権限をユーザーに付与し、示されている API アクションを指定のロード
バランサー（複数）でのみ使用することをユーザーに許可します。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "elasticloadbalancing:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
"elasticloadbalancing:AttachLoadBalancerToSubnets",
"elasticloadbalancing:ConfigureHealthCheck",
"elasticloadbalancing:Create*",
"elasticloadbalancing:Delete*",
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
"elasticloadbalancing:DisableAvailabilityZonesForLoadBalancer",
"elasticloadbalancing:EnableAvailabilityZonesForLoadBalancer",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:Set*"
],
"Resource": [
"arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/myload-balancer-1",
171
"arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/myload-balancer-2"
]
}]
}
例 3: ユーザーが特定のロードバランサーで特定の API アクションを使用することを許可する
次のポリシーでは、RegisterInstancesWithLoadBalancer と
DeregisterInstancesFromLoadBalancer の API アクションを指定のロードバランサーで使用する
ためのアクセス権限をユーザーに付与します。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:RegisterInstancesWithLoadBalancer"
],
"Resource":"arn:aws:elasticloadbalancing: us-east-1:123456789012:loadbal
ancer/my-load-balancer”
}]
}
例 4: ユーザーが特定のロードバランサーで SSL を利用して特定の API アクションを使用することを許
可する
次のポリシーでは、SSL リクエストを利用して、RegisterInstancesWithLoadBalancer と
DeregisterInstancesFromLoadBalancer の API アクションを指定のロードバランサーで使用する
ためのアクセス権限をユーザーに付与します。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:RegisterInstancesWithLoadBalancer"
],
"Condition": {"Bool":{"aws:SecureTransport":"true"}},
"Resource": "arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbal
ancer/my-load-balancer"
}]
}
172
Elastic Load Balancing のトラブル
シューティング
Abstract
Elastic Load Balancing を使用しているときに発生する可能性のある問題のトラブルシューティングを行います。
Elastic Load Balancing を利用する際に役立つトラブルシューティング資料を以下の表にまとめました。
API エラー
エラー
CertificateNotFound: 未定義 (p. 175)
OutofService: 一時的なエラー発生 (p. 175)
HTTP エラー
エラー
HTTP 400: BAD_REQUEST (p. 175)
HTTP 405: METHOD_NOT_ALLOWED (p. 175)
HTTP 408: Request Timeout (p. 176)
HTTP 502: Bad Gateway (p. 176)
HTTP 503: Service Unavailable または HTTP 504: Gateway Timeout (p. 176)
レスポンスコード
Response Code（レスポンスコード）
HTTPCode_ELB_4XX (p. 177)
HTTPCode_ELB_5XX (p. 177)
173
API エラー
Response Code（レスポンスコード）
HTTPCode_Backend_2XX (p. 177)
ヘルスチェックのエラー
エラー
インスタンスへの接続がタイムアウトした (p. 179)
ヘルスチェックのターゲットページのエラー (p. 180)
パブリックキー認証が失敗する (p. 180)
停止して起動したインスタンスがロードバランサーのヘルスチェックに失敗する (p. 180)
インスタンスがロードバランサーからのトラフィックを受信しない (p. 181)
インスタンスのポートが開いていない (p. 181)
Auto Scaling グループのインスタンスがロードバランサーのヘルスチェックに失敗する (p. 181)
インスタンスの登録
エラー
バックエンドインスタンスの登録に時間がかかりすぎる。 (p. 182)
AMI から起動したインスタンスを登録できません。 (p. 182)
Elastic Load Balancing のトラブルシューティング:
API エラー
Abstract
Elastic Load Balancing API から返されるエラーメッセージをトラブルシューティングを行います。
以下は Elastic Load Balancing API から返されるエラーメッセージ、考えられる原因、問題の絞り込み
や解決のための手順です。
エラーメッセージ
• CertificateNotFound: 未定義 (p. 175)
• OutofService: 一時的なエラー発生 (p. 175)
174
CertificateNotFound: 未定義
CertificateNotFound: 未定義
原因 1: AWS マネジメントコンソールを使用して証明書が作成されると、すべてのリージョンに伝達さ
れる際に遅延が発生します。この遅延が発生すると、ロードバランサーの作成プロセスの最終ステップ
でエラーメッセージが表示されます。
解決方法 1: 15 分ほど待ってから、再度試してください。問題が解決しない場合は、AWS サポートセ
ンターに連絡してください。
原因 2: AWS CLI または API を直接使用している場合、存在しない証明書の Amazon リソースネーム
（ARN）を指定すると、このエラーが返されることがあります。
解決方法 2: Identity and Access Management (IAM) のアクション GetServerCertificate を使用して証明
書 ARN を取得し、ARN に正しい値を指定したことを確認します。
OutofService: 一時的なエラー発生
原因: Elastic Load Balancing サービスまたはその基盤ネットワーク内に一時的な問題があります。この
一時的な問題は、Elastic Load Balancing がロードバランサーとこれと関連するバックエンドインスタ
ンスの状態を照会すると発生する場合があります。
[Solution]: API 呼出を再試行してください。問題が解決しない場合は、AWS サポートセンターに連絡
HTTP エラー
Abstract
ロードバランサーに対して返されるエラーメッセージをトラブルシューティングを行います。
以下はロードバランサーによって返されるエラーメッセージ、考えられる原因、問題の絞り込みや解決
のための手順です。
エラーメッセージ
• HTTP 400: BAD_REQUEST (p. 175)
• HTTP 405: METHOD_NOT_ALLOWED (p. 175)
• HTTP 408: Request Timeout (p. 176)
• HTTP 502: Bad Gateway (p. 176)
• HTTP 503: Service Unavailable または HTTP 504: Gateway Timeout (p. 176)
HTTP 400: BAD_REQUEST
Description: クライアントが無効なリクエストを送信したことを示します。
Cause: クライアントが HTTP 仕様を満たさない誤った形式のリクエストを送信しました。
ソリューション: 直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャします。ヘッ
ダーと URL で誤った形式のリクエストを確認します。リクエストが HTTP 仕様を満たすことを確認し
ます。
HTTP 405: METHOD_NOT_ALLOWED
Description: メソッドの長さが無効であることを示しています。
Cause: リクエストヘッダー内のメソッドの長さが 127 文字を超えています。
175
HTTP 408: Request Timeout
Solution: メソッドの長さを確認します。
HTTP 408: Request Timeout
Description: クライアントがリクエストをキャンセルしたか、リクエスト全体の送信に失敗したことを
示します。
原因: ネットワークの中断、または形式が完全でないヘッダー、指定されたコンテンツのサイズが実際
に送信されたコンテンツのサイズと一致しないなど、リクエストの構造に誤りがあります。
[Solution]: リクエストを生成するコードを検査します。実際のリクエストの検査について多くのコント
ロールを与えられている場合は、登録されたインスタンス（または開発/テスト環境）に直接送信して
みます。
HTTP 502: Bad Gateway
Description: 登録されたインスタンスから送信された応答をロードバランサーが解析できなかったこと
を示します。
[Cause]: インスタンスからの応答の形式が適切でないか、ロードバランサーに問題があります。
[Solution]: インスタンスから送信された応答が HTTP 仕様に準拠していることを確認します。詳細につ
いては、AWS サポートセンターに連絡してください。
HTTP 503: Service Unavailable または HTTP 504:
Gateway Timeout
説明: ロードバランサーまたは登録されたインスタンスが原因でエラーが発生していることを示します。
Cause 1: ロードバランサーにリクエストを処理する能力が不足しています。
解決方法: これは一時的な問題であり、数分以上は継続しません。問題が解決しない場合は、AWS サ
ポートセンターに連絡してください。
原因 2: 登録されたインスタンスが Elastic Load Balancing への接続を終了させています。
解決方法 2: EC2 インスタンスのキープアライブ設定を有効にし、キープアライブタイムアウトを、ロー
ドバランサーのアイドルタイムアウト設定と同じか、それより大きい値に設定します。詳細について
は、アイドル接続のタイムアウト (p. 11) を参照してください。
Cause 3: 登録されたインスタンスがありません。
解決方法 3: ロードバランサーによるレスポンスが設定された利用可能ゾーンごとに 1 つ以上のインス
タンスを登録します。これを確認するには、CloudWatch の HealthyHostCount メトリックスを確認
します。インスタンスが各アベイラビリティーゾーンに登録されているかどうか不確かな場合は、クロ
スゾーン負荷分散を有効にすることをお勧めします。詳細については、「ロードバランサーのクロス
ゾーン負荷分散の有効化または無効化 (p. 106)」を参照してください。
Cause 4: 正常なインスタンスがありません。
解決方法 4: ロードバランサーのレスポンスを設定しているすべての利用可能ゾーンに正常なインスタ
ンスがあることを確認します。これを確認するには、CloudWatch の HealthyHostCount を確認しま
す。
原因 5: クライアントとの接続が閉じています（ロードバランサーは応答を送信できません）。
解決方法 5: リクエストを送信するマシンでパケットスニッファーを使用して、レスポンスが送信され
る前にクライアントが接続を閉じないことを確認してください。
Cause 6: インスタンスのセキュリティグループがロードバランサーとの通信を許可していません。
解決方法 6: バックエンドインスタンスのセキュリティグループがロードバランサーのインスタンスポー
トへのアクセスを許可するように設定されていることを確認します。
176
レスポンスコードのメトリックス
レスポンスコードのメトリックス
Abstract
ロードバランサーに対して返される HTTP エラーコードをトラブルシューティングを行います。
ロードバランサーは、クライアントに送信された HTTP 応答コードの Amazon CloudWatch にメトリッ
クスを送信することで、エラーの原因がロードバランサーなのか、バックエンドインスタンスなのかを
特定します。ロードバランサーの CloudWatch から返されるメトリックスを Elastic Load Balancing の
トラブルシューティングに使用できます。詳細については、「Amazon CloudWatch を使用したロード
バランサーの監視 (p. 139)」を参照してください。
以下は Amazon CloudWatch がロードバランサーに対して返すレスポンスコードのメトリックス、考え
られる原因、問題の絞り込みや解決のための手順です。
レスポンスコード
• HTTPCode_ELB_4XX (p. 177)
• HTTPCode_ELB_5XX (p. 177)
• HTTPCode_Backend_2XX (p. 177)
HTTPCode_ELB_4XX
Cause: クライアントからのリクエストが誤った形式であるか、キャンセルされたことを示します。
ソリューション
• 「HTTP 400: BAD_REQUEST (p. 175)」を参照してください。
• 「HTTP 405: METHOD_NOT_ALLOWED (p. 175)」を参照してください。
• 「HTTP 408: Request Timeout (p. 176)」を参照してください。
HTTPCode_ELB_5XX
Cause: ロードバランサーまたは登録されたインスタンスがエラーの原因であるか、またはロードバラ
ンサーが応答を解析できませんでした。
ソリューション
• 「HTTP 502: Bad Gateway (p. 176)」を参照してください。
• 「HTTP 503: Service Unavailable または HTTP 504: Gateway Timeout (p. 176)」を参照してくださ
い。
原因: 登録されたインスタンスから正常に成功した応答が返されたことを示します。
177
Solution: なし.
原因: 登録されたインスタンスから送信された何らかのリダイレクト応答を示します。
解決方法: インスタンスのアクセスログまたはエラーログを表示して、問題の原因を判断します。リク
エストをインスタンスに直接送信（ロードバランサーをバイパス）して応答を表示します。
原因: 登録されたインスタンスから送信された何らかのクライアントエラー応答を示します。
原因: 登録されたインスタンスから送信された何らかのサーバーエラー応答を示します。
ヘルスチェック設定
Abstract
ロードバランサーのヘルスチェック失敗のトラブルシューティングを行います。
ロードバランサーは Elastic Load Balancing (ELB) によって提供される、デフォルトのヘルスチェック
設定、またはユーザーが指定するヘルスチェック設定を使用して、登録されたインスタンスの状態を
チェックします。ヘルスチェック設定には、プロトコル、ping ポート、ping パス、応答タイムアウト、
ヘルスチェック間隔などの情報が含まれます。詳細については、「ヘルスチェック (p. 9)」を参照し
てください。
ロードバランサーに登録された EC2 インスタンスの現在のヘルス状態を確認するためには、いくつか
の方法があります。AWS マネジメントコンソール、describe-instance-health AWS CLI コマンド、また
は DescribeInstanceHealth アクションを使用できます。
一部またはすべてのインスタンスの現在の状態が OutOfService で、説明フィールドに Instance
has failed at least the Unhealthy Threshold number of health checks consecutively
というメッセージが表示された場合は、インスタンスはロードバランサーのヘルスチェックに失敗して
います。以下は確認する必要がある問題、考えられる原因、問題の絞り込みや解決のための手順です。
問題点
• インスタンスへの接続がタイムアウトした (p. 179)
• Amazon Virtual Private Cloud (Amazon VPC) で起動したインターネット向けロードバランサーへの
接続がタイムアウトしました (p. 179)
• ヘルスチェックのターゲットページのエラー (p. 180)
• パブリックキー認証が失敗する (p. 180)
• 停止して起動したインスタンスがロードバランサーのヘルスチェックに失敗する (p. 180)
• インスタンスがロードバランサーからのトラフィックを受信しない (p. 181)
• インスタンスのポートが開いていない (p. 181)
178
インスタンスへの接続がタイムアウトした
• Auto Scaling グループのインスタンスがロードバランサーのヘルスチェックに失敗する (p. 181)
インスタンスへの接続がタイムアウトした
問題: ロードバランサーから EC2 インスタンスへのヘルスチェックのリクエストがタイムアウトした
か、断続的に失敗している。
まず、インスタンスに直接接続して問題を確認します。そのインスタンスのプライベート IP アドレス
を使用して、ネットワーク内からインスタンスに接続することをお勧めします。
TCP 接続では、次のコマンドを使用します。
telnet private-IP-address-of-the-instance port
HTTP または HTTPS 接続では、次のコマンドを使用します。
$curl –I private-IP-address-of-the-instance/health-check-target-page:port
HTTP/HTTPS 接続を使用している場合に、200 以外の応答が返されたときは、「ヘルスチェックのター
ゲットページのエラー (p. 180)」を参照してください。インスタンスに直接接続できる場合は、以下を
確認してください。
原因 1: インスタンスが、設定された応答タイムアウト期間内に応答できない。
ソリューション 1: ロードバランサーのヘルスチェック設定で、応答タイムアウト設定を調整します。
原因 2: インスタンスに大きな負荷がかかっていて、設定された応答タイムアウト期間よりも応答に時
間がかかっている。
ソリューション 2:
• Amazon EC2 のモニタリンググラフで、CPU の過度の使用率について確認します。詳細については、
「特定の EC2 インスタンスの統計情報を取得する」を参照してください。
• EC2 インスタンスに接続して、メモリ、制限など他のアプリケーションリソースの使用状況を確認
します。
• 必要に応じて、さらにインスタンスを追加するか、Auto Scaling を有効にします。Auto Scaling の使
用の詳細については、「Auto Scaling とは何か.
原因 3: HTTP または HTTPS 接続を使用していて、ping パスフィールドで指定したターゲットページ
（例: HTTP:80/index.html）でヘルスチェックを実行している場合、ターゲットページからの応答は、
設定したタイムアウトより長くかかる場合がある。
ソリューション 3: よりシンプルなヘルスチェックのターゲットページを使用するか、ヘルスチェック
間隔の設定を調整します。
Amazon Virtual Private Cloud (Amazon VPC) で起動
したインターネット向けロードバランサーへの接続
がタイムアウトしました
問題: フロントエンド接続（クライアントからロードバランサー）がタイムアウトしたため、ヘルス
チェックのリクエストが Amazon VPC で起動したインスタンスに到達していません。
原因: Amazon VPC で起動したインターネット向けロードバランサーが、インターネットゲートウェイ
を使用してインターネットに接続されていないサブネットに配置されている可能性があります。
179
ヘルスチェックのターゲットページのエラー
ソリューション: インターネット向けロードバランサーが、インターネットゲートウェイを経由するデ
フォルトルートがルートテーブルで設定されているパブリックサブネットに配置されていることを確認
ヘルスチェックのターゲットページのエラー
問題: 特定の ping ポートと ping パス（例: HTTP:80/index.html）上のインスタンスに対して発行された
HTTP GET リクエストで、200 以外の応答コードが受信される。または、一部のインスタンスでヘル
スチェックが失敗し、一部のインスタンスは正常である。
原因 1: 一部またはすべてのインスタンスでターゲットページが設定されていない。
ソリューション 1: すべての登録されたインスタンスで、ターゲットページ（例: index.html）を作成
します。
原因 2: 応答の Content-Length ヘッダーの値が設定されていない。
ソリューション 2: 応答に本文が含まれている場合、Content-Length ヘッダーの値を 0 以上に設定する
か、Transfer-Encoding の値を "chunked" に設定します。
原因 3: インスタンス上のアプリケーションが、ロードバランサーからリクエストを受信するように設
定されていない。
ソリューション 3: インスタンス上のアプリケーションを確認し、200 以外の応答の原因を調査します。
パブリックキー認証が失敗する
問題: バックエンド認証が有効で、HTTPS または SSL プロトコルを使用するように設定されたロード
バランサーが、パブリックキー認証に失敗する。s_client コマンドを使用して、証明書チェーン内の
すべてのサーバー証明書のリストを表示します。このコマンドの詳細については、「https://
www.openssl.org/docs/apps/s_client.html」を参照してください。
原因: SSL 証明書のパブリックキーが、ロードバランサーで設定されたパブリックキーと一致しない。
ソリューション: SSL 証明書の更新が必要な場合があります。SSL 証明書が最新状態である場合は、そ
の証明書をロードバランサーに再インストールしてみます。詳細については、ロードバランサーの SSL
証明書の更新 (p. 41) を参照してください。
停止して起動したインスタンスがロードバランサー
のヘルスチェックに失敗する
EC2-Classic インスタンス
問題: EC2-Classic で起動されるインスタンスが停止し、再起動される。ロードバランサーは再起動さ
れたインスタンスに接続することができません。
原因: Elastic Load Balancing は、関連付けられた IP アドレスを使用してロードバランサーを EC2 イン
スタンスに登録します。EC-Classic で起動した EC2 インスタンスを停止して再起動すると、インスタ
ンスに関連付けられた IP アドレスが変わります。ロードバランサーは新しい IP アドレスを認識しない
ため、ロードバランサーはインスタンスに接続できません。
Solution: インスタンスを停止した後、インスタンスをロードバランサーから登録解除し、インスタン
スを起動した後にインスタンスをロードバランサーに登録します。詳細については、ロードバランサー
での EC2 インスタンスの登録解除と登録 (p. 95) を参照してください。
EC2-VPC インスタンス
問題: Amazon Virtual Private Cloud（Amazon VPC）で起動されたインスタンスが停止し、再起動され
る。Amazon VPC のロードバランサーは、再起動されたインスタンスに接続することができません。
180
インスタンスがロードバランサーからのトラフィックを受
信しない
原因: VPC インスタンスを停止して起動した場合、インスタンスが再起動されたことをロードバラン
サーが認識するまで時間がかかることがある。この間、ロードバランサーは再起動されたインスタンス
に接続されていません。
Solution: 再起動後にインスタンスをロードバランサーに再登録します。詳細については、ロードバラ
ンサーでの EC2 インスタンスの登録解除と登録 (p. 95) を参照してください。
インスタンスがロードバランサーからのトラフィッ
クを受信しない
問題: インスタンスのセキュリティグループが、ELB セキュリティグループからのトラフィックをブ
ロックしている。
インスタンスでパケットキャプチャを実行して、問題を確認します。次のコマンドを使用します。
# tcpdump port health-check-port
原因 1: インスタンスに関連付けられたセキュリティグループが、ロードバランサーからのトラフィッ
クを許可していません。
ソリューション 1: ロードバランサーからのトラフィックを許可するようにインスタンスのセキュリティ
グループを編集します。ロードバランサーのセキュリティグループからのトラフィックを許可するルー
ルを追加します。
原因 2: EC2-VPC ロードバランサーのセキュリティグループで、バックエンドインスタンスにトラフィッ
クを送信するように Egress ルールをセットアップしていない。
ソリューション 2: EC2-VPC ロードバランサーのセキュリティグループを編集して、サブネットおよび
バックエンドインスタンスへのトラフィックを許可します。
EC2-Classic で起動されるインスタンスのセキュリティグループの管理の詳細については、「EC2-Classic
でのロードバランサーのセキュリティグループ (p. 68)」を参照してください。
VPC 内で起動されるインスタンスのセキュリティグループの管理については、「VPC でのロードバラ
ンサーのセキュリティグループ (p. 78)」を参照してください。
インスタンスのポートが開いていない
問題: ロードバランサーによって送信されるヘルスチェックが、バックエンドインスタンスのポートま
たはファイアウォールによってブロックされる。
次のコマンドを使用して問題を確認します。
netstat –ant
原因: 指定されたポートまたはリスナーポート（異なる設定の場合）が開いていません。ヘルスチェッ
クに指定したポートと、リスナーポートの両方が開いていて、リッスンしている必要があります。
ソリューション: リスナーポートと、ヘルスチェックで指定したポート（異なる設定の場合）をインス
タンスで開き、ロードバランサーのトラフィックを受信できるようにします。
Auto Scaling グループのインスタンスがロードバラ
ンサーのヘルスチェックに失敗する
問題: Auto Scaling グループのインスタンスはデフォルトの Amazon EC2 ヘルスチェックに合格する
が、ロードバランサーのヘルスチェックには失敗する。
原因: Amazon EC2 のヘルスチェックは、ロードバランサーのヘルスチェックとは異なる。Amazon EC2
ヘルスチェックには、ハードウェアとソフトウェアの問題を検出するためのインスタンスのステータス
チェックが含まれますが、ロードバランサーはリクエストをインスタンスに送信して 200 応答コード
181
を待機するか、インスタンスと TCP 接続を確立することにより（TCP ベースのヘルスチェックの場
合）、ヘルスチェックを実行します。
インスタンスは、インスタンス内で実行するアプリケーションに、ロードバランサーがインスタンスを
停止中と判断する問題があることが原因で、ロードバランサーのヘルスチェックに失敗する場合があり
ます。このインスタンスは、Amazon EC2 ヘルスチェックに合格する場合があります。EC2 ヘルス
チェックに基づいて正常な状態と見なされるため、Auto Scaling ポリシーによって置き換えられませ
ん。
ソリューション: Auto Scaling グループにロードバランサーのヘルスチェックを使用します。ロードバ
ランサーのヘルスチェックを使用すると、Auto Scaling は、Amazon EC2 インスタンスのステータス
チェックとロードバランサーのヘルスチェックの両方の結果を確認して、インスタンスのヘルスステー
タスを判断します。詳細については、『Auto Scaling 開発者ガイド』の「Auto Scaling グループに Elastic
Load Balancing ヘルスチェックを追加する」を参照してください。
Abstract
ロードバランサーにインスタンスを登録した際に発生する可能性のある問題のトラブルシューティングを行いま
す。
ロードバランサーにインスタンスを登録する場合、ロードバランサーがインスタンスへのリクエストの
送信を開始する前に行うべき手順があります。
以下はバックエンドインスタンスを登録するときにロードバランサーが遭遇する可能性のある問題、考
えられる原因、問題の絞り込みや解決のための手順です。
問題点
• バックエンドインスタンスの登録に時間がかかりすぎる。 (p. 182)
• AMI から起動したインスタンスを登録できません。 (p. 182)
バックエンドインスタンスの登録に時間がかかりす
ぎる。
Problem: インスタンスの登録に、In Service で予期されるより時間がかかっています。
Cause: バックエンドインスタンスの状態チェックが失敗している可能性があります。最初のインスタ
ンスを登録するステップ（最大約30秒かかります）が完了した後、バックエンドインスタンスは状態
チェックを実行します。ロードバランサーは、状態チェックの設定で定義した正常なしきい値と一致す
るまで、バックエンドインスタンスを In Service として処理しません。
[Solution]: 前のセクションの「インスタンスへの接続がタイムアウトした (p. 179)」で推奨されている手
順を実行してみます。
AMI から起動したインスタンスを登録できません。
問題: 有料 AMI を使用して起動したインスタンスが Elastic Load Balancing で登録されません。
Cause: インスタンスが有料 AMI を使用して Amazon DevPay サイトから起動された可能性がありま
す。
解決方法: Elastic Load Balancing では、有料 AMI を使用して Amazon DevPay サイトから起動したイ
ンスタンスの登録はサポートされていません。有料 AMI を使用する場合、ユースケースによっては、
AWS Marketplace を代替方法としてお勧めします。既に AWS Marketplace から有料 AMI を使用して
182
AMI から起動したインスタンスを登録できません。
おり、有料 AMI から起動したインスタンスを登録できない場合は、AWS サポートセンターに連絡して
ください。
有料 AMI の詳細については、『Amazon Elastic Compute Cloud User Guide』の「Paid AMIs」を参照
183
Elastic Load Balancing の制限
Abstract
Elastic Load Balancing の制限について説明します。
デフォルトでは、AWS アカウントに対して次の Elastic Load Balancing の制限が適用されます。
• リージョンあたりのロードバランサーの数: 20
• ロードバランサーあたりのリスナーの数: 100
他のサービスに関するデフォルトの制限を確認するには、「AWS サービスの制限」を参照してくださ
い。
次の手順に従って、アカウントの制限を拡大するようにリクエストできます。
制限の拡大をリクエストするには
1.
2.
3.
AWS サポートセンターのページを開き、必要に応じてサインインしたら、[Open a new case] を
クリックします。
[Regarding] で [Service Limit Increase] を選択します。
[Limit Type] で [Elastic Load Balancers] を選択し、フォームにあるすべての必須フィールド
を入力して、希望する連絡方法のページの下部にあるボタンをクリックします。
184
タスク 1: コマンドラインインターフェイスをダウンロード
する
Elastic Load Balancing コマンドライ
ンインターフェイス
Abstract
Elastic Load Balancing コマンドラインインターフェイスツールをインストールして、セットアップします。
ELB CLI は API のアクションをラップして、複数の機能を備えたコマンドを提供します。CLI コマンド
は Java で作成されており、Windows と Linux/UNIX/Mac OSX 用のシェルスクリプトが含まれていま
す。シェルスクリプトは自己完結型の ZIP ファイルとして使用できます。
Important
Elastic Load Balancing CLI は、複数の AWS サービスを管理するための統合ツールである、
AWS Command Line Interface（AWS CLI）に置き換えられました。ELB CLI バージョン 1.0.35.0
（14/7/24 付）以降にリリースされた新機能は、AWS CLI のみに含まれています。AWS CLI を
使用することを強くお勧めします。AWS CLI の使用を開始するには、「AWS コマンドライン
インターフェイスの設定」を参照してください。
ELB CLI のインストール手順
• タスク 1: コマンドラインインターフェイスをダウンロードする (p. 185)
• タスク 2: JAVA_HOME 環境変数を設定する (p. 186)
• タスク 3: AWS_ELB_HOME 環境変数を設定する (p. 187)
• タスク 4: AWS_CREDENTIAL_FILE 環境変数を設定する (p. 188)
• タスク 5: リージョンを設定する (p. 189)
• タスク 6: インストールを検証する (p. 189)
タスク 1: コマンドラインインターフェイスをダウ
ンロードする
Elastic Load Balancing API ツールからコマンドラインインターフェイスツールをダウンロードし、ZIP
ファイルを解凍します。
185
タスク 2: JAVA_HOME 環境変数を設定する
タスク 2: JAVA_HOME 環境変数を設定する
Elastic Load Balancing コマンドラインツールは、コンピュータ上の環境変数（JAVA_HOME）を読み取
り、Java ランタイムを見つけます。このコマンドラインツールを実行するには、Java バージョン 5 以
降が必要です。JRE または JDK のどちらでもかまいません。
JAVA_HOME 環境変数を設定するには
1.
2.
Java 1.5 以降がインストールされていない場合は、今すぐダウンロードしてインストールしてくだ
さい。Linux と Windows を含め各種プラットフォーム用の JRE は、http://java.oracle.com/ で参照
およびダウンロードすることができます。
JAVA_HOME として、（Java 実行ファイルが格納された）bin という名のサブディレクトリを含む
ディレクトリのフルパスを指定します。たとえば、Java 実行ファイルが /usr/jdk/bin ディレク
トリにある場合は、JAVA_HOME を /usr/jdk と指定します。Java 実行ファイルが C:\jdk\bin
にある場合は、JAVA_HOME を C:\jdk と指定します。
Note
Cygwin を使用している場合は、AWS_ELB_HOME および AWS_CREDENTIAL_FILE に Linux
のパスを使用する必要があります（例: C:\usr\bin ではなく /usr/bin）。ただし、
JAVA_HOME には Windows のパスを指定します。また、値が引用符で囲まれている場合
や、スペースがエスケープ処理されている場合も、値にはスペースを入れないでくださ
い。
次に示す Linux の例は、Java 実行ファイルが JAVA_HOME ディレクトリにある場合の
/usr/local/jre/bin の設定方法です。
$ export JAVA_HOME=/usr/local/jre
以下の Windows の例では、set および setx を使用して、JAVA_HOME として
C:\java\jdk1.6.0_6\bin ディレクトリの Java 実行ファイルを指定しています。set コマンド
は現在のセッションに対して JAVA_HOME を定義し、setx コマンドは変更を永続的なものにしま
す。
C:\> set JAVA_HOME=C:\java\jdk1.6.0_6
C:\> setx JAVA_HOME C:\java\jdk1.6.0_6
Note
• setx コマンドでは、= 記号を使用しません。
• よくある間違いですが、JAVA_HOME に bin ディレクトリを含めないでください。bin を
含めるとコマンドラインツールが動作しません。
• JAVA_HOME の値が引用符で囲まれている場合や、スペースがエスケープ処理されてい
る場合も、値にはスペースを入れないでください。値にスペース文字が含まれる場合、
コマンドラインツールは次の手順で JAVA_HOME をパスに追加するときにエラーを返し
ます。
3.
この Java ディレクトリは、パスの他のバージョンの Java の前に追加してください。
Linux の場合、PATH は以下の方法で更新できます。
186
タスク 3: AWS_ELB_HOME 環境変数を設定する
$ export PATH=$JAVA_HOME/bin:$PATH
Windows の場合、構文はわずかに異なります。
C:\> set PATH=%JAVA_HOME%\bin;%PATH%
C:\> setx PATH %JAVA_HOME%\bin;%PATH%
4.
Linux では、$/bin/java -version コマンドを使って JAVA_HOME の設定をテストします。
$ $JAVA_HOME/bin/java -version
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
Windows では構文は異なりますが、出力は同様です。
C:\> %JAVA_HOME%\bin\java -version
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
タスク 3: AWS_ELB_HOME 環境変数を設定する
コマンドラインツールは、環境変数（AWS_ELB_HOME）を使用して、サポートするライブラリを見つけ
ます。ツールを使用するには、この環境変数を設定する必要があります。
AWS_ELB_HOME 環境変数を設定するには
1.
AWS_ELB_HOME として、コマンドラインツールを解凍したディレクトリのパスを指定します。こ
のディレクトリの名前は、ElasticLoadBalancing-w.x.y.z（w、x、y、z はバージョンまたは
リリース番号）のようになっており、bin および lib という名前のサブディレクトリが含まれて
います。
以下の Linux の例では、AWS_ELB_HOME を /usr/local ディレクトリの
ElasticLoadBalancing-1.0.12.0 という名前のディレクトリに指定しています。
$ export AWS_ELB_HOME=/usr/local/ElasticLoadBalancing-1.0.12.0
以下の Windows の例では、AWS_ELB_HOME として ElasticLoadBalancing-1.0.12.0 ディレ
クトリの C:\CLIs という名前のディレクトリを指定しています。
C:\> set AWS_ELB_HOME=C:\CLIs\ElasticLoadBalancing-1.0.12.0
C:\> setx AWS_ELB_HOME C:\CLIs\ElasticLoadBalancing-1.0.12.0
2.
ツールの bin ディレクトリをシステムの PATH に追加します。このガイドのこれ以降の部分は、
この作業が実行済みであることを前提としています。
Linux の場合、PATH は以下の方法で更新できます。
187
タスク 4: AWS_CREDENTIAL_FILE 環境変数を設定する
$ export PATH=$PATH:$AWS_ELB_HOME/bin
Windows の場合、構文はわずかに異なります。
C:\> set PATH=%PATH%;%AWS_ELB_HOME%\bin
C:\> setx PATH %PATH%;%AWS_ELB_HOME%\bin
タスク 4: AWS_CREDENTIAL_FILE 環境変数を設
定する
AWS にサインアップした後で、アカウントのアクセスキーを作成する必要があります。アクセスキー
はお客様の AccessKeyId と SecretAccessKey です。アカウントからコマンドが発行されているこ
とをコマンドラインツールに認識させるために、コマンドラインツールにこのアクセスキーを指定する
必要があります。コマンドラインツールは、ローカルシステムに作成された認証情報ファイルからアク
セスキーを読み取ります。
コマンドを発行するたびに --aws-credential-file パラメータを使ってアクセスキーを指定するこ
ともできますし、またはローカルシステムの認証情報を指す環境変数を設定しておくこともできます。
環境変数が正しく設定されていれば、コマンドを発行するたびに --aws-credential-file パラメー
タを指定する必要はありません。以下の手順では、証明書ファイルおよび対応する
AWS_CREDENTIAL_FILE 環境変数を作成する方法を説明しています。
ローカルシステムに認証情報ファイルを作成するには
1.
2.
3.
アクセスキーを取得します。
[Security Credentials] ページからはアクセスキー ID を取得することはできますが、シークレット
アクセスキーを取得することはできません。シークレットアクセスキーを紛失または忘れた場合、
新しいアクセスキーを作成する必要があります。詳細については、「How Do I Get Security
Credentials?」（『Amazon Web Services General Reference』）を参照してください。
シークレットアクセスキーおよびアクセスキー ID を書き留めるか、保管します。
アクセスキー ID と秘密アクセスキーを、credential-file-path.template という名前のファ
イルに追加します。
a.
credential-file-path.template ファイルを開きます。このファイルは、コマンドライ
ンインターフェイス（CLI）アーカイブの中にあります。
b.
c.
アクセスキー ID と秘密アクセスキーをコピーして、このファイルに貼り付けます。
ファイル名を変更して、コンピュータ上の使いやすい場所に保存します。
d.
Linux を使用している場合は、以下のようにファイルへのアクセス許可を設定します。
$ chmod 600 credential-file-name
4.
AWS_CREDENTIAL_FILE 環境変数として、作成したファイルの完全修飾パスを設定します。
以下の Linux の例では、AWS_CREDENTIAL_FILE を /usr/local ディレクトリの
myCredentialFile に指定しています。
188
タスク 5: リージョンを設定する
$ export AWS_CREDENTIAL_FILE=/usr/local/myCredentialFile
以下の Windows の例では、AWS_CREDENTIAL_FILE として myCredentialFile.txt ディレク
トリの C:\aws を指定しています。
C:\> set AWS_CREDENTIAL_FILE=C:\aws\myCredentialFile.txt
C:\> setx AWS_CREDENTIAL_FILE C:\aws\myCredentialFile.txt
タスク 5: リージョンを設定する
Elastic Load Balancing ツールは、デフォルトでは
elasticloadbalancing.us-east-1.amazonaws.com サービスエンドポイント URL で指定された
米国東部(バージニア北部リージョン)（us-east-1）を使用します。インスタンスが別のリージョンに
ある場合は、その場所を指定する必要があります。たとえばインスタンスが欧州（アイルランド）リー
ジョンにある場合は、--region eu-west-1 パラメータを使用するか AWS_ELB_URL 環境変数を設定
することで、eu-west1 リージョンを使用する必要があります。
このセクションでは、サービスエンドポイント URL を変更することで別のリージョンを指定する方法
を説明します。
別のリージョンを指定するには
1. 使用可能なリージョンは、『Amazon Web Services General Reference』の「リージョンとエンドポ
イント」を参照してください。
2. サービスエンドポイントを変更したい場合は、AWS_ELB_URL 環境変数を設定します。
• 次に示す Linux の例では、AWS_ELB_URL を欧州（アイルランド）リージョンに設定します。
$ export AWS_ELB_URL=https://elasticloadbalancing.eu-west-1.amazonaws.com
• 以下の Windows の例では、AWS_ELB_URL を欧州（アイルランド）リージョンに指定します。
C:\> set AWS_ELB_URL=https://elasticloadbalancing.eu-west-1.amazonaws.com
C:\> setx AWS_ELB_URL https://elasticloadbalancing.eu-west-1.amazonaws.com
タスク 6: インストールを検証する
Elastic Load Balancing CLI のインストールと設定を確認するには
1.
Linux または Windows のワークステーションで、コマンドプロンプトを新しく開きます。
2.
elb-cmd コマンドを入力します。
3.
次のような出力が表示されます。
189
Command Name
Description
-----------elb-apply-security-groups-to-lb
Balancer.
----------Apply VPC security groups to Load
elb-associate-route53-hosted-zone
Route53 resource record.
Associate LoadBalancer DNS... a
elb-attach-lb-to-subnets
Subnets in VPC.
Attach existing LoadBalancer to
elb-configure-healthcheck
with a LoadBalancer.
Configure the parameters f...tered
elb-create-app-cookie-stickiness-policy Create an application-generated
stickiness policy.
elb-create-lb
Create a new LoadBalancer.
elb-create-lb-cookie-stickiness-policy
policy.
Create an LB-generated stickiness
elb-create-lb-listeners
Create a new LoadBalancer listener.
elb-create-lb-policy
LoadBalancerPolicyType.
Create a LoadBalancer poli...ed
elb-delete-lb
Deletes an existing LoadBalancer.
elb-delete-lb-listeners
LoadBalancer.
Deletes a listener on an existing
elb-delete-lb-policy
Delete a LoadBalancer policy.
elb-deregister-instances-from-lb
Balancer.
Deregisters instances from a Load
elb-describe-instance-health
Describes the state of instances.
elb-describe-lb-policies
Policies.
Describes the details of LoadBalancer
elb-describe-lb-policy-types
PolicyTypes.
Describes the details of LoadBalancer
elb-describe-lbs
of LoadBalancers.
Describes the state and properties
elb-detach-lb-from-subnets
Subnets in VPC.
Detach existing LoadBalancer from
elb-disable-zones-for-lb
LoadBalancer.
Remove availability zones from an
elb-disassociate-route53-hosted-zone
Route53 resource record.
Disassociate LoadBalancer ... a
190
elb-enable-zones-for-lb
LoadBalancer.
elb-register-instances-with-lb
Add availability zones to existing
Registers instances to a LoadBalancer.
elb-set-lb-listener-ssl-cert
LoadBalancer port.
Set the SSL Certificate fo...ecified
elb-set-lb-policies-for-backend-server
servers.
Set LoadBalancer policies for backend
elb-set-lb-policies-of-listener
port.
Set LoadBalancer policies for a
version
and the API.
Prints the version of the CLI tool
For help on a specific command, type '<commandname> --help'
191
ドキュメント履歴
Abstract
Elastic Load Balancing 開発者ガイドの改定日、関連リリース、重要な変更を確認することができます。
次の表は Elastic Load Balancing 開発者ガイドの重要な変更点をまとめたものです。
最新のドキュメンテーションの更新: 2015 年 1 月 19 日
機能
WSDL および CLI のダウ説明
ンロード
リリース日
リンクされた EC2- 2014-08-11 WSDL
Classic インスタン
スの登録をサポー
トします。
リンクされた EC2-Classic インスタン
スをロードバランサーに登録するため
のサポートを追加しました。
2015 年 1 月
19 日
のタグ付けのサ
ポート。
タグのロードバランサーを編成し管理
するためのタグの使用についての情報
を追加しました。
2014 年 8 月
11 日
2014-08-11 WSDL
このリリース以降、Elastic Load Balancing CLI（ELB CLI）は、複数の AWS
サービスを管理するための統合ツール
である AWS コマンドラインインター
フェイス（AWS CLI）に置き換えられ
ました。ELB CLI バージョン 1.0.35.0
（14/7/24 付）以降にリリースされた新
機能は、AWS CLI のみに含まれていま
す。現在 ELB CLI を使用している場合
は、代わりに AWS コマンドラインイン
ターフェイス（AWS CLI）を使用する
ことをお勧めします。詳細については、
「AWS CLI を使用した Elastic Load
Balancing へのアクセス (p. 18)」を参
192
機能
ンロード
リリース日
のアイドル接続タ
イムアウトの設定
のサポート。
2014-07-24 WSDL
2014 年 7 月
24 日
アイドル接続のタイムアウトに関する
情報とロードバランサーのアイドルタ
イムアウトを設定する手順を追加しま
した。詳細については、「アイドル接
続のタイムアウト (p. 11)」を参照して
ください。
IAM ユーザーおよ 2014-03-20 WSDL
びグループに特定
のロードバラン
サーまたは API ア
クションに対する
アクセスを許可す
る機能のサポート
IAM ポリシーを使用して、IAM ユーザー 2014 年 5 月
およびグループに特定のロードバラン 12 日
サーまたは API アクションに対するア
クセスを許可する方法について情報を
追加しました。詳細については、「ロー
ドバランサーへのアクセスの制
御 (p. 167)」を参照してください。
AWS CloudTrail の 2014-03-20 WSDL
サポート
ELB API、ELB コンソール、ELB CLI、 2014 年 4 月
または AWS CLI を使用して AWS アカ 04 日
ウントまたはその代理が実行する API
呼び出しを、AWS CloudTrail を使用し
てキャプチャする方法について情報を
追加しました。詳細については、
「AWS CloudTrail を使用した Elastic
Load Balancing API 呼び出しのログ作
成 (p. 164)」を参照してください。
Connection Drainingのサポート
2014-03-20 WSDL
Connection drainingに関する情報を追
加しました。このサポートを使用する
と、登録されたインスタンスが登録解
除中または正常でなくなったときに、
既存の接続を開いたままにしながら、
ロードバランサーがインスタンスに新
しいリクエストを送信しないようにす
ることができます。詳細については、
「Connection Draining (p. 11)」を参照
アクセスログのサ
ポート
2014-03-06 WSDL
アクセスログについての情報を追加し 2014 年 3 月
ました。このサポートを使用して、ロー 6 日
ドバランサーによるアクセスログのキャ
プチャと Amazon S3 バケットへの保存
を有効にすることができます。詳細に
ついては、「Elastic Load Balancing ア
クセスログ (p. 150)」を参照してくださ
い。
193
2014 年 3 月
20 日
機能
ンロード
TLSv1.1-1.2 のサ
ポート
2013-11-06 WSDL
HTTPS/SSL リスナーを使用したロード 2014 年 2 月
バランサーの TLSv1.1-1.2 プロトコル 19 日
サポートに関する情報を追加しました。
このサポートでは、Elastic Load Balancing は、事前定義された SSL ネゴシ
エーション設定も更新します。更新さ
れる事前定義 SSL ネゴシエーション設
定に関する情報については、「Elastic
Load Balancing の SSL ネゴシエーショ
ン設定 (p. 30)」を参照してください。
現在の SSL ネゴシエーション設定を更
新する方法については、「ロードバラ
ンサーの SSL ネゴシエーション設定の
更新 (p. 98)」を参照してください。
クロスゾーン負荷
分散
2013-11-06 WSDL
ロードバランサーのクロスゾーン負荷 2013 年 11
分散の有効化に関する情報を追加しま月 6 日
した。クロスゾーン負荷分散の詳細に
ついては、リクエストルーティン
グ (p. 7) を参照してください。クロス
ゾーン負荷分散の有効化または無効化
の手順については、ロードバランサー
のクロスゾーン負荷分散の有効化また
は無効化 (p. 106) を参照してください。
追加の Amazon
CloudWatch のメ
トリックス
2012-06-01 WSDL
Elastic Load Balancing で報告される追 2013 年 10
加の Amazon CloudWatch のメトリッ月 28 日
クスに関する情報を追加しました。
Elastic Load Balancing で報告されるす
べてのメトリックスとメトリックスの
使用方法については、Amazon CloudWatch を使用したロードバランサーの
監視 (p. 139) を参照してください。
Proxy Protocol に
よるサポート
2012-06-01 WSDL
TCP/SSL 接続用に設定されたロードバ 2013 年 7 月
ランサーの Proxy Protocol によるサポー 30 日
トに関する情報を追加。詳細について
は、「Proxy Protocol (p. 13)」を参照し
てください。
DNS フェイルオー 2012-06-01 WSDL
バーのサポート
ロードバランサーに対する Route 53
2013 年 6 月
DNS フェイルオーバーの設定に関する 3 日
情報を追加。詳細については、「ロー
ドバランサーに対する DNS フェイル
オーバーの設定 (p. 123)」を参照してく
ださい。
HTTP メソッド
Elastic Load Balancing でサポートされ 2013 年 5 月
る HTTP メソッドに関する情報を追加。 20 日
詳細については、「HTTP メソッ
ド (p. 12)」を参照してください。
2012-06-01 WSDL
194
リリース日
機能
ンロード
コンソールで
Amazon CloudWatch メトリック
スの表示とアラー
ムの作成が可能に
2012-06-01 WSDL
リリース日
コンソールの [Monitoring] タブを使用し 2013 年 3 月
て、指定されたロードバランサーにつ 28 日
いて、Amazon CloudWatch メトリック
スを表示したりアラームを作成したり
するための情報を追加。詳細について
は、「Amazon CloudWatch を使用した
ロードバランサーの監視 (p. 139)」を参
デフォルト VPC で 2012-06-01 WSDL
のロードバランシ
ング
デフォルト VPC 内で起動された EC2
インスタンスに関するサポートを追加
しました。
Amazon VPC の内 2012-06-01 WSDL
部負荷分散
このリリースでは、Amazon Virtual
2012 年 6 月
Private Cloud（Amazon VPC）のロー 10 日
ドバランサーを内部またはインターネッ
ト向けに作成することができます。内
部のロードバランサーには、プライベー
ト IP アドレスに解決する、パブリック
に解決可能な DNS 名が含まれていま
す。インターネット向けのロードバラ
ンサーには、パブリック IP アドレスに
解決する、パブリックに解決可能な
DNS 名が含まれています。詳細につい
ては、「VPC での内部向けロードバラ
ンサーの作成 (p. 82)」を参照してくだ
さい。
リスナー、暗号設 2011-11-15 WSDL
定、SSL 証明書を
管理するためのコ
ンソールでのサ
ポート。
既存のロードバランサーのリスナー、 2012 年 5 月
証明書、暗号化設定を管理するための 18 日
コンソールサポートの情報を追加しま
した。リスナーおよび暗号化設定の管
理については、「ロードバランサーの
リスナーの設定 (p. 89)」を参照してく
ださい。証明書の管理に関する詳細は、
「ロードバランサーの SSL 証明書の更
新 (p. 41)を参照してください。
リスナー設定に関
する新コンテンツ
2011-11-15 WSDL
ユースケースに最も適したロードバラ 2012 年 4 月
ンサーのリスナー設定の選択に関する 3 日
セクションを追加しました。詳細につ
いては、「Elastic Load Balancing のリ
スナー設定 (p. 24)」を参照してくださ
い。
トラブルシュー
ティングに関する
新コンテンツ
2011-11-15 WSDL
Elastic Load Balancing のトラブル
2012 年 4 月
シューティングに関するセクションを 3 日
追加しました。Elastic Load Balancing
使用時に遭遇する可能性のある問題を
取り上げ、原因や問題解決のためのス
テップを説明します。詳細については、
「Elastic Load Balancing のトラブル
シューティング (p. 173)」を参照してく
ださい。
195
2013 年 3 月
11 日
機能
ンロード
リスナーの追加と
削除に関する新コ
ンテンツ
2011-11-15 WSDL
ロードバランサーへのリスナーの追加 2012 年 4 月
およびロードバランサーからのリスナー 3 日
の削除に関するドキュメントを追加し
ました。詳細については、「ロードバ
ランサーのリスナーの設定 (p. 89)」を
Amazon Virtual
Private Cloud
（Amazon VPC）
での Elastic Load
Balancing
2011-11-15 WSDL
API バージョンを 2011-11-1 5 に更新 2011 年 11
し、Amazon VPC での Elastic Load
月 21 日
Balancing の使用に関するドキュメント
を追加しました。詳細については、VPC
のロードバランサー (p. 76)を参照して
ください。
新しいコンテンツ
2011-11-15 WSDL
ロードバランサーからの EC2 インスタ 2011 年 11
ンスの登録解除に関するコンテンツを月 21 日
追加しました。詳細については、ロー
ドバランサーでの EC2 インスタンスの
登録解除と登録 (p. 95) を参照してくだ
さい。
新しいコンテンツ
2011-08-15 WSDL
Amazon CloudWatch を使用したロード 2011 年 10
バランサーの監視に関するドキュメン月 17 日
トを追加しました。詳細については、
「Amazon CloudWatch を使用したロー
ドバランサーの監視 (p. 139)」を参照し
てください。
新機能
2011-08-15 WSDL
API バージョンを 2011-08-15 に更新し 2011 年 8 月
ました。また、新しい設定可能な SSL 30 日
暗号、バックエンド SSL、バックエン
ドサーバー認証機能に関するドキュメ
ントを追加しました。詳細については、
HTTPS/SSL ロードバランサーの作
成 (p. 46)を参照してください。
Zone Apex ドメイ
ン名
2011-04-05 WSDL
API バージョンを 2011-04-05 に更新
2011 年 5 月
し、Zone Apex ドメイン名機能に関す 24 日
るドキュメントを追加しました。詳細
については、ロードバランサーのカス
タムドメイン名の設定 (p. 103)を参照し
てください。
アプリケーション
インスタンスの
ロックダウン
2011-04-05 WSDL
バックエンドアプリケーションインス 2011 年 5 月
タンスのロックダウンに使用する
24 日
Elastic Load Balancing セキュリティグ
ループに関するドキュメントを追加し
ました。詳細については、EC2-Classic
でのロードバランサーのセキュリティ
グループ (p. 68)を参照してください。
IPv6 のサポート
2011-04-05 WSDL
新しいインターネットプロトコルバー 2011 年 5 月
ジョン 6（IPv6）の機能に関するドキュ 24 日
メントを追加しました。詳細について
は、Elastic Load Balancing での IPv6
の使用 (p. 74)を参照してください。
196
リリース日
機能
ンロード
リリース日
X-Forwarded-Proto 2010-07-01 WSDL
ヘッダーと X-Forwarded-Port ヘッ
ダーのサポート。
X-Forwarded-Proto ヘッダーと X-Forwar- 2010 年 10
ded-Port ヘッダーに関する情報を追加月 27 日
しました。X-Forwarded-Proto ヘッダー
は発信元のリクエストのプロトコルを
示し、X-Forwarded-Port ヘッダーは発
信元のリクエストのポートを示します。
リクエストにこれらのヘッダーを追加
することによって、お客様はロードバ
ランサーへの着信リクエストが暗号化
されているかどうかや、ロードバラン
サーでリクエストを受信したポートを
特定できます。詳細については、「XForwarded ヘッダー (p. 14)」を参照し
てください。
HTTPS サポート
2010-07-01 WSDL
HTTPS サポートに関する情報を追加し 2010 年 10
ました。このリリースによって、
月 14 日
SSL/TLS プロトコルを利用してトラ
フィックを暗号化することや、SSL 処
理をアプリケーションインスタンスか
らロードバランサーにオフロードする
ことができます。また、この機能によっ
て、個々のアプリケーションインスタ
ンスで証明書を管理するのではなく、
ロードバランサーで SSL サーバー証明
書を集中管理できます。詳細について
は、「HTTPS Support (p. 13)」を参照
AWS Identity and
Access Management（IAM）のサ
ポート
2010-07-01 WSDL
AWS Identity and Access Management 2010 年 9 月
（IAM）のサポートに関する情報を追加 02 日
しました。詳細については、「ロード
バランサーへのアクセスの制
御 (p. 167)」を参照してください。
アジアパシフィッ
ク（シンガポー
ル）リージョンの
サポート。
2009-11-25 WSDL
アジアパシフィック（シンガポール） 2010 年 4 月
リージョンのサポートを追加しました。 28 日
スティッキーセッ
ション
2009-11-25 WSDL
セッション維持の作成に関する情報を
追加しました。詳細については、「ス
ティッキーセッションの有効化と無効
化 (p. 127)」を参照してください。
2010 年 4 月
07 日
AWS SDK for Java 2009-11-25 WSDL
Java SDK のサポートを追加しました。 2010 年 3 月
22 日
米国西部（北カリ
フォルニア）リー
ジョンのサポート
米国西部（北カリフォルニア）リージョ 2009 年 12
ンのサポートを追加しました。
月 02 日
2009-11-25 WSDL
AWS SDK for .NET 2009-05-15 WSDL
AWS SDK for .NET のサポートを追加
しました。
197
2009 年 11
月 11 日
機能
ンロード
リリース日
新しいサービス
2009-05-15 WSDL
2009 年 5 月
18 日
Elastic Load Balancing の最初のパブ
リックベータリリース。
198
AWS の用語集
Abstract
最新の AWS の主要な用語と用法を示しています。
最新の AWS の用語については、『AWS General Reference』の「AWS の用語集」を参照してくださ
い。
199

Elastic Load Balancing éçºèã¬ã¤ã

Transcription

Similar documents

RDS - Amazon Web Services

LOADMASTER 2500 廉価、高機能、高性能

ご紹介資料

OneLogin に独自のアプリケーションを登録する手順 Custom Connector Manual 編

CA API Management

gear list pdf

Login and Pay with Amazon Integration Guide

PIC32 注意 : この日本語版文書は参考資料としてご利用ください。最新情報は必ずオリジナルの英語版をご参照願います。

Elastic Load Balancing éçºè ã¬ã¤ã

Transcription

Similar documents

Elastic Load Balancing éçºèã¬ã¤ã