全般

Q:アプリケーションに最適なロードバランサーは、どのように決めればよいですか?

A: Elastic Load Balancing (ELB) では、4 種類のロードバランサーをサポートしています。アプリケーションのニーズに応じて、最適なロードバランサーを選択できます。HTTP リクエストの負荷分散を行う必要がある場合は、Application Load Balancer (ALB) を使用することをお勧めします。ネットワーク/トランスポートプロトコル (レイヤー 4 - TCP、UDP) の負荷分散および非常に高いパフォーマンス/低レイテンシーのアプリケーションには、Network Load Balancer を使用することをお勧めします。アプリケーションが Amazon Elastic Compute Cloud (Amazon EC2) Classic ネットワーク内に構築されている場合は、Classic Load Balancer を使用してください。サードパーティ製の仮想アプライアンスを導入してデプロイする必要がある場合は、Gateway Load Balancer を使用することができます。

Q: Amazon Virtual Private Cloud (VPC) から Elastic Load Balancing API に、パブリック IP を使用せずにプライベートでアクセスできますか?

A: はい、VPC エンドポイントを作成すると、Amazon Virtual Private Cloud (VPC) から Elastic Load Balancing API にプライベートでアクセスできます。VPC エンドポイントを使うと、VPC と Elastic Load Balancing API の間のルーティングが AWS ネットワークによって処理されます。インターネットゲートウェイ、ネットワークアドレス変換 (NAT) ゲートウェイ、バーチャルプライベートネットワーク (VPN) 接続は必要ありません。Elastic Load Balancing で使用される VPC エンドポイントの最新世代では、AWS PrivateLink が使用されています。AWS PrivateLink は、VPC でのプライベート IP と Elastic Network Interface (ENI) を使用することにより、AWS のサービス間でのプライベート接続を実現する AWS のテクノロジーです。AWS PrivateLink の詳細については、AWS PrivateLink のドキュメントを参照してください。

Q: ロードバランサーに SLA はありますか?

A: はい、Elastic Load Balancing は、お客様のロードバランサー (Classic、Application または Network) 用に毎月少なくとも 99.99% の可用性を保証します。SLA の詳細について、またあなたがクレジットの資格をお持ちかどうか確認するには、こちらを参照してください。

Application Load Balancer

Q: Application Load Balancer でサポートされるのは、どのオペレーティングシステムですか?

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

Q: Application Load Balancer でサポートされるのは、どのプロトコルですか?

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

Q: Application Load Balancer で HTTP/2 はサポートされますか?

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

Q: Application Load Balancer で静的 IP や PrivateLink を使用するにはどうすればよいですか?

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

Q: どの TCP ポートを使用して負荷分散を実行できますか?

A: TCP ポート (1~65535) のロードバランシングを実行できます。

Q: Application Load Balancer で WebSocket はサポートされますか?

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

Q: Application Load Balancer でリクエストのトレースはサポートされますか?

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

Q: Classic Load Balancer と Application Load Balancer では、機能や利点は同じですか?

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

Q: Amazon EC2 インスタンスを Application Load Balancer からのみトラフィックを受け入れるように設定できますか?

A: はい。

Q: Application Load Balancer のフロントエンドのセキュリティグループは設定できますか?

A: はい。

Q: Classic Load Balancer で使用している既存の API を Application Load Balancer でも使用できますか?

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

Q: Application Load Balancer と Classic Load Balancer を同時に管理するには、どうすればよいですか?

A: 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` を使用して記述します。

Q: Classic Load Balancer を Application Load Balancer (およびその逆) に変換できますか?

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

Q: Classic Load Balancer から Application Load Balancer に移行できますか?

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

Q: Application Load Balancer をレイヤー 4 のロードバランサーとして使用できますか?

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

Q: HTTP および HTTPS リクエストを処理するために、単一の Application Load Balancer を使用できますか?

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

Q: セキュリティ分析や運用のトラブルシューティングのために、アカウントで実行した Application Load Balancer API コールの履歴を取得できますか?

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

Q:Application Load Balancer では HTTPS 終了はサポートされていますか?

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

Q: SSL 証明書を取得する手順はどのようなものですか?

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

Q:Application Load Balancer と AWS Certificate Manager (ACM) はどのように統合するのですか?

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

Q:Application Load Balancer でバックエンドサーバー認証はサポートされていますか?

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

Q: Application Load Balancer で Server Name Indication (SNI) を有効にするにはどうすればよいですか?

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

Q:同じドメインの複数の証明書を 1 つのセキュアリスナーに関連付けることはできますか?

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

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

Q:Application Load Balancer で IPv6 はサポートされていますか?

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

Q: Application Load Balancer にルールを設定するにはどうすればよいですか?

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

Q: Application Load Balancer のリソースには制限がありますか?

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

Q: ロードバランサーの背後にあるウェブアプリケーションを攻撃からどのようにして守ることができますか?

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

Q: 任意の IP アドレスに負荷分散できますか?

A: ロードバランサーの 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 接続によって到達可能なオンプレミスのロケーションのターゲットなど)。

Q:VPC およびオンプレミスのロケーションにかけて分散されたアプリケーションの負荷を分散するにはどうすればよいですか?

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

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

Q: EC2-Classic インスタンスに負荷を分散するにはどうすればよいですか?

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

Q:Application Load Balancer でどのようにクロスゾーン負荷分散の有効化ができますか?

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

Q:Application Load Balancer の Amazon Cognito への統合を使うユーザーを、Application Load Balancers の OpenID Connect (IODC) ID プロバイダ (IdP) へのネイティブなサポートを使うユーザーに対して、いつ認証すれば良いですか?

A: 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 ソリューションを使う方が良いかもしれません。

Q: Application Load Balancer では、どの種類のリダイレクトがサポートされていますか?

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

リダイレクトの種類
HTTP から HTTP http://hostA から http://hostB
HTTP から HTTPS

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

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

Q: 固定レスポンスアクションのメッセージ本文に ALB はどのコンテンツタイプをサポートしていますか?

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

Q: Application Load Balancer 経由の AWS Lambda 呼び出しはどのような仕組みですか?

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

Q: Application Load Balancer を使用した Lambda 呼び出しリクエストでは、HTTP プロトコルと HTTPS プロトコルのどちらもサポートされていますか?

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

Q: Application Load Balancer でターゲットとして Lambda 関数を使用できる AWS リージョンはありますか?

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

Q: Application Load Balancer は AWS Local Zones で使用できますか?

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

Application Load Balancer の料金についてよくある質問

Q: Application Load Balancer の料金はどのような仕組みですか?

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

Q: ロードバランサーキャパシティーユニット (LCU) とは何ですか?

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

Q: Classic Load Balancer は LCU で課金されますか?

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

Q: Application Load Balancer で使用する LCU 数を確認するにはどうすればよいですか?

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

Q: LCU のすべてのディメンションに対して請求されるのですか?

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

Q: 1 時間未満の LCU に対しても請求されますか?

A: はい。

Q: Application Load Balancer で AWS の新規アカウントの無料利用枠は利用できますか?

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

Q: 無料利用枠の一部として、Application Load Balancer と Classic Load Balancer を組み合わせて使用できますか?

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

Q: ルール評価とは何ですか?

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

Q: さまざまな証明書の種類やキーサイズで LCU はどのように請求されますか?

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

 

RSA 証明書        
キーサイズ <=2K  <=4K  <=8K  >8K 
新しい接続/秒 25 5 1 0.25
ECDSA証明書        
キーサイズ <=256 <=384 <=521 >521 
新しい接続/秒 25 5 1 0.25

Q: Application Load Balancer でクロスゾーンロードバランシングを有効にすると、リージョンの AWS データ転送について料金が発生しますか?

A: いいえ。クロスゾーンロードバランシングは Application Load Balancer では常に有効であるため、この種類のリージョン内データ転送には料金はかかりません。

Q: Application Load Balancer でのユーザー認証は別途課金されますか?

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

Q: AWS Lambda ターゲットを使用した Application Load Balancer の使用料金はどのように請求されますか?

A: 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 料金が適用されます。

Q: 他のターゲット (Amazon EC2、コンテナ、オンプレミスサーバー) で処理されたバイトに対して、Lambda ターゲットによって処理されたバイトを区別するにはどうすればよいですか?

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

Network Load Balancer

Q: Network Load Balancer に対して TCP または UDP (レイヤー 4) リスナーを作成できますか?

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

Q: Network Load Balancer で利用できる主な機能は何ですか?

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

Q: Network Load Balancer は、TCP と UDP の両方のプロトコルトラフィックを同じポートで処理できますか?

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

Q: Classic Load Balancer で TCP リスナーを使用した場合と Network Load Balancer の違いは何ですか?

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

Q: Classic Load Balancer から Network Load Balancer に移行できますか?

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

Q: Network Load Balancer のリソースには制限がありますか?

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

Q: Network Load Balancer の設定に AWS マネジメントコンソールを使用することはできますか?

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

Q: Classic Load Balancer の既存の API を Network Load Balancer で使用することはできますか?

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

Q: Network Load Balancer は単一のアベイラビリティーゾーンで作成できますか?

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

Q: Network Load Balancer は リージョンおよびゾーンでの DNS フェイルオーバーをサポートしますか?

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

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

Q: Network Load Balancer は、ELB で提供される IP と Elastic IP または割り当て済みのプライベート IP を組み合わせたものと一緒に使用できますか?

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

Q: 各サブネットの Network Load Balancer に 複数の EIP を割り当てることはできますか?

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

Q: Network Load Balancer を削除または消去した場合、その Network Load Balancer と関連付けられていた Elastic IP アドレスはどうなりますか?

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

Q: Network Load Balancer は内部のロードバランサーをサポートしていますか?

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

Q: 内部 Network Load Balancer は、各サブネットで複数のプライベート IP をサポートしていますか?

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

Q: Network Load Balancer で WebSocket を設定できますか?

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

Q: 任意の IP アドレスに負荷分散できますか?

A: はい。ロードバランサーの 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 リスナーでは、現在サポートされていません。

Q: Network Load Balancer を使用して AWS PrivateLink を設定できますか?

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

Q: UDP フローとは何ですか?

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

Q: Network Load Balancer でサポートされているアイドルタイムアウトとは何ですか?

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

Q: ロードバランサーの背後にあるコンテナをインスタンス ID ではなく IP アドレスでターゲットにすることの利点は何ですか?

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

Q:VPC およびオンプレミスのロケーションにかけて分散されたアプリケーションの負荷を分散するにはどうすればよいですか?

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

Q: EC2-Classic インスタンスに負荷を分散するにはどうすればよいですか?

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

Q: Network Load Balancer でどのようにクロスゾーン負荷分散の有効化ができますか?

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

Q: Network Load Balancer でクロスゾーン負荷分散を有効にすると、リージョンの AWS データ転送に対して料金が発生しますか?

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

Q: クロスゾーン負荷分散は、Network Load Balancer の制限に何か影響がありますか?

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

Q: Network Load Balancer は TLS 終了をサポートしていますか?

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

Q. Network Load Balancer で TLS を終了しても、ソース IP は保持されますか?

A: Network Load Balancer で TLS を終了しても、ソース IP は保持され続けます。

Q: SSL 証明書を取得する手順はどのようなものですか?

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

Q: Network Load Balancer で Server Name Indication (SNI) を有効にするにはどうすればよいですか?

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

Q: Network Load Balancer は AWS Certificate Manager (ACM) または Identity Access Manager (IAM) と、どのように統合されていますか?

A: 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 で得られるものと似ています。

Q: Network Load Balancer でバックエンドサーバー認証はサポートされていますか?

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

Q: Network Load Balancer がサポートしている証明書のタイプは何ですか?

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

Q: Network Load Balancer の TLS 終了は、どの AWS リージョンでサポートされていますか?

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

Network Load Balancer の料金についてよくある質問

Q: Network Load Balancer の料金はどのような仕組みですか?

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

Q: ロードバランサーキャパシティーユニット (LCU) とは何ですか?

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

Q: Network Load Balancer の TCP トラフィックに関する LCU メトリクスとは何ですか?

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

  • 1 秒あたり 800 個の新しい TCP 接続。
  • 100,000 個のアクティブ TCP 接続 (1 分あたりのサンプル)。
  • ターゲットとしての Amazon EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。
 
Q: Network Load Balancer の UDP トラフィックに関する LCU メトリクスとは何ですか?

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

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

Q: Network Load Balancer の TLS トラフィックに関する LCU メトリクスとは何ですか?

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

  • 1 秒あたり 50 個の新しい TLS 接続。
  • 3,000 個のアクティブ TLS 接続 (1 分あたりのサンプル)。
  • ターゲットとしての Amazon EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。
 
Q: すべてのディメンション (処理されたバイト数、新しいフロー、アクティブフロー) に対して料金を請求されますか?
 
A: いいえ。各プロトコルについて、3 つのディメンションうちの 1 つに対してのみ課金されます (1 時間の使用量が最も多いもの)。

Q: 1 秒あたりの新しい接続/フローは、1 秒あたりのリクエストと同じですか?

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

Q: Classic Load Balancer は LCU で課金されますか?

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

Q: Network Load Balancer で使用する LCU 数を確認するにはどうすればよいですか?

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

Q: LCU のすべてのディメンションに対して請求されるのですか?

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

Q: 1 時間未満の LCU に対しても請求されますか?

A: はい。

Q: Network Load Balancer で AWS の新規アカウントの無料利用枠は利用できますか?

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

Q: 無料利用枠の一部として、Network Load Balancer、Application Load Balancer、および Classic Load Balancer を組み合わせて使用できますか?

A: はい。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

開始方法

Q: Network Load Balancer や Application Load Balancer ではなく、Gateway Load Balancer はいつ使用しますか?

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

Q: ゲートウェイロードバランサーはリージョンごとに、またはアベイラビリティゾーン (AZ) ごとにデプロイされていますか?

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

Q: Gateway Load Balancer で利用できる主な機能は何ですか?

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

Q: Gateway Load Balancer は TLS ターミネーションを実行しますか?

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

Q: Gateway Load Balancer はアプリケーションの状態を維持しますか?

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

Q: Gateway Load Balancer は、どのようにしてフローを定義するのですか?

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

Q: ゲートウェイロードバランサーで 5 タプル、3 タプル、2 タプルのスティッキネスはいつ使うべきですか?

デフォルトの 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 フローの持続性を有効にする必要があります。

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

Q: Gateway Load Balancer でサポートされているアイドルタイムアウトとは何ですか?

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

Q: GWLB はパケットのフラグメンテーションをサポートしていますか?
A: GWLB 自体は透過的なバンプ・イン・ザ・ワイヤーなので、パケットのフラグメント化や再構成は行いません。

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

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

Q: Gateway Load Balancer は、単一のアベイラビリティーゾーンで 1 つの仮想アプライアンスインスタンスの障害をどのように処理しますか?

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

Q: Gateway Load Balancer は、単一の AZ 内のすべての仮想アプライアンスの障害をどのように処理しますか?

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

Q: アプライアンスを複数の Gateway Load Balancer のターゲットとして構成できますか?

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

Q: Gateway Load Balancer にはどのようなタイプのリスナーを作ることができますか?

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

Q: Gateway Load Balancer のリソースには制限がありますか?

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

Q: Gateway Load Balancer の設定に AWS マネジメントコンソールを使用することはできますか?

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

Q: Gateway Load Balancer は単一のアベイラビリティーゾーンで作成できますか?

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

Q: Gateway Load Balancer でどのようにクロスゾーン負荷分散の有効化ができますか?

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

Q: Gateway Load Balancer でクロスゾーン負荷分散を有効にすると、AWS データ転送に対して料金が発生しますか?

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

Q: クロスゾーン負荷分散は、Gateway Load Balancer の制限に何か影響がありますか?

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

Gateway Load Balancer の料金についてよくある質問

Q: Gateway Load Balancer の料金はどのような仕組みですか?

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

Q: ロードバランサーキャパシティーユニット (LCU) とは何ですか?

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

Q: Gateway Load Balancer に関する LCU メトリクスとは何ですか?

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

  • 1 秒あたり 600 個の新しいフロー (あるいは接続)。
  • 60,000 個のアクティブフロー (あるいは接続) (1 分あたりのサンプル)。
  • ターゲットとしての EC2 インスタンス、コンテナ、および IP アドレスの場合は 1 時間あたり 1 GB。
 
Q: すべてのディメンション (処理されたバイト数、新しいフロー、アクティブフロー) に対して料金を請求されますか?

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

Q: 1 秒あたりの新しいフロー (あるいは接続) は、1 秒あたりのリクエストと同じですか?
 
A: いいえ、1 つの接続で複数のリクエストを送信できます。
 
Q: Gateway Load Balancer で使用する LCU 数を確認するにはどうすればよいですか?
 
A: Amazon CloudWatch を介して、LCU の 3 つのすべてのディメンションの使用量を追跡することができます。
 
Q: 1 時間未満の LCU に対しても請求されますか?
 
A: はい。

Gateway Load Balancer エンドポイント

Q: Gateway Load Balancer エンドポイントが必要な理由は何ですか?

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

Q: Gateway Load Balancer エンドポイントは集中化にどのように役立ちますか?

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

Q: Gateway Load Balancer エンドポイントはどのように機能しますか?

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

Q: PrivateLink インターフェイスエンドポイントは Gateway Load Balancer エンドポイントとどのように異なりますか?

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

Q: 1 つの Gateway Load Balancer にいくつの Gateway Load Balancer エンドポイントを接続できますか?

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

Classic Load Balancer

Q: Classic Load Balancer でサポートされているのはどのオペレーティングシステムですか?

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

Q: Classic Load Balancer でサポートされているのはどのプロトコルですか?

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

Q: どの TCP ポートでロードバランスを実行できますか?

A: TCP ポートのロードバランシングを実行できます。

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

Q: Classic Load Balancer では IPv6 トラフィックはサポートされていますか?

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

Q: Classic Load Balancer からのトラフィックのみを受け入れるように Amazon EC2 インスタンスを設定できますか?

A: はい。

Q: Classic Load Balancer のフロントエンドのセキュリティグループを設定できますか?

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

Q: HTTP および HTTPS リクエストを処理するために、単一の Classic Load Balancer を使用できますか?

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

Q: 負荷分散が実行された Amazon EC2 インスタンスでは、各 Classic Load Balancer からの接続をいくつ受け入れる必要がありますか?

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

Q: 有料 AMI を使用して、起動した Amazon EC2 インスタンスのロードバランスを実行できますか?

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

Q: Amazon Virtual Private Cloud で Classic Load Balancer を使用できますか?

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

Q: セキュリティ分析や運用のトラブルシューティングのためにアカウントで実行した Classic Load Balancer API コールの履歴を取得できますか?

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

Q: Classic Load Balancer では SSL 終了をサポートしていますか?

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

Q: SSL 証明書を取得する手順はどのようなものですか?

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

Q: Classic Load Balancer と AWS Certificate Manager (ACM) はどのように統合されますか?

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

Q: Classic Load Balancer でどのようにクロスゾーン負荷分散の有効化ができますか?

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

Q: Classic Load Balancer でクロスゾーン負荷分散を有効にすると、リージョンの AWS データ転送に対して料金が発生しますか?

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

Elastic Load Balancing の料金表について詳しく見る

料金ページを見る

詳細はこちら 
無料のアカウントにサインアップ

AWS 無料利用枠にすぐにアクセスできます。 

サインアップ 
コンソールで構築を開始する

AWS コンソールで Elastic Load Balancing を開始する。

サインイン