Elastic Load Balancing - Application Load Balancer

Transcription

1 Elastic Load Balancing Application Load Balancer

2 Elastic Load Balancing: Application Load Balancer Copyright 2018 Amazon Web Services, Inc. and/or its affiliates. All rights reserved. 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.

3 Table of Contents Application Load Balancer とは... 1 Application Load Balancer コンポーネント... 1 Application Load Balancer の概要... 1 Classic Load Balancer からの移行のメリット... 2 開始方法... 2 料金... 3 開始方法... 2 開始する前に... 4 ステップ 1: ロードバランサーの種類の選択... 4 ステップ 2: ロードバランサーとリスナーの設定... 5 ステップ 3: ロードバランサーのセキュリティグループの設定... 5 ステップ 4: ターゲットグループの設定... 5 ステップ 5: ターゲットグループへのターゲットの登録... 6 ステップ 6: Load Balancer の作成とテスト... 6 ステップ 7: ロードバランサーの削除 ( オプション )... 6 チュートリアル... 8 チュートリアル : パスベースのルーティングを使用する... 8 開始する前に... 8 Load Balancer の作成... 8 チュートリアル : ターゲットとして Microservices を使用する 開始する前に Load Balancer の作成 チュートリアル : AWS CLI を使用した Application Load Balancer の作成 開始する前に Load Balancer の作成 HTTPS リスナーの追加 ポートの上書きを使用したターゲットの追加 パスベースのルーティングの追加 ロードバランサーの削除 ロードバランサー ロードバランサーのセキュリティグループ ロードバランサーの状態 ロードバランサーの属性 IP アドレスタイプ 削除保護 接続のアイドルタイムアウト Application Load Balancer および AWS WAF ロードバランサーの作成 ステップ 1: ロードバランサーとリスナーを設定する... 5 ステップ 2: HTTPS リスナーのセキュリティ設定を指定する ステップ 3: セキュリティグループを設定する ステップ 4: ターゲットグループを設定する... 5 ステップ 5: ターゲットグループのターゲットを設定する ステップ 6: ロードバランサーを作成する アベイラビリティーゾーンの更新 セキュリティグループの更新 推奨ルール 関連付けられたセキュリティグループの更新 アドレスタイプの更新 タグの更新 ロードバランサーの削除 リスナー リスナーの設定 リスナールール iii

4 デフォルトのルール ルールの優先順位 ルールのアクション ルールの条件 リダイレクトアクション 固定レスポンスアクション ホストの条件 パスの条件 リスナーの作成 前提条件 リスナーの追加 HTTPS リスナーの設定 SSL 証明書 セキュリティポリシー セキュリティポリシーの更新 リスナールールの更新 前提条件 ルールの追加 ルールの編集 ルールの順序変更 ルールの削除 サーバー証明書の更新 証明書の追加 デフォルトの証明書の置き換え 証明書の削除 ユーザーの認証 OIDC 準拠 IdP を使用する準備を整える Amazon Cognito を使用する準備を整える Amazon CloudFront を使用する準備を整える ユーザー認証を設定する 認証のフロー ユーザークレームのエンコードと署名の検証 認証のログアウトとセッションのタイムアウト リスナーの削除 ターゲットグループ ルーティング設定 ターゲットの種類 登録済みターゲット ターゲットグループの属性 登録解除の遅延 スロースタートモード スティッキーセッション ターゲットグループの作成 ヘルスチェックを設定する ヘルスチェックの設定 ターゲットヘルスステータス ヘルスチェックの理由コード ターゲットのヘルスステータスをチェックする ターゲットグループのヘルスチェック設定を変更する ターゲットの登録 ターゲットセキュリティグループ ターゲットの登録または登録解除 タグの更新 ターゲットグループの削除 ロードバランサーの監視 CloudWatch のメトリクス Application Load Balancer メトリクス iv

5 Application Load Balancer のメトリクスディメンション Application Load Balancer メトリクスの統計 ロードバランサーの CloudWatch メトリクスを表示する アクセスログ アクセスログファイル アクセスログのエントリ バケットのアクセス許可 アクセスログの作成の有効化 アクセスログの作成の無効化 アクセスログファイルの処理 リクエストのトレース 構文 制約事項 CloudTrail ログ CloudTrail 内の Elastic Load Balancing 情報 Elastic Load Balancing ログファイルエントリの概要 ロードバランサーのトラブルシューティングを行う 登録されたターゲットが実行中でない クライアントがインターネット向けロードバランサーに接続できない ロードバランサーが異常なターゲットにリクエストを送信する ロードバランサーが HTTP エラーを生成する HTTP 400: Bad Request HTTP 401: Unauthorized HTTP 403: Forbidden HTTP HTTP HTTP 500: 内部サーバーエラー HTTP 502: Bad Gateway HTTP 503: Service Unavailable HTTP 504: Gateway Timeout HTTP 561: Unauthorized ターゲットが HTTP エラーを生成する 制限 ドキュメント履歴 v

6 Application Load Balancer コンポーネント Application Load Balancer とは Elastic Load Balancing は Application Load Balancer Network Load Balancer およびクラシックロードバランサーの 3 種類のロードバランサーをサポートしています このガイドでは Application Load Balancer について説明します Network Load Balancer の詳細については Network Load Balancer 用ユーザーガイドを参照してください クラシックロードバランサーの詳細については クラシックロードバランサー用ユーザーガイドを参照してください Application Load Balancer コンポーネント ロードバランサーは クライアントにとって単一の通信先として機能します このロードバランサーは 受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンスなど ) に分散します これにより アプリケーションの可用性が向上します ロードバランサーに 1 つ以上のリスナーを追加できます リスナーは ユーザーが設定したプロトコルとポートを使用してクライアントからの接続リクエストを確認し ユーザーが定義したルールに基づいて 1 つ以上のターゲットグループにリクエストを転送します 各ルールは ターゲットグループ 条件 優先順位を指定します 条件が満たされると トラフィックがターゲットグループに転送されます リスナーごとにデフォルトのルールを定義する必要があり リクエストの内容に基づいて異なるターゲットグループを指定するルールを追加できます ( 内容に基づくルーティングとも呼ばれます ) 各ターゲットグループは 指定されたプロトコルとポート番号を使用して 1 つ以上の登録済みのターゲット (EC2 インスタンスなど ) にリクエストをルーティングできます 1 つのターゲットを複数のターゲットグループに登録できます ターゲットグループ単位でヘルスチェックを設定できます ヘルスチェックは ロードバランサーのリスナールールに指定されたターゲットグループに登録されたすべてのターゲットで実行されます 次の図に 基本コンポーネントを示します 各リスナーにデフォルトのルールがあり 1 つのリスナーにリクエストを別のターゲットグループにルーティングする別のルールが含まれていることに注意してください 1 つのターゲットが 2 つのターゲットグループに登録されています 詳細については 次のドキュメントを参照してください ロードバランサー (p. 16) リスナー (p. 27) ターゲットグループ (p. 48) Application Load Balancer の概要 Application Load Balancer は 開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します ロードバランサーはリクエストを受信すると 優先度順にリスナールールを評価 1

7 Classic Load Balancer からの移行のメリット して適用するルールを決定し ルールアクションのターゲットグループからターゲットを選択します リスナールールを構成し アプリケーショントラフィックのコンテンツに基づいて異なるターゲットグループにリクエストをルーティングできます それぞれのターゲットグループでルーティングは個別に実行され 複数のターゲットグループに登録されているターゲットの場合も同じです アプリケーションへのリクエストの流れを中断することなく ニーズの変化に応じてロードバランサーに対してターゲットの追加と削除を行うことができます Elastic Load Balancing はアプリケーションへのトラフィックが時間の経過とともに変化するのに応じてロードバランサーをスケーリングします Elastic Load Balancing は大半のワークロードに合わせて自動的にスケーリングできます 登録済みのインスタンスのヘルス状態をモニタリングするために使用されるヘルスチェックを設定することで ロードバランサーは正常なターゲットにのみリクエストを送信できます 詳細については Elastic Load Balancing ユーザーガイドの Elastic Load Balancing の仕組み を参照してください Classic Load Balancer からの移行のメリット Classic Load Balancer の代わりに Application Load Balancer を使用すると 次のメリットがあります パスベースのルーティングのサポート リクエスト内の URL に基づいてリクエストを転送するリスナーのルールを設定できます これにより アプリケーションをより小さなサービスとして構成し URL の内容に基づいて適切なサービスにリクエストをルーティングできます ホストベースのルーティングのサポート HTTP ヘッダー内のホストフィールドに基づいてリクエストを転送するリスナーのルールを設定できます これにより 1 つのロードバランサーを使用して複数のドメインにリクエストをルーティングできます 1 つの EC2 インスタンス上での複数のアプリケーションへのルーティングリクエストのサポート 複数のポートを使用して 各インスタンスまたは IP アドレスを同じターゲットグループに登録できます ロードバランサーの VPC 外のターゲットを含め IP アドレスによるターゲットの登録をサポート コンテナ化されたアプリケーションのサポート Amazon Elastic Container Service (Amazon ECS) は タスクをスケジュールするときに未使用のポートを選択し そのポートを使用するターゲットグループにタスクを登録できます これにより クラスターを効率的に使用することができます 各サービスの個別のヘルスステータスのモニタリングのサポート ヘルスチェックがターゲットグループレベルで定義され 多数の CloudWatch メトリクスがターゲットグループレベルで報告されます ターゲットグループを Auto Scaling グループにアタッチすることで 各サービスをオンデマンドで動的にスケールすることができます アクセスログへの情報の追加と圧縮形式での保存 ロードバランサーのパフォーマンスの向上 各ロードバランサーの種類でサポートされている機能の詳細については Elastic Load Balancing 製品の比較 を参照してください 開始方法 Application Load Balancerを作成するには 次のいずれかのチュートリアルに従います Elastic Load Balancing ユーザーガイドの Elastic Load Balancing の開始方法 チュートリアル : Application Load Balancer でパスベースのルーティングを使用する (p. 8) チュートリアル : Application Load Balancer のターゲットとして Microservices を使用する (p. 10) 2

8 料金 料金 ロードバランサーについては お客様が利用された分のみのお支払いとなります 詳細については Elastic Load Balancing 料金表 を参照してください 3

9 開始する前に Application Load Balancer の使用開始 このチュートリアルでは ウェブベースインターフェイスである AWS マネジメントコンソールを使用して Application Load Balancer を実践的に説明します 最初の Application Load Balancer を作成するには 次のステップを完了します タスク 開始する前に (p. 4) ステップ 1: ロードバランサーの種類の選択 (p. 4) ステップ 2: ロードバランサーとリスナーの設定 (p. 5) ステップ 3: ロードバランサーのセキュリティグループの設定 (p. 5) ステップ 4: ターゲットグループの設定 (p. 5) ステップ 5: ターゲットグループへのターゲットの登録 (p. 6) ステップ 6: Load Balancer の作成とテスト (p. 6) ステップ 7: ロードバランサーの削除 ( オプション ) (p. 6) または ネットワークロードバランサーを作成するには Network Load Balancer 用ユーザーガイド の Network Load Balancer の開始方法 を参照してください Classic Load Balancer を作成するには クラシックロードバランサー用ユーザーガイド の Classic Load Balancer の作成 を参照してください 開始する前に EC2 インスタンスに使用する 2 つのアベイラビリティーゾーンを決定します これらの各アベイラビリティーゾーンに少なくとも 1 つのパブリックサブネットがある Virtual Private Cloud (VPC) を設定します これらのパブリックサブネットは ロードバランサーを設定するために使用されます その代わりに これらのアベイラビリティーゾーンの他のサブネットで EC2 インスタンスを起動することができます 各アベイラビリティーゾーンで少なくとも 1 つの EC2 インスタンスを起動します 必ず Apache や Internet Information Services (IIS) などのウェブサーバーを各 EC2 インスタンスにインストールします これらのインスタンスのセキュリティグループでは ポート 80 の HTTP アクセスを許可していることを確認してください ステップ 1: ロードバランサーの種類の選択 Elastic Load Balancing は 3 種類のロードバランサーをサポートしています このチュートリアルでは Application Load Balancer を作成します Application Load Balancer を作成するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションバーで ロードバランサーのリージョンを選択します EC2 インスタンス用に使用したリージョンと同じリージョンを必ず選択してください 3. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 4

10 ステップ 2: ロードバランサーとリスナーの設定 4. [Create Load Balancer] を選択します 5. [ アプリケーションロードバランサー ] で [ 作成 ] を選択します ステップ 2: ロードバランサーとリスナーの設定 [Configure Load Balancer] ページで 次の手順を完了します ロードバランサーとリスナーを設定するには 1. [Name] に ロードバランサーの名前を入力します Application Load Balancer の名前は リージョンの Application Load Balancer および Network Load Balancer セット内で一意にする必要があります 最大 32 文字で 英数字とハイフンのみ使用できます 先頭と末尾にハイフンを使用することはできず internal- で始めることはできません 2. [Scheme] および [IP address type] については デフォルト値のままにします 3. [Listeners] では デフォルトを保持します これは ポート 80 で HTTP トラフィックを受け付けるリスナーです 4. [Availability Zones] で EC2 インスタンスに使用する VPC を選択します EC2 インスタンスの起動に使用した各アベイラビリティーゾーンについて アベイラビリティーゾーンを選択し そのアベイラビリティーゾーンのパブリックサブネットを選択します 5. [Next: Configure Security Settings] を選択します 6. このチュートリアルでは HTTPS リスナーを作成しません [Next: Configure Security Groups] を選択します ステップ 3: ロードバランサーのセキュリティグループの設定 ロードバランサーのセキュリティグループは リスナーポートポートとヘルスチェックポートの両方で登録済みターゲットとの通信を許可する必要があります コンソールはユーザーに代わって ロードバランサーに正しいプロトコルとポートを指定するルールを持つセキュリティグループを作成できます 希望する場合には 独自のセキュリティグループを作成して選択することもできます 詳細については 推奨ルール (p. 23) を参照してください [Configure Security Groups ( セキュリティグループの設定 )] ページで 次の手順を実行し Elastic Load Balancing を使用して ユーザーの代わりロードバランサーのセキュリティグループを作成します ロードバランサーのセキュリティグループを設定するには 1. [Create a new security group] を選択します 2. セキュリティグループの名前と説明を入力するか デフォルトの名前と説明を維持します この新しいセキュリティグループには [Configure Load Balancer] ページで選択したロードバランサーリスナーポートへのトラフィックを許可するルールが含まれます 3. [Next: Configure Routing] を選択します ステップ 4: ターゲットグループの設定 リクエストルーティングで使用されるターゲットグループを作成します リスナーのデフォルトルールは このターゲットグループ内の登録済みターゲットにリクエストをルーティングします ロードバランサーは ターゲットグループに定義されたヘルスチェック設定を使用してこのターゲットグループ内のターゲットの状態を確認します [Configure Routing] ページで 次の手順を完了します 5

11 ステップ 5: ターゲットグループへのターゲットの登録 ターゲットグループを設定するには 1. [Target group] で デフォルトの [New target group] を保持します 2. [Name] に 新しいターゲットグループの名前を入力します 3. [ プロトコル ] は HTTP [ ポート ] は 80 [ ターゲットの種類 ] はインスタンスで維持します 4. [Health checks] は デフォルトプロトコルと ping パスを保持します 5. [Next: Register Targets] を選択します ステップ 5: ターゲットグループへのターゲットの登録 [Register Targets] ページで 次の手順を完了します ターゲットグループにターゲットを登録するには 1. [Instances] で 1 つ以上のインスタンスを選択します 2. デフォルトポート 80 を保持し [Add to registered] を選択します 3. インスタンスの選択が完了したら [Next: Review] を選択します ステップ 6: Load Balancer の作成とテスト ロードバランサーを作成する前に 選択した設定を確認します ロードバランサーを作成した後で EC2 インスタンスにトラフィックを送信するかどうかを検証します ロードバランサーを作成してテストするには 1. [Review] ページで [Create ] を選択します 2. ロードバランサーが正常に作成されたことが通知されたら [Close] を選択します 3. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 4. 新しく作成したターゲットグループを選択します 5. [Targets] タブで インスタンスの準備ができていることを確認します インスタンスのステータスが initial の場合 インスタンスがまだ登録の途中であるか 正常と見なされるのに必要なヘルスチェックの最小数に合格しなかったと考えられます 少なくとも 1 つのインスタンスのステータスが healthy であれば ロードバランサーをテストできます 6. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 7. 新しく作成したロードバランサーを選択します 8. [Description] タブで ロードバランサーの DNS 名 ( 例 : my-load-balancer uswest-2.elb.amazonaws.com) をコピーします インターネットに接続したウェブブラウザのアドレスフィールドに DNS 名を貼り付けます すべて適切な場合は ブラウザにサーバーのデフォルトページが表示されます 9. ( 省略可能 ) 追加のリスナールールを定義するには ルールの追加 (p. 37) を参照してください ステップ 7: ロードバランサーの削除 ( オプション ) ロードバランサーが利用可能になると ロードバランサーの実行時間に応じて 1 時間ごと または 1 時間未満の時間について課金されます 不要になったロードバランサーは削除できます ロードバランサーが 6

12 ステップ 7: ロードバランサーの削除 ( オプション ) 削除されると ロードバランサーの課金も停止されます ロードバランサーを削除しても ロードバランサーに登録されたターゲットには影響を与えません たとえば EC2 インスタンスを実行し続けます ロードバランサーを削除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. 任意のロードバランサーのチェックボックスを選択し [Actions] [Delete] を選択します 4. 確認を求めるメッセージが表示されたら [Yes, Delete] を選択します 7

13 チュートリアル : パスベースのルーティングを使用する Application Load Balancer のチュートリアル 次の Elastic Load Balancing のチュートリアルでは Application Load Balancer を使用して一般的なタスクを実行する方法を示します Elastic Load Balancing の開始方法 (Elastic Load Balancing ユーザーガイド ) チュートリアル : Application Load Balancer でパスベースのルーティングを使用する (p. 8) チュートリアル : Application Load Balancer のターゲットとして Microservices を使用する (p. 10) チュートリアル : AWS CLI を使用した Application Load Balancer の作成 (p. 12) チュートリアル : Application Load Balancer でパスベースのルーティングを使用する URL パスに基づいてリクエストを転送するルールを持つリスナーを作成できます これは パスベースのルーティングと呼ばれます マイクロサービスを実行している場合 パスベースのルーティングを使用して複数のバックエンドサービスにトラフィックをルーティングすることができます たとえば 1 つのターゲットグループに全般的なリクエストをルーティングし イメージをレンダリングするリクエストを別のターゲットグループにルーティングできます 開始する前に Virtual Private Cloud (VPC) で EC2 インスタンスを起動します これらのインスタンスのセキュリティグループがリスナーポートとヘルスチェックポートでアクセスを許可することを確認します 詳細については ターゲットセキュリティグループ (p. 57) を参照してください マイクロサービスが 登録する予定の EC2 インスタンスにデプロイされていることを確認します Load Balancer の作成 パスベースのルーティングを使用するロードバランサーを作成するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションバーで EC2 インスタンスのために選択したのと同じリージョンを選択します 3. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 4. 次のようにして 最初のターゲットセットのターゲットグループを作成します a. [Create target group] を選択します b. ターゲットグループの名前 プロトコル ポート VPC を指定し [Create] を選択します c. 新しいターゲットグループを選択します d. [Targets] タブで [Edit] を選択します e. [Instances] で 1 つ以上のインスタンスを選択します インスタンスのポートを指定し [Add to registered] を選択して [Save] を選択します インスタンスのステータスは インスタンスが登録されてヘルスチェックに合格するまで initial であり ロードバランサーからのトラフィックを受信するようにターゲットグループを設定するまで unused である点に注意してください 8

14 Load Balancer の作成 5. 次のようにして 2 番目のターゲットセットのターゲットグループを作成します a. [Create target group] を選択します b. ターゲットグループの名前 プロトコル ポート VPC を指定し [Create] を選択します c. [Targets] タブで [Edit] を選択します d. [Instances] で 1 つ以上のインスタンスを選択します インスタンスのポートを指定し [Add to registered] を選択して [Save] を選択します インスタンスのステータスは インスタンスが登録されてヘルスチェックに合格するまで initial であり ロードバランサーからのトラフィックを受信するようにターゲットグループを設定するまで unused である点に注意してください 6. ナビゲーションペインの [LOAD BALANCING] で [ Load Balancers] を選択します 7. [Create Load Balancer] を選択します 8. [Select load balancer type] で [Application Load Balancer] を選択します 9. [Continue] を選択します 10. [Configure Load Balancer] ページで次の操作を完了します a. [Name] に ロードバランサーの名前を入力します Application Load Balancer の名前は リージョンの Application Load Balancer および Network Load Balancer セット内で一意にする必要があります 最大 32 文字で 英数字とハイフンのみ使用できます 先頭と末尾にハイフンを使用することはできません b. [Scheme] のインターネット向けロードバランサーは クライアントからインターネット経由でリクエストをターゲットにルーティングします 内部ロードバランサーは プライベート IP アドレスを使用してターゲットにリクエストをルーティングします c. [Listeners] のデフォルトは ポート 80 で HTTP トラフィックを受け付けるリスナーです デフォルトのリスナーの設定をそのままにしておくことも リスナーのプロトコルまたはポートを変更することも [Add] を選択して別のリスナーを追加することもできます d. [Availability Zones] で EC2 インスタンスに使用する VPC を選択します アベイラビリティーゾーンを少なくとも 2 つ選択します アベイラビリティーゾーンに対して 1 つのサブネットがある場合 そのサブネットが選択されます そのアベイラビリティーゾーンに複数のサブネットがある場合は いずれかのサブネットを選択します アベイラビリティーゾーンにつき 1 つのサブネットしか選択できないことに注意してください e. [Next: Configure Security Settings] を選択します 11. ( オプション ) 前のステップでセキュアリスナーを作成した場合は [Configure Security Settings] ページで次の操作を完了します a. AWS Certificate Manager を使用して証明書を作成またはインポートした場合は [Choose an existing certificate from AWS Certificate Manager (ACM) (AWS Certificate Manager (ACM) から既存の証明書を選択 )] を選択し [Certificate name ( 証明書の名前 )] から証明書を選択します b. IAM を使用して証明書をすでにアップロードしている場合は [Choose an existing certificate from AWS Identity and Access Management (IAM)] を選択し [ 証明書名 ] から証明書を選択します c. アップロードする証明書があっても ACM がお客様のリージョンでサポートされていない場合は [Upload a new SSL Certificate to AWS Identity and Access Management (IAM)] を選択します [Certificate name] に証明書の名前を入力します [Private Key] に PEM エンコードされたプライベートキーファイルの内容をコピーして貼り付けます [Public Key Certificate] に PEM エンコードされたパブリックキー証明書ファイルの内容をコピーして貼り付けます 自己署名証明書を使用しておらず ブラウザが暗黙的に証明書を受け入れることが重要である場合に限り [Certificate Chain] に PEM エンコードされた証明書チェーンファイルの内容をコピーして貼り付けます d. [Select policy] の場合は デフォルトのセキュリティポリシーを維持します 12. [Next: Configure Security Groups] を選択します 9

15 チュートリアル : ターゲットとして Microservices を使用する 13. [Configure Security Groups] ページで次の操作を完了します a. [Create a new security group] を選択します b. セキュリティグループの名前と説明を入力するか デフォルトの名前と説明を維持します この新しいセキュリティグループには [Configure Load Balancer] ページでロードバランサー用に選択したポートへのトラフィックを許可するルールが含まれます c. [Next: Configure Routing] を選択します 14. [Configure Routing] ページで次の操作を完了します a. [Target group] で [Existing target group] を選択します b. [Name] で 作成した最初のターゲットグループを選択します c. [Next: Register Targets] を選択します 15. [Register Targets] ページで ターゲットグループに登録したインスタンスが [Registered instances] に表示されます ウィザードを完了するまで ターゲットグループに登録したターゲットを変更することはできません [Next: Review] を選択します 16. [Review] ページで [Create ] を選択します 17. ロードバランサーが正常に作成されたことが通知されたら [Close] を選択します 18. 新しく作成したロードバランサーを選択します 19. [Listeners] タブで 矢印を使用してリスナーのルールを表示し [Add rule] を選択します 次のようにしてルールを指定します a. [Target group name] で 作成した 2 番目のグループを選択します b. [Path pattern] で パスベースのルーティングに使用する正確なパターンを指定します ( たとえば /img/*) 詳細については リスナールール (p. 28) を参照してください c. [Save] を選択します チュートリアル : Application Load Balancer のターゲットとして Microservices を使用する 個別に開発およびデプロイできるサービスとしてのアプリケーションを構成するために microservices アーキテクチャを使用できます これらのサービスを 1 つ以上各 EC2 インスタンスにインストールし 各サービスが別のポートで接続を受け入れるようにできます 単一の Application Load Balancer でアプリケーションのすべてのサービスにリクエストをルーティングできます ターゲットグループに EC2 インスタンスを登録する場合 それを複数回登録できます 各サービスで そのサービスのポートを使用するインスタンスを登録します Important Amazon Elastic Container Service (Amazon ECS) を使用してサービスをデプロイする場合 動的ポートマッピングを使用して 同じコンテナインスタンスの単一のサービスからの複数のサービスをサポートできます Amazon ECS は インスタンス ID と各コンテナのポートを使用して自動的にコンテナをターゲットグループに登録およびターゲットグループから登録解除して サービスに対する更新を管理します 詳細については Amazon Elastic Container Service Developer Guide の サービスロードバランシング を参照してください 開始する前に EC2 インスタンスを起動します インスタンスのセキュリティグループが リスナーポートとヘルスチェックポートでロードバランサーのセキュリティグループからのアクセスを許可することを確認します 詳細については ターゲットセキュリティグループ (p. 57) を参照してください 10

16 Load Balancer の作成 EC2 インスタンスにサービスをデプロイします ( たとえばコンテナを使用して ) Load Balancer の作成 ターゲットとして複数のサービスを使用するロードバランサーを作成するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションバーで EC2 インスタンスのために選択したのと同じリージョンを選択します 3. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 4. [Create Load Balancer] を選択します 5. [Select load balancer type] で [Application Load Balancer] を選択します 6. [Continue] を選択します 7. [Configure Load Balancer] ページで次の操作を完了します a. [Name] に ロードバランサーの名前を入力します Application Load Balancer の名前は リージョンの Application Load Balancer および Network Load Balancer セット内で一意にする必要があります 最大 32 文字で 英数字とハイフンのみ使用できます 先頭と末尾にハイフンを使用することはできません b. [Scheme] のインターネット向けロードバランサーは クライアントからインターネット経由でリクエストをターゲットにルーティングします 内部ロードバランサーは プライベート IP アドレスを使用してターゲットにリクエストをルーティングします c. [Listeners] のデフォルトは ポート 80 で HTTP トラフィックを受け付けるリスナーです デフォルトのリスナーの設定をそのままにしておくことも リスナーのプロトコルまたはポートを変更することも [Add] を選択して別のリスナーを追加することもできます d. [Availability Zones] で EC2 インスタンスに使用する VPC を選択します アベイラビリティーゾーンを少なくとも 2 つ選択します アベイラビリティーゾーンに対して 1 つのサブネットがある場合 そのサブネットが選択されます そのアベイラビリティーゾーンに複数のサブネットがある場合は いずれかのサブネットを選択します アベイラビリティーゾーンにつき 1 つのサブネットしか選択できないことに注意してください e. [Next: Configure Security Settings] を選択します 8. ( オプション ) 前のステップでセキュアリスナーを作成した場合は [Configure Security Settings] ページで次の操作を完了します a. AWS Certificate Manager を使用して証明書を作成またはインポートした場合は [Choose an existing certificate from AWS Certificate Manager (ACM) (AWS Certificate Manager (ACM) から既存の証明書を選択 )] を選択し [Certificate name ( 証明書の名前 )] から証明書を選択します b. IAM を使用して証明書をすでにアップロードしている場合は [Choose an existing certificate from AWS Identity and Access Management (IAM) (AWS Certificate Manager (ACM) から既存の証明書を選択 )] を選択し [Certificate name ( 証明書名 )] から証明書を選択します c. アップロードする証明書があっても ACM がお客様のリージョンでサポートされていない場合は [Upload a new SSL Certificate to AWS Identity and Access Management (IAM)] を選択します [Certificate name] に証明書の名前を入力します [Private Key] に PEM エンコードされたプライベートキーファイルの内容をコピーして貼り付けます [Public Key Certificate] に PEM エンコードされたパブリックキー証明書ファイルの内容をコピーして貼り付けます 自己署名証明書を使用しておらず ブラウザが暗黙的に証明書を受け入れることが重要である場合に限り [Certificate Chain] に PEM エンコードされた証明書チェーンファイルの内容をコピーして貼り付けます d. [Select policy] の場合は デフォルトのセキュリティポリシーを維持します 9. [Next: Configure Security Groups] を選択します 10. [Configure Security Groups] ページで次の操作を完了します 11

17 チュートリアル : AWS CLI を使用した Application Load Balancer の作成 a. [Create a new security group] を選択します b. セキュリティグループの名前と説明を入力するか デフォルトの名前と説明を維持します この新しいセキュリティグループには [Configure Load Balancer] ページでロードバランサー用に選択したポートへのトラフィックを許可するルールが含まれます c. [Next: Configure Routing] を選択します 11. [Configure Routing] ページで次の操作を完了します a. [Target group] はデフォルトの [New target group] を保持します b. [Name] に 新しいターゲットグループの名前を入力します c. [Protocol] と [Port] を必要に応じて設定します d. [Health checks] は デフォルトのヘルスチェック設定のままにします e. [Next: Register Targets] を選択します 12. [Register Targets] で 次の操作を行ないます a. [Instances] で EC2 インスタンスを選択します b. サービスが使用するポートを入力し [Add to registered] を選択します c. 登録する各サービスで操作を繰り返します 完了したら [Next: Review] を選択します 13. [Review] ページで [Create ] を選択します 14. ロードバランサーが正常に作成されたことが通知されたら [Close] を選択します チュートリアル : AWS CLI を使用した Application Load Balancer の作成 このチュートリアルでは AWS CLI を使った Application Load Balancer の実践的な導入について説明します 開始する前に 次のコマンドを使用して Application Load Balancer をサポートするバージョンの AWS CLI を実行していることを確認します aws elbv2 help elbv2 が有効な選択肢ではないことを示すエラーメッセージが発生した場合は AWS CLI を更新します 詳細については AWS Command Line Interface ユーザーガイド の AWS コマンドラインインターフェイスのインストール を参照してください Virtual Private Cloud (VPC) で EC2 インスタンスを起動します これらのインスタンスのセキュリティグループがリスナーポートとヘルスチェックポートでアクセスを許可することを確認します 詳細については ターゲットセキュリティグループ (p. 57) を参照してください Load Balancer の作成 最初のロードバランサーを作成するには 次のステップを完了します ロードバランサーを作成するには 1. ロードバランサーを作成するには create-load-balancer コマンドを使用します 同じアベイラビリティーゾーンにない 2 つのサブネットを指定する必要があります 12

18 HTTPS リスナーの追加 aws elbv2 create-load-balancer --name my-load-balancer \ --subnets subnet subnet security-groups sg 出力には 次の形式でロードバランサーの Amazon リソースネーム (ARN) が含まれます arn:aws:elasticloadbalancing:us-east-2: :loadbalancer/app/my-loadbalancer/ ターゲットグループを指定し EC2 インスタンスに使用したのと同じ VPC を指定するには createtarget-group コマンドを使用します aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 \ --vpc-id vpc 出力には 次の形式のターゲットグループの ARN が含まれます 3. インスタンスをターゲットグループに登録するには register-targets コマンドを使用します aws elbv2 register-targets --target-group-arn targetgroup-arn \ --targets Id=i Id=i ターゲットグループにリクエストを転送するデフォルトルールを持つロードバランサーのリスナーを作成するには create-listener コマンドを使用します aws elbv2 create-listener --load-balancer-arn loadbalancer-arn \ --protocol HTTP --port 80 \ --default-actions Type=forward,TargetGroupArn=targetgroup-arn 出力には 次の形式のリスナーの ARN が含まれます arn:aws:elasticloadbalancing:us-east-2: :targetgroup/mytargets/ arn:aws:elasticloadbalancing:us-east-2: :listener/app/my-loadbalancer/ / ( オプション ) この describe-target-health コマンドを使用してターゲットグループの登録されたターゲットのヘルスステータスを確認できます aws elbv2 describe-target-health --target-group-arn targetgroup-arn HTTPS リスナーの追加 HTTP リスナーを持つロードバランサーがある場合 次のように HTTPS リスナーを追加できます ロードバランサーに HTTPS リスナーを追加するには 1. 次のいずれかの方法を使用して ロードバランサーで使用する SSL 証明書を作成します AWS Certificate Manager (ACM) を使用して証明書を作成またはインポートします 詳細については AWS Certificate Manager ユーザーガイドでパブリック証明書のリクエストまたは証明書のインポートを参照してください 13

19 ポートの上書きを使用したターゲットの追加 AWS Identity and Access Management (IAM) を使用して証明書をアップロードします 詳細については IAM ユーザーガイドの サーバー証明書の使用 を参照してください 2. ターゲットグループにリクエストを転送するデフォルトルールを持つリスナーを作成するには create-listener コマンドを使用します HTTPS リスナーを作成するときは SSL 証明書を指定する必要があります --ssl-policy オプションを使用してデフォルト以外の SSL ポリシーを指定できます aws elbv2 create-listener --load-balancer-arn loadbalancer-arn \ --protocol HTTPS --port 443 \ --certificates CertificateArn=certificate-arn \ --default-actions Type=forward,TargetGroupArn=targetgroup-arn ポートの上書きを使用したターゲットの追加 1 つのインスタンスに複数の ECS コンテナがある場合 各コンテナは別のポートで接続を受け入れます 毎回別のポートで インスタンスをターゲットグループに複数回登録できます ポートの上書きを使用してターゲットを追加するには 1. ターゲットグループを作成するには create-target-group コマンドを使用します aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 \ --vpc-id vpc インスタンスをターゲットグループに登録するには register-targets コマンドを使用します インスタンス ID はコンテナごとに同じですが ポートは異なることに注意してください aws elbv2 register-targets --target-group-arn targetgroup-arn \ --targets Id=i ,Port=80 Id=i ,Port= ターゲットグループにリクエストを転送するルールをリスナーに追加するには create-rule コマンドを使用します aws elbv2 create-rule --listener-arn listener-arn --priority 10 \ --actions Type=forward,TargetGroupArn=targetgroup-arn パスベースのルーティングの追加 1 つのターゲットグループにリクエストを転送するデフォルトルールを持つリスナーがある場合 URL に基づいて別のターゲットグループにリクエストを転送するルールを追加できます たとえば 1 つのターゲットグループに全般的なリクエストをルーティングし イメージを表示するリクエストを別のターゲットグループにルーティングできます パスパターンを持つリスナーにルールを追加するには 1. ターゲットグループを作成するには create-target-group コマンドを使用します aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 \ --vpc-id vpc インスタンスをターゲットグループに登録するには register-targets コマンドを使用します aws elbv2 register-targets --target-group-arn targetgroup-arn \ 14

20 ロードバランサーの削除 --targets Id=i Id=i URL に指定されたパターンが含まれている場合に ターゲットグループにリクエストを転送するルールをリスナーに追加するには create-rule コマンドを使用します aws elbv2 create-rule --listener-arn listener-arn --priority 10 \ --conditions Field=path-pattern,Values='/img/*' \ --actions Type=forward,TargetGroupArn=targetgroup-arn ロードバランサーの削除 ロードバランサーとターゲットグループが必要なくなった場合は 次のように削除することができます aws elbv2 delete-load-balancer --load-balancer-arn loadbalancer-arn aws elbv2 delete-target-group --target-group-arn targetgroup-arn 15

21 ロードバランサーのセキュリティグループ Application Load Balancer ロードバランサーは クライアントにとって単一の通信先として機能します クライアントはロードバランサーにリクエストを送信し ロードバランサーは複数のアベイラビリティーゾーンにあるターゲット (EC2 インスタンスなど ) にそれらのリクエストを送信します ロードバランサーを設定するには ターゲットグループ (p. 48) を作成し ターゲットグループにターゲットを登録します さらに リスナー (p. 27) を作成してクライアントからの接続リクエストがないかチェックし リスナールールを作成してリクエストをクライアントから 1 つ以上のターゲットグループ内のターゲットにルーティングします 詳細については Elastic Load Balancing ユーザーガイドの Elastic Load Balancing の仕組み を参照してください 目次 ロードバランサーのセキュリティグループ (p. 16) ロードバランサーの状態 (p. 16) ロードバランサーの属性 (p. 17) IP アドレスタイプ (p. 17) 削除保護 (p. 18) 接続のアイドルタイムアウト (p. 18) Application Load Balancer および AWS WAF (p. 19) Application Load Balancer の作成 (p. 19) Application Load Balancer のアベイラビリティーゾーン (p. 22) Application Load Balancer のセキュリティグループ (p. 23) Application Load Balancer の IP アドレスタイプ (p. 24) Application Load Balancer のタグ (p. 25) Application Load Balancer の削除 (p. 25) ロードバランサーのセキュリティグループ セキュリティグループは ロードバランサーとの間で許可されているトラフィックを制御するファイアウォールとして機能します インバウンドトラフィックとアウトバウンドトラフィックの両方を許可するポートとプロトコルを選択できます ロードバランサーのセキュリティグループに関連付けられたセキュリティグループのルールは リスナーポートとヘルスチェックポートの両方における両方向のトラフィックを許可する必要があります リスナーをロードバランサーに追加するとき またはターゲットグループのヘルスチェックポートを更新するときは必ず セキュリティグループルールを見直し 新しいポートで両方向のトラフィックが許可されていることを確認する必要があります 詳細については 推奨ルール (p. 23) を参照してください ロードバランサーの状態 ロードバランサーの状態は次のいずれかです 16

22 ロードバランサーの属性 provisioning active ロードバランサーはセットアップ中です ロードバランサーは完全にセットアップされており トラフィックをルーティングする準備ができています failed ロードバランサークラウドをセットアップできませんでした ロードバランサーの属性 ロードバランサーの属性は以下のとおりです access_logs.s3.enabled Amazon S3 に保存されたアクセスログが有効かどうかを示します デフォルト : false access_logs.s3.bucket アクセスログの S3 バケットの名前 この属性は アクセスログが有効になっている場合は必須です 詳細については バケットのアクセス許可 (p. 76) を参照してください access_logs.s3.prefix S3 バケットの場所のプレフィックス deletion_protection.enabled 削除保護が有効化されているかどうかを示します デフォルト : false idle_timeout.timeout_seconds アイドルタイムアウト値 ( 秒単位 ) デフォルト値は 60 秒です routing.http2.enabled HTTP/2 が有効化されているかどうかを示します デフォルト : true IP アドレスタイプ インターネット向けロードバランサーを作成するとき またはそれがアクティブになった後は その IP アドレスタイプを設定できます 内部ロードバランサーは IPv4 アドレスを使う必要があります ロードバランサーの IP アドレスタイプを次に示します ipv4 ロードバランサーは IPv4 アドレス ( 例 : ) のみをサポートします dualstack ロードバランサーは IPv4 と IPv6 アドレスの両方 ( 例 : 2001:0db8:85a3:0:0:8a2e:0370:7334) をサポートします IPv4 アドレスを使用してロードバランサーと通信するクライアントは A レコードを解決し IPv6 アドレスを使用してロードバランサーと通信するクライアントは AAAA レコードを解決します ただし クライ 17

23 削除保護 アントとロードバランサーとの通信方法に関係なく ロードバランサーは IPv4 アドレスを使用してターゲットと通信します 詳細については Application Load Balancer の IP アドレスタイプ (p. 24) を参照してください 削除保護 ロードバランサーが誤って削除されるのを防ぐため 削除保護を有効にできます デフォルトでは ロードバランサーで削除保護が無効になっています ロードバランサーの削除保護を有効にした場合 ロードバランサーを削除する前に無効にする必要があります コンソールを使用して削除保護を有効にするには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Description] タブで [Edit attributes] を選択します 5. [ ロードバランサー属性の編集 ] ページで [ 削除保護 ] の [ 有効 ] を選択し [ 保存 ] を選択します 6. [Save] を選択します コンソールを使用して削除保護を無効にするには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Description] タブで [Edit attributes] を選択します 5. [ ロードバランサー属性の編集 ] ページで [ 削除保護 ] の [ 有効 ] の選択を解除し [ 保存 ] を選択します 6. [Save] を選択します AWS CLI を使用して削除保護を有効または無効にするには deletion_protection.enabled 属性を指定して modify-load-balancer-attributes コマンドを使用します 接続のアイドルタイムアウト クライアントがロードバランサーを通じて行うリクエストごとに ロードバランサーは 2 つの接続を維持します フロントエンド接続とはクライアントとロードバランサー間の接続を意味し バックエンド接続とはロードバランサーとターゲット間の接続を意味します ロードバランサーは 指定された期間に接続でデータが送信されない場合にトリガーされるアイドルタイムアウトを管理します アイドルタイムアウトが経過するまでデータが送受信されなかった場合 ロードバランサーは接続を閉じます デフォルトでは Elastic Load Balancing はアイドルタイムアウト値を 60 秒に設定します したがって リクエストが転送中にターゲットが少なくとも 60 秒ごとにデータを送信しない場合 ロードバランサーはフロントエンド接続を閉じることができます ファイルのアップロードなどの長いオペレーションで 18

24 Application Load Balancer および AWS WAF 完了までの時間を確保するため 各アイドルタイムアウト期間が経過するまでに少なくても 1 バイトのデータを送信し 必要に応じてアイドルタイムアウトの長さを増やします バックエンド接続では EC2 インスタンスに HTTP キープアライブオプションを有効にすることが推奨されます EC2 インスタンスのウェブサーバー設定で HTTP キープアライブを有効にできます HTTP キープアライブを有効にすると ロードバランサーはキープアライブのタイムアウト期間が終了するまで バックエンド接続を再利用できます また アプリケーションのアイドルタイムアウトは ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定することをお勧めします コンソールを使用してアイドルタイムアウト値を更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Description] タブで [Edit attributes] を選択します 5. [Edit load balancer attributes] ページで [Idle timeout] の値を秒単位で入力します 有効な範囲は 1 ~ 4000 です デフォルト値は 60 秒です 6. [Save] を選択します AWS CLI を使用してアイドルタイムアウト値を更新するには idle_timeout.timeout_seconds 属性を指定して modify-load-balancer-attributes コマンドを使用します Application Load Balancer および AWS WAF Application Load Balancer で AWS WAF を使用して ウェブアクセスコントロールリスト ( ウェブ ACL) のルールに基づいてリクエストを許可またはブロックできます 詳細については AWS WAF 開発者ガイドの ウェブ ACL の使用 を参照してください Application Load Balancer の作成 ロードバランサーはクライアントからリクエストを受け取り ターゲットグループのターゲット間でリクエストを分散します 開始する前に ターゲットが使用する各アベイラビリティーゾーンで少なくとも 1 つのパブリックサブネットを持つ Virtual Private Cloud (VPC) があることを確認します AWS CLI を使用してロードバランサーを作成する方法については チュートリアル : AWS CLI を使用した Application Load Balancer の作成 (p. 12) を参照してください AWS マネジメントコンソールを使用してロードバランサーを作成するには 以下のタスクを完了します タスク ステップ 1: ロードバランサーとリスナーを設定する (p. 5) ステップ 2: HTTPS リスナーのセキュリティ設定を指定する (p. 20) ステップ 3: セキュリティグループを設定する (p. 21) ステップ 4: ターゲットグループを設定する (p. 5) ステップ 5: ターゲットグループのターゲットを設定する (p. 21) 19

25 ステップ 1: ロードバランサーとリスナーを設定する ステップ 6: ロードバランサーを作成する (p. 22) ステップ 1: ロードバランサーとリスナーを設定する 最初に 名前 ネットワーク 1 つ以上のリスナーなど ロードバランサーの基本的な設定情報を指定します リスナーとは接続リクエストをチェックするプロセスです これは クライアントからロードバランサーへの接続用のプロトコルとポートを使用して設定します サポートされるプロトコルとポートの詳細については リスナーの設定 (p. 27) を参照してください ロードバランサーとリスナーを設定するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. [Create Load Balancer] を選択します 4. [ アプリケーションロードバランサー ] で [ 作成 ] を選択します 5. [Name] に ロードバランサーの名前を入力します たとえば my-alb と指定します 6. [Scheme] のインターネット向けロードバランサーは クライアントからインターネット経由でリクエストをターゲットにルーティングします 内部ロードバランサーは プライベート IP アドレスを使用してターゲットにリクエストをルーティングします 7. [Listeners] のデフォルトは ポート 80 で HTTP トラフィックを受け付けるリスナーです デフォルトのリスナー設定を保持する プロトコルを変更する またはポートを変更することができます [Add] を選択して別のリスナー ( たとえば HTTPS リスナー ) を追加します 8. [Availability Zones] で VPC から少なくとも 2 つのアベイラビリティーゾーンを選択します アベイラビリティーゾーンに対して 1 つのサブネットがある場合 そのサブネットが選択されます そのアベイラビリティーゾーンに複数のサブネットがある場合は いずれかのサブネットを選択します アベイラビリティーゾーンにつき 1 つのサブネットしか選択できないことに注意してください 9. [Next: Configure Security Settings] を選択します ステップ 2: HTTPS リスナーのセキュリティ設定を指定する 前のステップで HTTPS リスナーを作成した場合は 必要なセキュリティ設定を指定します それ以外の場合は ウィザードの次のページに進みます ロードバランサーに HTTPS を使用するときは ロードバランサーに SSL 証明書をデプロイする必要があります ターゲットにリクエストを送信する前に ロードバランサーはこの証明書を使用して接続を終了し クライアントからのリクエストを復号します 詳細については SSL 証明書 (p. 34) を参照してください また クライアントとの SSL 接続のネゴシエーションのためにロードバランサーが使用するセキュリティポリシーも指定する必要があります 詳細については セキュリティポリシー (p. 34) を参照してください 証明書とセキュリティポリシーを設定するには 1. [ デフォルトの証明書の選択 ] で 次のいずれかを実行します AWS Certificate Manager を使用して証明書を作成またはインポートした場合は [Choose a certificate from ACM (ACM から証明書を選択する )] を選択し [Certificate name ( 証明書名 )] から証明書を選択します IAM を使用して証明書をアップロードした場合は [Choose a certificate from IAM (IAM から証明書を選択する )] を選択し [Certificate name ( 証明書名 )] から証明書を選択します 2. [ セキュリティポリシー ] では デフォルトのセキュリティポリシーを維持することをお勧めします 20

26 ステップ 3: セキュリティグループを設定する 3. [Next: Configure Security Groups] を選択します ステップ 3: セキュリティグループを設定する ロードバランサーのセキュリティグループは リスナーポートポートとヘルスチェックポートの両方で登録済みターゲットとの通信を許可する必要があります コンソールは この通信を許可するルールにより お客様に代わってロードバランサー用のセキュリティグループを作成できます 希望する場合は 代わりにセキュリティグループを作成して選択することもできます 詳細については 推奨ルール (p. 23) を参照してください ロードバランサーのセキュリティグループを設定するには 1. [Create a new security group] を選択します 2. セキュリティグループの名前と説明を入力するか デフォルトの名前と説明を維持します この新しいセキュリティグループには [Configure Load Balancer] ページでロードバランサー用に選択したポートへのトラフィックを許可するルールが含まれます 3. [Next: Configure Routing] を選択します ステップ 4: ターゲットグループを設定する ターゲットグループにターゲットを登録します このステップで設定するターゲットグループは リクエストをターゲットグループに転送するデフォルトのリスナールールで ターゲットグループとして使用されます 詳細については Application Load Balancer のターゲットグループ (p. 48) を参照してください ターゲットグループを設定するには 1. [Target group] で デフォルトの [New target group] を保持します 2. [Name] に ターゲットグループの名前を入力します 3. [Protocol] と [Port] を必要に応じて設定します 4. [Target type] には instance を選択してインスタンス ID でターゲットを指定するか ip を選択して IP アドレスでターゲットを指定します 5. [Health checks] は デフォルトのヘルスチェック設定のままにします 6. [Next: Register Targets] を選択します ステップ 5: ターゲットグループのターゲットを設定する Application Load Balancer を使用して ターゲットグループに選択したターゲットタイプによってインスタンス ID または IP アドレスを使用してターゲットを登録します インスタンス ID でターゲットを登録するには 1. [Instances] で 1 つ以上のインスタンスを選択します 2. インスタンスのリスナーポートを入力し [Add to registered] を選択します 3. インスタンスの登録が完了したら [Next: Review] を選択します IP アドレスでターゲットを登録するには 1. 各 IP アドレスを登録するには 次の操作を行います 21

27 ステップ 6: ロードバランサーを作成する a. [Network] で IP アドレスがターゲットグループ VPC のサブネットからのものである場合は VPC を選択します それ以外の場合は [Other private IP address] を選択します b. [IP] に IP アドレスを入力します c. [Port] にポートを入力します d. [Add to list] を選択します 2. IP アドレスのリストへの追加が完了したら [Next: Review] を選択します ステップ 6: ロードバランサーを作成する ロードバランサーを作成したら ターゲットが最初のヘルスチェックに合格したことを確認してから ロードバランサーがターゲットにトラフィックを送信することをテストできます ロードバランサーの操作を終了したら ロードバランサーを削除できます 詳細については Application Load Balancer の削除 (p. 25) を参照してください ロードバランサーを作成するには 1. [Review] ページで [Create ] を選択します 2. ロードバランサーが作成されたら [Close] を選択します 3. ( オプション ) パスパターンまたはホスト名に基づいてリクエストを転送する追加のリスナールールを定義する方法については ルールの追加 (p. 37) を参照してください Application Load Balancer のアベイラビリティーゾーン アベイラビリティーゾーンは ロードバランサーに対していつでも有効または無効にできます アベイラビリティーゾーンを有効にしたら ロードバランサーはこれらのアベイラビリティーゾーン内の登録済みターゲットにリクエストをルーティングするようになります 有効な各アベイラビリティーゾーンに少なくとも 1 つの登録済みターゲットがあるようにする場合 ロードバランサーが最も効果的です アベイラビリティーゾーンを無効にすると そのアベイラビリティーゾーン内のターゲットはロードバランサーに登録されたままですが ロードバランサーはリクエストをターゲットにルーティングしなくなります コンソールを使用してアベイラビリティーゾーンを更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Description] タブの [Basic Configuration] で [Edit Availability Zones] を選択します 5. アベイラビリティーゾーンを有効にするには そのアベイラビリティーゾーンのチェックボックスをオンにします そのアベイラビリティーゾーンに対して 1 つのサブネットがある場合 そのサブネットが選択されます そのアベイラビリティーゾーンに複数のサブネットがある場合は いずれかのサブネットを選択します アベイラビリティーゾーンにつき 1 つのサブネットしか選択できないことに注意してください 6. 有効なアベイラビリティーゾーンのサブネットを変更するには [Change subnet] を選択し その他のサブネットの 1 つを選択します 7. アベイラビリティーゾーンを削除するには そのアベイラビリティーゾーンのチェックボックスをオフにします 22

28 セキュリティグループの更新 8. [Save] を選択します AWS CLI を使用してアベイラビリティーゾーンを更新するには set-subnets コマンドを使用します Application Load Balancer のセキュリティグループ ロードバランサーが リスナーポートとヘルスチェックポートの両方で 登録済みターゲットと通信できることを確認する必要があります ロードバランサーにリスナーを追加するか リクエストをルーティングするためにロードバランサーにより使用されるターゲットグループのヘルスチェックポートを更新する場合は必ず ロードバランサーに関連付けられたセキュリティグループが新しいポートで両方向のトラフィックを許可することを確認する必要があります 許可しない場合 現在関連付けられているセキュリティグループのルールを編集するか 別のセキュリティグループをロードバランサーに関連付けることができます 推奨ルール 推奨ルールは ロードバランサーのタイプ ( インターネット向けまたは内部向け ) によって異なります インターネット接続ロードバランサー Inbound Source Port Range Comment /0 リリリリ ロードバランサーのリスナーポートですべてのイ ンバウンドトラフィックを許可する Outbound Destination Port Range Comment リリリリリリリリリリリリリリリリ リリリリリリリリリリ インスタンスリスナーポートでインスタンスへの アウトバウンドトラフィックを許可する リリリリリリリリリリリリリリリリ リリリリリリリ ヘルスチェックポートでインスタンスへのアウト バウンドトラフィックを許可する 内部ロードバランサー Inbound Source Port Range Comment VPC CIDR リリリリ ロードバランサーのリスナーポートで VPC CIDR からのインバウンドトラフィックを許可する Outbound Destination Port Range Comment リリリリリリリリリリリリリリリリ リリリリリリリリリリ インスタンスリスナーポートでインスタンスへの アウトバウンドトラフィックを許可する 23

29 関連付けられたセキュリティグループの更新 リリリリリリリリリリリリリリリリ リリリリリリリ ヘルスチェックポートでインスタンスへのアウト バウンドトラフィックを許可する また パス MTU 検出をサポートするため インバウンド ICMP トラフィックを許可することをお勧めします 詳細については Linux インスタンス用 Amazon EC2 ユーザーガイド の パス MTU 検出 を参照してください 関連付けられたセキュリティグループの更新 ロードバランサーに関連付けられたセキュリティグループは いつでも更新できます コンソールを使用してセキュリティグループの更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Description] タブの [Security] で [Edit security groups] を選択します 5. セキュリティグループをロードバランサーに関連付けるには そのセキュリティグループを選択します セキュリティグループをロードバランサーから削除するには そのセキュリティグループを選択解除します 6. [Save] を選択します AWS CLI を使用してセキュリティグループを更新するには set-security-groups コマンドを使用します Application Load Balancer の IP アドレスタイプ IPv4 トラフィックのみ または IPv4 と IPv6 トラフィックの両方をルーティングするよう Application Load Balancer を設定できます 詳細については IP アドレスタイプ (p. 17) を参照してください IPv6 の要件 インターネット向けロードバランサー Virtual Private Cloud (VPC) には 関連付けられた IPv6 CIDR ブロックを持つサブネットがあります 詳細については Amazon EC2 ユーザーガイドの IPv6 アドレス を参照してください IP アドレスを更新するには コンソールを使用して入力します 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Actions] [Edit IP address type] を選択します 5. [IP address type] で [ipv4] を選択して IPv4 アドレスのみをサポートするか [dualstack] を選択して IPv4 と IPv6 アドレスの両方をサポートします 6. [Save] を選択します AWS CLI を使用して IP アドレスタイプを更新するには set-ip-address-type コマンドを使用します 24

30 タグの更新 Application Load Balancer のタグ タグを使用すると ロードバランサーを目的 所有者 環境などさまざまな方法で分類することができます 各ロードバランサーに対して複数のタグを追加できます タグキーは 各ロードバランサーで一意である必要があります すでにロードバランサーに関連付けられているキーを持つタグを追加すると そのキーの値が更新されます タグが不要になったら ロードバランサーからタグを削除できます 制限 リソースあたりのタグの最大数 50 キーの最大長 127 文字 (Unicode) 値の最大長 255 文字 (Unicode) タグのキーと値では大文字と小文字が区別されます 使用できる文字は UTF-8 で表現できる文字 スペース および数字と 特殊文字 + - =. _ : です ただし 先頭または末尾にはスペースを使用しないでください タグの名前または値に aws: プレフィックスは使用しないでください このプレフィックスは AWS 用に予約されています このプレフィックスが含まれるタグの名前または値は編集または削除できません このプレフィックスを持つタグは リソースあたりのタグ数の制限時には計算されません コンソールを使用してロードバランサーのタグを更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択します 4. [Tags] タブで [Add/Edit Tags] を選択し 次のうち 1 つ以上を選択します a. タグを更新するには [Key] と [Value] の値を編集します b. 新しいタグを追加するには [Create Tag] を選択し [Key] と [Value] の値を入力します c. タグを削除するには タグの横にある削除アイコン (X) を選択します 5. タグの更新を完了したら [Save] を選択します AWS CLI を使用してロードバランサーのタグを更新するには add-tags コマンドと remove-tags コマンドを使用します Application Load Balancer の削除 ロードバランサーが利用可能になると ロードバランサーの実行時間に応じて 1 時間ごと または 1 時間未満の時間について課金されます 不要になったロードバランサーは削除できます ロードバランサーが削除されると ロードバランサーの課金も停止されます 削除保護が有効になった場合 ロードバランサーを削除することはできません 詳細については 削除保護 (p. 18) を参照してください ロードバランサーを削除しても 登録済みターゲットには影響を与えない点に注意してください たとえば EC2 インスタンスは実行を続け ターゲットグループに登録されたままです ターゲットグループを削除するには ターゲットグループの削除 (p. 60) を参照してください 25

31 ロードバランサーの削除 コンソールを使用してロードバランサーを削除するには 1. ロードバランサーをポイントするドメインの CNAME レコードが存在する場合は 新しい場所にポイントして DNS の変更が有効になってから ロードバランサーを削除します 2. にある Amazon EC2 コンソールを開きます 3. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 4. ロードバランサーを選択して [Actions] [Delete] を選択します 5. 確認を求めるメッセージが表示されたら [Yes, Delete] を選択します AWS CLI を使用してロードバランサーを削除するには delete-load-balancer コマンドを使用します 26

32 リスナーの設定 Application Load Balancer のリスナー Application Load Balancer の使用を開始する前に 1 つ以上のリスナーを追加する必要があります リスナーとは 設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです リスナーに対して定義したルールは ロードバランサーが 1 つ以上のターゲットグループ内のターゲットにリクエストをルーティングする方法を決定します 目次 リスナーの設定 (p. 27) リスナールール (p. 28) リダイレクトアクション (p. 29) 固定レスポンスアクション (p. 30) ホストの条件 (p. 31) パスの条件 (p. 31) Application Load Balancer のリスナーの作成 (p. 32) Application Load Balancer の HTTPS リスナー (p. 33) Application Load Balancer のリスナールール (p. 36) サーバー証明書の更新 (p. 40) Application Load Balancer を使用してユーザーを認証する (p. 42) Application Load Balancer のリスナーの削除 (p. 47) リスナーの設定 リスナーは次のポートとプロトコルをサポートします プロトコル : HTTP HTTPS ポート : 1 ~ アプリケーションがビジネスロジックに集中できるように HTTPS リスナーを使用して 暗号化および復号の作業をロードバランサーに任せることができます リスナープロトコルが HTTPS の場合は リスナーに SSL サーバー証明書を 1 つだけデプロイする必要があります 詳細については Application Load Balancer の HTTPS リスナー (p. 33) を参照してください Application Load Balancer は WebSockets のネイティブサポートを提供します WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用できます Application Load Balancer は HTTPS リスナーに HTTP/2 のネイティブサポートを提供します 1 つの HTTP/2 コネクションで最大 128 のリクエストを並行して送信できます ロードバランサーは これらのリクエストを個々の HTTP/1.1 のリクエストに変換し ターゲットグループの正常なターゲットにこれを分配します HTTP/2 ではフロントエンド接続を効率的に使用するため クライアントとロードバランサー間の接続数が減少します HTTP/2 のサーバープッシュ機能は使用できません 27

33 リスナールール 詳細については Elastic Load Balancing ユーザーガイドの リクエストルーティング を参照してください リスナールール 各リスナーにはデフォルトのルールがあり オプションで追加のルールを定義できます 各ルールは 優先順位 1 つ以上のアクション ホスト条件 ( オプション ) およびパス条件 ( オプション ) で構成されます デフォルトのルール リスナーを作成するときは デフォルトのルールのアクションを定義します デフォルトのルールに条件を定義することはできません リスナーのルールに設定された条件のいずれも満たされない場合は デフォルトのルールのアクションが実行されます デフォルトのルールの例を コンソールに表示されるとおりに次に示します ルールの優先順位 各ルールには優先順位があります ルールは優先順位の低 ~ 高順によって評価されます デフォルトのルールが最後に評価されます デフォルト以外のルールは 優先順位をいつでも変更できます デフォルトルールの優先順位は変更できません 詳細については ルールの順序変更 (p. 39) を参照してください ルールのアクション ルールのアクションごとにタイプ 順序 およびアクションを実行するために必要な情報があります サポートされているアクションタイプを以下に示します authenticate-cognito [HTTPS リスナー ] Amazon Cognito を使用してユーザーを認証します authenticate-oidc [HTTPS リスナー ] OpenID Connect (OIDC) に準拠する ID プロバイダーを使用してユーザーを認証します fixed-response カスタムの HTTP レスポンスを返します forward 指定されたターゲットグループにリクエストを転送します redirect 別の URL にリクエストをリダイレクトします 順番の値が最も小さいアクションが最初に実行されます 最後に実行されるアクションは forward redirect fixed-response アクションのいずれかにする必要があります 次の 28

34 ルールの条件 タイプのアクションのいずれかを各ルールに含める必要があります : forward redirect fixedresponse ルールはいつでも編集できます 詳細については ルールの編集 (p. 38) を参照してください ルールの条件 ルールには ホストとパスという 2 つのルール条件があります 各ルールには最大 1 つのホスト条件および最大 1 つのパス条件を指定できます ルールの条件が満たされると アクションが実行されます リダイレクトアクション クライアントリクエストを別の URL にリダイレクトするには redirect アクションを使用します 必要に応じて 一時的 (HTTP 302) または恒久的 (HTTP 301) としてリダイレクトを設定します URI のコンポーネントは次のとおりです protocol://hostname:port/path?query リダイレクトのループを避けるために 次のコンポーネントを 1 つ以上変更する必要があります : protocol hostname port または path 変更しないコンポーネントはすべて 元の値が保持されます プロトコル プロトコル (HTTP または HTTPS) HTTP から HTTP HTTP から HTTPS HTTPS から HTTPS にリダイレクトできます HTTPS から HTTP にリダイレクトすることはできません hostname port パス query ホスト名 ポート (1~65535) 絶対パス ( 先頭は /) クエリパラメーター 次の予約キーワードを使用して 元 URL の URI コンポーネントをターゲット URL で再利用できます #{protocol} プロトコルが保持されます プロトコルとクエリコンポーネントで使用する #{host} ドメインが保持されます ホスト名 パス クエリコンポーネントで使用する #{port} ポートが保持されます ポート パス クエリコンポーネントで使用する #{path} パスが保持されます パスとクエリコンポーネントで使用する #{query} クエリパラメーターが保持されます クエリコンポーネントで使用する たとえば 次のルールでは HTTPS プロトコルと指定されたポート (40443) を使用する URL にリダイレクトする永続的 URL が設定されますが 元のホスト名 パス およびクエリパラメーターは保持されます この画面は に相当します 29

35 固定レスポンスアクション 次のルールでは 元のプロトコル ポート ホスト名 クエリパラメーターを保持する URL に恒久的ダイレクトをセットアップし #{path} キーワードを使用して次の変更されたパスを作成します この画面は #{protocol}://#{host}:#{port}/new/#{path}?#{query} に相当します redirect アクションが実行されると そのアクションはアクセスログに記録されます 詳細については アクセスログのエントリ (p. 72) を参照してください redirect アクションが正常に実行された数は HTTP_Redirect_Count メトリクスでレポートされます 詳細については Application Load Balancer メトリクス (p. 62) を参照してください redirect アクションを既存のルールに追加するか redirect アクションを使用して新しいルールを作成する方法については Application Load Balancer のリスナールール (p. 36) を参照してください 固定レスポンスアクション クライアントリクエストを破棄し カスタムの HTTP レスポンスを返すには fixed-response アクションを使用します このアクションを使用して 2XX 4XX または 5XX のレスポンスコードとオプションのメッセージを返すことができます fixed-response アクションが実行されると そのアクションと リダイレクトターゲットの URL がアクセスログに記録されます 詳細については アクセスログのエントリ (p. 72) を参照してください fixed-response アクションが正常に実行された数は HTTP_Fixed_Response_Count メトリクスでレポートされます 詳細については Application Load Balancer メトリクス (p. 62) を参照してください fixed-response アクションを既存のルールに追加するか fixed-response アクションを使用して新しいルールを作成する方法については Application Load Balancer のリスナールール (p. 36) を参照してください 30

36 ホストの条件 ホストの条件 ホストの条件を使用して ホストヘッダーのホスト名に基づいて別のターゲットグループにリクエストを転送する ( ホストベースのルーティングとも呼ばれます ) ルールを定義できます これにより 1 つのロードバランサーを使用して複数のドメインをサポートできます 各ホスト条件には 1 つのホスト名が含まれています ホストヘッダーのホスト名がリスナールールのホスト名に正確に一致する場合 リクエストはそのルールを使用してルーティングされます ホスト名では大文字と小文字が区別され 次の文字を最大 128 文字含めることができます A Z a z * (0 個以上の文字と一致します )? ( 正確に 1 個の文字と一致します ) また 3 つまでのワイルドカード文字を含めることができます 少なくとも 1 つの. 文字を含める必要があります 最後の. の文字の後はアルファベット文字のみ含めることができます ホスト名の例 example.com test.example.com *.example.com ルール *.example.com は test.example.com には一致しますが example.com には一致しません コンソールの例 コンソールに示すホスト条件を持つルールの例を次に示します ホストヘッダーのホスト名が *.example.com に一致する場合 リクエストは my-web-servers という名前のターゲットグループに転送されます 詳細については ルールの追加 (p. 37) を参照してください パスの条件 パスの条件を使用して リクエスト内の URL に基づいてリクエストを別のターゲットグループに転送するルールを定義できます ( パスベースのルーティングとも呼ばれます ) パスの各状態には 1 つのパスパターンがあります リクエストの URL のパスがリスナールールのパスパターンに一致する場合 リクエストはそのルールを使用してルーティングされます パスパターンは URL のパスにのみ適用され クエリパラメーターには適用されません パスパターンでは大文字と小文字が区別され 最大 128 文字までの次の文字を含めることができます また 3 つまでのワイルドカード文字を含めることができます A Z a z 0 9 _ -. $ / ~ " : + & (& を使用 ) 31

37 リスナーの作成 * (0 個以上の文字と一致します )? ( 正確に 1 個の文字と一致します ) パスパターンの例 /img/* /js/* パスパターンはリクエストのルーティングに使用されますが 変更はしません たとえば ルールにパスパターン /img/* がある場合 ルールは /img/picture.jpg のリクエストを /img/picture.jpg のリクエストとして 指定されたターゲットグループに転送します コンソールの例 コンソールに表示されたパス条件を持つルールの例を次に示します リクエストの URL が /img/* と一致する場合 リクエストは my-targets という名前のターゲットグループに転送されます 詳細については ルールの追加 (p. 37) を参照してください Application Load Balancer のリスナーの作成 リスナーとは接続リクエストをチェックするプロセスです ロードバランサーを作成するときにリスナーを定義し いつでもロードバランサーにリスナーを追加できます 前提条件 転送アクションをデフォルトのリスナールールに追加するには 利用可能なターゲットグループを指定する必要があります 詳細については ターゲットグループの作成 (p. 52) を参照してください HTTPS リスナーを作成するには 証明書とセキュリティポリシーを指定する必要があります ターゲットにリクエストをルーティングする前に ロードバランサーはこの証明書を使用して接続を終了し クライアントからのリクエストを復号します 詳細については SSL 証明書 (p. 34) を参照してください ロードバランサーは クライアントと SSL 接続のネゴシエーションを行うときにセキュリティポリシーを使用します 詳細については セキュリティポリシー (p. 34) を参照してください リスナーの追加 クライアントからロードバランサーへの接続用のプロトコルとポート およびデフォルトのリスナールールのターゲットグループでリスナーを設定します 詳細については リスナーの設定 (p. 27) を参照してください コンソールを使用してリスナーを追加するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [ リスナー ] [ リスナーの追加 ] を選択します 4. [Protocol : port ( プロトコル : ポート )] で [HTTP] または [HTTPS] を選択します デフォルトポートのままにすることも 別のポートを入力することもできます 32

38 HTTPS リスナーの設定 5. ( 省略可能 HTTPS リスナー ) ユーザーを認証するには [ デフォルトアクション ] で [ アクションの追加 ] [Authenticate ( 認証 )] の順に選択し 必要な情報を入力します アクションを保存するには チェックマークアイコンを選択します 詳細については Application Load Balancer を使用してユーザーを認証する (p. 42) を参照してください 6. [Default actions ( デフォルトアクション )] で 次のいずれかを実行します [ アクションの追加 ] [ 転送先 ] の順に選択し ターゲットグループを選択します [ アクションの追加 ] [ リダイレクト先 ] の順に選択し リダイレクト先の URL を指定します 詳細については リダイレクトアクション (p. 29) を参照してください [ アクションの追加 ] [Return fixed response ( 固定レスポンスを返す )] の順に選択し レスポンスコードと ( オプション ) レスポンスの本文を指定します 詳細については 固定レスポンスアクション (p. 30) を参照してください アクションを保存するには チェックマークアイコンを選択します 7. [HTTPS リスナー ] [Security policy ( セキュリティポリシー )] で デフォルトのセキュリティポリシーを保持することをお勧めします 8. [HTTPS リスナー ] [Default SSL certificate ( デフォルトの SSL 証明書 )] で 次のいずれかを実行します AWS Certificate Manager を使用して証明書を作成またはインポートした場合は [From ACM (ACM から )] を選択して 証明書を選択します IAM を使用して証明書をアップロードした場合は [From IAM (IAM から )] を選択して 証明書を選択します 9. [Save] を選択します 10. ( オプション ) パスパターンまたはホスト名に基づいてリクエストを転送する追加のリスナールールを定義する方法については ルールの追加 (p. 37) を参照してください AWS CLI を使用してリスナーを追加するには create-listener コマンドを使用してリスナーとデフォルトのルールを作成し create-rule コマンドを使用して追加のリスナールールを定義します Application Load Balancer の HTTPS リスナー 暗号化された接続を使用するリスナーを作成できます (SSL オフロードとも呼ばれます ) この機能によって ロードバランサーと SSL あるいは TLS セッションを開始したクライアント間のトラフィックを暗号化できます HTTPS リスナーを使用するには ロードバランサーに SSL/TLS サーバー証明書をデプロイする必要があります ターゲットにリクエストを送信する前に ロードバランサーはこの証明書を使用して接続を終了し クライアントからのリクエストを復号します Elastic Load Balancing は セキュリティポリシーと呼ばれる Secure Socket Layer (SSL) ネゴシエーション設定を使用して クライアントとロードバランサー間の SSL 接続をネゴシエートします セキュリティポリシーはプロトコルと暗号の組み合わせです プロトコルは クライアントとサーバーの間の安全な接続を確立し クライアントとロードバランサーの間で受け渡しされるすべてのデータのプライバシーを保証します 暗号とは 暗号化キーを使用してコード化されたメッセージを作成する暗号化アルゴリズムです プロトコルは 複数の暗号を使用し インターネットを介してデータを暗号化します 接続ネゴシエーションのプロセスで クライアントとロードバランサーでは それぞれサポートされる暗号とプロトコルのリストが優先される順に表示されます デフォルトでは サーバーのリストで最初にクライアントの暗号と一致した暗号が安全な接続用に選択されます Application Load Balancer ではクライアントまたはターゲット接続の SSL 再ネゴシエーションはサポートされていません 33

39 SSL 証明書 SSL 証明書 ロードバランサーは X.509 証明書 (SSL/TLS サーバー証明書 ) を使用します 証明書とは 認証機関 (CA) によって発行された識別用デジタル形式です 証明書には 認識用情報 有効期間 パブリックキー シリアル番号と発行者のデジタル署名が含まれます ロードバランサーで使用する証明書を作成するときに ドメイン名を指定する必要があります AWS Certificate Manager (ACM) を使用して ロードバランサーの証明書を作成することをお勧めします ACM は Elastic Load Balancing と統合して ロードバランサーに証明書をデプロイできます 詳細については AWS Certificate Manager ユーザーガイド を参照してください また SSL/TLS を使用して署名証明書リクエスト (CSR) を作成し CA から CSR 署名を取得して証明書を発行し ACM にこの証明書をインポートする あるいは AWS Identity and Access Management (IAM) に証明書をアップロードすることもできます ACM への証明書のインポートに関する詳細については AWS Certificate Manager ユーザーガイドの 証明書のインポート を参照してください IAM にアップロードする証明書に関する詳細については IAM ユーザーガイドの サーバー証明書の使用 を参照してください Important 4096 ビット RSA キーまたは EC キーを使用する証明書を ACM との統合を介してロードバランサーにインストールすることはできません 4096 ビット RSA キーまたは EC キーを使用する証明書をロードバランサーで使用するには IAM にアップロードする必要があります HTTPS リスナーを作成するには デフォルトの証明書を指定します 別の証明書を追加することで リスナーにオプションの証明書リストを作成できます これによって ロードバランサーが複数のドメインを同じポートでサポートし 各ドメインに別々の証明書を提供できます リスナーのデフォルトの証明書は デフォルトでは証明書リストに追加されません 詳細については サーバー証明書の更新 (p. 40) を参照してください クライアントは Server Name Indication (SNI) プロトコル拡張子を使用して到達先のホスト名を指定します ホスト名が証明書リストの証明書と一致しない場合 ロードバランサーはデフォルトの証明書を選択します ホスト名が証明書リストの単一の証明書と一致する場合 ロードバランサーはその証明書を選択します クライアントが提供するホスト名が証明書リストの複数の証明書と一致する場合 ロードバランサーはクライアントがサポートできる最適な証明書を選択します 証明書の選択は 次の条件と順序に基づいて行われます パブリックキーアルゴリズム (RSA よりも ECDSA が優先 ) ハッシュアルゴリズム (MD5 よりも SHA が優先 ) キーの長さ ( 最大が優先 ) 有効期間 ロードバランサーアクセスログエントリは クライアントが指定したホスト名とクライアントが提出する証明書を示します 詳細については アクセスログのエントリ (p. 72) を参照してください セキュリティポリシー フロントエンド接続に使用するセキュリティポリシーを選択できます バックエンド接続には 常に ELBSecurityPolicy セキュリティポリシーが使用されます Application Load Balancer はカスタムセキュリティポリシーをサポートしていません Elastic Load Balancing に用意されている Application Load Balancer 用のセキュリティポリシーは次のとおりです ELBSecurityPolicy

40 セキュリティポリシー ELBSecurityPolicy-FS ELBSecurityPolicy-TLS ELBSecurityPolicy-TLS-1-2-Ext ELBSecurityPolicy-TLS ELBSecurityPolicy ELBSecurityPolicy-TLS 一般的な使用には ELBSecurityPolicy ポリシーをお勧めします Forward Secrecy (FS) を必要とする場合は ELBSecurityPolicy-FS ポリシーを使用できます ELBSecurityPolicy-TLS ポリシーの 1 つを使用して 特定の TLS プロトコルバージョンを無効にする必要があるコンプライアンスおよびセキュリティ標準を満たすか 廃止された暗号を必要とするレガシークライアントをサポートできます TLS バージョン 1.0 を必要とするのは 一部のインターネットクライアントのみです ロードバランサーへのリクエストの TLS プロトコルバージョンを表示するには ロードバランサーのアクセスログ記録を有効にして アクセスログを調べます 詳細については アクセスログ (p. 71) を参照してください 次の表は Application Load Balancer に定義されたセキュリティポリシーについて示しています セキュリティポリシー * FS TLS-1-2 TLS-1-2- Ext TLS-1-1 TLS-1-0 TLS Protocols Protocol-TLSv1 Protocol-TLSv1.1 Protocol-TLSv1.2 TLS Ciphers ECDHE-ECDSA-AES128- GCM- SHA256 ECDHE-RSA-AES128- GCM- SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-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 35

41 セキュリティポリシーの更新 セキュリティポリシー * FS TLS-1-2 TLS-1-2- Ext TLS-1-1 TLS-1-0 AES128-GCM-SHA256 AES128-SHA256 AES128-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA DES-CBC3-SHA * Application Load Balancer の ELBSecurityPolicy および ELBSecurityPolicy のセキュリティポリシーは同じです DES-CBC3-SHA 暗号 ( 弱い暗号 ) を必要とするレガシークライアントをサポートする必要がない限り このセキュリティポリシーは使用しないでください AWS CLI を使用して Application Load Balancer のセキュリティポリシーの設定を表示するには describe-ssl-policies コマンドを使用します セキュリティポリシーの更新 HTTPS リスナーを作成するときに ニーズを満たすセキュリティポリシーを選択できます 新しいセキュリティのポリシーを追加したら HTTPS リスナーを更新して新しいセキュリティポリシーを使用できます Application Load Balancer はカスタムセキュリティポリシーをサポートしていません コンソールを使用してセキュリティポリシーを更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. HTTPS リスナーのチェックボックスを選択して [ 編集 ] を選択します 5. [Security policy ( セキュリティポリシー )] で セキュリティポリシーを選択します 6. [Update] を選択します AWS CLI を使用してセキュリティポリシーを更新するには modify-listener コマンドを使用します Application Load Balancer のリスナールール リスナーに対して定義したルールは ロードバランサーが 1 つ以上のターゲットグループ内のターゲットにリクエストをルーティングする方法を決定します 各ルールは 優先順位 1 つ以上のアクション ホスト条件 ( オプション ) およびパス条件 ( オプション ) で構成されます 詳細については リスナールール (p. 28) を参照してください 36

42 前提条件 Note コンソールには ルールの優先度ではなく 各ルールの相対シーケンス番号が表示されます AWS CLI または Elastic Load Balancing API を使用してルールを記述することによって ルールの優先度を取得できます 前提条件 転送アクションで ターゲットグループにリクエストをルーティングすること 転送アクションを使用してルールを作成する または転送アクションを使用してルールのターゲットグループを更新する前に ターゲットグループを作成してターゲットを追加します 詳細については ターゲットグループの作成 (p. 52) を参照してください ルールの追加 リスナーを作成するときはデフォルトのルールを定義し デフォルト以外の追加のルールはいつでも定義できます コンソールを使用してルールを追加するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. 更新するリスナーについては [View/edit rules] を選択します 5. メニューバーの [Add rules] アイコン ( プラス記号 ) を選択します これにより 優先順位でルールを挿入できる場所に [ ルールの挿入 ] アイコンが追加されます 6. ルールを次のように定義します a. [Insert Rule] を選択します b. ( 省略可能 ) ホストベースのルーティングを設定するには [Add condition ( 条件の追加 )] [Host is ( ホスト )] の順に選択し ホスト名 ( 例 : *.example.com) を入力します 条件を保存するには チェックマークアイコンを選択します c. ( 省略可能 ) パスベースのルーティングを設定するには [Add condition ( 条件の追加 )] [Path is ( パス )] の順に選択し パスパターン ( 例 : /img/*) を入力します 条件を保存するには チェックマークアイコンを選択します d. ( オプション HTTPS リスナー ) ユーザーを認証するには [ アクションの追加 ] [Authenticate ( 認証 )] の順に選択し 必要な情報を入力します 詳細については Application Load Balancer を使用してユーザーを認証する (p. 42) を参照してください e. 次のいずれかを行ってください 転送アクションを追加するには [ アクションの追加 ] [ 転送先 ] の順に選択し ターゲットグループを選択します リダイレクトアクションを追加するには [ アクションの追加 ] [ リダイレクト先 ] の順に選択し リダイレクト先の URL を指定します 詳細については リダイレクトアクション (p. 29) を参照してください 固定レスポンスアクションを追加するには [ アクションの追加 ] [Return fixed response ( 固定レスポンスを返す )] の順に選択し レスポンスコードと ( オプション ) レスポンスの本文を指定します 詳細については 固定レスポンスアクション (p. 30) を参照してください 37

43 ルールの編集 アクションを保存するには チェックマークアイコンを選択します f. ( オプション ) ルールの順序を変更するには 矢印を使用します デフォルトのルールは常に最も低い優先度です g. [Save] を選択します 7. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用してルールを追加するには ルールを作成するには create-rule コマンドを使用します ルールに関する情報を確認するには describe-rules コマンドを使用します ルールの編集 ルールのアクションおよび条件はいつでも編集できます コンソールを使用してルールを編集するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. 更新するリスナーについては [View/edit rules] を選択します 5. メニューバーの [Edit rules] アイコン ( 鉛筆 ) を選択します 6. 編集するルールについては [Edit rules] アイコン ( 鉛筆 ) を選択します 7. ( 省略可能 ) 必要に応じて 条件とアクションを変更します たとえば 条件またはアクションの編集 ( 鉛筆アイコン ) パス条件の追加 ( 指定されていない場合 ) ホスト条件の追加 ( 指定されていない場合 ) HTTPS リスナーのルールの認証アクションの追加 または条件またはアクションの削除 ( ごみ箱アイコン ) を行うことができます デフォルトのルールに条件を追加することはできません 38

44 ルールの順序変更 8. [Update] を選択します 9. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用してルールを編集するには modify-rule コマンドを使用します ルールの順序変更 ルールは優先順位の低 ~ 高順によって評価されます デフォルトのルールが最後に評価されます デフォルト以外のルールは 優先順位をいつでも変更できます デフォルトルールの優先順位は変更できません Note コンソールには ルールの優先度ではなく 各ルールの相対シーケンス番号が表示されます コンソールを使用してルールの順序を変更すると 既存のルールの優先度に基づいて新しいルールの優先度が取得されます ルールの優先度を特定の値に設定するには AWS CLI または Elastic Load Balancing API を使用します コンソールを使用してルールの順序を変更するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. 更新するリスナーについては [View/edit rules] を選択します 5. メニューバーの [Reorder rules] アイコン ( 矢印 ) を選択します 6. ルールの横にあるチェックボックスをオンにしてから 矢印を使ってルールに新しい優先順位を設定します デフォルトのルールは常に最も低い優先度です 7. ルールの順序変更を完了したら [Save] を選択します 8. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用してルールの優先順位を更新するには set-rule-priorities コマンドを使用します ルールの削除 リスナーのデフォルト以外のルールはいつでも削除できます リスナーのデフォルトのルールは削除できません リスナーを削除すると そのルールはすべて削除されます コンソールを使用してルールを削除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. 更新するリスナーについては [View/edit rules] を選択します 5. メニューバーの [Delete rules ( ルールの削除 )] アイコン ( マイナス記号 ) を選択します 39

45 サーバー証明書の更新 6. ルールのチェックボックスを選択して [ 削除 ] を選択します リスナーのデフォルトのルールは削除できません 7. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用してルールを削除するには delete-rule コマンドを使用します サーバー証明書の更新 HTTPS リスナーを作成するには デフォルトの証明書を指定します 別の証明書を追加することで リスナーに証明書リストを作成することもできます 各証明書には有効期間が記載されています 有効期間が終わる前に 証明書を更新するか 置き換える必要があります 証明書を更新または置き換えしても ロードバランサーノードが受信し 正常なターゲットへのルーティングを保留中の未処理のリクエストには影響しません 証明書更新後 新しいリクエストは更新された証明書を使用します 証明書置き換え後 新しいリクエストは新しい証明書を使用します 証明書の更新と置き換えは次のとおりに管理できます AWS Certificate Manager が提供し ロードバランサーにデプロイされた証明書は 自動的に更新できます ACM は期限切れになる前に証明書を更新しようとします 詳細については AWS Certificate Manager ユーザーガイド にある 管理された更新 を参照してください 証明書を ACM にインポートした場合は 証明書の有効期限をモニタリングし 期限切れ前に更新する必要があります 詳細については AWS Certificate Manager ユーザーガイドの 証明書のインポート を参照してください IAM に証明書をインポートする場合 新しい証明書を作成し この新しい証明書を ACM; あるいは IAM にインポートします ロードバランサーにこの新しい証明書を追加し 期限切れの証明書をロードバランサーから削除します 制限 ACM は 4096 キー長および EC 証明書を使用する RSA 証明書をサポートします ただし これらの証明書を ACM との統合を介してロードバランサーにインストールすることはできません これらの証明書をロードバランサーで使用するには IAM にアップロードする必要があります 証明書の追加 次の手順でリスナーの証明書リストに証明書を追加できます リスナーのデフォルトの証明書は証明書リストにデフォルトで追加されませんが デフォルトの証明書を証明書リストに追加できます コンソールを使用して証明書を追加するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. HTTPS リスナーを更新するには [ 証明書の表示 / 編集 ] を選択します デフォルトの証明書を先頭に リスナーに追加したそのほかのすべての証明書が表示されます 5. ACM と IAM によって管理されるそのほかすべての証明書に続いてデフォルトの証明書を表示する [ 証明書の追加 ] アイコン ( プラス記号 ) をメニューバーで選択します リスナーにすでに証明書を追加した場合は そのチェックボックスが選択され無効になっています 6. ACM または IAM によってすでに管理されている証明書を追加するには その証明書のチェックボックスを選択して [ 追加 ] を選択します 40

46 デフォルトの証明書の置き換え 7. ACM または IAM が管理していない証明書がある場合は その証明書を ACM にインポートし 次のとおりにリスナーに追加します a. [ 証明書のインポート ] を選択します b. 証明書のプライベートキーの場合 PEM エンコードされ 暗号化されていないプライベートキーを証明書に貼り付けます c. [ 証明書本文 ] では PEM エンコードされた証明書を貼り付けます d. ( オプション ) [ 証明書チェーン ] では PEM エンコードされた証明書チェーンを貼り付けます e. [Import] を選択します 新規にインポートされた証明書は 選択された利用可能な証明書リストに表示されます f. [Add] を選択します 8. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用して証明書を追加するには add-listener-certificates コマンドを使用します デフォルトの証明書の置き換え 次の手順でリスナーのデフォルトの証明書を置き換えできます コンソールを使用してデフォルトの証明書を変更するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. リスナーのチェックボックスを選択して [ 編集 ] を選択します 5. [Default SSL certificate ( デフォルトの SSL 証明書 )] で 次のいずれかを実行します AWS Certificate Manager を使用して証明書を作成またはインポートした場合は [From ACM (ACM から )] を選択して 証明書を選択します IAM を使用して証明書をアップロードした場合は [From IAM (IAM から )] を選択して 証明書を選択します 6. [Save] を選択します AWS CLI を使用してデフォルトの証明書を変更するには modify-listener コマンドを使用します 証明書の削除 デフォルト以外の証明書は HTTPS リスナーからいつでも削除できます 次の手順では HTTPS リスナーのデフォルトの証明書は削除できません コンソールを使用して証明書を削除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. リスナーを更新するには [ 証明書の表示 / 編集 ] を選択します デフォルトの証明書を先頭に リスナーに追加したそのほかのすべての証明書が表示されます 41

47 ユーザーの認証 5. メニューバーで [ 証明書の削除 ] アイコン ( マイナス記号 ) を選択します 6. 証明書のチェックボックスを選択して [Remove ( 削除 )] を選択します 7. この画面をそのままにして メニューバーの [Back to the load balancer] ( 戻るボタン ) を選択します AWS CLI を使用して証明書を削除するには remove-listener-certificates コマンドを使用します Application Load Balancer を使用してユーザーを認証する Application Load Balancer を設定して ユーザーがアプリケーションにアクセスしたときに安全に認証できます これにより アプリケーションがビジネスロジックに集中できるように ユーザーを認証する作業をロードバランサーに任せることができます 次にユースケースがサポートされています OpenID Connect (OIDC) に準拠する ID プロバイダー (IdP) を使用してユーザーを認証します Amazon Facebook または Google などよく知られているソーシャル IdP を介して Amazon Cognito でサポートされているユーザープールを経由して ユーザーを認証します 企業アイデンティティを介して SAML LDAP または Microsoft AD を使用して Amazon Cognito でサポートされているユーザープールを経由して ユーザーを認証します OIDC 準拠 IdP を使用する準備を整える Application Load Balancer で OIDC 準拠 IdP を使用している場合は 以下を実行します IdP に新しい OIDC アプリを作成します クライアント ID およびクライアントシークレットを設定する必要があります その IdP によって発行される次のエンドポイントを取得します 認証 トークン およびユーザー情報 この情報は よく知られている config で確認できます IdP アプリで次のリダイレクト URL のいずれかをホワイトリストに入れます ユーザーが使用するものであればどれでも構いません ここで DNS はロードバランサーのドメイン名であり CNAME はアプリケーションの DNS エイリアスです Amazon Cognito を使用する準備を整える Application Load Balancer で Amazon Cognito ユーザープールを使用している場合は 以下を実行します ユーザープールを作成します 詳細については Amazon Cognito 開発者ガイドの Amazon Cognito ユーザープール を参照してください ユーザープールのクライアントを作成します クライアントシークレットを生成し コード付与フローを使用し ロードバランサーが使用するものと同じ OAuth スコープをサポートするように クライアントを設定する必要があります 詳細については Amazon Cognito 開発者ガイドの ユーザープールアプリクライアントの設定 を参照してください 42

48 Amazon CloudFront を使用する準備を整える ユーザープールのドメインを作成します 詳細については Amazon Cognito 開発者ガイドの ユーザープールのドメイン名の追加 を参照してください リクエストされたスコープで ID トークンが返されていることを確認します たとえば デフォルトのスコープ openid では ID トークンが返されますが aws.cognito.signin.user.admin スコープでは返されません ソーシャルまたは企業 IdP と連携するには フェデレーションセクションで IdP を有効にします 詳細については Amazon Cognito 開発者ガイドの ユーザープールにソーシャルサインインを追加する または SAML IdP を使用したサインインをユーザープールに追加する を参照してください Amazon Cognito のコールバック URL フィールドで次のリダイレクト URL のいずれかをホワイトリストに入れます ユーザーが使用するものであればどれでも構いません ここで DNS はロードバランサーのドメイン名であり CNAME はアプリケーションの DNS エイリアス ( 使用している場合 ) です IdP アプリのコールバック URL でユーザープールドメインをホワイトリストに入れます IdP の形式を使用します 以下に例を示します IAM ユーザーを有効にして ロードバランサーで Amazon Cognito を使用してユーザーを認証するように設定するには cognito-idp:describeuserpoolclient アクションを呼び出すアクセス許可をユーザーに付与する必要があります Amazon CloudFront を使用する準備を整える Application Load Balancer の前面で CloudFront ディストリビューションを使用している場合は 次の設定を有効にします クエリ文字列の転送とキャッシュ ( すべて ) Cookie の転送 ( すべて ) リクエストヘッダーに基づいたキャッシュ ( すべて ) ユーザー認証を設定する 1 つ以上のリスナールールの認証アクションを作成して ユーザー認証を設定します authenticatecognito および authenticate-oidc アクションタイプは HTTPS リスナーでのみサポートされています 対応するフィールドの説明については Elastic Load Balancing API リファレンスバージョン の AuthenticateCognitoActionConfig および AuthenticateOidcActionConfig を参照してください デフォルトでは SessionTimeout フィールドは 7 日に設定されています セッションをこれより短くするばあいは セッションタイムアウトを最短 1 秒に設定できます 詳細については 認証のログアウトとセッションのタイムアウト (p. 47) を参照してください アプリケーションの必要に応じて OnUnauthenticatedRequest フィールドを設定します 以下に例を示します ユーザーがソーシャル ID または企業 ID を使用してログインする必要があるアプリケーション デフォルトのオプション authenticate でサポートされています ユーザーがログインしていない場合は ロードバランサーはリクエストを IdP 認証エンドポイントにリダイレクトし IdP によってユーザーにユーザーインターフェイスを使用したログインを求めるプロンプトが表示されます ログインしているユーザーにはパーソナライズされたビューを ログインしていないユーザーには一般的なビューを提供するアプリケーション このタイプのアプリケーションをサポートするには allow 43

49 ユーザー認証を設定する オプションを使用します ユーザーがログインしている場合 ロードバランサーがユーザークレームを提供するため アプリケーションはパーソナライズされたビューを提供できます ユーザーがログインしていない場合 ロードバランサーはリクエストをユーザークレームなしで転送するため アプリケーションは一般的なビューを提供できます 数秒ごとに読み込みを行う JavaScript を使用した単一ページのアプリケーション デフォルトでは 認証セッションの Cookie が有効期限切れになると AJAX 呼び出しは IdP にリダイレクトされてブロックされます deny オプションを使用する場合 ロードバランサーはこれらの AJAX 呼び出しに対して HTTP 401 Unauthorized エラーを返します ロードバランサーは IdP トークンのエンドポイント (TokenEndpoint) および IdP ユーザー情報エンドポイント (UserInfoEndpoint) と通信できる必要があります ロードバランサーのセキュリティグループおよび VPC のネットワーク ACL がこれらのエンドポイントに対するアウトバウンドアクセスを許可していることを検証します VPC がインターネット接続されていることを確認します 内部向けロードバランサーがある場合は NAT ゲートウェイを使用して ロードバランサーからこれらのエンドポイントにアクセスできるようにします 次の create-rule コマンドを使用して ユーザー認証を設定します aws elbv2 create-rule --listener-arn listener-arn --priority 10 \ --conditions Field=path-pattern,Values="/login" --actions file://actions.json authenticate-oidc アクションと forward アクションを指定する actions.json ファイルの例を次に示します [{ }, { "Type": "authenticate-oidc", "AuthenticateOidcConfig": { "Issuer": " "AuthorizationEndpoint": " "TokenEndpoint": " "UserInfoEndpoint": " "ClientId": "abcdefghijklmnopqrstuvwxyz ", "ClientSecret": " ", "SessionCookieName": "my-cookie", "SessionTimeout": 3600, "Scope": " ", "AuthenticationRequestExtraParams": { "display": "page", "prompt": "login" }, "OnUnauthenticatedRequest": "deny" }, "Order": 1 "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:accountid:targetgroup/target-group-name/target-group-id", "Order": 2 }] authenticate-cognito アクションと forward アクションを指定する actions.json ファイルの例を次に示します [{ "Type": "authenticate-cognito", "AuthenticateCognitoConfig": { "UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id", "UserPoolClientId": "abcdefghijklmnopqrstuvwxyz ", 44

50 認証のフロー }, { "UserPoolDomain": "userpooldomain1", "SessionCookieName": "my-cookie", "SessionTimeout": 3600, "Scope": " ", "AuthenticationRequestExtraParams": { "display": "page", "prompt": "login" }, "OnUnauthenticatedRequest": "deny" }, "Order": 1 "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:accountid:targetgroup/target-group-name/target-group-id", "Order": 2 }] 詳細については リスナールール (p. 28) を参照してください 認証のフロー Elastic Load Balancing では OIDC 認証コードフローを使用します これには 以下のステップが含まれます 1. 認証アクションを持つルールの条件が満たされている場合 ロードバランサーはリクエストヘッダーに認証セッション Cookie があるかどうかを確認します Cookie が存在しない場合 ロードバランサーはユーザーを IdP 認証エンドポイントにリダイレクトし IdP でユーザーを認証できるようにします 2. ユーザーが認証されると IdP は認証付与コードを伴ったユーザーをロードバランサーにリダイレクトして戻します ロードバランサーはコードを IdP トークンエンドポイントに示し ID トークンやアクセストークンを取得します 3. ロードバランサーは ID トークンを検証した後 アクセストークンを IdP ユーザー情報エンドポイントと交換してユーザークレームを取得します 4. ロードバランサーは認証セッション Cookie を作成してクライアントに送信します これにより クライアントのユーザーエージェントがリクエストを送信したときにロードバランサーに Cookie を送信できます ほとんどのブラウザでは Cookie のサイズを 4K に制限しているため ロードバランサーはサイズが 4K を超える Cookie を複数の Cookie に分割します IdP から受け取ったユーザークレームとアクセストークンの合計サイズが 11K を超える場合 ロードバランサーはエラーを返します 5. ロードバランサーは HTTP ヘッダーのターゲットにユーザークレームを送信します 詳細については ユーザークレームのエンコードと署名の検証 (p. 45) を参照してください 6. IdP によって ID トークンに有効な更新トークンが提供されている場合 ロードバランサーは更新トークンを保存し アクセストークンの有効期限が切れるたびにこれを使用して セッションがタイムアウトするか IdP の更新に失敗するまで ユーザークレームを更新します ユーザーがログアウトすると 更新は失敗し ロードバランサーはユーザーを IdP 認証エンドポイントにリダイレクトします これにより ロードバランサーはユーザーがログアウト後にセッションを削除できます 詳細については 認証のログアウトとセッションのタイムアウト (p. 47) を参照してください ユーザークレームのエンコードと署名の検証 ロードバランサーがユーザーの認証に成功すると IdP から受け取ったユーザークレームがターゲットに送信されます ロードバランサーはユーザークレームに署名するため アプリケーションは署名の検証およびそのクレームがロードバランサーから送信されたものであることの検証を行うことができます ロードバランサーは以下の HTTP ヘッダーを追加します 45

51 ユーザークレームのエンコードと署名の検証 x-amzn-oidc-accesstoken トークンエンドポイントからのアクセストークン ( プレーンテキスト ) x-amzn-oidc-identity ユーザー情報エンドポイントからの件名フィールド (sub) ( プレーンテキスト ) x-amzn-oidc-data ユーザークレーム (JSON ウェブトークン (JWT) 形式 ) 完全なユーザークレームが必要なアプリケーションでは 任意の標準 JWT ライブラリを使用できます JWT 形式にはヘッダー ペイロード および Base64 URL でエンコードされた署名が含まれています JWT 署名は ECDSA + P SHA256 です この JWT ヘッダーは 次のフィールドを持つ JSON オブジェクトです { "alg": "algorithm", "kid": " ", "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/loadbalancer-name/load-balancer-id", "iss": "url", "client": "client-id", "exp": "expiration" } この JWT ペイロードは IdP ユーザー情報エンドポイントから受け取ったユーザークレームを含む JSON オブジェクトです { } "sub": " ", "name": "name", " ": "alias@example.com",... ロードバランサーではユーザークレームが暗号化されないため HTTPS を使用するようにターゲットグループを設定することをお勧めします HTTP を使用するようにターゲットグループを設定する場合は ロードバランサーへのトラフィックをセキュリティグループを使用するトラフィックのみに制限してください また クレームに基づいて認証を行う前に 署名を検証することもお勧めします パブリックキーを取得するには JWT ヘッダーからキー ID を取得し それを使用して次のリージョンエンドポイントからパブリックキーを検索します AWS GovCloud (US-West) の場合 エンドポイントは次のとおりです 次の例では Python でパブリックキーを取得する方法を示しています import jwt import requests import base64 import json # Step 1: Get the key id from JWT headers (the kid field) 46

52 認証のログアウトとセッションのタイムアウト encoded_jwt = headers.dict['x-amzn-oidc-data'] jwt_headers = encoded_jwt.split('.')[0] decoded_jwt_headers = base64.b64decode(jwt_headers) decoded_json = json.loads(decoded_jwt_headers) kid = decoded_json['kid'] # Step 2: Get the public key from regional endpoint url = ' + region + '.amazonaws.com/' + kid req = requests.get(url) pub_key = req.text # Step 3: Get the payload payload = jwt.decode(encoded_jwt, pub_key, algorithms=['es256']) 認証のログアウトとセッションのタイムアウト アプリケーションで認証済みユーザーをログアウトさせる必要がある場合 認証セッション Cookie の有効期限を -1 に設定し クライアントを IdP ログアウトエンドポイントにリダイレクト (IdP でサポートされている場合 ) する必要があります ユーザーが削除された Cookie を再利用しないようにするには アクセストークンの有効期限を問題のない範囲でできるだけ短く設定することをお勧めします 有効期限切れのアクセストークンと null 以外の更新トークンがある認証セッション Cookie を持つロードバランサーをクライアントが提供する場合 ロードバランサーは IdP に接続してユーザーがまだログインしているかどうかを判別します 更新トークンとセッションタイムアウトは連携して次のように動作します セッションタイムアウトがアクセストークンの有効期限よりも短い場合 ロードバランサーはセッションのタイムアウトを優先し 認証セッションがタイムアウトした後はユーザーに再度ログインさせます セッションタイムアウトがアクセストークンの有効期限よりも長く IdP が更新トークンをサポートしていない場合 ロードバランサーは認証セッションをタイムアウトまで維持してから ユーザーに再度ログインさせます セッションタイムアウトがアクセストークンの有効期限よりも長く IdP が更新トークンをサポートしている場合 ロードバランサーはアクセストークンの有効期限が切れるたびにユーザーセッションを更新します ロードバランサーは 認証セッションがタイムアウトした後 または更新フローに失敗した場合にのみ ユーザーに再度ログインさせます Application Load Balancer のリスナーの削除 リスナーの削除はいつでも行うことができます ロードバランサーを削除すると そのリスナーがすべて削除されます コンソールを使用してリスナーを削除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します 3. ロードバランサーを選択し [Listeners] を選択します 4. HTTPS リスナーのチェックボックスを選択して [ 削除 ] を選択します 5. 確認を求めるメッセージが表示されたら [Yes, Delete] を選択します AWS CLI を使用してリスナーを削除するには delete-listener コマンドを使用します 47

53 ルーティング設定 Application Load Balancer のターゲットグループ 各ターゲットグループは 1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます 各リスナーのルールを作成するときに ターゲットグループと条件を指定します ルールの条件が満たされると トラフィックが該当するターゲットグループに転送されます さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます たとえば 一般的なリクエスト用に 1 つのターゲットグループを作成し アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます 詳細については Application Load Balancer コンポーネント (p. 1) を参照してください ロードバランサーのヘルスチェック設定は ターゲットグループ単位で定義します 各ターゲットグループはデフォルトのヘルスチェック設定を使用します ただし ターゲットグループを作成したときや 後で変更したときに上書きした場合を除きます リスナーのルールでターゲットグループを指定すると ロードバランサーは ロードバランサーで有効なアベイラビリティーゾーンにある ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします ロードバランサーは 正常な登録済みターゲットにリクエストをルーティングします 目次 ルーティング設定 (p. 48) ターゲットの種類 (p. 49) 登録済みターゲット (p. 49) ターゲットグループの属性 (p. 50) 登録解除の遅延 (p. 50) スロースタートモード (p. 51) スティッキーセッション (p. 52) ターゲットグループの作成 (p. 52) ターゲットグループのヘルスチェック (p. 53) ターゲットグループへのターゲットの登録 (p. 56) ターゲットグループのタグ (p. 59) ターゲットグループの削除 (p. 60) ルーティング設定 デフォルトでは ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して リクエストをターゲットにルーティングします または ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます ターゲットグループでは 次のプロトコルとポートがサポートされています プロトコル : HTTP HTTPS ポート : 1 ~ ターゲットグループが HTTPS プロトコルを使用して設定されているか HTTPS ヘルスチェックを使用する場合 ターゲットへの SSL 接続には ELBSecurityPolicy ポリシーのセキュリティ設定が使用されます 48

54 ターゲットの種類 ターゲットの種類 ターゲットグループを作成するときは そのターゲットの種類を指定します ターゲットの種類は ターゲットの指定方法を決定します ターゲットグループを作成した後で ターゲットの種類を変更することはできません 可能なターゲットの種類は次のとおりです instance ip インスタンス ID で指定されたターゲット IP アドレスで指定されたターゲット ターゲットの種類が ip の場合 次のいずれかの CIDR ブロックから IP アドレスを指定できます ターゲットグループの VPC のサブネット /8 (RFC 1918) /10 (RFC 6598) /12 (RFC 1918) /16 (RFC 1918) これらのサポートされている CIDR ブロックを使用すると ClassicLink インスタンス ピアリング接続 VPC 内のインスタンス IP アドレスとポートでアドレス指定できる AWS リソース ( たとえば データベース ) AWS Direct Connect または VPN 接続を介して AWS にリンクされたオンプレミスリソースをターゲットグループに登録できます Important パブリックにルーティング可能な IP アドレスは指定できません インスタンス ID を使用してターゲットを指定すると トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して インスタンスにルーティングされます IP アドレスを使用してターゲットを指定する場合は 1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して トラフィックをインスタンスにルーティングできます これにより インスタンスの複数のアプリケーションが同じポートを使用できるようになります 各ネットワークインターフェイスは独自のセキュリティグループを持つことができます 登録済みターゲット ロードバランサーは クライアントにとって単一の通信先として機能し 正常な登録済みターゲットに受信トラフィックを分散します 各ターゲットは 1 つ以上のターゲットグループに登録できます 異なるポートを使用して 各 EC2 インスタンスまたは IP アドレスを同じターゲットグループに複数回登録できます これにより ロードバランサーはリクエストをマイクロサービスにルーティングできます アプリケーションの需要が高まった場合 需要に対処するため 1 つまたは複数のターゲットグループに追加のターゲットを登録できます 登録処理が完了し ターゲットが最初のヘルスチェックに合格するとすぐに ロードバランサーは新しく登録したターゲットへのリクエストのルーティングを開始します アプリケーションの需要が低下した場合や ターゲットを保守する必要がある場合 ターゲットグループからターゲットを登録解除することができます ターゲットを登録解除するとターゲットグループから削 49

55 ターゲットグループの属性 除されますが ターゲットにそれ以外の影響は及びません 登録解除するとすぐに ロードバランサーはターゲットへのリクエストのルーティングを停止します ターゲットは 未処理のリクエストが完了するまで draining 状態になります リクエストの受信を再開する準備ができると ターゲットをターゲットグループに再度登録することができます インスタンス ID でターゲットを登録する場合は Auto Scaling グループでロードバランサーを使用できます Auto Scaling グループにターゲットグループをアタッチすると ターゲットの起動時に Auto Scaling によりターゲットグループにターゲットが登録されます 詳細については Amazon EC2 Auto Scaling ユーザーガイドの Auto Scaling グループにロードバランサーをアタッチする を参照してください ターゲットグループの属性 ターゲットグループの属性は次のとおりです deregistration_delay.timeout_seconds ターゲットを登録解除する前に Elastic Load Balancing が待機する時間 範囲は 0~3600 秒です デフォルト値は 300 秒です slow_start.duration_seconds ロードバランサーが新しく登録されたターゲットに ターゲットグループに対するトラフィックのシェアを直線的に増加させて送信する期間 ( 秒 ) 範囲は 30~900 秒 (15 分 ) です デフォルトは 0 秒 ( 無効 ) です stickiness.enabled スティッキーセッションが有効かどうかを示します stickiness.lb_cookie.duration_seconds Cookie の有効期間 ( 秒単位 ) です この期間が過ぎると Cookie は古いと見なされます 最小値は 1 秒で 最大値は 7 日間 ( 秒 ) です デフォルト値は 1 日 (86400 秒 ) です stickiness.type 維持の種類です 有効な値は lb_cookie です 登録解除の遅延 Elastic Load Balancing は 登録解除するターゲットへのリクエストの送信を停止します デフォルトでは Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って ターゲットへ処理中のリクエストが完了するのを助けることができます Elastic Load Balancing が待機する時間を変更するには 登録解除の遅延値を更新します 登録解除するターゲットの初期状態は draining です 登録解除の遅延が経過すると 登録解除プロセスは完了し ターゲットの状態は unused になります ターゲットが Auto Scaling グループの一部である場合 ターゲットを終了して置き換えることができます 登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は Elastic Load Balancing は登録解除の遅延時間が経過するのを待たずに 即時登録解除プロセスを完了します ただし ターゲットの登録解除が完了しても ターゲットのステータスは 登録解除の遅延が経過するまで draining と表示されます 登録解除の遅延が経過する前に登録解除するターゲットが接続を終了すると クライアントは 500 レベルのエラー応答を受信します 50

56 スロースタートモード コンソールを使用して登録解除の遅延値を更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 現在の値が [ 説明 ] タブに [ 登録解除の遅延 ] として表示されます 4. [Description] タブで [Edit attributes] を選択します 5. [Edit attributes] ページで 必要に応じて [Deregistration delay] の値を変更し [Save] を選択します AWS CLI を使用して登録解除の遅延値を更新するには deregistration_delay.timeout_seconds 属性を指定して modify-target-group-attributes コマンドを使用します スロースタートモード デフォルトでは ターゲットはターゲットグループを使用して登録され初期ヘルスチェックを渡した後 すぐにリクエストの全シェアを受信し始めます スロースタートモードを使用すると ロードバランサーがターゲットにリクエストの全シェアを送信し始めるまでの猶予期間が設定されます ターゲットグループでスロースタートが有効化されると ターゲットはそのターゲットグループに登録されたときにスロースタートモードに入り 設定されたスロースタート期間が経過したときにスロースタートモードを終了します ロードバランサーは スロースタートモードのターゲットに送信できるリクエスト数を直線的に増加させます ターゲットがスロースタートモードを終了すると ロードバランサーはリクエストの全シェアを送信できます 考慮事項 ターゲットグループでスロースタートを有効にする場合 既にそのターゲットグループに登録済みのターゲットをスロースタートモードに入りません 空のターゲットグループでスロースタートを有効にし その後 単一登録オペレーションを使用して 1 つ以上のターゲットを登録すると それらのターゲットはスロースタートモードに入りません 新しく登録されたターゲットは スロースタートモードになっていない登録済みターゲットが 1 つ以上ある場合にのみスロースタートモードに入ります スロースタートモードのターゲットを登録解除すると そのターゲットはスロースタートモードを終了します 同じターゲットを再度登録すると 再度スロースタートモードに入ります スロースタートモードのターゲットに異常が発生してから 期間が経過する前に正常に戻った場合 そのターゲットはスロースタートモードを維持し 期間の残りが経過してからスロースタートモードを終了します スロースタートモードではないターゲットが異常な状態から正常に変わった場合は スロースタートモードに入りません コンソールを使用してスロースタート期間の値を更新するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 現在の値が [ 説明 ] タブに [ スロースタート期間 ] として表示されます 4. [Description] タブで [Edit attributes] を選択します 5. [ 属性の編集 ] ページで 必要に応じて [ スロースタート期間 ] の値を変更し [ 保存 ] を選択します スロースタートモードを無効にするには 期間を 0 に設定します AWS CLI を使用してスロースタート期間の値を更新するには 51

57 スティッキーセッション slow_start.duration_seconds 属性を指定して modify-target-group-attributes コマンドを使用します スティッキーセッション スティッキーセッションは ターゲットグループ内の同じターゲットにリクエストをルーティングするメカニズムです これは クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます スティッキーセッションを使用するには クライアントが Cookie をサポートしている必要があります ロードバランサーは クライアントから最初のリクエストを受信すると リクエストをターゲットにルーティングし クライアントへのレスポンスに含める Cookie を生成します そのクライアントからの次のリクエストには Cookie が含まれています スティッキーセッションがターゲットグループに対して有効であり リクエストが同じターゲットグループに送信される場合 ロードバランサーは Cookie を検出して同じターゲットにリクエストをルーティングします Application Load Balancer はロードバランサーによって生成されるクッキーのみをサポートします Cookie 名は AWSALB です このクッキーのコンテンツはローテーションキーを使用して暗号化されます ロードバランサーによって生成されたクッキーを複合あるいは編集することはできません WebSockets 接続は本来はスティッキーです クライアントが WebSockets へ接続アップグレードをリクエストする場合 接続アップグレードを受け入れるために HTTP 101 のステータスコードを返したターゲットが WebSockets 接続で使用されるターゲットです WebSockets のアップグレードが完了したら Cookie ベースの維持は使用されません ターゲットグループレベルでスティッキーセッションを有効にします ロードバランサー生成のクッキーの維持期間を秒単位で設定することもできます 期間はリクエストごとに設定されます そのため 各期間の有効期限が切れる前にクライアントがリクエストを送信すると スティッキセッションが継続されます 複数のターゲットグループのスティッキーセッションを有効にした場合 すべてのターゲットグループに同じ継続時間を設定することをお勧めします コンソールを使用してスティッキーセッションを有効にするには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 4. [Description] タブで [Edit attributes] を選択します 5. [Edit attributes] ページで 以下を実行します a. [Enable load balancer generated cookie stickiness] を選択します b. [Stickiness duration] で 1 秒から 7 日の間の値を指定します c. [Save] を選択します AWS CLI を使用してスティッキーセッションを有効にするには stickiness.enabled および stickiness.lb_cookie.duration_seconds 属性を指定して modifytarget-group-attributes コマンドを使用します ターゲットグループの作成 ターゲットグループにターゲットを登録します デフォルトでは ロードバランサーはターゲットグループに指定したポートとプロトコルを使用して登録済みターゲットにリクエストを送信します ターゲットグループに各ターゲットを登録するときに このポートを上書きできます 52

58 ヘルスチェックを設定する ターゲットグループを作成すると タグを追加できます ターゲットグループ内のターゲットにトラフィックをルーティングするには リスナーを作成するか リスナーのルールを作成するときに アクションでターゲットグループを指定します 詳細については リスナールール (p. 28) を参照してください ターゲットグループのタグはいつでも追加または削除できます 詳細については ターゲットグループへのターゲットの登録 (p. 56) を参照してください ターゲットグループのヘルスチェック設定を変更することもできます 詳細については ターゲットグループのヘルスチェック設定を変更する (p. 56) を参照してください コンソールを使用してターゲットグループを作成するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. [Create target group] を選択します 4. [Target group name] で ターゲットグループの名前を入力します 5. ( オプション ) [Protocol] と [Port] で 必要に応じてデフォルト値を変更します 6. [Target type] には instance を選択してインスタンス ID でターゲットを指定するか ip を選択して IP アドレスでターゲットを指定します 7. [VPC] で Virtual Private Cloud (VPC) を選択します 8. ( オプション ) [Health check settings] と [Advanced health check settings] で 必要に応じてデフォルト設定を変更します 9. [Create ( 作成 )] を選択します 10. ( オプション ) 次のように 1 つ以上のタグを追加します a. 新しく作成したターゲットグループを選択します b. [Tags] タブで [Add/Edit Tags] を選択します c. [Add/Edit Tags] ページで 追加したタグごとに [Create Tag] を選択し タグキーとタグの値を指定します タグの追加を完了したら [Save] を選択します 11. ( オプション ) ターゲットグループにターゲットを追加する方法については ターゲットグループへのターゲットの登録 (p. 56) を参照してください AWS CLI を使用してターゲットグループを作成するには ターゲットグループを作成するには create-target-group コマンド ターゲットグループにタグを付けるには add-tags コマンド ターゲットを追加するには register-targets コマンドを使用します ターゲットグループのヘルスチェック Application Load Balancer は ステータスをテストするため 登録されたターゲットに定期的にリクエストを送信します これらのテストは ヘルスチェックと呼ばれます 53

59 ヘルスチェックの設定 各ロードバランサーノードは ロードバランサーに対して有効になっているアベイラビリティーゾーンの正常なターゲットにのみ リクエストをルーティングします 各ロードバランサーノードは ターゲットが登録されているターゲットグループのヘルスチェック設定を使用して 各ターゲットの状態を確認します ターゲットは 登録後に正常と見なされるためには 1 つのヘルスチェックに合格する必要があります 各ヘルスチェックが完了すると ロードバランサーノードはヘルスチェック用に確立された接続を終了します 正常なターゲットが含まれているアベイラビリティーゾーンがない場合 ロードバランサーノードはすべてのターゲットにリクエストをルーティングします ヘルスチェックでは WebSocket はサポートされません ヘルスチェックの設定 次の設定を使用して ターゲットグループのターゲットのヘルスチェックを設定します ロードバランサーは 指定されたポート プロトコル および ping パスを使用して HealthCheckIntervalSeconds 秒ごとに 登録された各ターゲットにヘルスチェックリクエストを送信します 各ヘルスチェックリクエストは独立しており 間隔全体で存続します ターゲットが応答するまでにかかる時間は 次のヘルスチェックリクエストまでの間隔に影響を与えません ヘルスチェックが UnhealthyThresholdCount 連続失敗数のしきい値を超えると ロードバランサーはターゲットをサービス停止中の状態にします ヘルスチェックが HealthyThresholdCount 連続成功数のしきい値を超えると ロードバランサーはターゲットを実行中の状態に戻します 設定 HealthCheckProtocol HealthCheckPort HealthCheckPath HealthCheckTimeoutSeconds HealthCheckIntervalSeconds HealthyThresholdCount UnhealthyThresholdCount マッチャー 説明 ターゲットでヘルスチェックを実行するときにロードバランサーが使用するプロトコル 使用可能なプロトコルは HTTP および HTTPS です デフォルトは HTTP プロトコルです ターゲットでヘルスチェックを実行するときにロードバランサーが使用するポート デフォルトでは ターゲットがロードバランサーからトラフィックを受信するポートが使用されます ヘルスチェックのターゲットの送信先である ping パス デフォルトは / です ヘルスチェックを失敗と見なす ターゲットからレスポンスがない時間 ( 秒単位 ) 範囲は 2~3600 秒です デフォルト値は 5 秒です 個々のターゲットのヘルスチェックの概算間隔 ( 秒単位 ) 範囲は 5~300 秒です デフォルト値は 30 秒です 非正常なインスタンスが正常であると見なすまでに必要なヘルスチェックの連続成功回数 範囲は 2 ~10 です デフォルトは 5 です 非正常なインスタンスが非正常であると見なすまでに必要なヘルスチェックの連続失敗回数 範囲は 2~10 です デフォルトは 2 です ターゲットからの正常なレスポンスを確認するために使用する HTTP コード 200 ~ 499 で値または値の範囲を指定できます デフォルト値は 200 です 54

60 ターゲットヘルスステータス ターゲットヘルスステータス ロードバランサーがターゲットにヘルスチェックリクエストを送信する前に ターゲットグループに登録し リスナールールでターゲットグループを指定して ターゲットのアベイラビリティーゾーンがロードバランサーに対して有効になっていることを確認する必要があります ターゲットがロードバランサーからリクエストを受信する前に 最初のヘルスチェックに合格する必要があります ターゲットが最初のヘルスチェックに合格すると ステータスは Healthy になります 次の表は 登録されたターゲットのヘルスステータスの可能値を示しています 値 initial healthy unhealthy unused draining 説明 ロードバランサーは ターゲットを登録中か ターゲットで最初のヘルスチェックを実行中です ターゲットは正常です ターゲットはヘルスチェックに応答しなかったか ヘルスチェックに合格しませんでした ターゲットがターゲットグループに登録されていないか ターゲットグループがロードバランサーのリスナールールで使用されていません または ロードバランサーに対して有効ではないアベイラビリティーゾーンにターゲットがあります ターゲットは登録解除中で Connection Draining 中です ヘルスチェックの理由コード ターゲットのステータスが Healthy 以外の値の場合 API は問題の理由コードと説明を返し コンソールではツールヒントで同じ説明が表示されます Elb で始まる理由コードはロードバランサー側で発生し Target で始まる理由コードはターゲット側で発生します 理由コード Elb.InitialHealthChecking Elb.InternalError Elb.RegistrationInProgress 説明進行中の最初のヘルスチェック内部エラーのため ヘルスチェックが失敗しましたターゲットの登録中です Target.DeregistrationInProgress ターゲットの登録解除中です Target.FailedHealthChecks Target.InvalidState ヘルスチェックに失敗しました ターゲットが停止状態にあります ターゲットは終了状態にあります ターゲットは終了状態か または停止状態にあります ターゲットは無効な状態にあります Target.IpUnusable IP アドレスはロードバランサーによって使用されているので ターゲットとして使用できません 55

61 ターゲットのヘルスステータスをチェックする 理由コード Target.NotInUse 説明 ターゲットグループは ロードバランサーからトラフィックを受信するように設定されていません ロードバランサーが有効になっていないアベイラビリティーゾーンにターゲットがあります Target.NotRegistered Target.ResponseCodeMismatch Target.Timeout ターゲットはターゲットグループに登録されていません 次のコードでヘルスチェックに失敗しました : [code] リクエストがタイムアウトしました ターゲットのヘルスステータスをチェックする ターゲットグループに登録されたターゲットのヘルスステータスをチェックできます コンソールを使用してターゲットのヘルスステータスをチェックするには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 4. [Targets] タブの [Status] 列は 各ターゲットのステータスを示します 5. ステータスの値が Healthy 以外の場合は 詳細についてツールヒントを参照してください AWS CLI を使用してターゲットのヘルスステータスをチェックするには describe-target-health コマンドを使用します このコマンドの出力にはターゲットのヘルス状態が含まれます ステータスの値が Healthy 以外の場合は 理由コードも出力に含まれています ターゲットグループのヘルスチェック設定を変更する ターゲットグループのヘルスチェック設定はいつでも変更できます コンソールを使用してターゲットグループのヘルスチェック設定を変更するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 4. [Health checks] タブで [Edit] を選択します 5. [Edit target group] ページで 必要に応じて設定を変更し [Save] を選択します AWS CLI を使用してターゲットグループのヘルスチェック設定を変更するには modify-target-group コマンドを使用します ターゲットグループへのターゲットの登録 ターゲットグループにターゲットを登録します インスタンス ID または IP アドレスでターゲットを登録できます 詳細については Application Load Balancer のターゲットグループ (p. 48) を参照してください 56

62 ターゲットセキュリティグループ 現在登録されているターゲットの需要が上昇した場合 需要に対応するために追加ターゲットを登録できます ターゲットがリクエストを処理する準備ができたら ターゲットグループに登録します 登録処理が完了し ターゲットが最初のヘルスチェックに合格するとすぐに ロードバランサーはターゲットへのリクエストのルーティングを開始します 登録済みターゲットの需要が低下した場合や ターゲットを保守する必要がある場合 ターゲットグループから登録解除できます 登録解除するとすぐに ロードバランサーはターゲットへのリクエストのルーティングを停止します ターゲットがリクエストを受信する準備ができたら ターゲットグループに再度登録することができます ターゲットを登録解除すると ロードバランサーは未処理のリクエストが完了するまで待機します これは Connection Draining と呼ばれます Connection Draining の進行中 ターゲットのステータスは draining です IP アドレスで登録されたターゲットを登録解除する場合 同じ IP アドレスを再び登録するには 登録解除の遅延が完了するまで待機する必要があります インスタンス ID でターゲットを登録する場合は Auto Scaling グループでロードバランサーを使用できます Auto Scaling グループにターゲットグループを接続し そのグループがスケールアウトすると Auto Scaling グループによって起動されたインスタンスが自動的にターゲットグループに登録されます Auto Scaling グループからターゲットグループをデタッチした場合 インスタンスはターゲットグループから自動的に登録解除されます 詳細については Amazon EC2 Auto Scaling ユーザーガイドの Auto Scaling グループにロードバランサーをアタッチする を参照してください ターゲットセキュリティグループ EC2 インスタンスをターゲットとして登録した場合 インスタンスのセキュリティグループにより ロードバランサーがリスナーポートとヘルスチェックポートの両方でインスタンスとの通信が許可されるようにする必要があります 推奨ルール Inbound Source Port Range Comment リリリリリリリリリリリリリリリリリリリ リリリリリリリリリリリリリリリリリリリ リリリリリリリリリリ リリリリリリリ インスタンスリスナーポートでロードバランサーからのトラフィックを許可する ヘルスチェックポートでロードバランサーからのトラフィックを許可する また パス MTU 検出をサポートするため インバウンド ICMP トラフィックを許可することをお勧めします 詳細については Linux インスタンス用 Amazon EC2 ユーザーガイド の パス MTU 検出 を参照してください ターゲットの登録または登録解除 ターゲットグループを作成するときに インスタンス ID または IP アドレスでターゲットを登録する必要があるかどうかを指定します タスク インスタンス ID によるターゲットの登録または登録解除 (p. 58) IP アドレスによるターゲットの登録または登録解除 (p. 58) 57

63 ターゲットの登録または登録解除 インスタンス ID によるターゲットの登録または登録解除 インスタンスは ターゲットグループに指定された Virtual Private Cloud (VPC) に存在している必要があります また インスタンスの登録時の状態は running である必要があります コンソールを使用してターゲットをインスタンス ID で登録または登録解除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 4. [Targets] タブで [Edit] を選択します 5. インスタンスを登録するには [Instances] で選択し 必要に応じてデフォルトインスタンスポートを変更して [Add to registered] を選択します 6. インスタンスを登録解除するには [Registered instances] から選択して [Remove] を選択します 7. [Save] を選択します AWS CLI を使用してターゲットを登録または登録解除するには ターゲットを追加するには register-targets コマンドを使用し ターゲットを削除するには deregistertargets コマンドを使用します IP アドレスによるターゲットの登録または登録解除 登録する IP アドレスは ターゲットグループの VPC のサブネット RFC 1918 範囲 ( / /12 および /16) および RFC 6598 範囲 ( /10) である必要があります パブリックにルーティング可能な IP アドレスを登録することはできません コンソールを使用してターゲットを IP アドレスで登録または登録解除するには 1. にある Amazon EC2 コンソールを開きます 2. ナビゲーションペインの [LOAD BALANCING] で [Target Groups] を選択します 3. ターゲットグループを選択します 4. [Targets] タブで [Edit] を選択します 58

64 タグの更新 5. IP アドレスを登録するには メニューバーの [Register targets] アイコン ( プラス記号 ) を選択します 各 IP アドレスに対して ネットワークを選択して IP アドレスやポートを入力し [Add to list ( リストに追加 )] を選択します アドレスの指定が終了したら [Register] を選択します 6. IP アドレスを登録解除するには メニューバーの [Deregister targets] アイコン ( マイナス記号 ) を選択します 登録済みの IP アドレスが多い場合は フィルタを追加したりソート順を変更したりすると便利です IP アドレスを選択し [Deregister] を選択します 7. この画面から抜けるには メニューバーの [Back to target group] ( 戻るボタン ) を選択します AWS CLI を使用してターゲットを登録または登録解除するには ターゲットを追加するには register-targets コマンドを使用し ターゲットを削除するには deregistertargets コマンドを使用します ターゲットグループのタグ タグを使用すると ターゲットグループを目的 所有者 環境などさまざまな方法で分類することができます 各ターゲットグループに対して複数のタグを追加できます タグキーは 各ターゲットグループで一意である必要があります すでにターゲットグループに関連付けられているキーを持つタグを追加すると そのキーの値が更新されます 不要になったタグは 削除することができます 制限 リソースあたりのタグの最大数 50 キーの最大長 127 文字 (Unicode) 59