Application Load Balancer

相互 TLS のサポート
相互 TLS は、X.509 証明書ベースの ID を使用するクライアントとサーバー間の双方向認証用のプロトコルです。この機能により、ALB はクライアント証明書を認証し、サードパーティの認証局 (CA) またはプライベート認証局 (ACM PCA) の両方によって発行された証明書の失効チェックを実行します。また、ロードバランサーはクライアント証明書情報をターゲットにプロキシし、アプリケーションによる承認の決定に使用できます。 

Automatic Target Weights
Automatic Target Weights (ATW) は、新しい「重み付きランダム」負荷分散アルゴリズムを使用しています。このアルゴリズムは、アプリケーションのターゲットに障害が発生した場合でもアプリケーションの可用性を向上させます。このアルゴリズムは、HTTP ステータスコードと TCP/TLS エラー率を分析して、同じターゲットグループのピアよりもエラー率が高いターゲットを識別します。ATW がパフォーマンスの低いターゲットを特定すると、この機能はパフォーマンスに基づいて各ターゲットに送られるトラフィックの量を調整し、問題のあるターゲットが正常に回復できるようにします。

レイヤー 7 の負荷分散
リクエスト属性 (X-Forwarded-For ヘッダーなど) に基づいて、HTTP/HTTPS トラフィックをターゲット (Amazon EC2 インスタンス、マイクロサービス、コンテナ) に負荷分散できます。

セキュリティ機能
Amazon Virtual Private Cloud (VPC) を使用する際は、Elastic Load Balancing に関連付けられているセキュリティグループを作成および管理して、追加のネットワーキングおよびセキュリティオプションを提供できます。Application Load Balancer をインターネットに接続するよう設定できるほか、パブリック IP アドレスを使用せずに内部的な (インターネットに接続しない) ロードバランサーを作成することもできます。

ALB は、http_desync_guardian ライブラリに基づく非同期保護の実装をサポートしています。この新機能により、可用性やレイテンシーに大きな妥協をすることなく、お客様のアプリケーションは非同期による HTTP の脆弱性から保護されます。お客様は、アプリケーションアーキテクチャに基づいて、疑わしいリクエストに対する許容レベルを選択することもできます。

Outposts のサポート
Application Load Balancer (ALB) は、AWS インフラストラクチャ、サービス、およびツールを事実上すべてのデータセンター、コロケーションスペース、またはオンプレミス施設に拡張し、真に一貫したハイブリッドエクスペリエンスを提供するフルマネージドサービスである AWS Outposts をサポートしています。お客様は、サポート対象のインスタンスタイプで ALB をプロビジョニングでき、ALB は、手動による介入なしで、さまざまなレベルのアプリケーション負荷に対応するために、ラックで利用可能な容量まで自動スケールアップします。お客様は、負荷分散に関連する容量のニーズを把握するのに役立つ通知を受け取ることもできます。お客様は、同じ AWS コンソール、API、および CLI を使用して、リージョン内の ALB で現在行っているのと同じように、Outposts で ALB をプロビジョニングおよび管理できます。

HTTPS サポート
Application Load Balancer では、クライアントとロードバランサーの間の HTTPS ターミネーションをサポートしています。また、Application Load Balancers では、定義済みのセキュリティポリシーに対応する AWS Identity and Access Management (IAM) および AWS Certificate Manager を使用した SSL 証明書の管理も可能です。

HTTP/2 と gRPC のサポート
HTTP/2 は HyperText Transfer Protocol (HTTP) の新しいバージョンで、単一の多重化された接続を使用して複数のリクエストを同一の接続で送信できるようにします。また、ヘッダーデータを圧縮してバイナリ形式で送信する機能と、クライアントへの SSL 接続もサポートしています。

ALB は、マイクロサービス間または gRPC 対応のクライアントとサービス間で gRPC トラフィックをルーティングおよび負荷分散できます。これにより、お客様のクライアントやサービスの基盤となるインフラストラクチャを変更することなく、アーキテクチャに gRPC トラフィック管理をシームレスに導入できます。gRPC はトランスポートに HTTP/2 を使用し、マイクロサービスアーキテクチャでのサービス間通信のための人気のプロトコルになりつつあります。軽量なネットワークフットプリント、圧縮、双方向ストリーミングなどの HTTP/2 固有の利点に加えて、効率的なバイナリシリアル化や多数の言語のサポートなどの機能を備えており、REST などの従来のプロトコルよりも優れています。

TLS のオフロード
暗号化された接続 (SSL オフロードとも呼ばれます) を使用する HTTPS リスナーを作成できます。この機能により、ロードバランサーと SSL または TLS セッションを開始するクライアント間のトラフィック暗号化が可能になります。Application Load Balancer は、クライアント TLS セッション終了をサポートします。これにより、バックエンドアプリケーションのソース IP アドレスを保持しながら、TLS 終了タスクをロードバランサーにオフロードできます。TLS リスナーの定義済みのセキュリティポリシーから選択して、コンプライアンスとセキュリティ標準を満たすことができます。サーバー証明書の管理には、AWS Certificate Manager (ACM) または AWS Identity and Access Management (IAM) を使用できます。

SNI を使用すると、単一の TLS リスナーを使用して複数の安全なウェブサイトを提供できます。クライアントのホスト名が複数の証明書と一致する場合、ロードバランサーはスマート選択アルゴリズムに基づいて使用に最適な証明書を選択します。

スティッキーセッション
スティッキーセッションは、同一のクライアントから同一のターゲットにリクエストをルーティングするメカニズムです。Application Load Balancer は、期間ベースの Cookie とアプリケーションベースの Cookie の両方をサポートします。スティッキーセッションを管理するために重要なのは、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする時間の決定です。スティッキーセッションは、ターゲットグループレベルで有効になります。すべてのターゲットグループで、期間ベースの持続性、アプリケーションベースの持続性、および持続性なしの組み合わせを使用できます。

ネイティブ IPv6 のサポート
Application Load Balancer では VPC 内でネイティブなインターネットプロトコルバージョン 6 (IPv6) がサポートされます。クライアントは IPv4 または IPv6 経由で Application Load Balancer に接続できます。

リクエストトレーシング
Application Load Balancer は、受信するすべてのリクエストに新しいカスタム識別子「X-Amzn-Trace-Id」HTTP ヘッダーを挿入します。リクエストトレーシングでは、ウェブサイトや分散アプリケーションのトラフィックに大部分を構成しているさまざまなサービス間をリクエストが移動するときに、一意の ID を使用してそのリクエストを追跡することができます。一意のトレース識別子を使用すると、個々のリクエスト単位で、アプリケーションスタックでのパフォーマンスやタイミングの問題を明らかにすることができます。

リダイレクト
Application Load Balancer は、ある URL から別の URL への入力リクエストのリダイレクトができます。これには、HTTP リクエストを HTTPS リクエストにリダイレクトする機能も含まれており、安全なブラウジングのコンプライアンス目標を達成でき、同時にサイトの検索ランキングと SSL/TLS スコアを向上させることができます。また、リダイレクトを用いてユーザーを別のウェブサイトに送ることもでき、例えば、アプリケーションの古いバージョンから新しいバージョンへとリダイレクトできます。

固定レスポンス
Application Load Balancer は、お使いのアプリケーションがどのクライアントリクエストを行うかをコントロールできます。このため、受信リクエストに対して HTTP エラーレスポンスコードとロードバランサー自身からのカスタムエラーメッセージで応答でき、リクエストをアプリケーションに転送する必要はありません。

WebSocket サポート
WebSocket を使用すると、エンドユーザーがサーバーにアップデートをリクエスト (またはポーリング) することなく、サーバーがエンドユーザーとリアルタイムでメッセージを交換できます。WebSocket プロトコルは、長時間維持される TCP 接続を経由して、クライアントとサーバーとの間で双方向通信チャンネルを提供します。

Server Name Indication (SNI)
サーバーネームインディケーション (SNI) は、クライアントが TLS ハンドシェイク開始時に接続先のホスト名を提示する、TLS プロトコルの拡張機能の 1 つです。ロードバランサーは、同じセキュアリスナーを通じて複数の証明書を提示できるため、単一のセキュアリスナーを使用して複数のセキュアなウェブサイトをサポートすることができます。Application Load Balancer は、SNI を使用したスマート証明書の選択アルゴリズムもサポートしています。クライアントによって示されたホスト名が複数の証明書と一致する場合、ロードバランサーは、クライアントの特徴を含む複数の要因に基づいて、使用する最適な証明書を決定します。

IP アドレスをターゲットに設定
アプリケーションのバックエンドの IP アドレスをターゲットとして使用し、AWS またはオンプレミスにホスティングされた任意のアプリケーションの負荷を分散できます。これにより、インスタンス内の任意の IP アドレスまたはインターフェイスにホスティングされたアプリケーションのバックエンドに対する負荷分散が可能です。同じインスタンスにホスティングされた各アプリケーションにはセキュリティグループを関連付けることが可能で、同じポートを使用できます。また、IP アドレスをターゲットとして使用して、オンプレミスロケーション (Direct Connect または VPN 接続を使用)、ピアリング接続された VPC、EC2-Classic (ClassicLink を使用) にホスティングされたアプリケーションの負荷を分散できます。AWS およびオンプレミスのリソースにかけて負荷を分散できるため、クラウドへの移行、バースト、フェイルオーバーに役立ちます。

ターゲットとしての Lambda 関数
Application Load Balancers は、ユーザがウェブブラウザを含む任意の HTTP クライアントからサーバーレスアプリケーションにアクセスできるように、HTTP(S) リクエストを処理する Lambda 関数の呼び出しをサポートします。Lambda 関数をロードバランサーのターゲットとして登録し、コンテンツベースのルーティングルールがサポートされていることを利用して、リクエストを異なる Lambda 関数にルーティングします。Application Load Balancer は、サーバーおよびサーバーレスコンピューティングを使用するアプリケーションの共通の HTTP エンドポイントとして使用できます。Lambda 関数を使用してウェブサイト全体を構築したり、EC2 インスタンス、コンテナ、オンプレミスサーバー、Lambda 関数を組み合わせてアプリケーションを構築できます。

コンテンツベースのルーティング
アプリケーションが複数の個別のサービスで構成されている場合、Application Load Balancer は、ホストフィールド、パス URL、HTTP ヘッダー、HTTP メソッド、クエリ文字列、送信元 IP アドレスなどのリクエストのコンテンツに基づいてリクエストをサービスにルーティングできます。

ホストベースのルーティング: HTTP ヘッダーの Host フィールドに基づいてクライアントのリクエストをルーティングできます。これにより、同一のロードバランサーから複数のドメインへのルーティングが可能になります。

パスベースのルーティング: HTTP ヘッダーの URL パスに基づいてクライアントのリクエストをルーティングできます。

HTTP ヘッダーベースのルーティング: 標準またはカスタムの HTTP ヘッダーの値に基づいてクライアントのリクエストをルーティングできます。

HTTP メソッドベースのルーティング: 標準またはカスタムの HTTP メソッドに基づいてクライアントのリクエストをルーティングできます。

クエリ文字列パラメータベースのルーティング: クエリ文字列またはクエリパラメータに基づいてクライアントリクエストをルーティングできます。

ソース IP アドレス CIDR ベースのルーティング: リクエスト元のソース IP アドレス CIDR に基づいてクライアントのリクエストをルーティングできます。

コンテナ化されたアプリケーションのサポート
Application Load Balancer では、単一の Amazon EC2 インスタンスにある複数のポート間で負荷を分散することで、コンテナサポートを強化しています。Amazon Elastic Container Service (ECS) との密接な統合により、コンテナを完全に管理できます。ECS では、ECS タスク定義でダイナミックポートを指定でき、EC2 インスタンスでスケジュールされている場合にコンテナに未使用のポートを付与できます。ECS スケジューラでは、このポートを使用してロードバランサーにタスクを自動的に追加します。

ウェブアプリケーションファイアウォール
AWS WAF を使用して、Application Load Balancer 上のウェブアプリケーションを保護できるようになりました。AWS WAF は、アプリケーションの可用性の低下、セキュリティ侵害、リソースの過剰消費に影響を及ぼし得る一般的なウェブの脆弱性からウェブアプリケーションを保護するウェブアプリケーションファイアウォールです。

ロードバランシングアルゴリズムでの低速開始モード
Application Load Balancer はラウンドロビンのロードバランシングアルゴリズムをサポートしています。また、Application Load Balancer はラウンドロビンのアルゴリズムでの低速開始モードをサポートしており、新しいターゲットをリクエストであふれ返させずに追加できます。低速開始モードでは、ターゲットは割り当てられたリクエスト数を受け取る前に、お客様の指定するランプアップ期間に基づいてウォームアップします。低速開始は、最適なパフォーマンスでリクエストに応答できるようになる前にウォームアップ期間を要するキャッシュに依存するアプリケーションには大変有用です。

ユーザー認証
お使いのアプリから Application Load Balancer に認証機能をオフロードできます。Application Load Balancer は、ユーザーがクラウドアプリケーションにアクセスする際に、安全にユーザー認証を行います。Application Load Balancer は Amazon Cognito とシームレスに統合されていますので、エンドユーザーは Google、Facebook、Amazon などのソーシャル ID プロバイダーで認証でき、また SAML 経由で Microsoft Active Directory などのエンタープライズ ID プロバイダー、または任意の OpenID Connect に準拠した ID プロバイダー (IdP) で認証できます。既に OpenID Connect に準拠したカスタム IdP ソリューションをお使いの場合、Application Load Balancer はエンタープライズユーザーを直接お使いの ID プロバイダーに接続して認証することもできます。