Amazon ANS-C01: ロードバランシングとトラフィック管理 — 学習ガイド

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

こちらの一部です： AWS Advanced Networking Specialty ANS-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

コアコンセプト

AWSにおけるロードバランシングは、L4（トランスポート）とL7（アプリケーション）という2つの基本的なレイヤーで動作します。Network Load Balancer (NLB) はL4（TCP/UDP/TLS）の分散を提供し、極めて高いパフォーマンスに最適化されており、クライアントの送信元IPを維持し、非常に低いレイテンシーと接続チャーンで数百万の同時接続をサポートします。Application Load Balancer (ALB) はL7（HTTP/HTTPS/WebSocketおよびHTTP/2/gRPC）で動作し、ホストベースおよびパスベースのルーティング、ヘッダーの検査、HTTPベースのヘルスチェック、Cookieベースのスティッキネスを提供し、ACMの証明書で設定されている場合、TLS終端を実行します。Gateway Load Balancer (GWLB) は、サードパーティ製の仮想アプライアンス（ファイアウォール、IDS/IPS）をスケールさせるための専用ロードバランサーで、GENEVEカプセル化とGateway Load Balancerエンドポイント（GWLBe）を使用して、手動でのアプライアンスのスケーリングなしにインラインでのトラフィック検査を可能にします。

リスナーとリスナールールは、プロトコル/ポートをターゲットグループにマッピングするL4/L7のエントリポイントです。ALBのリスナーは、ホスト、パス、ヘッダー、送信元IPのCIDRを検査し、異なるターゲットグループに転送する複雑なルールを持つことができます。また、ALBはTLSをオフロード（終端）し、X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Portヘッダーをターゲットに渡すことができます。NLBのリスナーは通常、ペイロードを解析することなくトラフィックをターゲットグループに転送するTCP/UDP/TLSリスナーです（NLBでTLS終端を有効にする場合を除く）。TCPパススルーを使用する場合、エンドツーエンドのTLSが維持されるため、バックエンドは相互TLSのために証明書を提示し、検証する必要があります。ターゲットグループは、ロードバランサーのリスナーとエンドポイント（インスタンス、IP、またはLambda）のセットとの間の紐付けであり、ヘルスチェックのプロトコル/ポート/パス、登録解除の遅延（コネクションドレイニング）、スティッキネスのプロパティなどの属性を公開します。

主要なサービスと設定

トラフィックの特性とセキュリティ要件に適したバランサーを選択します。ホスト/パスベースのルーティング、WebSocketやHTTP/2/gRPCなどのHTTP/HTTPS機能とアプリケーションを意識したルーティング、Cookieベースのスティッキネスが必要な場合はALBを使用します。ALBリスナーを

undefined

またはAWS::ElasticLoadBalancingV2::Listener経由で設定し、ACMから証明書をアタッチし、条件（Field=path-pattern, host-header, http-header）を指定して

undefined

でリスナールールを設定します。ALBターゲットグループでスティッキネスを有効にするには、

undefined

でKey=stickiness.enabled,Value=trueおよびKey=stickiness.lb_cookie.duration_seconds,Value=<seconds>を設定し、ロードバランサーが生成したCookieを使用します。

高スループットで長寿命なTCP接続や、バックエンドでクライアントの送信元IPの維持が必要な場合はNLBを使用します。

undefined

でNLBを作成し、

undefined

でTCPリスナーを追加します。パススルーTLSおよびmTLSの場合、TLSがバックエンドで終端されるように、NLBリスナーをTCPとして設定します。KubernetesのPod IPを登録する際は、ターゲットグループのtarget-typeをipに設定します。コネクションドレイニングを許可するために、

undefined

を使用してKey=deregistration_delay.timeout_seconds,Value=<seconds>を設定します。NLBでは、必要に応じて送信元IPアフィニティ（ターゲットグループのスティッキネス）を有効にすることもできます。

Gateway Load Balancerは、

undefined

Type=gatewayで設定され、アプライアンスインスタンス（またはオートスケーリンググループ内のスケールセット）のターゲットグループによって支えられます。そして、コンシューマーVPC内のGateway Load Balancerエンドポイントを使用して、サービスVPCのアプライアンスにトラフィックを誘導します。このパターンは、透過的な検査が必要で、トラフィックに応じてアプライアンスを自動的にスケールさせたい場合に使用します。ポート6081（GENEVEカプセル化）でリスナーを作成し、GWLBターゲットグループにアプライアンスのENIを登録します。

プログラムで制御する必要がある運用設定には、クロスゾーン負荷分散、登録解除の遅延（コネクションドレイニング）、ヘルスチェックのチューニングが含まれます。クロスゾーン負荷分散については、ロードバランサーの属性を（

undefined

）設定し、AZごとのキャパシティに偏るのではなく、AZ間でトラフィックが分散されるようにします。オートスケーリングイベント中のフラッピングを避けるため、ターゲットグループでヘルスチェックの間隔、タイムアウト、正常/非正常のしきい値を設定します。

設計パターンとトレードオフ

エンドツーエンドTLSおよび相互TLS (mTLS) のように、トラフィックを暗号化したまま維持し、クライアント証明書をバックエンドに提示する必要がある場合は、TCPリスナーを持つNLBを使用したL4パススルーが推奨されます。これによりTLSセッションが維持されるため、バックエンドはクライアントのX.509証明書を検証できます。ターゲットグループをIPターゲットを使用するように設定することで、KubernetesのPod IPを直接登録でき、AWS Load Balancer Controllerがターゲットのライフサイクルを管理できます。トレードオフとして、ホスト/パスベースのルーティング、Web Application Firewallとの統合、ロードバランサー層でのネイティブなHTTPクッキーによるスティッキネスといったALBのL7機能を失うことになります。

コンテンツベースのルーティング、TLS終端、および高度なHTTP機能が必要な場合は、ALBを使用し、ALBでTLSを終端します（ACMで管理される証明書を使用）。ロギングやWAFルールでクライアントIPを保持するには、ALBが設定するX-Forwarded-Forヘッダーを読み取るか、元のクライアントIPをヘッダーに挿入するレイヤーを使用します。バックエンドのOS/ネットワークスタックがソケットレベルでクライアントIPを認識する必要がある場合は、NLBを使用します（またはProxy Protocolを有効にして元のIPを渡します）。ただし、Proxy Protocolはターゲットグループで有効にする必要があり、アプリケーションまたはプロキシ（例: Envoy）がそれをパースする必要があることに注意してください。

オートスケーリング環境でスティッキーセッションを扱うには、慎重な検討が必要です。ALBのクッキーによるスティッキネスは、クライアントを一定期間ターゲットに紐付けますが、セッショントラフィックが多い場合にPod間の均等なスケーリングを妨げる可能性があります。代替パターンとしては、短期間のスティッキネスとElastiCache (Redis) やDynamoDBへのセッション状態の外部化を組み合わせる方法や、サイドカープロキシ（Envoy）を使用してコンシステントハッシュでセッションアフィニティを処理する方法があります。グレースフルシャットダウンには、コネクションドレイニング（登録解除の遅延）が不可欠です。Podの終了時に突然の通信切断やクライアントエラーを避けるため、deregistration_delay.timeout_secondsを最も長いRPC/HTTPリクエストよりも長い期間に設定します。また、KubernetesのpreStopフックを設定して、Podのライフサイクルを登録解除と連携させます。

多くのVPCにまたがってスケーラブルなインライン検査が必要で、一元化されたセキュリティ制御を行いたい場合、GWLBが適切なパターンです。必要に応じてGWLBをTransit GatewayやVPCピアリングアーキテクチャと組み合わせます。アプライアンス管理のコストと運用の複雑さが、AWS Network Firewallのようなマネージドサービスを利用する場合とのトレードオフになります。

一般的な落とし穴と判断基準

よくある間違いは、ダウンストリームでのクライアント認証や元の送信元IPの必要性を考慮せずにALBでTLSを終端することです。バックエンドが（ロギングや認可のために）TCPレイヤーでクライアント証明書や真の送信元IPを必要とする場合は、NLBのパススルーを介してバックエンドでTLSを終端するか、Proxy Protocolを使用してアプリケーションがそれをパースするようにします。もう一つの一般的な落とし穴は、Horizontal Pod Autoscalerを使用している状況で、外部セッションストレージなしでスティッキーセッションを有効にすることです。Podがスケールアウトまたはスケールインするにつれて、スティッキーアフィニティがホットスポットや無駄なキャパシティを生み出す可能性があります。ステートレスなバックエンドを優先するか、セッション状態を外部化してください。

また、不適切なヘルスチェック設定や登録解除の遅延に起因する運用上のエラーもあり、スケーリング中にリクエストがドロップされる原因となります。常にヘルスチェックのパスと閾値をアプリケーションのウォームアップを反映するように設定し、長時間接続がドレイン（正常に完了）するのを許可するためにderegistration_delay.timeout_secondsを使用してください。クロスゾーン負荷分散は意図的に設定する必要があります。有効にするとテールレイテンシーが削減され負荷が均等になりますが、AZ間のデータ転送料金が増加する可能性があります。AZのキャパシティとトラフィックパターンを評価して判断してください。最後に、GWLBはカプセル化（GENEVE）とアプライアンス管理のオーバーヘッドを導入します。AWS API（CreateTargetGroup/RegisterTargets）を使用してアプライアンスの登録を自動化し、CloudWatchメトリクスで計測してオートスケーリングポリシーを駆動してください。

実践的な問題：ユースケースシナリオ

会社：Acme Telemetry。課題：Amazon EKSクラスターにデプロイされたgRPCサービス（TCPポート443上のTLSを介したgRPC）にエンドツーエンドの暗号化を提供し、数千の同時長寿命接続をサポートし、Kubernetes Cluster AutoscalerとHPAを使用し、クライアント証明書がバックエンドによって検証されるように相互TLS（mTLS）を要求する（つまり、トラフィックは中間ロードバランサーによって復号化されてはならない）。

ユースケースの実装アプローチ：ポート443にTCPリスナーを持つNetwork Load Balancerと、PodのIPを指すタイプ「ip」のターゲットグループをプロビジョニングします。aws elbv2 create-load-balancer --name acme-nlb --type network --subnets <subnet-ids>でNLBを作成し、aws elbv2 create-target-group --name tg-grpc --protocol TCP --port 443 --target-type ip --vpc-id <vpc-id>でターゲットグループを作成します。KubernetesのAWS Load Balancer Controllerアノテーション（service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"）を介してターゲットを登録し、コントローラーがPodのIPを自動的に登録するようにします。そして、aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn>でリスナーを作成します。グレースフルなドレイニングを有効にするために、aws elbv2 modify-target-group-attributesを使用してターゲットグループの属性deregistration_delay.timeout_secondsを適切な値（例：300）に設定します。
バックエンドのTLSおよびmTLS設定：PodレイヤーでTLSを終端し、相互TLSを実行します。Envoyサイドカーをデプロイするか、gRPCサーバーが直接TLSを受け入れるようにし、サーバー証明書とCAバンドルをKubernetes Secretsに保存してPodにマウントします。バックエンドがCAに対してクライアント証明書を検証するように設定し、ロードバランサーでのTLS終端を避けるためにヘルスチェックがTCPを使用するように設定します。HPAとCluster Autoscalerのライフサイクルフックがターゲットグループの登録解除と連携するように、Podが終了する前にドレイニングを完了できるようにするpreStopフックを実装します。
スケーラビリティと運用管理：必要に応じてaws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=trueを使用してNLBでクロスゾーン負荷分散を有効にし、AZ間で接続を均等に分散します。CloudWatchメトリクス（NLBのNetworkPackets、ActiveFlowCount）で同時接続数とフローレートを監視し、アプライアンス（サイドカーを使用している場合）とワーカーノードのオートスケーリングポリシーを設定します。フラッピング（不安定な状態）を起こさずに、より迅速な障害検出のためにヘルスチェックの間隔を調整し、コネクションドレイニングにはModifyTargetGroupAttributesを使用します。最後に、AWS Secrets ManagerとKubernetesのcert-managerの統合を使用して証明書のローテーションを自動化します。

AWSの論理的根拠：TCPモードのNLBはTLSセッションをエンドツーエンドで維持するため、バックエンドはmTLS検証を実行できます。そのL4アーキテクチャは、数百万の同時フローと長寿命の接続のために構築されており、target-type ipを使用することで、AWS Load Balancer ControllerがPodのIPを直接登録でき、HPA/Cluster Autoscalerが透過的にスケールできるようになります。コネクションドレイニング（deregistration_delay）とヘルスチェックにより、Pod終了時のリクエストロスを防ぎ、クロスゾーンバランシングは、パフォーマンスと引き換えにAZ間の転送料コストを許容しつつ、AZ間での均等な分散を保証します。

← DNSとRoute 53 · すべてのドメイン · ネットワークセキュリティとコンプライアンス →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →