Elastic Load Balancing のよくある質問

Application Load Balancer では、現在 Amazon EC2 サービスでサポートされているすべてのオペレーティングシステムでターゲットをサポートしています。

Application Load Balancer では、HTTP および HTTPS (セキュア HTTP) プロトコルを使用するアプリケーションの負荷分散をサポートしています。

はい。Application Load Balancer では HTTP/2 のネイティブなサポートが有効です。HTTP/2 をサポートするクライアントは TLS 経由で Application Load Balancer に接続できます。

PrivateLink とアベイラビリティーゾーンごとの静的 IP アドレスをサポートしている Network Load Balancer から Application Load Balancer にトラフィックを転送することができます。Application Load Balancer タイプのターゲットグループを作成し、そこに Application Load Balancer を登録し、Application Load Balancer タイプのターゲットグループにトラフィックを転送するように Network Load Balancer を設定します。

以下の TCP ポートの負荷分散を実行できます。1-65535

はい。WebSocket およびセキュア WebSocket はネイティブにサポートされており、Application Load Balancer で使用可能です。

はい。Application Load Balancer では、デフォルトでリクエストトレーシングは有効になっています。

重複している点はありますが、これらのロードバランサーの機能は同等です。Application Load Balancer は、将来のアプリケーションレイヤーロードバランシングプラットフォームの基礎となるものです。

はい。

はい。

いいえ、Application Load Balancer には、新しいアプリケーションプログラミングインターフェイス (API) が必要です。

ELB コンソールを使用すると、同じインターフェイスから Application Load Balancer と Classic Load Balancer の両方を管理できます。コマンドラインインターフェイス (CLI) やソフトウェア開発キット (SDK) を使用している場合は、Application Load Balancer には異なる「サービス」を使用します。例えば CLI では、Classic Load Balancer には `aws elb describe-load-balancers` を使用し、Application Load Balancer には `aws elbv2 describe-load-balancers` を使用して記述します。

いいえ。ロードバランサーのタイプは別のタイプに変換できません。

はい。Classic Load Balancer から Application Load Balancer に移行するには、このドキュメントにあるいずれかのオプションを使用します。

レイヤー 4 の機能が必要な場合は、Network Load Balancer を使用してください。

はい。単一の Application Load Balancer に HTTP ポート 80 および HTTPS ポート 443 用のリスナーを追加できます。

はい。アカウントで実行した Application Load Balancer API コールの履歴を取得するには、AWS CloudTrail を使用します。

はい。Application Load Balancer で HTTPS 接続を終了できます。ロードバランサーに Secure Sockets Layer (SSL) 証明書をインストールする必要があります。ターゲットにリクエストを送信する前に、ロードバランサーはこの証明書を使用して接続を終了し、クライアントからのリクエストを復号します。

AWS Certificate Manager を使用して SSL/TLS 証明書をプロビジョンできます。または、証明書リクエストを作成して他のソースから証明書を取得し、証明書リクエストに CA の署名を受けてから、AWS Certification Manager と AWS Identity and Access Management (IAM) のいずれかのサービスを使用して証明書をアップロードすることもできます。

Application Load Balancer は AWS Certificate Manager (ACM) と統合されています。ACM との統合により、ロードバランサーへの証明書のバインドがシンプルになり、SSL オフロードプロセス全体も簡単になりました。SSL/TLS 証明書の購入、アップロード、および更新は複雑な、手作業による時間のかかるプロセスです。ACM が Application Load Balancer と統合されることでプロセス全体が短縮され、信頼できる SSL/TLS 証明書をリクエストし、ACM 証明書を選択してロードバランサーにプロビジョニングするというシンプルなものになりました。

いいえ。Application Load Balancer ではバックエンドへの暗号化のみサポートされています。

SNI は、複数の TLS 証明書をロードバランサーの同一のセキュアリスナーに関連付けると、自動的に有効になります。同様に、セキュアリスナーに関連付けられた証明書が 1 つのみになると、セキュアリスナーの SNI モードは自動的に無効になります。

はい。同じドメインの複数の証明書を 1 つのセキュアリスナーに関連付けることが可能です。たとえば、以下を関連付けることができます。

• ECDSA 証明書、RSA 証明書
• SSL/TLS 証明書用の異なるキーサイズ (2K や 4K など) の証明書
• シングルドメイン証明書、マルチドメイン (SAN) 証明書、ワイルドカード証明書

はい。IPv6 は Application Load Balancer でサポートされています。

ロードバランサーの各リスナーのルールを設定できます。ルールには、条件と、条件が満たされている場合の対応するアクションが含まれています。サポートされている条件は、Host ヘッダー、パス、HTTP ヘッダー、メソッド、クエリパラメータ、ソース IP クラスレスドメイン間ルーティング (CIDR) です。サポートされているアクションは、リダイレクト、固定レスポンス、認証、転送です。一度設定すると、ロードバランサーはこのルールを使用して、特定の HTTP リクエストをどのようにルーティングすべきか決定します。1 つのルールで複数の条件とアクションを使用でき、各条件で複数の値に対する一致を指定することができます。

AWS アカウントには、Application Load Balancer のこれらの制限があります。

Application Load Balancer を AWS ウェブアプリケーションファイアウォール (WAF) と統合すると、IP アドレス、HTTP ヘッダー、および独自ユニフォームリソース識別子 (URI) 文字列に基づいてルールを設定して、ウェブアプリケーションを攻撃から守ることができます。AWS WAF では、これらのルールを使用して、ウェブアプリケーションに対するウェブリクエストをブロック、許可または監視 (カウント) できます。詳細については、AWS WAF デベロッパーガイドをご覧ください。

ロードバランサーの VPC CIDR の任意の IP アドレスをロードバランサーの VPC 内のターゲットとして使用できます。また、RFC 1918 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) または RFC 6598 範囲 (100.64.0.0/10) の IP アドレスをロードバランサーの VPC 外のターゲットとして使用できます (例えば、ピアリング接続された VPC、Amazon EC2 Classic、AWS Direct Connect または VPN 接続によって到達可能なオンプレミスのロケーションのターゲットなど)。

ハイブリッド負荷分散を達成するにはさまざまな方法があります。VPC およびオンプレミスのロケーションにかけて分散されたターゲットでアプリケーションが実行されている場合は、IP アドレスを使用して同じターゲットグループに追加できます。アプリケーションに影響を与えずに AWS に移行するには、徐々に VPC のターゲットをターゲットグループに加え、オンプレミスのターゲットをターゲットグループから削除します。 

2 つの異なるアプリケーションがあり、1 つのアプリケーションのターゲットは VPC に、別のアプリケーションのターゲットはオンプレミスのロケーションにある場合は、VPC のターゲットに 1 つのターゲットグループを、オンプレミスのターゲットに別のターゲットグループを設定し、コンテンツベースのルーティングを使用して各ターゲットグループにトラフィックをルーティングできます。また、VPC とオンプレミスのターゲットに異なるロードバランサーを使用し、DNS 重み付けを使用して、VPC とオンプレミスのターゲット間で重み付け負荷分散を達成することもできます。

インスタンス ID をターゲットとして登録している場合、EC2-Classic インスタンスに負荷を分散することはできません。ただし、ClassicLink を使用してこれらの EC2-Classic インスタンスをロードバランサーの VPC にリンクさせ、これらの EC2-Classic インスタンスのプライベート IP をターゲットとして使用すれば、EC2-Classic インスタンスに負荷を分散できます。現在 EC2-Classic インスタンス と Classic Load Balancer を使用している場合は、簡単に Application Load Balancer に移行できます。

クロスゾーン負荷分散は、Application Load Balancer ではデフォルトですでに有効になっています。

Amazon Cognito での認証は次の場合にお使いください:

• a. ユーザーに、ソーシャルネットワークのアイデンティティ (Google、Facebook、Amazon) で、エンタープライズのアイデンティティ (SAML) で、または Amazon Cognito のユーザープールの、お客様自身のユーザーディレクトリで認証するという柔軟性を与えたい場合。
• OpenID Connect を含む複数の ID プロバイダーを管理しており、Amazon Cognito を使える Application Load Balancer (ALB) 内のひとつの認証ルールを作成して複数の ID プロバイダーをフェデレーションする場合。
• c. ひとつ以上のソーシャルまたはひとつの中央の場所からの OpenID Connect ID プロバイダーでアクティブにユーザープロファイルを管理する必要がある場合。例えば、ユーザーをグループに入れて、カスタム属性の追加をしてユーザーのステータスを表し、支払いをしたユーザーのアクセスをコントロールできます。

別の方法としては、すでにカスタム IdP ソリューションに投資をしていて、単一の OpenID Connect に準拠した ID プロバイダで認証したいだけならば、Application Load Balancer のネイティブな OIDC ソリューションを使う方が良いかもしれません。

次の 3 つのタイプのリダイレクトをサポートしています。

HTTP から HTTP
http://hostA to http://hostB

HTTP から HTTPS
http://hostA to https://hostB
https://hostA:portA/pathA から https://hostB:portB/pathB

HTTPS から HTTPS
https://hostA to https://hostB

次のコンテンツタイプをサポートしています: text/plain、text/css、text/html、application/javascript、application/json。

ロードバランサーに送信される HTTP(S) リクエストは、内容に基づくルーティングルールによって処理されます。リクエストの内容が、Lambda 関数を介してターゲットとしてターゲットグループに転送するアクションを持つルールと一致する場合は、対応する Lambda 関数が呼び出されます。リクエストの内容 (ヘッダーと本文を含む) は、JavaScript Object Notation (JSON) 形式で Lambda 関数に渡されます。Lambda 関数からのレスポンスは、JSON 形式である必要があります。Lambda 関数からの応答は HTTP レスポンスに変換され、クライアントに送信されます。ロードバランサーは、AWS Lambda Invoke API を使用して Lambda 関数を呼び出すため、Lambda 関数の呼び出しアクセス許可を Elastic Load Balancing サービスに付与する必要があります。

はい。Application Load Balancer では、Lambda 呼び出しでリクエストする際、HTTP プロトコルと HTTPS プロトコルのいずれも使用することができます。

米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ)、GovCloud (米国西部) の AWS リージョンでは、Application Load Balancer でターゲットとして Lambda を使用できます。

はい、Application Load Balancer はロサンゼルスのローカルゾーンで使用できます。ロサンゼルスのローカルゾーン内では、Application Load Balancer は単一のサブネット内で動作し、アプリケーションの負荷レベルが変化すると、人手による介入がなくても、それを満たすよう自動的にスケーリングします。

Application Load Balancer が実行される時間に対して 1 時間単位または 1 時間未満で、また時間ごとのロードバランサーキャパシティーユニット (LCU) 使用量で課金されます。

LCU は、Application Load Balancer の支払方法を決定するための新しいメトリクスです。LCU は、Application Load Balancer でトラフィックを処理するいずれかのディメンション (新しい接続、アクティブ接続、帯域幅、ルール評価) のうち消費量が最大のリソースを定義します。

いいえ。Classic Load Balancer は、引き続き帯域幅および時間単位の使用量に対して課金されます。

Amazon CloudWatch によって LCU を構成する 4 つのディメンションの使用状況が示されます。

時間ごとの LCU 数は、LCU を構成する 4 つのディメンションで消費量が最大のリソースに基づいて決定されます。

はい。

はい。新規の AWS アカウントの無料利用枠では、Application Load Balancer を 750 時間分および 15 LCU ご利用いただけます。この無料利用枠は、AWS の新規のお客様のみが対象であり、AWS にサインアップした日から 12 か月間ご利用いただけます。

はい。Classic Load Balancer を 15 GB、および Application Load Balancer を 15 LCU ずつご利用いただけます。750 ロードバランサー時間分は Classic Load Balancer および Application Load Balancer 間で共有されます。

ルール評価は、処理されたルールの数と 1 時間あたりの平均リクエストレートの積で定義されます。

証明書のキーサイズは、請求のための LCU の計算では 1 秒あたりの新しい接続数にのみ影響します。以下の表は、RSA 証明書と ECDSA 証明書の異なるキーサイズでのディメンションの値を示しています。

RSA 証明書
キーサイズ: <=2K 
新しい接続/秒: 25

キーサイズ: <=4K 
新しい接続/秒: 5

キーサイズ: <=8K 
新しい接続/秒: 1

キーサイズ: >8K
新しい接続/秒: 0.25

ECDSA 証明書
キーサイズ: <=256
新しい接続/秒: 25

キーサイズ: <=384
新しい接続/秒: 5

キーサイズ: <=521 
新しい接続/秒: 1

キーサイズ: >521 
新しい接続/秒: 0.25

いいえ。クロスゾーン負荷分散は Application Load Balancer では常に有効であるため、この種類のリージョンデータ転送には料金はかかりません。

いいえ、Application Load Balancer での認証機能を有効にするための別個の料金はありません。Amazon Cognito を Application Load Balancer と共に使う場合、Amazon Cognito の料金が適用されます。

Application Load Balancer が実行される時間に対して、通常どおり 1 時間単位または 1 時間未満で、また時間ごとのロードバランサーキャパシティーユニット (LCU) 使用量で請求されます。Lambda ターゲットでは、LCU ごとに 1 時間あたり 0.4 GB の処理バイト、1 秒間に 25 回の新規接続、1 分間に 3,000 回のアクティブ接続、1 秒あたり 1,000 回のルール評価を使用できます。処理されたバイトのディメンションでは、LCU ごとに、Lambda ターゲットでは 1 時間あたり 0.4 GB と、その他すべてのタイプ (Amazon EC2 インスタンス、コンテナ、IP アドレス) では 1 時間あたり 1 GB 使用できます。Application Load Balancer による Lambda 呼び出しに対しては、通常の AWS Lambda 料金が適用されます。

Application Load Balancer では、2 つの新しい CloudWatch メトリクスが出力されます。LambdaTargetProcessedBytes メトリクスは、Lambda ターゲットによって処理されるバイト、StandardProcessedBytes メトリクスは、他のすべてのターゲットタイプによって処理されるバイトを示します。

はい。Network Load Balancer は、TCP、UDP、TCP+UDP (レイヤー 4) リスナーおよび TLS リスナーの両方をサポートしています。

Network Load Balancer では、TCP と UDP (レイヤー 4) の両方の負荷分散を利用できます。秒あたり数百万のリクエストや、突発的で変動しやすいトラフィックパターンに対応できるように設計されており、レイテンシーも非常に低くなっています。さらに Network Load Balancer では、TLS 終了をサポートし、クライアントのソース IP を保持して、安定した IP サポートとゾーンごとのアイソレーションを提供します。WebSocket タイプのアプリケーションに有用な、長期間の接続もサポートしています。

はい。これを実現するために、TCP + UDP リスナーを使用することができます。たとえば、TCP と UDP の両方を使用する DNS サービスでは、ポート 53 に TCP + UDP リスナーを作成することができます。ロードバランサーは、当該ポートの UDP リクエストと TCP リクエスト両方のトラフィックを処理します。TCP + UDP リスナーを TCP + UDP ターゲットグループに関連付ける必要があります。

Network Load Balancer では、クライアントの送信元 IP が保持されますが、これは Classic Load Balancer では保持されません。Classic Load Balancer では、プロキシプロトコルを使用して送信元 IP を取得できます。Network Load Balancer は、アベイラビリティーゾーン (AZ) ごとに 1 つの静的 IP を自動的にロードバランサーに提供します。また、AZ ごとのロードバランサーに Elastic IP を割り当てることもできます。これは Classic Load Balancer ではサポートされていません。

はい。Classic Load Balancer から Network Load Balancer に移行するには、このドキュメントにあるオプションのうち 1 つを用いて移行できます。

はい。詳細については、Network Load Balancer の制限のドキュメントを参照してください。

はい。Network Load Balancer は、AWS マネジメントコンソール、AWS CLI、API のいずれかを使用して設定できます。

Classic Load Balancer を作成するには、2012-06-01 API を使用します。Network Load Balancer または Application Load Balancer を作成するには、2015-12-01 API を使用します。

はい。ロードバランサーの作成時にサブネットを 1 つ指定することにより、単一の AZ に Network Load Balancer を作成できます。

はい。Amazon Route 53 のヘルスチェックと DNS フェイルオーバーの特徴を使用して、Network Load Balancer で稼働するアプリケーションのアベイラビリティーを向上させることができます。Route 53 DNS フェイルオーバーを使用することで、複数の AWS アベイラビリティーゾーンでアプリケーションを稼働し、リージョンからリージョンにフェイルオーバーするための代替ロードバランサーを指定できます。 

Network Load Balancer をマルチ AZ 用に構成しているイベントでは、その AZ のロードバランサーに登録されている正常な Amazon EC2 インスタンスがない場合、または特定のゾーン内のロードバランサーノードが正常でない場合、Route 53 がフェイルして他の正常な AZ の代替ロードバランサーノードに切り替わります。

Network Load Balancer のアドレスは、ユーザーまたは ELB によって、完全に制御される必要があります。これは、Network Load Balancer で Elastic IP を使用する場合に、クライアントで把握しているすべてのアドレスが変わらないようにするためです。

いいえ、Network Load Balancer は、関連付けられている各サブネットに対して、1 つのパブリック/インターネット向け IP アドレスしかサポートできません。

ロードバランサーと関連付けられていた Elastic IP アドレスは、割り当てられているプールに戻り、後で再利用できます。

Network Load Balancer は、Application Load Balancer や Classic Load Balancer と同様に、インターネット向けロードバランサーまたは内部ロードバランサーとして設定できます。

Network Load Balancer は、ロードバランサーが含まれる各関連サブネットに対して、1 つのプライベート IP しかサポートできません。

はい。WebSocket プロトコル (https://tools.ietf.org/html/rfc6455) を実装するターゲットにトラフィックをルーティングするように、TCP リスナーを構成してください。WebSocket はレイヤー 7 のプロトコルで、Network Load Balancer はレイヤー 4 で動作するため、WebSocket などの上位レベルのプロトコルを処理する特殊な機能は Network Load Balancer には存在しません。

はい。ロードバランサーの VPC CIDR の任意の IP アドレスを、ロードバランサーの VPC 内のターゲットとして使用できます。また、RFC 1918 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) または RFC 6598 範囲 (100.64.0.0/10) の IP アドレスを、ロードバランサーの VPC 外のターゲットとして使用できます (EC2-Classic、AWS Direct Connect によって到達可能なオンプレミスのロケーションなど)。IP アドレスターゲットタイプへの負荷分散は、TCP リスナーでのみサポートされており、UDP リスナーでは、現在サポートされていません。

はい。TCP および TLS リスナーを使用する Network Load Balancer を使用して、AWS PrivateLink を設定できます。Network Load Balancer の UDP リスナーを使用して PrivateLink を設定することはできません。

ユーザーデータグラムプロトコル (UDP) はコネクションレスですが、ロードバランサーは 5 タプルハッシュに基づいて UDP フローの状態を維持し、同じコンテキストで送信されたパケットが一貫して同じターゲットに転送されるようにしています。トラフィックが流れていれば、アイドルタイムアウトに達するまでフローはアクティブであるとみなされます。タイムアウトのしきい値に達するとロードバランサーはアフィニティを保持しないため、着信 UDP パケットは新しいフローと見なされ、新しいターゲットに負荷分散されます。

TCP 接続の Network Load Balancer のアイドルタイムアウトは 350 秒です。UDP フローのアイドルタイムアウトは 120 秒です。

インスタンスの各コンテナに独自のセキュリティグループを設定でき、別のコンテナとセキュリティのルールを共有する必要がなくなります。セキュリティグループを ENI にアタッチすることで、インスタンスの各 ENI に異なるセキュリティグループを設定できます。特定の ENI の IP アドレスにコンテナをマッピングすることで、コンテナごとにセキュリティグループを関連付けることができます。また、IP アドレスを使用して負荷分散することで、1 つのインスタンスで実行される複数のコンテナで同じポート (ポート 80 など) を使用できます。複数のコンテナで同じポートを使用することで、1 つのインスタンスのコンテナ間で、ランダムのポートではなくよく知られたポートで互いに通信できます。

ハイブリッド負荷分散を達成するにはさまざまな方法があります。VPC およびオンプレミスのロケーションにかけて分散されたターゲットでアプリケーションが実行されている場合は、IP アドレスを使用して同じターゲットグループに追加できます。アプリケーションに影響を与えずに AWS に移行するには、徐々に VPC のターゲットをターゲットグループに加え、オンプレミスのターゲットをターゲットグループから削除します。また、VPC とオンプレミスのターゲットに異なるロードバランサーを使用し、DNS 重み付けを使用して、VPC とオンプレミスのターゲット間で重み付け負荷分散を達成することもできます。

インスタンス ID をターゲットとして登録している場合、EC2-Classic インスタンスに負荷を分散することはできません。ただし、ClassicLink を使用してこれらの EC2-Classic インスタンスをロードバランサーの VPC にリンクさせ、これらの EC2-Classic インスタンスのプライベート IP をターゲットとして使用すれば、EC2-Classic インスタンスに負荷を分散できます。現在 EC2-Classic インスタンスと Classic Load Balancer を使用している場合は、簡単に Network Load Balancer に移行できます。

クロスゾーン負荷分散は、Network Load Balancer を作成後にのみ有効にできます。これを行うには、負荷分散属性を編集し、次いでクロスゾーン負荷分散サポートのチェックボックスにチェックを入れます。

はい、クロスゾーン負荷分散を有効にすると、Network Load Balancer でのアベイラビリティーゾーン間のリージョンデータ転送には料金が発生します。料金は、Amazon EC2 オンデマンド料金表のページのデータ転送セクションを参照してください。

はい。Network Load Balancer は現在アベイラビリティーゾーンごとに 200 個のターゲットをサポートしています。例えば、2 つの AZ にある場合、Network Load Balancer では最大 400 個のターゲットを登録できます。クロスゾーン負荷分散がオンの場合、AZ ごとに最大 200 個のターゲット数は、ロードバランサーごとに 200 個に減ります。つまり上の例では、クロスゾーン負荷分散がオンの場合、お使いのロードバランサーが 2 つの AZ にあるにもかかわらず、ロードバランサーに登録できるターゲット数は 200 に制限されます。

はい、Network Load Balancer で TLS 接続を終了することができます。ロードバランサーには SSL 証明書をインストールする必要があります。ターゲットにリクエストを送信する前に、ロードバランサーはこの証明書を使用して接続を終了し、クライアントからのリクエストを復号します。

Network Load Balancer で TLS を終了しても、送信元 IP は保持され続けます。

AWS Certificate Manager を使用して SSL/TLS 証明書をプロビジョンできます。または、証明書リクエストを作成して他のソースから証明書を取得し、証明書リクエストに証明書機関 (CA) の署名を受けてから、AWS Certification Manager (ACM) と AWS Identity and Access Management (IAM) のいずれかのサービスを使用して証明書をアップロードすることもできます。

SNI は、複数の TLS 証明書をロードバランサーの同一のセキュアリスナーに関連付けると、自動的に有効になります。同様に、セキュアリスナーに関連付けられた証明書が 1 つのみになると、セキュアリスナーの SNI モードは自動的に無効になります。

Network Load Balancer は AWS Certificate Manager (ACM) と統合されています。ACM との統合により、証明書のロードバランサーへのバインドが非常にシンプルになり、SSL オフロードプロセス全体も簡単になりました。SSL/TLS 証明書の購入、アップロード、および更新は時間のかかる、手作業による複雑なプロセスです。ACM が Network Load Balancer と統合されることで、プロセス全体が短縮され、信頼できる SSL/TLS 証明書をリクエストし、ACM 証明書を選択して、ロードバランサーにプロビジョニングするというシンプルなものになりました。Network Load balancer を作成すると、まずはTLS リスナーを構成してから、ACM または Identity Access Manager (IAM) のどちらから証明書を選択できます。この経験は、Application Load Balancer または Classic Load Balancer で得られるものと似ています。

いいえ。Network Load Balancer ではバックエンドへの暗号化のみサポートされています。

Network Load Balancer は、キーサイズが 2K の RSA 証明書のみをサポートしています。現在、Network Load Balancer では、キーサイ ズ 2K を超える RSA 証明書や ECDSA 証明書はサポートされていません。

米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ)、GovCloud (米国西部) の AWS リージョンでは、Network Load Balancer で TLS ターミネーションを使用できます。

Network Load Balancer が実行される時間に対して 1 時間単位または 1 時間未満で、また時間ごとのロードバランサーキャパシティーユニット (LCU) 使用量で課金されます。

LCU は、Network Load Balancer の支払方法を決定するための新しいメトリクスです。LCU は、Network Load Balancer でトラフィックを処理するいずれかのディメンション (新規接続/フロー、アクティブ接続/フロー、および帯域幅) のうち消費量が最大のリソースを定義します。

TCP トラフィックの LCU メトリクスは、次のとおりです。

• 1 秒あたり 800 個の新しい TCP 接続。
• 100,000 個のアクティブ TCP 接続 (1 分あたりのサンプル)。
• ターゲットとしての Amazon EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。

UDP トラフィックの LCU メトリクスは、次のとおりです。

• 1 秒あたり 400 個の新しいフロー。
• 50,000 個のアクティブ UDP フロー (1 分あたりのサンプル)。
• ターゲットとしての Amazon EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。

TLS トラフィックの LCU メトリクスは、次のとおりです。

• 1 秒あたり 50 個の新しい TLS 接続。
• 3,000 個のアクティブ TLS 接続 (1 分あたりのサンプル)。
• ターゲットとしての Amazon EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。

いいえ。各プロトコルについて、3 つのディメンションのうちの 1 つに対してのみ課金されます (1 時間の使用量が最も多いもの)。

1 つの接続で複数のリクエストを送信できます。

いいえ。Classic Load Balancer は、引き続き帯域幅および時間単位の使用量に対して課金されます。

LCU を構成する 3 つのすべてのディメンションの使用量を Amazon CloudWatch 経由で公開します。

時間ごとの LCU 数は、LCU を構成する 3 つのディメンションで消費量が最大のリソースに基づいて決定されます。

はい。

はい。新規の AWS アカウントの無料利用枠では、Network Load Balancer を 750 時間分および 15 LCU ご利用いただけます。この無料利用枠は、AWS の新規のお客様のみが対象であり、AWS にサインアップした日から 12 か月間ご利用いただけます。

はい。Application Load Balancer と Network Load Balancer は 15 LCU ずつご利用いただけます。Classic Load Balancer は 15 GB ご利用いただけます。750 ロードバランサー時間分は Application Load Balancer、Network Load Balancer、および Classic Load Balancer 間で共有されます。

ネットワークトラフィックが Gateway Load Balancer 自体に送信されないインライン仮想アプライアンスをデプロイする場合は、Gateway Load Balancer を使用する必要があります。Gateway Load Balancer は、すべてのレイヤー 3 トラフィックをサードパーティーの仮想アプライアンスに透過的に渡すため、トラフィックの送信元と送信先からは見えません。これらのロードバランサーの比較方法については、「機能の比較」ページを参照してください。

Gateway Load Balancer は、1 つの AZ 内で実行されます。

Gateway Load Balancer は、レイヤー 3 のゲートウェイ機能とレイヤー 4 の負荷分散機能の両方を備えています。パケットのどの部分も変更しない、トランスペアレントなバンプインザワイヤー・デバイスです。秒あたり数百万のリクエストや、変動しやすいトラフィックパターンを処理できるように設計されており、極めて低いレイテンシーを実現しています。この表で、Gateway Load Balancer の機能をご覧ください。 

Gateway Load Balancer は TLS ターミネーションを実行せず、アプリケーションの状態を維持しません。これらの機能は、トラフィックを転送したり、トラフィックを受信したりするサードパーティーの仮想アプライアンスによって実行されます。

Gateway Load Balancer はアプリケーションの状態を維持しませんが、5 タプル (TCP/UDP フローの場合) または 3 タプル (非 TCP/UDP フローの場合) を使用して特定のアプライアンスへのフローの持続性を維持します。

デフォルトでは、Gateway Load Balancer は、送信元 IP、送信先 IP、IP プロトコル、送信元ポート、送信先ポートの 5 タプルの組み合わせをフローと定義しています。Gateway Load Balancer は、デフォルトの 5 タプルのハッシュを用いて、フローの両方向 (すなわち、送信元から送信先、送信先から送信元) が一貫して同じターゲットに転送されるようにします。トラフィックが流れていれば、アイドルタイムアウトに達するまでフローはアクティブであるとみなされます。タイムアウトのしきい値に達するとロードバランサーはアフィニティを保持しないため、着信トラフィック パケットは新しいフローと見なされ、新しいターゲットに負荷分散される可能性があります。

デフォルトの 5 タプル (送信元 IP、宛先 IP、IP プロトコル、送信元ポート、送信元ポート、および宛先ポート) スティッキネスは、ターゲットへの最適なトラフィック分散を実現し、一部の例外を除いて、ほとんどの TCP および UDP ベースのアプリケーションに適しています。デフォルトの 5 タプルのスティッキネスは、FTP、Microsoft RDP、Windows RPC、SSL VPN など、制御とデータに別々のストリームやポート番号を使用する TCP や UDP ベースのアプリケーションには適していません。このようなアプリケーションの制御やデータの流れは、異なるターゲットのアプライアンスに着地する可能性があり、トラフィックの混乱を引き起こす可能性があります。このようなプロトコルに対応したい場合は、3 タプル (送信元 IP、送信先 IP、IP プロトコル) または 2 タプル (送信元 IP、送信先 IP) を用いて GWLB フローの持続性を有効にする必要があります。

一部のアプリケーションでは、TCP または UDP トランスポートをまったく使用せず、代わりに SCTP や GRE などの IP プロトコルを使用します。GWLB のデフォルトの 5 タプルのスティッキネスでは、これらのプロトコルからのトラフィックフローがさまざまなターゲットアプライアンスに届き、中断が発生する可能性があります。このようなプロトコルに対応したい場合は、3 タプル (送信元 IP、送信先 IP、IP プロトコル) または 2 タプル (送信元 IP、送信先 IP) を用いて GWLB フローの持続性を有効にする必要があります。

フローの持続性の種類を変更する方法については、「フローの持続性のドキュメント」を参照してください。

TCP 接続の Gateway Load Balancer のアイドルタイムアウトは 350 秒です。非 TCP フローのアイドルタイムアウトは 120 秒です。これらのタイムアウトは固定されており、変更することはできません。

GWLB 自体は透過的なバンプ・イン・ザ・ワイヤーなので、パケットのフラグメント化や再構成は行いません。

GWLB は UDP フラグメントをターゲットアプライアンスへ、またはターゲットアプライアンスから転送します。ただし、GWLB は TCP フラグメントと ICMP フラグメントをドロップします。これは、レイヤ 4 ヘッダーがこれらのフラグメントに存在しないためです。

さらに、ターゲットアプライアンスが元の受信パケットをフラグメントに変換し、新しく作成されたフラグメントをGWLBに送り返す場合、GWLBはこれらの新しく作成されたフラグメントをドロップします。これらのフラグメントにはレイヤー4ヘッダーが含まれていないためです。ターゲットアプライアンスでフラグメンテーションが発生するのを防ぐには、ターゲットアプライアンスでジャンボフレームを有効にするか、ターゲットアプライアンスのネットワークインターフェイスで必要な最大 MTU を使用するように設定することをお勧めします。これにより、元のパケットの内容をそのまま保持することで透過的な転送動作を実現できます。 

単一の仮想アプライアンスインスタンスに障害が発生すると、Gateway Load Balancer はそれをルーティングリストから削除し、トラフィックを正常なアプライアンスインスタンスに再ルーティングします。

アベイラビリティーゾーン内のすべての仮想アプライアンスに障害が発生した場合、Gateway Load Balancer はネットワークトラフィックをドロップします。可用性を高めるために、Gateway Load Balancer を複数の AZ にデプロイすることをお勧めします。1 つの AZ ですべてのアプライアンスに障害が発生した場合、スクリプトを使用して新しいアプライアンスを追加するか、別の AZ の Gateway Load Balancer にトラフィックを転送できます。

はい、複数の Gateway Load Balancer が同じ仮想アプライアンスのセットを指すことができます。

Gateway Load Balancer はトランスペアレントなバンプインザワイヤーデバイスで、あらゆる種類の IP トラフィック (TCP、UDP、ICMP、GRE、ESP など) をリッスンします。そのため Gateway Load Balancer には IP リスナーのみを作成します。

はい。詳細については、Gateway Load Balancer の制限のドキュメントを参照してください。

はい。Gateway Load Balancer は、AWS マネジメントコンソール、AWS CLI、API のいずれかを使用して設定できます。

はい。ロードバランサーの作成時にサブネットを 1 つ指定することにより、単一のアベイラビリティーゾーンに Gateway Load Balancer を作成できます。しかし可用性を高めるためには、複数のアベイラビリティーゾーンを使用することをお勧めします。Gateway Load Balancer を作成した後に、そのアベイラビリティーゾーンを追加・削除することはできません。

デフォルトでは、クロスゾーン負荷分散は無効になっています。クロスゾーン負荷分散は、Gateway Load Balancer を作成後にのみ有効にできます。これを行うには、負荷分散属性を編集し、次いでクロスゾーン負荷分散サポートのチェックボックスにチェックを入れます。

はい、クロスゾーン負荷分散を有効にすると、Gateway Load Balancer でのアベイラビリティーゾーン間のデータ転送には料金が発生します。料金は、Amazon EC2 オンデマンド料金表のページのデータ転送セクションを参照してください。

はい。Gateway Load Balancer は現在アベイラビリティーゾーンごとに 300 個のターゲットをサポートしています。例えば、3 つのアベイラビリティーゾーンで Gateway Load Balancer を作成した場合、最大 900 個のターゲットを登録できます。クロスゾーン負荷分散がオンの場合、アベイラビリティーゾーンごとに 300 個の最大ターゲット数は、Gateway Load Balancer ごとに 300 個に減ります。

Gateway Load Balancer が実行される時間に対して 1 時間単位または 1 時間未満で、また Gateway Load Balancer が使用する時間ごとの Load Balancer キャパシティーユニット (LCU) 使用量で課金されます。

LCU は、Gateway Load Balancer の支払い方法を決定するための Elastic Load Balancing の指標です。LCU は、Gateway Load Balancer でトラフィックを処理するいずれかのディメンション (新規接続/フロー、アクティブ接続/フロー、および帯域幅) のうち消費量が最大のリソースを定義します。

TCP トラフィックの LCU メトリクスは、次のとおりです。

• 1 秒あたり 600 個の新しいフロー (あるいは接続)。
• 60,000 個のアクティブフロー (あるいは接続) (1 分あたりのサンプル)。
• ターゲットとしての EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。

いいえ。3 つのディメンションのうちの 1 つに対してのみ課金されます (1 時間の使用量が最も多いもの)。

1 つの接続で複数のリクエストを送信できます。

Amazon CloudWatch を介して、LCU の 3 つのすべてのディメンションの使用量を追跡することができます。

はい。

価値をもたらすために、仮想アプライアンスは可能な限りレイテンシーを最低限に抑え、仮想アプライアンスとの間を行き来するトラフィックは安全な接続に従う必要があります。Gateway Load Balancer エンドポイントは、これらの要件を満たすために必要な、セキュリティで保護された低レイテンシーの接続を行います。

Gateway Load Balancer エンドポイントを使用すると、アプライアンスは異なる AWS アカウントと VPC に常に存在できます。これにより、アプライアンスを 1 つの場所に集中化して、管理を容易にし、運用オーバーヘッドを削減できます。

Gateway Load Balancer エンドポイントは、PrivateLink テクノロジーを使用する新しいタイプの VPC エンドポイントです。ネットワークトラフィックがソース (インターネットゲートウェイ、VPC など) から Gateway Load Balancer に流れ、また戻ってくると、Gateway Load Balancer エンドポイントは 2 つの間のプライベート接続を保証します。すべてのトラフィックは AWS ネットワークを介して流れ、データがインターネットに公開されることはなく、セキュリティとパフォーマンスの両方が向上します。

PrivateLink インターフェイスエンドポイントは、ウェブアプリケーション宛ての TCP および UDP トラフィックを分散するために、Network Load Balancer (NLB) とペアになっています。対照的に、Gateway Load Balancer エンドポイントは、トラフィックの送信元と送信先を接続するために Gateway Load Balancer とともに使用されます。トラフィックは、Gateway Load Balancer エンドポイントから Gateway Load Balancer に流れ、仮想アプライアンスを経由して、セキュリティで保護された PrivateLink 接続を介して送信先に戻ります。

Gateway Load Balancer エンドポイントは VPC エンドポイントであり、Gateway Load Balancer を使用するサービスに接続できる VPC エンドポイントの数に制限はありません。ただし、サービス障害が発生した場合に、その影響が広範囲に及ぶリスクを軽減するために、接続する Gateway Load Balancer エンドポイントの数は、1 つの Gateway Load Balancer につき 50 以下にすることをお勧めします。

Classic Load Balancer では、現在 Amazon EC2 サービスでサポートされているすべてのオペレーティングシステムで、Amazon EC2 インスタンスをサポートしています。

Classic Load Balancer では、HTTP、HTTPS (セキュア HTTP)、SSL (セキュア TCP) と TCP プロトコルを使用するアプリケーションの負荷分散がサポートされています。

以下の TCP ポートのロードバランスを実行できます。

• [EC2-VPC] 1～65535
• [EC2-Classic] 25、80、443、465、587、1024～65535

はい。各 Classic Load Balancer は、関連付けられた IPv4、IPv6、およびデュアルスタック (IPv4 と IPv6 両方) の DNS 名を持っています。IPv6 は VPC ではサポートされていません。VPC でネイティブ IPv6 をサポートするには、Application Load Balancers を使用できます。

はい。

Amazon Virtual Private Cloud を使用している場合は、Classic Load Balancer のフロントエンドのセキュリティグループを設定できます。

はい、HTTP ポート 80 および HTTPS ポート 443 を単一の Classic Load Balancer にマッピングできます。

Classic Load Balancer は、負荷分散が実行された Amazon EC2 インスタンスで確立できる接続数に制限を設けていません。この数は、Classic Load Balancer が受け取る、HTTP、HTTPS、SSL のリクエスト同時実行数、または TCP 接続同時実行数によって変化することが予想されます。

AWS Marketplace の有料 AMI を使用して起動した Amazon EC2 インスタンスでも、ロードバランスを行うことができます。ただし、Classic Load Balancer では、有料 AMI を使用して Amazon DevPay サイトから起動したインスタンスはサポートされていません。

はい。Elastic Load Balancing のウェブページを参照してください。

はい。アカウントで実行した Classic Load Balancer API コールの履歴を取得するには、AWS マネジメントコンソールで CloudTrail を有効にします。

はい。Classic Load Balancer で SSL を終了できます。各ロードバランサーには SSL 証明書をインストールする必要があります。バックエンドインスタンスにリクエストを送信する前に、ロードバランサーはこの証明書を使用して接続を終了し、クライアントからのリクエストを復号します。

AWS Certificate Manager を使用して SSL/TLS 証明書をプロビジョンできます。または、証明書リクエストを作成して他のソースから証明書を取得し、証明書リクエストに CA の署名を受けてから、AWS Identity and Access Management (IAM) サービスを使用して証明書をアップロードすることもできます。

Classic Load Balancer は AWS Certificate Management (ACM) と統合されました。ACM との統合により、証明書の各ロードバランサーへのバインドが非常にシンプルになり、SSL オフロードプロセス全体も簡単になりました。通常、SSL/TLS 証明書の購入、アップロード、および更新は時間のかかる、手作業による複雑なプロセスになります。ACM が Classic Load Balancer と統合されたことでプロセス全体が短縮され、信頼できる SSL/TLS 証明書をリクエストし、ACM 証明書を選択して各ロードバランサーにプロビジョニングするというシンプルなものになりました。

クロスゾーン負荷分散の有効化は、コンソール、AWS CLI、または AWS SDK を用いて行えます。詳細については、クロスゾーン負荷分散のドキュメントを参照してください。

いいえ、お使いの Classic Load Balancer に対してクロスゾーン負荷分散を有効にしても、アベイラビリティーゾーン間でのリージョン内データ転送に対する料金は発生しません。