ANS-#41

AWS PrivateLink

Network Load Balancerと VPC エンドポイントサービス を使用してサービスを非公開で公開し、IP が重複していても機能するため正解です。

・Network Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
→Network Load Balancer (NLB) の背後に SaaS サービスのエンドポイントをデプロイすることで、IP が重複していても機能します。NLB は、同じ IP アドレス範囲を持つ複数の VPC 間でのトラフィックを効果的に負荷分散することができます。

・エンドポイントサービスを構成し、エンドポイントサービスへの接続を作成する権限をお客様に付与します。
→VPC エンドポイントサービスを構成し、エンドポイントサービスへの接続を作成する権限をお客様に付与することで、インターネットを経由せずに SaaS サービスに接続することが可能になります。これにより、お客様は内部 IP アドレスを共有せずにサービスを利用できます。

※AWS PrivateLink
AWS PrivateLink は、VPC 間、AWS サービス、およびオンプレミスネットワーク間のプライベート接続を提供し、トラフィックをパブリックインターネットにさらすことなく、異なるアカウントや VPC 間でサービスを接続することが容易になります。これにより、 リージョン内 の 1 つの VPC (サービスプロバイダ) にあるサービス / アプリケーションを、他の VPC (コンシューマ) にプライベートに公開し、コンシューマ VPC がサービスプロバイダ VPC に接続を開始できます。

AWS PrivateLink を使用するには、VPC 内のアプリケーション用に Network Load Balancer を作成し、そのロードバランサを指す VPC エンドポイントサービス設定を作成します。次に、サービスコンシューマがインターフェースエンドポイントを作成します。これにより、サブネット内にプライベート IP アドレスを持つ Elastic Network Interface (ENI) が作成され、サービスへのトラフィックのエントリーポイントとなります。コンシューマとサービスは同じ VPC にある必要はありません。VPC が異なる場合、コンシューマとサービスプロバイダの VPC は重複した IP アドレス範囲を持つことができます。他の VPC 内のサービスにアクセスするためのインターフェース VPC エンドポイントの作成に加えて、AWS PrivateLink を介してサポートされる AWS サービスにプライベートにアクセスするためのインターフェース VPC エンドポイントを作成することができます。

参考URL : AWS PrivateLink

■以下は間違いです。
・お客様の VPC への VPC ピアリング接続を構成します。NAT ゲートウェイ経由でトラフィックをルーティングします。
・AWS Transit Gateway をデプロイし、SaaS VPC に接続します。Transit Gateway をお客様と共有します。 Transit Gateway でルーティングを構成します。
→ VPC ピアリング と Transit Gateway 接続は重複する IP をサポートしていないため間違いです。

VPC ピアリングを使用しても、IP が重複する問題は解決できません。VPC ピアリングでは、異なる VPC 間で IP アドレス範囲が重複している場合、ルーティングが正常に機能しません。
Transit Gateway を使用しても、IP が重複する問題は直接解決できません。Transit Gateway は複数の VPC 間でのネットワーク接続を簡素化できますが、IP アドレスが重複している場合、ルーティングが正常に機能しない可能性があります。

・Application Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
→ Application Load Balancer (ALB) は、IP が重複する場合に問題が発生する可能性があるため間違いです。Network Load Balancer (NLB) を構成する必要があります。

Application Load Balancer (ALB) を使用すると、IP が重複する場合に問題が発生する可能性があります。これは、ALB は IP が重複する状況での負荷分散やルーティングが困難であるためです。代わりに、Network Load Balancer (NLB) を使用することで、同じ IP アドレス範囲を持つ複数の VPC 間でのトラフィックを効果的に負荷分散することができます。

Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする

Egress-Only インターネットゲートウェイは、プライベートサブネット内のインスタンスが IPv6 を使用してインターネットに接続できるため正解です。

Egress-Only インターネットゲートウェイ を使用することで、プライベートサブネット内の Amazon EC2 インスタンスが IPv6 を使用してインターネットにアクセスできるようになります。同時に、インターネットからのアクセスは許可されず、プライベートサブネット内のインスタンスのセキュリティが維持されます。

この選択肢では、既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。その後、Egress-Only インターネットゲートウェイを作成し、すべてのプライベートサブネットの VPC ルートテーブルを更新して、Egress-Only インターネットゲートウェイに ::/0 のルートを追加します。これにより、プライベートサブネット内のインスタンスはインターネットに IPv6 でアクセスできるようになりますが、インターネットからアクセスされることはありません。

※Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする
Egress-Only インターネットゲートウェイは水平にスケールされ、冗長で、高度な可用性を持つ VPC コンポーネントで、IPv6 経由での VPC からインターネットへの送信を可能にし、インスタンスとの IPv6 接続が開始されるのを防ぎます。


IPv6 アドレスはグローバルに一意であるため、デフォルトではパブリックアドレスになっています。インスタンスにインターネットにアクセスさせる場合で、インターネット上のリソースにインスタンスとの通信を開始させないようにする場合は、Egress-Only インターネットゲートウェイを使用できます。これを行うには、Egress-Only インターネットゲートウェイを VPC で作成し、次にすべての IPv6 トラフィック (::/0) または特定の IPv6 アドレスの範囲をポイントするルートテーブルに、Egress-Only インターネットゲートウェイへのルートを追加します。ルートテーブルに関連付けられるサブネットの IPv6 トラフィックは、Egress-Only インターネットゲートウェイにルーティングされます。

Egress-Only インターネットゲートウェイはステートフルです。サブネットのインスタンスからインターネットや他の AWS のサービスに転送し、インスタンスに応答を戻します。

Egress-Only インターネットゲートウェイには、次のプロパティがあります :

・Egress-Only インターネットゲートウェイとセキュリティグループを関連付けることはできません。セキュリティグループは、プライベートサブネットのインスタンスに対して使用し、それらのインスタンスに出入りするトラフィックを管理できます。
・ネットワーク ACL を使用して、Egress-Only インターネットゲートウェイがサブネットとの間でルーティングするトラフィックを制御できます。
参考URL : Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする

■以下は間違いです。
・既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべてのプライベートサブネットの VPC ルートテーブルを更新し、NAT ゲートウェイに ::/0 用のルートを追加します。
・既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。新しい NAT ゲートウェイを作成し、IPv6 サポートを有効にします。すべてのプライベートサブネットの VPC ルートテーブルを更新し、IPv6 を有効にした NAT ゲートウェイに ::/0 のルートを追加します。
→NAT ゲートウェイは IPv6 トラフィックをサポートしていないため間違いです。

・既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべての VPC のルートテーブルを更新し、インターネットゲートウェイに ::/0 のルートを追加します。
→インターネットからインスタンスへのアクセスを許可するため間違いです。

この方法ではインターネットからプライベートサブネット内のインスタンスへのアクセスが許可されてしまい、セキュリティ上の要件を満たせません。

Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehose は、Amazon CloudWatch Logs と統合し、Amazon OpenSearch Service にデータをストリーミングするためのマネージドソリューションを提供するため正解です。

Amazon Kinesis Data Firehose は、 Amazon CloudWatch Logs と統合して、データを Amazon OpenSearch Service にストリーミングすることができます。このマネージドソリューションを使用することで、データエンジニアリングチームはログ記録システムの保守と運用を管理する必要がなくなります。

まず、Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングします。次に、Amazon Kinesis Data Firehose 配信ストリームを CloudWatch にサブスクライブして、ウェブログを Amazon OpenSearch Service に転送します。これにより、データエンジニアリングチームはほぼリアルタイムの検索エンジンを実現できます。

■以下は間違いです。
・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Firehose 配信ストリームを CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon DynamoDB を設定します。
→Amazon Kinesis Data Firehose は宛先として Amazon DynamoDB をサポートしておらず、Amazon DynamoDB はログの理想的なストレージソリューションではないため間違いです。

Amazon Kinesis Data Firehose は Amazon DynamoDB を宛先としてサポートしていません。また、Amazon DynamoDB は主にキー・バリュー型のデータストレージに最適化されており、ログデータの検索や分析には適していません。そのため、この選択肢はウェブログ記録システムには適していません。

・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。Splunk をウェブログの最終宛先として設定します。
→Amazon Kinesis Data Streams によってウェブログ記録システムの保守・運用が増えます。また、Splunk を別途購入する必要があるため間違いです。

Amazon Kinesis Data Streams を使用すると、データエンジニアリングチームはログ記録システムの保守・運用を行う必要があります。さらに、 Splunk は別途購入が必要であり、コスト面でも効率的でないため、この選択肢は間違いです。

・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon OpenSearch Service を選択します。
→Amazon Kinesis Data Streams は、データ収集や Amazon OpenSearch Service への取り込みなど、ウェブログ記録システムの保守・運用の手間が増えるため間違いです。

Amazon Kinesis Data Streams を使用すると、データエンジニアリングチームはデータ収集や Amazon OpenSearch Service への取り込みに関連するタスクを手動で行う必要があります。これにより、保守・運用の手間が増えるため、この選択肢はウェブログ記録システムに適していません。

X-Forwarded-For

Application Load Balancer は SSL 終端とパスベースのルーティングをサポートし、リクエストの URL に基づいて異なるターゲットグループにリクエストをルーティングできるため正解です。また、X-Forwarded-For ヘッダーもサポートされているため、HTTP または HTTPS ロードバランサーを使用するときにクライアントの IP アドレスを識別できます。

Application Load Balancer は、SSL 終端を行い、TLS 処理をロードバランサーにオフロードできます。これにより、すべてのトラフィックで HTTPS を使用する要件が満たされます。また、パスベースのルーティング機能を利用して、リクエスト内の URL に基づいて複数のターゲットグループにリクエストをルーティングすることができます。

さらに、Application Load Balancer は X-Forwarded-For リクエストヘッダーをサポートしており、これによってウェブサーバーはユーザーの IP アドレスを認識することができます。この機能を利用することで、企業はセキュリティ目的で正確なログを残すことが可能になります。

※X-Forwarded-For
X-Forwarded-For リクエストヘッダーは、HTTP または HTTPS ロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント / サーバー間のトラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認するには、routing.http.xff_header_processing.mode 属性を使用します。この属性を使用すると、Application Load Balancer がターゲットにリクエストを送信する前に、HTTP リクエストの X-Forwarded-For ヘッダーを変更、保持、削除できます。この属性に指定できる値は、append、preserve、および remove です。この属性のデフォルト値は append です。
参考URL : X-Forwarded-For

■以下は間違いです。
・TLS リスナーを使用して Network Load Balancer をデプロイします。パスベースのルーティングルールを使用して、トラフィックを正しいターゲットグループに転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
・各ドメインの TLS リスナーを使用して Network Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
→Network Load Balancer はパスベースまたはホストベースのルーティングをサポートしていないため間違いです。

Network Load Balancer はパスベースのルーティングやホストベースのルーティングをサポートしていません。そのため、リクエスト内の URL に基づいて複数のターゲットグループにリクエストをルーティングする要件を満たすことができません。これらの機能は、Application Load Balancer を使用することで実現できます。

・各ドメインに HTTPS リスナーを使用して Application Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに X-Forwarded-For リクエストヘッダーを含めます。
→各ドメインの Application Load Balancer は必要ないため間違いです。ALB は、複数の TLS 証明書をサポートしています。

実際には、単一の Application Load Balancer で複数の TLS 証明書をサポートし、ホストベースのルーティングを使用してトラフィックを適切なターゲットグループに転送することができます。そのため、各ドメインごとに個別の Application Load Balancer をデプロイする必要はありません。

Application Load Balancer でのパスベースのルーティング

ALB は パスベースのルーティング をサポートし、/meteor を処理するために新しいターゲットグループとリスナーを作成することができるため正解です。

Application Load Balancer (ALB) は、パスベースのルーティングをサポートしており、異なるターゲットグループにトラフィックを分配することができます。これにより、宇宙開発会社は新しいターゲットグループを作成し、EC2 インスタンスの Auto Scaling グループがそのターゲットグループを使用するように設定できます。さらに、/meteor をリダイレクトするリスナールールを追加して ALB を更新することで、/meteor へのアクセスを新しいターゲットグループにルーティングできます。

このソリューションは、宇宙開発会社が必要とする自動スケーリング機能を提供し、他の選択肢と比較して最も運用効率が高いといえます。

※Application Load Balancer でのパスベースのルーティングを実現するにはどうすればよいですか ?
Application Load Balancer では、URL に基づいてリクエストをターゲットグループに転送するルールを持つリスナーを作成できます。この機能は、Classic Load Balancer、Network Load Balancer、Gateway Load Balancer など、他の種類のロードバランサーでは使用できません。

Application Load Balancer でパスベースのルーティングを確立するには、次の操作を実行します。

1. ターゲットグループを作成します。
2. リスナールールを設定します。
参考URL : Application Load Balancer でのパスベースのルーティングを実現するにはどうすればよいですか ?

■以下は間違いです。
・Amazon CloudFront ディストリビューションの背後に ALB を配置します。リクエスト URI を解析し、EC2 インスタンスの IP アドレスを含む path-pattern ヘッダーを /meteor のリクエストに追加する Lambda@Edge 関数を作成します。HTTP ヘッダーを検索し、EC2 インスタンスの IP アドレスを使用してトラフィックを転送するリスナールールを ALB に追加します。
→アプリケーションの スケーリング に役立たないため間違いです。

Amazon CloudFront と Lambda@Edge 関数を使用しても、アプリケーションの自動スケーリングが実現できません。宇宙開発会社はアプリケーションが自動的にスケーリングされることを求めているため、この選択肢は適切ではありません。

・Network Load Balancer (NLB) を作成します。NLB を 2 つのポートでリッスンするように構成します。1 つ目のポートのターゲットグループを構成して、すべての IP トラフィックを Auto Scaling グループに配信し、カスタム画像を処理します。2 つ目のポートにターゲットグループを設定し、すべての IP トラフィックを Fargate に配信します。 ALB でパスベースのルーティングを使用して、URL プレフィックス /meteor のトラフィックを最初のターゲットグループに転送します。その他のパスはすべて 2 つ目のターゲットグループにルーティングします。
→トラフィックは主に HTTPSであり、NLB よりも ALB が理想的であるため間違いです。

Network Load Balancer (NLB) は主に TCP/UDP トラフィックに対して最適化されており、HTTPS やパスベースのルーティングには適していません。そのため、ALB を使用する方が効果的です。

・既存のターゲットグループを新しい EC2 インスタンスで更新します。アプリケーションの ALB を更新し、/meteor を新しく追加された EC2 インスタンスにリダイレクトするリスナールールを追加します。
→既存のターゲットグループが ルーティングを処理できない ため間違いです。

既存のターゲットグループを新しい EC2 インスタンスで更新しても、/meteor へのアクセスを適切にルーティングできません。パスベースのルーティングを使用するためには、新しいターゲットグループとリスナールールが必要です。

MAC セキュリティ

MACsec を使用した Direct Connect は、運用効率の高い方法で、利用可能な最大帯域幅で安全に AWS とデータを交換するのに役立つため正解です。

MACsec は、有線イーサネットネットワークにおける暗号化のためのプロトコルであり、データの保護とコンプライアンスを提供します。MACsec を使用した Direct Connect は、最大帯域幅で安全かつ効率的にデータを交換することができます。このため、この選択肢は最も効率的な運用方法を提供し、要件を満たします。

※MAC セキュリティ
MAC Security (MACsec) は IEEE 標準の 1 つです。データの機密性、データの整合性、およびデータオリジンの信頼性を定義しています。MACsec をサポートする AWS Direct Connect 接続を使用して、企業のデータセンターから AWS Direct Connect ロケーションへのデータを暗号化できます。データセンターおよびリージョンと相互接続する AWS グローバルネットワークを流れるすべてのデータは、データセンターを離れる前に物理層で自動的に暗号化されます。

次の図では、専用接続とオンプレミスのリソースの両方が MacSec をサポートしている必要があります。データセンターとの間にある、専用接続を通過するレイヤ 2 トラフィックは暗号化されます。


これまで、ネットワークと AWS の間で転送中のデータをマルチギガビットの速度で保護するには、単一の VPN 接続を使用する場合のスループット制限を避けるために複数の IPsec VPN トンネルを集約する必要がありました。このようなソリューションは複雑であるため、運用リスクが高まり、10 Gbps を超える高速接続を確保することによる利点がなくなります。MACsec サポートのリリースにより、AWS Direct Connect は、10 Gbps および 100 Gbps の専用接続に対してネイティブでほぼラインレートのポイントツーポイント暗号化を提供するようになり、AWS とデータセンター、オフィス、またはコロケーション施設との間のデータ通信が引き続き保護されます。
参考URL : MAC セキュリティ

■以下は間違いです。
・VPC にインターネットゲートウェイを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
→VPN は安全な接続性を提供するだけであり、安定したパフォーマンスを提供することはできないため間違いです。

インターネットゲートウェイを通じた VPN 接続を提案していますが、安全な接続性を提供するだけであり、帯域幅の制約や安定性の問題があるため、安定したパフォーマンスを提供することはできません。

・Direct Connect 接続でパブリック仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
・Direct Connect 接続でプライベート仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
→VPN over AWS Direct Connect は、利用可能な最高の帯域幅でパフォーマンスを提供しないため間違いです。

VPN 接続は、暗号化や安全性のために追加のオーバーヘッドをもたらすため、最大帯域幅でのパフォーマンスが得られません。これは、オンプレミスのデータセンターと Amazon VPC の間で利用可能な最高の帯域幅で一貫したパフォーマンスを提供するという要件に適合しません。

スティッキーセッション

ログアウトの理由は、セッションが維持されず、リクエストが異なるインスタンスに送信されるためです。スティッキーセッションは、Cookie 転送用に設定された Application Load Balancer と Amazon CloudFront に対して有効にする必要があります。

・CloudFront ディストリビューションのキャッシュ動作で Cookie 転送を設定します。
→Amazon CloudFront ディストリビューションのキャッシュ動作で Cookie 転送を設定することにより、セッション情報を維持できます。これによって、ユーザーがログアウトする問題が解決されます。

・ALB のターゲットグループでスティッキーセッションを有効にします。
→Application Load Balancer (ALB) のターゲットグループでスティッキーセッションを有効にすることで、ユーザーのリクエストが同じインスタンスに送信され続けます。これにより、セッションが維持され、ログアウト問題が解消されます。

※Application Load Balancer のスティッキーセッション
デフォルトでは、Application Load Balancer は、選択したロードバランシングアルゴリズムに基づいて、登録されたターゲットに各リクエストを個別にルーティングします。ただし、スティッキーセッション機能 (セッションアフィニティとも呼ばれます) を使用して、ロードバランサーがユーザーのセッションを特定のターゲットにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じターゲットに送信されます。これは、クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます。スティッキーセッションを使用するには、クライアントが Cookie をサポートする必要があります。

Application Load Balancer は、期間ベースの Cookie とアプリケーションベースの Cookie の両方をサポートします。スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間の決定です。ターゲットグループレベルでスティッキーセッションを有効にします。すべてのターゲットグループで、期間ベースの維持、アプリケーションベースの維持、および維持しないの組み合わせを使用できます。
参考URL : Application Load Balancer のスティッキーセッション

※Cookie に基づくコンテンツのキャッシュ
デフォルトでは、CloudFront はリクエストとレスポンスを処理するとき、またはオブジェクトをエッジロケーションにキャッシュするときに Cookie を考慮しません。CloudFront が Cookie ヘッダーに含まれる内容以外は同一の 2 つのリクエストを受信した場合、デフォルトでは、CloudFront はリクエストを同一として扱い、両方のリクエストに対して同じオブジェクトを返します。
参考URL : Cookie に基づくコンテンツのキャッシュ

■以下は間違いです。
・ALB リスナールールでグループレベルのスティッキーネスを有効にします。
→スティッキーネスは、セッション維持に役立ちますが、リスナールールではなく、Application Load Balancer のターゲットグループで設定する必要があります。この選択肢では、問題が解決されません。

※Application Load Balancer がアプリケーション Cookie のスティッキーネスのサポートを開始
Application Load Balancer (ALB) がアプリケーション Cookie のスティッキーネスのサポートを開始しました。この新機能は、クライアントがアプリケーション Cookie を使用して、セッション中に同じターゲットのロードバランサーに接続できることを保証するのに役立ちます。これにより、カスタム Cookie 名を設定する柔軟性や、ターゲットグループ内でのクライアントターゲットのスティッキーネスの基準など、より優れた制御により、一貫性のあるクライアントサーバー体験を実現できます。
参考URL : Application Load Balancer がアプリケーション Cookie のスティッキーネスのサポートを開始

・CloudFront ディストリビューションのキャッシュ動作でヘッダー転送を設定します。
→ヘッダー転送は、キャッシュ動作と関連する設定であり、セッション維持とは直接関係がありません。問題を解決するためには、Cookie 転送を設定する必要があります。

・ALB のターゲットグループの最小未処理リクエストアルゴリズムに変更します。
→最小未処理リクエストアルゴリズムは、リクエストのロードバランシングに関するものであり、セッションの維持には関係ありません。したがって、この選択肢ではログアウト問題は解決されません。

※Application Load Balancer のターゲットグループ
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。
参考URL : Application Load Balancer のターゲットグループ

※最小未処理リクエストアルゴリズム
最小未処理リクエスト (LOR) アルゴリズムを使用してターゲットグループ内でリクエストをルーティングすることを選択できます。このアルゴリズムを使用すると、新しいリクエストが到着したときにロードバランサーが未処理のリクエスト数が 最も少ないターゲット にリクエストを送信します。長期にわたるリクエストを処理するターゲットや処理能力が低いターゲットは、リクエストが増えても負荷がかからず、ターゲット全体に負荷が均等に分散されます。これは、新しいターゲットが過負荷のターゲットから効果的に負荷を取り除くためにも役立ちます。
参考URL : 最小未処理リクエストアルゴリズム