STAY KOBE

[SolutionArchitect Pro] AWS Elastic Load Balancing – ELB –

Atsushi Marumo

Jayendra’s Blog

この記事は自己学習用に「AWS Elastic Load Balancing – ELB – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。

AWS Elastic Load Balancer – ELB

ELB キーポイント

スケーリング ELB

暖気（Pre-warming）ELB

DNS の解決

ロードバランサーの種類

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

セキュリティグループと NACL

SSL ネゴシエーションの構成

ヘルスチェック

リスナー

アイドル接続タイムアウト

X-Forwarded Headers とプロキシプロトコルのサポート

クロスゾーン

接続ドレイン

スティッキー・セッション (セッションアフィニティ)

要件

持続時間ベースのセッションのスティッキー性

アプリケーション制御セッションのスティッキー

ロードバランサーの削除

ELB with Autoscaling

オートスケーリングとELBについてを参照してください。

AWS認定試験の練習問題

  1. ユーザーが ELB で HTTPS リスナを構成しました。ユーザーは、クライアントと ELB の間で SSL をネゴシエートするのに役立つセキュリティポリシーを構成していません。このシナリオでは、ELB は何を行いますか？
    1. デフォルトでは、ELB はセキュリティポリシーの最初のバージョンを選択します。
    2. デフォルトでは、ELB はポリシーの最新バージョンを選択します。
    3. ELB の作成はセキュリティポリシーなしで失敗します。
    4. SSL が既にインストールされているため、セキュリティポリシーを持っている必要はありません
  2. ユーザは、クライアントとロードバランサ間の安全なネゴシエーションのためのセキュリティポリシーを使用して、SSL を使用して ELB を設定しました。 ELB のセキュリティポリシーは、さまざまな暗号をサポートしています。 下記のどのオプションが、クライアントが SSL 経由で ELB DNS を要求しているときに、クライアント側で一致する暗号を ELB 暗号リストと識別するのに役立つか。
    1. 暗号プロトコル
    2. クライアント構成の設定
    3. サーバーの順序の優先順位
    4. ロードバランサーの優先順位
  3. ユーザーは、クライアントとロードバランサー間のセキュリティで保護されたネゴシエーションを行うために、SSL を使用して ELB を構成しています。ELB でサポートされているセキュリティポリシーを以下に示します。
    1. 動的セキュリティポリシー
    2. 他のすべてのオプション
    3. 定義済みのセキュリティポリシー
    4. 既定のセキュリティポリシー
  4. ユーザは、クライアントとロードバランサ間の安全なネゴシエーションのためのセキュリティポリシーを使用して、SSL を使用して ELB を設定しました。 次の SSL プロトコルのうち、セキュリティポリシーでサポートされていないものはどれですか？
    1. TLS 1.3
    2. TLS 1.2
    3. SSL 2.0
    4. SSL 3.0
  5. ユーザーは、バックエンドインスタンスと同様に ELB でリスナを使用して。ユーザーはヘッダー内の送信元と送信先の IP 情報を取得するためにプロキシプロトコルを有効にする必要があります。以下のステートメントのうちユーザーは TCP 構成でプロキシプロトコルを理解するのに役立ちますか？
    1. エンドユーザーがプロキシサーバーの背後で要求している場合、ユーザーは ELB でプロキシプロトコルを有効にしないでください。
    2. ELB ロードバランサーとバックエンドインスタンスの両方でリッスンしているときにプロキシプロトコルをサポートしていません。
    3. エンドユーザーがプロキシサーバーから直接要求しているかどうかにかかわらず、プロキシプロトコルの違いはありません。
    4. エンドユーザーがプロキシの背後に要求している場合、ユーザーは ELB 構成に「isproxy」フラグを追加する必要があります。
  6. ユーザーが ELB でセッションの粘りを有効にしました。ユーザーは、ELB にクッキーを管理させたくありません。代わりに、彼は、アプリケーションがクッキーを管理することを望んでいます。cookie にバインドされているサーバーインスタンスがクラッシュした場合はどうなりますか。
    1. 応答は、クッキーを持っていますが、スティッキーが削除されます
    2. 新しい cookie が挿入されるまで、セッションは固定されません。
    3. ELB は、クッキーの可用性のためにエラーをスローします。
    4. セッションはスティッキーになり、ELB は ELB がクッキーを複製し続けるので、リクエストを別のサーバにルーティングします。
  7. ユーザが自動スケーリング付きの ELB を作成しました。 下記の ELB のオファリングは、実行中のリクエストを継続しながらインスタンスの登録抹消中にロードバランサから EC2 インスタンスへの新しいリクエストトラフィックの送信を停止するのに役立ちますか？
    1. ELB スティッキーセッション
    2. ELB 登録チェック
    3. ELB 接続ドレイン
    4. ELB 自動登録オフ
  8. ELB を使用して Web サーバーへのトラフィックを提供する場合、次のいずれかが当てはまりますか？
    1. Web サーバーはパブリックにアクセスできる必要があります。
    2. ELB と EC2 インスタンスの両方に同じセキュリティグループを適用する必要があります。
    3. ELB と EC2 インスタンスは同じサブネット内にある必要があります。
    4. ELB と EC2 インスタンスは同じ VPC 内にある必要があります。
  9. セキュリティポリシーと呼ばれるセキュアソケットレイヤ (SSL) ネゴシエーション構成を有効にすることにより、ユーザーは ELB を構成しました。以下のうち、ユーザーとクライアントの間の SSL 接続をネゴシエートする際に、このセキュリティポリシーの一部ではないオプションはどれですか？
    1. SSL プロトコル
    2. クライアントの注文の優先順位
    3. SSL 暗号
    4. サーバーの順序の優先順位
  10. ユーザーがアベイラビリティーゾーンの ELB を作成しました。ユーザーは、高可用性を実現するために、ELB にゾーンを追加したいと考えています。どのようにユーザーが既存の ELB により多くのゾーンを追加できますか?
    1. 既存の ELB にゾーンを追加することはできません。
    2. 唯一のオプションは、別のゾーンでインスタンスを起動し、ELB に追加することです。
    3. ユーザーは ELB を停止し、必要に応じてゾーンとインスタンスを追加する必要があります。
    4. ユーザーは AWS コンソールからその場でゾーンを追加できます。
  11. ユーザーは、5つのインスタンスが登録された ELB を起動しました。ユーザーは誤って ELB を削除します。インスタンスはどうなるのでしょうか?
    1. ELB は、インスタンスを削除するかどうかをユーザーにたずねます。
    2. インスタンスは終了されます。
    3. ELB が登録されているインスタンスを実行している場合は削除できません。
    4. インスタンスが実行され続ける。
  12. システム管理者は、ショッピングカートアプリケーションを作成し、EC2 上でホストしています。EC2 インスタンスは ELB の背後で実行されています。管理者は、エンドユーザーの要求が、ユーザーセッションが作成された EC2 インスタンスに常に移動するようにしたいと考えています。どのように管理者はこれを構成できますか?
    1. ELB クロスゾーン負荷分散を有効にする。
    2. ELB クッキーの設定を有効にする。
    3. ELB スティッキーセッションを有効にする。
    4. ELB 接続のドレインを有効にする。
  13. ユーザーは、自動スケーリングを使用してインスタンスが登録解除されている間に、飛行中のリクエストを続行できるように、ELB を使用して接続をドレインします。 ユーザーがドレイン時間を指定していない場合、ELB は機内リクエスト要求のトラフィックをどのくらいの期間にわたって継続できますか？
    1. 600秒
    2. 3600秒
    3. 300秒
    4. 0秒
  14. 顧客には、cookie ベースのセッションを使用してログインしたユーザーを追跡する Web アプリケーションがあります。ELB と Auto スケーリングを使用して AWS にデプロイされます。お客様は、負荷が増加すると自動スケーリングによって新しいインスタンスが起動されますが、既存のインスタンスの負荷は減少せず、既存のすべてのユーザーの操作性が低下します。 どの2つの選択肢が、ユーザーエクスペリエンスの低迷の原因となる可能性のある動作を個別に記述していますか？
    1. ELB の通常の動作では、同じユーザーから同じバックエンドインスタンスに要求が送信されます (既定ではありません)。
    2. スティッキー・セッションが有効になっている場合の ELB の動作により、ELB は同じセッションで同じバックエンドに要求を送信します。
    3. 障害のあるブラウザは、ELB DNS 名の TTL を尊重していません (DNS TTL は、トラフィックがルーティングされる EC2 インスタンスではなく、スケーリングした場合にのみ ELB インスタンスに影響します)
    4. Web アプリケーションは、comet やウェブソケットなどの長いポーリングを使用します。これにより、Web サーバへの接続を長時間開いたままにすることができます。
  15. 顧客には、cookie ベースのセッションを使用してログインした顧客を追跡するオンラインストアがあります。ELB とオートスケーリングを使用して AWS にデプロイされます。負荷が増加すると、自動スケーリングによって新しい Web サーバーが自動的に起動されますが、Web サーバーの負荷は減少しません。これにより、顧客エクスペリエンスが乏しくなります。何が問題を引き起こしている可能性がありますか?
    1. ELB DNS レコードの生存時間が大きすぎます (DNS TTL は、トラフィックがルーティングされる EC2 インスタンスではなく、スケーリングされた場合にのみ ELB インスタンスに影響を及ぼします)
    2. ELB は、以前に確立したセッションで要求を送信するように構成されます。
    3. ウェブサイトは、セッションを生きて維持している cloudfront を使用して
    4. 自動スケーリングのクールダウン期間中に新しいインスタンスが ELB に追加されない
  16. AWS 用のマルチプラットフォーム Web アプリケーションを設計しています。アプリケーションは EC2 インスタンス上で実行され、PC、タブレット、スマートフォンからアクセスされます。サポートされているプラットフォームへのアクセスは、windows、MacOS、iOS、アンドロイドです。異なるプラットフォームタイプには、個別のスティッキー・セッションと SSL 証明書のセットアップが必要です。次のうち最もコスト効率が高く、パフォーマンスが高いアーキテクチャのセットアップについて説明してください。
    1. オンプレミスのセッション状態と SSL 証明書を処理するためのハイブリッドアーキテクチャをセットアップし、VPC で実行されているさまざまなプラットフォームの種類に対して Web アプリケーションを実行する個別の EC2 インスタンスグループを設定します。
    2. すべてのプラットフォームに対して1つの ELB を設定し、その下に複数のインスタンス間で負荷を分散します。各 EC2 インスタンスは、特定のプラットフォームのすべての機能を実装します。
    3. 2つの ELB を設定します。最初の ELB はすべてのプラットフォームの SSL 証明書を処理し、2番目の ELB は各プラットフォームの Web アプリケーションを処理するために、それぞれの ELB を実行する個別の EC2 インスタンスグループのすべてのプラットフォームのセッションのスティッキーを処理します。)
    4. Web アプリケーションの共通コンポーネントを実行している EC2 インスタンスまたは EC2 インスタンスのグループに複数のエルを割り当て、各プラットフォームタイプごとに1つの ELB を指定します。セッションのスティッキーと SSL の終了は、エルで行われます。(セッションのスティッキーは、ELB 上で SSL ターミネーションを持つ HTTPS リスナを必要とし、ELB は複数の SSL 証明をサポートしていないため、各 cert に1つが必要です)
  17. レガシクライアントサーバーアプリケーションを AWS に移行しています。アプリケーションは、特定の DNS ドメイン (例: www.example.com) に応答し、2層アーキテクチャを持ち、複数のアプリケーションサーバーとデータベースサーバーを備えています。リモートクライアントは TCP を使用してアプリケーションサーバーに接続します。アプリケーションサーバーは、適切に機能するためにクライアントの IP アドレスを知り、現在 TCP ソケットからその情報を取得している必要があります。マルチ AZ RDS MySQL インスタンスがデータベースに使用されます。移行中にアプリケーションコードを変更できますが、変更要求をファイルする必要があります。スケーラビリティと高可用性を最大限に引き出すために、AWS のアーキテクチャをどのように実装しますか?
    1. アプリケーションでプロキシプロトコルサポートを実装するための変更要求をファイルします。TCP リスナとプロキシプロトコルが有効になっている ELB を使用して、異なる AZ の2つのアプリケーションサーバーに負荷を分散します。(TCP リスナとプロキシプロトコルを使用した ELB は IP を通過できるようになります)
    2. アプリケーションでクロスゾーンサポートを実装するための変更要求をファイルします。TCP リスナとクロスゾーン負荷分散を有効にした ELB を使用して、異なる AZ の2つのアプリケーションサーバーを利用します。
    3. アプリケーションで遅延ベースのルーティングサポートを実装するための変更要求をファイルします。異なる AZ の2つのアプリケーションサーバーに負荷を分散するために、遅延ベースのルーティングを有効にした Route53 を使用します。
    4. アプリケーションで Alias リソースサポートを実装するための変更要求をファイルする Route53 Alias リソースレコードを使用して、異なる AZ の2つのアプリケーションサーバーに負荷を分散します。
  18. ユーザーは3つのインスタンスを持つ ELB を作成しました。 ELB はデフォルトでいくつのセキュリティグループを作成しますか？
    1. 3
    2. 5
    3. 2 (1つは ELB がインスタンスのリスナとヘルスチェックポートへのインバウンドとアウトバウンドを許可し、もう1つはインスタンスがELBからのインバウンドを許可するためです)
    4. 1
  19. ステートレスですが、VPC 内の cc2 8xlarge EC2 インスタンス上で実行されるステートレスな CPU /メモリ集約型 Web 層を持つ Web スタイルのアプリケーションがあります。負荷がかかっているインスタンスが、ビジネスで定義された SLA 内の要求を返すときに問題が発生します。 その状態は DynamoDB テーブルにありますが、データ層は適切にプロビジョニングされており、応答は一貫して高速です。 SLAを 満たしていないアプリケーションの応答の問題を、どのようにして解決するのがベストでしょうか？
    1. 別の CC2.8xlarge アプリケーションインスタンスを追加し、両方を ELB の背後に配置する。
    2. CC2.8xlarge を DynamoDB テーブルと同じアベイラビリティーゾーンに移動します (応答時間とパフォーマンスは向上しません)。
    3. より迅速なアクセスのために elasticache でデータベース応答をキャッシュする (データ層が高速に応答している)。
    4. スケールアウト読み取り/レプリカ構成で DynamoDB から RDS MySQL にデータベースを移動する (データ層が高速に応答している)。
  20. 組織は、インターネットゲートウェイ (IGW) を持つ VPC を構成しています。パブリックおよびプライベートサブネットのペア (各 AZ ごとに1つのサブネットを持つ) と、パブリックサブネットを使用するように構成されたエラスティックロードバランサー (ELB)。アプリケーション Web 層は、ELB、自動スケーリング、およびマルチ AZ RDS データベースインスタンスを活用します。組織は、この設計で障害の潜在的な単一のポイントを排除したいと思います。この組織の目標を達成するために、どのようなステップを踏むべきでしょうか？
    1. 何も、このアーキテクチャでは単一の障害点はありません。
    2. 2番目の IGW を作成して接続し、冗長なインターネット接続を提供します。(VPC は 1 IGW のみ接続可能)
    3. 冗長ロードバランサーを提供するために、2つ目の ELB を作成して構成します。(ELB はそれで構成される複数の AZ とそれ自身によってスケールする)
    4. 別の AZ 2つ目のマルチ AZ RDS インスタンスを作成し、冗長データベースを提供するようにレプリケーションを構成します。(マルチ AZ は、セットアップのための2つの異なる AZ を必要とし、すでにスタンバイを持っている)
  21. アプリケーションは現在、AWS Auto スケーリングを活用して、負荷が増減するにつれて拡大/縮小し、パフォーマンスも向上しています。あなたのマーケティングチームは、トラフィックの着実なランプアップ4週間以上のトラフィックの20倍の成長につながる今後のキャンペーンに従うことを期待しています。ピークの需要を満たすために必要な Amazon EC2 インスタンスのおおよその数の予測は、175です。あなたは、トラフィックのランプアップ中に潜在的なサービスの中断を回避するために何をすべきか?
    1. 各サーバーが起動中に1つを取得できるように、事前に割り当てられた 175 Elastic IP アドレスがあることを確認します (max limit 5 eip およびサービスリクエストの送信が必要)。
    2. Trusted Advisor のサービス制限を確認し、必要に応じて調整して、予測数が制限内に収まるようにします。
    3. Auto スケーリングの設定を変更して、マーケティングキャンペーンを開始する前に175の容量を設定します (175 インスタンスの起動と実行が発生しますが、徐々にスケーリングされることはありません)
    4. ピーク要求時に予想される1秒あたりの要求に合わせて、エラスティックロードバランサーを事前にウォームアップ。
  22. ロードバランサーに登録されている複数のアベイラビリティーゾーンの Amazon EC2 インスタンスへのトラフィックの分散も、次のどの機能によって保証されますか？
    1. ELB リクエストルーティング
    2. Amazon Route53 加重ルーティングポリシー (EC2 インスタンスへのトラフィックを制御しません)
    3. ELB クロスゾーン負荷分散
    4. Amazon Route53 レイテンシルーティングポリシー (ec2 インスタンスへのトラフィックを制御しません)
  23. Web アプリケーションのフロントエンドは、エラスティックロードバランサーの背後にある複数の EC2 インスタンスで構成されます。インスタンスが正常性チェックに合格しなかった場合、これらの EC2 インスタンスでヘルスチェックを実行するように ELB を構成した場合、どのステートメントが True になりますか。
    1. インスタンスは ELB によって自動的に終了します (自動スケーリングによって行われます)。
    2. インスタンスは、根本原因分析のために ELB によって検疫されます。
    3. インスタンスは、ELB によって自動的に置き換えられます。(自動スケーリングによって行われます)
    4. ELB は、ヘルスチェックに失敗したインスタンスへのトラフィックの送信を停止します。
  24. Web アプリケーションは、6つの Amazon EC2 インスタンスで実行され、各インスタンスのリソースの約 45% を消費します。自動スケーリングを使用して、6つのインスタンスが常時実行されていることを確認します。このアプリケーションプロセスの要求の数は一貫しており、スパイクは発生しません。アプリケーションはビジネスにとって非常に重要であり、常に高可用性が求められます。すべてのインスタンス間で負荷を均等に分散する必要があります。また、すべてのインスタンスに同じ Amazon マシンイメージ (AMI) を使用することもできます。次のどちらのアーキテクチャを選択する必要がありますか？
    1. 1つのアベイラビリティーゾーンに6個の EC2 インスタンスをデプロイし、Amazon ELB を使用します。(シングル az は高可用性を提供しません)
    2. あるリージョンに3つの EC2 インスタンスをデプロイし、別のリージョンに3つ、Amazon ELB を使用します。(異なるリージョン AMI はコピーされない限り利用できません)
    3. 1つのアベイラビリティーゾーンに3個の EC2 インスタンスをデプロイし、別のアベイラビリティーゾーンに3つを配置し、Amazon エラスティックロードバランサーを使用します。
    4. 3つのリージョンに2つの EC2 インスタンスをデプロイし、Amazon エラスティックロードバランサーを使用します。(異なるリージョン、AMI はコピーされない限り利用できません)
  25. クライアント証明書認証を使用して Web サーバーで HTTPS クライアントを認証する必要がある SSL/TLS ソリューションを設計しています。ソリューションは、弾力性のある必要があります。Web サーバーインフラストラクチャの構成について、次のどちらのオプションを検討しますか。(2 つの回答を選択)
    1. TCP/443 で TCP リスナを使用して ELB を構成します。Web サーバーをその背後に配置します。(クライアント側の証明書を使用してインスタンスの SSL を終了する)
    2. EIP を使用して Web サーバーを構成します。Web サーバーを Route53 レコードセットに配置し、すべての Web サーバーに対してヘルスチェックを構成します。(ELB を削除し、Route53で直接 Web サーバを使用)
    3. HTTPS リスナを使用して ELB を構成し、Web サーバーをその背後に配置します。(HTTPS を使用した ELB はクライアント側の証明書をサポートしていません)**
    4. Web サーバーを CloudFront ディストリビューションのオリジンとして設定します。CloudFront ディストリビューションでカスタム SSL 証明書を使用する (CloudFront はクライアント側の SSL 証明書を提供しません)
  26. 保護された正常性情報を含むアプリケーションを設計しています。アプリケーションのすべての保護された正常性情報が、残りの部分および転送中に暗号化を使用することを申請のためのセキュリティおよびコンプライアンス要件。アプリケーションは、データがロードバランサーを通過する3層アーキテクチャを使用し、処理のために Amazon EBS ボリュームに格納され、結果は AWS SDK を使用して Amazon S3 に格納されます。セキュリティ要件を満たす次の2つのオプションを選択してください。2つの回答を選択。
    1. ロードバランサー、Amazon EC2 インスタンスでの Amazon EBS 暗号化、およびサーバー側の暗号化による Amazon S3 の SSL ターミネーションを使用します。(ELB と EC2 の間の接続は暗号化されません)
    2. ロードバランサーの SAN SSL 証明書、Amazon EBS のすべての Amazon EBS ボリュームを使用した Amazon EC2、および Amazon S3 を使用して、お客様が管理するキーでサーバー側の暗号化を行うことができます。
    3. ロードバランサーでの TCP 負荷分散、Amazon EC2 インスタンスでの SSL ターミネーション、Amaozn EBS ボリューム上の OS レベルのディスク暗号化、およびサーバー側の暗号化による Amazon S3 の使用。
    4. ロードバランサーでの TCP 負荷分散、Amazon EC2 インスタンスでの SSL の終了、およびサーバー側の暗号化による Amazon S3 の使用。(EBS 暗号化については言及しません)
    5. ロードバランサー、Amazon EC2 インスタンス上の SSL リスナ、PHI を含む EBS ボリューム上の Amazon EBS 暗号化、およびサーバー側の暗号化による Amazon S3 の SSL ターミネーションを使用します。
  27. スタートアップは、その写真共有サイトを VPC 内に展開します。ELB は、2つのサブネット間で Web トラフィックを分散します。ロードバランサーセッションのスティッキーは、AWS で生成されたセッション cookie を使用するように構成されており、セッション TTL は5分です。Web サーバーの自動スケーリンググループは、最小サイズ = 4、最大サイズ = 4 として構成されています。スタートアップは、us-west-2a で実行されている単一の Amazon エラスティックコンピューティングクラウド (EC2) インスタンスにインストールされているロードテストソフトウェアを実行することによって、パブリック起動の準備をしています。負荷テストの60分後、Web サーバーのログは次のように表示されます。ウェブサーバログ |ロードテスターからの HTTP リクエスト数 |プライベートベータユーザーからの HTTP リクエストの # | |ウェブサーバ # 1 (subnet in us-west-2a): |19210 |434 | |ウェブサーバ # 2 (subnet in us-west-2a): |21790 |490 | |ウェブサーバ # 3 (subnet in us-west-2b): |0 |410 | |ウェブサーバ # 4 (subnet in us-west-2b): |0 |428 |負荷テストの HTTP 要求が4つの web サーバーに均等に分散されるようにするための推奨事項はどれですか。2つの回答を選択
    1. 代わりに、ロードテスター Amazon EC2 インスタンスを起動して実行します。
    2. アプリケーション固有のセッション cookie を使用するように、ELB セッションのスティッキーを構成します。
    3. 各 Web 要求の DNS を再解決するために、ロードテストソフトウェアを再構成します。(リンク参照)
    4. ELB と Auto スケーリングを構成して、us-west-2a と us-west-2b をまたがって配布します。
    5. サードパーティのロードテストサービスを使用して、グローバルに分散されたテストクライアントを提供します。(リンク参照)
  28. 人気のある製品のための Web トラフィックを提供するあなたの最高財務責任者と IT ディレクターは、10 m1 を購入している。大規模なヘビー使用リザーブドインスタンス (RIS) は、2つのアベイラビリティーゾーンに均等に分散されます。Route53 は、トラフィックをエラスティックロードバランサー (ELB)数ヶ月後、製品はさらに普及して成長し、結果として、追加の容量を必要とする、あなたの会社は2つの c3.2xlarge 媒体の使用率の RIS を購入あなたの ELB と2つの c3.2xlarge インスタンスを登録し、すぐに ml の大規模なインスタンスがでていることを見つける容量の 100% と c3.2xlarge インスタンスは、最もコスト効率がよく、EC2 容量を最も効果的に使用するオプションが未使用の重要な容量を持っていますか?
    1. 各インスタンスタイプに別々の ELB を使用し、Route53 加重ラウンドロビンを使用して ELB に負荷を分散する
    2. オートスケーリンググループを構成し、ELB を使用して構成を起動し、Cloudwatch によってトリガされた場合に最大10個のオンデマンド mi の大規模なインスタンスを追加します。 c3.2xlarge インスタンスをシャットオフします (RI に支払う費用を増額します)
    3. EC2 m1 へのトラフィックをルーティングします。Route53 レイテンシベースのルーティングとヘルスチェックを使用して、大規模および c3.2xlarge インスタンスを直接 ELB (まだ容量を有効に使用しません)
    4. 2つの c3.2xlarge インスタンスで ELB を構成し、最大2つの追加の c3.2xlarge インスタンスに対してオンデマンドの Autoscailng グループを使用します。大規模なインスタンス (あなたはまだ 10 m1 のために支払うように、コストが増加します。)
  29. EC2 インスタンスで受信したヘッダーは、ELB を要求している間にクライアントが使用したポートを識別しますか？
    1. X-Forwarded-Prot
    2. X-Requested-Proto
    3. X-Forwarded-Port
    4. X-Requested-Port
  30. ユーザーは、同じリージョンの別々の AZ で実行されている2つのインスタンスで ELB を構成しましたか？次のうちどれに該当するのか？
    1. マルチ AZ インスタンスは HA に ELB を提供します (ELB は、トラフィックを正常なインスタンスにルーティングする HA を提供し、スケーラビリティを提供しません)
    2. マルチ AZ インスタンスは、単一の ELB では使用できません。
    3. マルチ AZ インスタンスは、ELB でスケーラビリティを提供します。
    4. ユーザーは ELB を使用して HA とスケーラビリティの両方を実現できます。
  31. ユーザーは、フロントエンド ELB の HTTPS プロトコルと、ELB のバックエンドリスナの SSL プロトコルを構成しています。ELB は何をしますか?
    1. これにより、構成を作成できますが、インスタンスは正常性チェックに合格しません。
    2. HTTPS で要求を受信し、SSL のバックエンドインスタンスに送信します。
    3. これは、この構成を作成することはできません (エラー “ロードバランサープロトコルは、アプリケーション層プロトコルですが、インスタンスプロトコルではありません。ロードバランサープロトコルとインスタンスプロトコルの両方が同じレイヤーにある必要があります。修正してください。
    4. これは、構成を作成することができますが、ELB は期待どおりに動作しません
  32. ELB は、5つのインスタンス間でトラフィックを迂回しています。インスタンスの1つは20分間だけ不健康だった。インスタンスが正常になる20分後に何が起こるか。
    1. ELB は、同じインスタンスにトラフィックを迂回することはありません。
    2. ELB は、同じインスタンスに自動的にトラフィックを送信しません。ただし、ユーザーは同じインスタンスへのトラフィックの送信を開始するように構成できます。
    3. ELB が正常なインスタンスにトラフィックの送信を開始する。
    4. ELB は、インスタンスが異常な場合に終了します。したがって、10分後にインスタンスを正常にすることはできません。
  33. ユーザーは AWS 上で Web サイトをホストし、ELB を使用して複数のインスタンスの負荷分散を行います。ユーザーアプリケーションには、cookie の管理はありません。ユーザーはどのようにして、リクエスタのセッションを特定のインスタンスにバインドできますか。
    1. IP アドレスをスティッキーの cookie にバインドする。
    2. ELB で設定するアプリケーションレベルで cookie を作成します。
    3. ELB とのセッション同期を使用する。
    4. 指定した期間の cookie を生成する ELB。
  34. ユーザーが Web サイトを構成し、ポート80の Apache web サーバーを使用して起動しました。ユーザーは、負荷分散のために EC2 インスタンスと ELB を使用しています。EC2 インスタンスが ELB からの要求のみを受け付けるようにするには、ユーザーは何をすべきでしょうか。
    1. EC2 セキュリティグループの ELB 静的 IP のポートを開きます。
    2. ELB ソースセキュリティグループへのアクセスを許可する EC2 のセキュリティグループを構成する。
    3. ELB ポートでのみリッスンするように EC2 インスタンスを構成します。
    4. ELB リスナへのアクセスのみを許可する EC2 のセキュリティグループを構成する。
  35. AWS エラスティックロードバランサーは、SSL ターミネーションをサポートします。
    1. 特定のアベイラビリティーゾーンのみ
    2. false
    3. 特定の AZ のみ
    4. すべての地域
  36. ユーザーは ELB で5つのインスタンスを起動しました。ユーザーは、6番目の EC2 インスタンスを ELB に追加する方法を教えてください。
    1. ユーザーは、その場で6番目のインスタンスを追加できます。
    2. ユーザーは ELB を停止し、6番目のインスタンスを追加する必要があります。
    3. ユーザーはインスタンスを追加し、ELB 設定ファイルを変更できます。
    4. ELB には、最大5つのインスタンスのみを持つことができます。

リファレンス

Elastic Load Balancer ドキュメント
ELB Best Practices
AWS Black Belt Online Seminar 2016 Elastic Load Balancing SlideShare / オンデマンドセミナー