ANS-1.3高可用性、スケーラビリティ、セキュリティ要件を満たすようにロードバランシングを統合するソリューションを設計する。

ヒントボタン

単一で変わらないグローバル IP を外部に提示したい場合、Route 53 のエイリアスやパブリック ALB では背後の ENI 増減に伴い IP が変動するため「固定」とは言えません。Global Accelerator の任意キャスト IP は世界中で同一の 2 つの IPv4 を恒久的に保持し、さらにサービスそのものに 99.99% の SLA が明示されているため、可用性と固定 IP の両立を最小運用で満たせる点が大きな手掛かりになります。

OWASP Top10 に準拠したアプリケーション層防御をローコードで実装するには AWS WAF マネージドルールを直接アタッチできるリソースを選ぶのが近道です。現時点で WAF を関連付けられるロードバランサーは Application Load Balancer であり Network Load Balancer には未対応なので、TLS 終端と L7 防御を同じ場所で行いたい要件では ALB を用いた構成が本流になります。

秒間 5 万リクエストというスループットは ALB と Auto Scaling グループの水平スケールで現実的にさばけますが、クライアント元 IP の透過は X-Forwarded-For が追加されれば問題ありません。ここに Global Accelerator を前段に置くと最適 PoP で受けた通信が低遅延でリージョンに到達し、アプリ側でヘッダーを読むだけで IP を取得できます。これら複数の要件を俯瞰すると「固定 IP」「高 SLA」「L7 防御」「運用簡素化」を同時にかなえる組み合わせが自然と浮かび上がるはずです。

ヒントボタン

1. TLS証明書を人手で更新しない仕組みを探す場合、AWS Certificate Manager と統合されたリソースを前段に置くことが鍵です。ACM は Application Load Balancer や HTTPS 対応 Network Load Balancer とネイティブ連携し、Route 53 の DNS 検証で自動発行・自動ローテーションが行えます。CloudTrail に証跡が残るため金融機関の監査証明にも有効で、自己署名や手動アップロードの作業負荷をゼロにできます。

2. URL パスでマイクロサービスを振り分けたい場合、レイヤ 7 でルールを書ける Application Load Balancer が最もシンプルです。ALB は ECS Fargate サービスをターゲットに直接登録でき、/api や /login などのパスごとにターゲットグループを切り替えられます。さらに AWS WAF v2 を同じ ALB に関連付ければ OWASP Top-10 に対応したマネージドルールを数クリックで有効化でき、Terraform や CloudFormation でコード化も可能です。

3. RTO 5 分以内を求められる場合、マルチ AZ で自動フェイルオーバーする Application Load Balancer とステートレスな ECS Fargate の組み合わせが優位です。ALB は AZ 障害時も自動で健全ターゲットにトラフィックを流し、Fargate は Service Auto Scaling ですぐにタスクを補充します。TLS 自動管理、L7 ルーティング、AWS WAF によるセキュリティを単一エントリポイントに集約できる構成が、可用性・セキュリティ・運用負荷の全要件を最もバランス良く満たします。

ヒントボタン

CloudFront 経由では多くのエンドユーザがエッジサーバの共通 IP で Application Load Balancer に到達しますので、Network Load Balancer のソース IP アドレスアフィニティのような IP ベース固定ではユーザ識別が困難であり、代わりに ALB が発行する AWSALB Cookie と durationSeconds を活用したスティッキーセッションで 30 分間タスクを保持しつつ、Fargate タスク側の実装変更も不要にできます。
Application Load Balancer のリスナールールはパスベースルーティングをサポートしており、/cart 用のターゲットグループにだけロードバランサー生成 Cookie を付与し durationSeconds を 1800 に設定する一方、他のパスはスティッキーを無効にしてラウンドロビンで分散できるため、ターゲットグループ単位のきめ細かな制御で要件をシンプルに満たせます。
追加ミドルウェアを入れずにマルチ AZ の Amazon ECS on Fargate サービスを背後で動かしつつ、CloudFront からの共有 IP、30 分間のセッション維持、/cart のみの固定という複数条件を俯瞰すると、ALB のパス別ターゲットグループにロードバランサー生成 Cookie スティッキーを組み合わせる構成が柔軟性、運用負荷、拡張性の三面で最適だと総合判断できます。

ヒントボタン

HTTP/2 ストリーミングを L7 で処理しつつ AWS WAF の WebACL を直接関連付けられるロードバランサーは現状 Application Load Balancer のみであり、Network Load Balancer や Classic Load Balancer では TCP レイヤーや旧仕様が中心で HTTP/2 やルールベース防御を補う追加プロキシやスクリプトが必要となって運用とレイテンシが跳ね上がるため、シンプルに視聴体験を守るには ALB を選ぶ発想が極めて重要になります。
EKS の Pod は HPA に従い数秒単位で増減し IP が入れ替わるため、ターゲットタイプを ip にして AWS Load Balancer Controller が Pod IP を自動登録・削除してくれる構成でなければ 1 万同時接続の最中にエンドポイントが消えクライアント再接続が頻発する恐れがあり、さらにスティッキー Cookie を 1,200 秒に伸ばせる ALB の機能を組み合わせれば 20 分維持というアプリ側要求を無理なく充足できます。
HTTP/2 対応、AWS WAF 連携、Pod 単位の自動ターゲット登録、1,200 秒のスティッキーセッション、最小運用という複数の要件を総合的に俯瞰すると、Amazon EKS とネイティブに統合されている Application Load Balancer と AWS Load Balancer Controller の組み合わせが唯一すべての条件を自然に両立させることが見えてきます。

ヒントボタン

AWS Certificate Manager で発行した証明書を自動更新しながら HTTPS を終端し、ドメイン単位でまとめて管理したいときは、リスナーに ACM 証明書を直接アタッチできて更新も完全に自動化される Application Load Balancer が最もシンプルです。Network Load Balancer で終端する場合は証明書を各ポートごとに手動登録する必要があり、API Gateway はステージごとに独立管理になるため運用が煩雑化します。

動的な /api/* リクエストはプライベートサブネット内の EKS サービスへ、静的な /static/* リクエストは S3 静的ホスティングへといった URL のパスごと振り分けは、リスナー規則でパスベースルーティングや固定レスポンス・リダイレクトが設定できる Application Load Balancer の代表的機能で、Layer4 の Network Load Balancer や Classic Load Balancer では URL を解釈できず、API Gateway を使うと料金やスロットルを考慮した設計が別途必要になります。

二つのアベイラビリティゾーンで二万セッションを同時に捌きつつクライアント IP をアプリケーションログに残すには、クロスゾーン負荷分散で自動スケールし X-Forwarded-For ヘッダを付与してくれる Application Load Balancer が適合し、マネージドで帯域に応じて伸縮するため EKS 側の Auto Scaling と組み合わせても追加設定が最小で済みます。

以上を踏まえると、HTTPS 終端・パスルーティング・高同時接続と IP 伝搬の全要件を一台で満たし運用を簡易化できるロードバランサを選ぶことが最も合理的です。

ヒントボタン

60,000 接続/分の TLS を三つの AZ に分散させる場合、暗号化オフロードの同時スケールと Cross-Zone 負荷分散が要求されます。Application Load Balancer は TLS リスナーを持ち、接続数に応じてキャパシティユニットを自動追加できるため、EC2 や Fargate 側に負担を残さず捌くことができます。Network Load Balancer も TLS 終端自体は可能ですが、後述のセッション保持方式が限定される点を念頭に置いて比較してみましょう。

ショッピングカートを 15 分保持したい場合、ロードバランサーレベルのスティッキーセッションは実装コストが最小で済みます。Application Load Balancer の lb_cookie は有効期限を最大 7 日まで任意秒数で設定でき、モバイル NAT で IP が頻繁に変わっても維持できます。Network Load Balancer の source IP 固定はキャリア回線やプロキシ環境で IP が変化するとセッションが切れるため、ユーザ体験に影響しないか慎重に考えるとヒントが見えてくるはずです。

証明書の自動更新とダウンタイムなしのリリースを同時に満たしたいなら、AWS Certificate Manager と CodeDeploy Blue/Green を組み合わせた二つのターゲットグループ切替が王道です。ACM は ALB や NLB にワイルドカード証明書を自動展開しますが、ECS Blue/Green が扱えるのは Application Load Balancer ベースの構成です。TLS 終端、セッション保持、リリース方式の三要件を横断的に突き合わせたとき、すべてを追加開発なしで満たせる組み合わせを探してみてください。

ヒントボタン

単一のホスト名を保ったまま /trade と /quote を分岐させるには、パス条件を理解できるレイヤ7のロードバランサが不可欠です。Application Load Balancer なら Listener Rule に「/trade」「/quote」を並べるだけで済み、Network Load Balancer は L4 なので不可、Classic Load Balancer も URL 判定を持ちません。さらに Fargate タスクを IP ターゲットとして登録できるのは ALB のみで、タスク起動に伴う ENI 変化を自動追跡でき、手動更新の運用が不要になる点も見逃せません。

TLS 証明書の自動更新と OWASP Top10 防御を同時に満たすには、AWS Certificate Manager と AWS WAF を同一リソースに紐付けられるサービスを選ぶことが大切です。ALB であれば ACM の証明書をリスナーに設定するだけで期限管理が不要になり、同じ ALB に WAF ウェブ ACL を関連付ければ追加の CloudFront や API Gateway を挟まずとも SQL インジェクションや XSS を遮断できます。一方、Network Load Balancer は現状 WAF 非対応で、CloudFront を前段に置くとディストリビューション管理やレイテンシ増が運用コストになります。

毎秒 2,000 ハンドシェイクと 1 万同時接続、3AZ 構成で RTO 5 分、単一 FQDN でのレート制限、将来的なスケールアウトという複数要件を俯瞰すると、Application Load Balancer が備えるパス分岐・ACM 連携・AWS WAF 統合・X-Forwarded-For 付与・IP ターゲット登録を一台で活かし、ECS on Fargate のオートスケーリングと組み合わせる構成が、最少リソースで高可用性と運用負荷最小化の両立を実現できる総合的な判断となります。

ヒントボタン

ヒント1
単一の FQDN を維持したまま「パス /admin」かつ「送信元 10.0.0.0/8 だけ許可」という複合条件で振り分けるには、Layer7 でパスベースと IP 条件を同時に組める Application Load Balancer のリスナールールが最もシンプルです。HTTPS リスナーに ACM ワイルドカード証明書を関連付ければ更新業務は ACM が自動化し、複数 AZ に配置されるため高可用性もデフォルトで満たせます。

ヒント2
ユーザーセッションを 10 分間維持するにはスティッキーセッション機能が必要です。Network Load Balancer はそもそも Cookie を扱えず、Classic Load Balancer の ELB Cookie は TTL を独自に指定できますが既定値が短い構成例も多く注意が要ります。一方 Application Load Balancer なら Application-based Cookie を 1 秒〜7 日まで細かく設定でき、600 秒の要件を簡単に実現できます。

ヒント3
ルーティング条件の柔軟性、HTTPS 終端と ACM 連携、スティッキーの細かな TTL 設定、マルチ AZ による高可用、そしてリソース数を最小化して運用コストも抑えるという複数要件を俯瞰すると、Layer7 の機能が豊富な各種 ELB の中でも Application Load Balancer を 1 台で完結させる設計が最も合理的だと判断できます。

ヒントボタン

同時 5 万接続をさばきつつ TLS 終端と HTTP レイヤ 7 の URL リライトをクラウドで完結させたい場合、スケーラブルでフルマネージドな Application Load Balancer を前段に置き、ACM にアップロードした証明書を HTTPS リスナーに割り当てるだけで暗号化解除・ヘッダ書き換え・パスベースルーティングが GUI で設定できるため、手作業の運用が極小化できます。
オンプレミス側の 10.0.1.0/24 にある Web サーバーも Auto Scaling で増減する EC2 と同一のターゲットグループで扱うには、Direct Connect で結ばれたプライベート IP を Application Load Balancer のターゲットタイプを IP にして登録する必要があり、instance 型を選ぶと ENI を持つ EC2／ECS しか追加できないことがポイントです。
少なくとも 20 分間ユーザーを同じバックエンドに固定する要件は、Application Load Balancer が自動発行する AWSALBCookie の有効期限を 1200 秒に設定すれば解決し、Network Load Balancer は L4 で Cookie 制御や TLS 終端ができず、Gateway Load Balancer はセキュリティアプライアンス専用でオーバースペックになるため、全要件を満たす構成を総合的に選択してください。

ヒントボタン

金融取引のように P99 3 ms 未満で 5 万同時接続と 1 万 TLS ハンドシェイク/秒をこなすには、EC2 だけでなくロードバランサの性能が鍵です。ALB は TLS を終端する設計、Classic Load Balancer はスケーラビリティが旧式です。暗号化をパススルーしつつ超低レイテンシを実現しやすいのは Network Load Balancer で、単一エンドポイントで複数 Availability Zone を自動カバーできる強みがあります。DNS ベースの Route 53 フェイルオーバーだけでは切替に数十秒以上かかるため低遅延要件を保てません。

FIX セッションを 600 秒同じバックエンドに維持するにはロードバランサ側で TCP コネクションのスティッキー制御が欠かせません。ALB の Cookie スティッキーは HTTP/HTTPS 前提、Classic Load Balancer の Duration スティッキーも HTTP/S のみで TCP では利用できません。Network Load Balancer ならターゲットグループ属性で Source-IP ベース 1〜3600 秒の設定が行え、TLS パススルーでも問題なくセッションを固定できます。

バックエンドがクライアント送信元 IP を把握するには Proxy Protocol v2 が有効で、TLS を終端しない TCP リスナーでこの機能を提供できるのは Network Load Balancer です。NLB と Auto Scaling Group をマルチ AZ で組み合わせれば、高可用性、低遅延、5 万接続処理、エンドツーエンド暗号化、600 秒スティッキー、ソース IP 取得という複数要件を最小運用負荷で同時に満たせると総合的に判断できます。

ヒントボタン

Application Load Balancer のターゲットグループには slow-start という登録直後の EC2 Auto Scaling インスタンスへ流すリクエスト割合を段階的に増やす仕組みがあり、CPU が温まる 90 秒前後のウォームアップを安全にやり過ごすため持続時間を 120 秒程度に設定すればコード改修や追加コストなしで 5XX スパイクを抑え、既存ヘルスチェックもそのまま維持したままピークトラフィックへ滑らかに到達できます。
同じ Application Load Balancer でも deregistration delay や Classic Load Balancer の connection draining はスケールインや置換時にターゲットが外れる局面で未完了リクエストを処理させる機能であり、起動直後の EC2 が高負荷になるタイミングとは方向が異なるため流量制御には寄与せず、逆に unhealthy threshold を大きくすると障害検出が遅れ Auto Scaling の回復も遅延して平均 5XX が長引くリスクを招きます。
HTTP/2 への切替や最大キャパシティ倍増で並列性を確保する策はコスト増やレイテンシ増大といった副作用が大きく、登録直後の個体に対してトラフィックを緩やかに与えるという要件を直接満たさないため、トランスポート変更や台数追加ではなく Application Load Balancer の slow-start でウォームアップと SLA、コスト、改修範囲という複数要件を俯瞰した総合判断が最も合理的といえます。

ヒントボタン

1. ステートフル検査を維持したまま Auto Scaling するには、同一フローを同一 EC2 にピン留めしつつ送信元 IP を失わない転送方式が不可欠です。Gateway Load Balancer は Geneve トンネルで元パケットを包むため L3/L4 ヘッダーを保持し、最大 25 Gbps まで拡張できます。背後のファイアウォール EC2 が増減しても 3 タプルハッシュでフローを固定してくれるため、1 Gbps 超のトラフィックでもセッション切断が起こりにくい設計になります。

2. 既存のスポーク VPC に大規模な変更を加えないことが重要です。Gateway Load Balancer エンドポイント（GWLBE）は ENI と同様に振る舞い、ルートテーブルの 0.0.0.0/0 を GWLBE に向けるだけでアウトバウンド通信が自動的に検査を経由します。セキュリティグループやアプリケーションの IP 設定を変更する必要がなく、オンボーディングはエンドポイントの作成とルーティングの差し替えだけで完了するため運用がシンプルです。

3. 可用性の観点では、ロードバランサ自身がマルチ AZ で冗長化され、障害インスタンスを自動的に外す仕組みが求められます。Network Load Balancer は主に TCP/UDP を扱い、ICMP やその他 L3 プロトコルを透過するには追加設計が必要です。対照的に Gateway Load Balancer はプロトコル非依存で全 IPv4 トラフィックを転送でき、各 AZ に配置したエンドポイント経由で単一点障害を排除しやすい特徴があります。

総合的には Geneve による IP 透過性、スポーク側の最小変更、高スループットとマルチ AZ 冗長をネイティブに備えた構成が、提示された全要件をバランス良く充足します。

ヒントボタン

GENEVE トンネルを用いた透過転送をマネージドで提供しサードパーティ IPS をインライン配置できるのは Gateway Load Balancer だけで、各開発 VPC ではサブネットに GWLB エンドポイントを 1 つ置き 0.0.0.0/0 をその VPCE へ向けるだけで済むため、VPC 数が倍増してもルートテーブル変更工数がほぼ増えないうえ既存サブネットやセキュリティグループを変えずに段階的な導入が容易です。
Gateway Load Balancer はフローごとの状態を保持したままヘルスチェック異常を検知すると 500ms 未満で別アプライアンスへ転送でき、Auto Scaling Group と連動させれば 10Gbps や 2,000 同時接続のピークも自動的に捌けるうえ、Transit Gateway と組み合わせて VPC 間通信を一元化すれば RTO 60 秒要件も余裕を持ってクリアできます。
GENEVE 対応可否、0.0.0.0/0 をまとめるシンプルなルート、500ms のフェイルオーバー、高スループット、将来的な VPC 増加時の運用負荷、RTO 60 秒という複数要件を俯瞰すると、中央検査 VPC に Gateway Load Balancer と Transit Gateway を配置し各開発 VPC では GWLB エンドポイントへ集約する構成が総合的に最もバランスが取れています。

ヒントボタン

Gateway Load Balancer はリージョンリソースですが、各アベイラビリティーゾーンに用意した GWL エンドポイントをルートテーブルで“同一 AZ 内”に向ければ、通常時のトラフィックはゾーン外へ出ずに検査が完了します。これにより 1 GiB あたり 0.01USD のクロス AZ 料金を回避しつつレイテンシーも抑えられます。
ターゲットグループを AZ ごとに分割して ENI を登録すると、GWLB のヘルスチェックが個別に状態を監視し、不健全時は別ゾーンの健全 ENI へ自動で切り替えます。各ゾーンに 20 Gbps 分ずつファイアウォールを水平展開すれば合計 40 Gbps のアクティブ／アクティブ処理と AZ 障害時の無停止フェイルオーバーが実現できます。
ステートフル検査ではフローが常に同じアプライアンスを往復する必要がありますが、GWLB は 5 タプルベースのフロースティッキー機能で対称ルーティングを保証します。一方、Transit Gateway や Network Load Balancer のクロスゾーン転送はフロー整合性やコスト要件を同時に満たしにくいため、高帯域・低コスト・自動復旧・フロー固定を俯瞰して最適解を選択しましょう。

ヒントボタン

Application VPC のプライベートサブネットから出る全パケットをまず Gateway Load Balancer Endpoint に送り、検査 VPC 内の Gateway Load Balancer が同じ Availability Zone の IDS Auto Scaling グループへ透過転送し、続けて同一 Zone の NAT Gateway に流すと、セッション整合性とインターネット接続が担保され、AZ 間料金が不要になります。Endpoint は ENI 扱いのためコンテナ側の設定変更も不要で、ルートを 0.0.0.0/0 に書き換えるだけで 1 Gbps・5,000 同時接続の要件にも十分対応できます。

Network Load Balancer や Transit Gateway Appliance モードでもインライン検査は可能ですが、エンドポイントを経由しない復路や中央集約経路が発生しやすく、同一 Availability Zone 内で往復を完結させたい要件とは整合しにくいです。Gateway Load Balancer はステートフルなセッションピンニングで戻りパケットも元の IDS へ届けるため、可用性と運用簡素化を両立できます。さらに Gateway Load Balancer Endpoint を各サブネット内に置くことで帯域消費が局所化し、VPC 内 SLA も確保できます。

金融システムの高スループット要求、IDS 後に NAT 変換を行う必要性、同一 AZ 経路でコストを抑える方針、構成管理のシンプルさを総合的に評価すると、Gateway Load Balancer と Gateway Load Balancer Endpoint を組み合わせ、各 Availability Zone に専用の IDS と NAT Gateway を配置しルートを 0.0.0.0/0 で紐付ける分散ペア設計が複数要件を同時に満たす最適な解となります。

ヒントボタン

要件①②を満たすには、プライベートサブネットのあらゆる送受信をL3～L7で解析しつつファイアウォールのSNATだけでインターネットへ出す必要があります。NAT Gatewayを置かず透過インライン化できる手段として、Gateway Load BalancerとGateway Load Balancerエンドポイントが最適で、2ENI型の仮想アプライアンスをVPCに挿入しGeneveトンネルで経路対称性を保ちながら大量セッションを処理できます。

要件③の「AZ障害時5分以内復旧・毎分2Gbpsスケール」には、ヘルスチェック連動で即時フェイルオーバーしEC2 Auto Scalingと連携できるロードバランサーが不可欠です。Gateway Load Balancerはターゲット異常時に即座に別インスタンスへ転送し、ターゲットグループを秒単位で増減させられるため、Route 53や手動オペレーションに頼る構成より遥かに迅速・自動的にキャパシティを確保できます。

ルートテーブル変更を最小に抑える要件④では、各プライベートサブネットの既定ルートをGWLBeへ向けるだけで完結する構成が管理負荷を最小化します。Network Load BalancerやTransit Gatewayを介す案は静的ルートやNAT設定が増えがちですが、Gateway Load Balancerなら追加のNAT Gateway不要で可用性・スケール・運用簡素化を総合的に両立できると判断できます。

ヒントボタン

レイヤー4の独自TCPで毎秒1万接続と3秒以内のAZフェイルオーバーという条件が示されたら、TLS終端を持たず数百万同時接続を捌けるNetwork Load Balancerを想起すると良く、NLBは複数AZのターゲットをヘルスチェックで監視して健全なAZへトラフィックを速やかに切り替えられ、さらにAuto Scalingグループと組み合わせれば負荷に応じた水平拡張も自動化できます。
インターネット経由を避けながら顧客VPCからシームレスにアクセスしてもらうには、NLBをVPCエンドポイントサービスとして公開し各顧客がInterface VPCエンドポイントを張る方式が適しており、このENIはサブネット内のローカルIPとして動作するためルートテーブルやNACLの追加変更を不要にしつつ、エンドポイント単位でVPC Flow Logsを有効化でき監査にも直結します。
Transit GatewayやVPCピアリングを組む案はルーティング調整やセキュリティ設定が顧客側に発生し、Application Load BalancerやCloudFrontはHTTP想定で独自TCPを扱えず、Global AcceleratorはAnycast公開でプライベート要件に反する一方、Auto Scaling対応のNetwork Load BalancerをVPCエンドポイントサービスとして配布する構成ならAWSバックボーンだけで通信し運用と管理を簡素化できるため、全要件を俯瞰するとこの選択肢が最も整合的です。

ヒントボタン

クライアント証明書をアプリケーションコンテナで検証したい場合はTLSセッションをポッドのIPまで終端させないことが必須で、Application Load BalancerやIngress-NGINXは途中で復号するため不適ですが、Network Load BalancerをAmazon EKSのAWS Load Balancer Controllerでannotation指定して自動作成すればTCPパススルーにより暗号化を維持したままPCI-DSS要件を満たせます。
送信元IPアドレスをアプリ層へ届けるにはHTTPヘッダーが使えないL4転送時にメタデータを補う必要があり、Network Load BalancerはProxy Protocol v2をサポートするのでAmazon EKSのService manifestにnlb-ipとproxy-protocolのannotationを追加するだけでPodはmTLSセッションを維持したまま元IPを受け取れます。
1リージョン3AZで秒間5,000接続を処理しつつマニフェストのみでロードバランサを管理したいという高可用性・スケーラビリティ・運用自動化の三条件を並立させるには、Pod IPを直接ターゲットとしAZ単位で伸縮できるNetwork Load BalancerをAWS Load Balancer Controller経由でプロビジョニングしProxy Protocol v2を有効にする構成が総合的に最適です。

ヒントボタン

TLS の秘密鍵を EC2 や EKS ノード外へ持ち出さないという前提は、ロードバランサ側で復号を行う方式を避ける必要があることを示しています。ACM で証明書を置く Application Load Balancer や Classic Load Balancer の HTTPS リスナーは終端時に秘密鍵がマネージド領域へ渡るため条件を満たせませんが、Network Load Balancer は L4 パススルーで暗号化通信をそのまま転送できるため鍵をノード内に留められます。

パートナー向けにグローバル固定 IP を二つだけ提示したい場合、各 Availability Zone に Elastic IP を当てるとアドレス数が増えてしまいますが、AWS Global Accelerator を Network Load Balancer に関連付ければリージョン全体で Anycast の二つの IP が発行され、三つの AZ へ自動ルーティングされるため登録が容易で可用性も確保できます。

二百万同時 TCP 接続を 20ms 以内に処理するスケール、Proxy Protocol でのクライアント IP 透過、TLS 鍵の保持、固定 IP 提供という複数要件を俯瞰すると、L4 で高性能な Network Load Balancer と Global Accelerator の組み合わせが最小運用負荷で各条件を同時に満たす構成であると判断できます。

ヒントボタン

Network Load Balancer は関連付けた Availability Zone ごとに ENI を作成し、その ENI から同じ AZ 内の EC2 へヘルスチェックやデータ転送を行います。ロードバランサにサブネットを割り当てていない AZ のインスタンスは他 AZ の ENI 経由でしか通信できず、遅延増大やチェック失敗の原因になります。gRPC で 1 万 rps を処理する環境ではこの設計原則を満たすことが可用性の出発点になります。

NACL はステートレスで、Network Load Balancer が用いる 1024–65535/TCP のエフェメラルポートをインバウンド・アウトバウンドとも許可していないとヘルスチェックが拒否されます。特定 AZ のサブネットだけ許可が不足するとその AZ のチェックだけ失敗します。クロスゾーン負荷分散を使えば見かけの分散は得られますが AZ 間トラフィック課金や障害時のリスクが残るため、まずサブネット追加と NACL 整合性の確認が最小の改善策になります。

RPO 0、RTO 15 分、高トラフィック gRPC、Transit Gateway 連携という複数条件を変えずに高可用性を強化するなら、Network Load Balancer に不足している AZ のプライベートサブネットを追加し、そのサブネットの NACL を適切に開放するだけで 3AZ 化とヘルスチェック安定を同時に満たせるため、総合的に最もシンプルかつ効果的な打ち手といえます。

ヒントボタン

1. 片方向0.5ミリ秒未満という要件は、パケットが同一アベイラビリティーゾーン内で完結することが前提になります。Network Load Balancer ではクロスゾーンロードバランシングを無効にし、use1-az1.elb.amazonaws.com など各ゾーン固有の DNS 名を Route 53 にエイリアス登録すると、クライアントは必ず自ゾーンのエンドポイントに接続します。リージョン共通の DNS 名はラウンドロビンで他ゾーンへ名前解決される可能性があるため、こちらの方法がクロス AZ 転送量を 1 GB/日以内に抑える近道です。

2. 障害発生から 30 秒以内に別ゾーンへ切り替えるには、Route 53 でマルチバリュールーティングを選択し、各 Network Load Balancer のゾーン固有レコードにヘルスチェックを関連付けると効果的です。NLB が不健全になるとヘルスチェックは数回の失敗でレコードを応答から除外し、DNS キャッシュの TTL が短ければクライアントは速やかに健全なゾーンのアドレスを再取得します。これによりアプリ側で特別なフェイルオーバーロジックを組まなくても、DNS レベルだけで 30 秒以内の自動復旧が実現できます。

3. Application Load Balancer は TCP/UDP5000 の L4 ワークロードや FPGA のカスタムプロトコルをネイティブに扱えず、Auto Scaling に頼ったインスタンス追加はブートやウォームアップに数分かかるため低遅延要件と乖離します。一方、Network Load Balancer ＋ Route 53 ヘルスチェックは設定項目が少なく運用負荷も軽いまま、超低遅延・クロス AZ 転送量抑制・30 秒以内フェイルオーバーという複数の条件を同時に満たせるので、全体要件を俯瞰して最も整合する選択肢かどうかを確認してください。

ヒントボタン

TCP系APIで15万同時接続と3Gbpsのピークを処理するには、レイヤー4専用の Network Load Balancer が最適です。NLB はコネクション管理能力が高く、事前プレウォーム不要で自動スケールするため、運用負荷を抑えつつ数百万接続まで対応できる点を確認しておきましょう。

取引先が許可するのは固定IPだけという制約がある場合、Elastic IP をアベイラビリティゾーン単位で割り当てられるのは NLB だけです。Application Load Balancer は EIP を持たず Route 53 でレコードを返す方式になるため、TTL やキャッシュの影響で障害発生から 10 秒以内の確実なフェイルオーバーを保証しにくいことに注意してください。

高可用性を担保するには 3 つの AZ にパブリックサブネットを配置し Network Load Balancer をマルチ AZ で展開、ターゲットグループには各 AZ の Amazon EC2 Auto Scaling グループをインスタンス登録して最低 1 台のヘルシーターゲットを維持する構成が定石です。複数要件を俯瞰して総合的に判断しましょう。

ヒントボタン

相手ファイアウォールに登録できる送信元グローバルIPを2個に抑えるには利用者が静的に保持できるIPが必須であり、Application Load BalancerやClassic Load BalancerはElastic IPを関連付けられない一方でNetwork Load Balancerは各AZに1個ずつElastic IPを割り当てられるため2AZでも合計2個に収まり、Global Acceleratorも静的IPを提供するものの追加料金が増える点を比較して考えてみてください。
20万同時接続を処理するにはL4で高スループットを持つ仕組みが望ましく、Network Load Balancerは毎秒数百万リクエストに耐える設計で接続上限も心配がほぼ不要であるのに対し、Classic Load Balancerは旧世代でスケールに限界があり、Application Load BalancerはL7処理によるオーバーヘッドがあるため、Site-to-Site VPN越しのHTTPSを流す用途ではパフォーマンス効率を見比べることがポイントになります。
AZ障害時もサービスを継続するにはAuto Scalingを複数AZに広げるだけでなくロードバランサが受けた通信を生き残ったターゲットへ再分配できる必要があり、Network Load Balancerでクロスゾーンロードバランシングを有効化すれば2本のElastic IPで待受けたトラフィックが健全なインスタンスへ流れ続け、Global Accelerator＋Application Load Balancerの二段構成は高機能でもコストと運用が増すため、全要件を俯瞰して最もシンプルで費用対効果の高い案を選ぶ視点が大切です。

ヒントボタン

60,000 同時 TCP 接続を 1 ミリ秒未満でさばくには、レイヤ 4 でコネクション毎の NAT や TLS 終端が発生しない Network Load Balancer が最有力です。Application Load Balancer は HTTP/S 専用で遅延が伸び、Classic Load Balancer はスケール上限が低めです。NLB は各 AZ のリスナーがターゲットへ直結し経路が短く、AWS Hyperplane により 100 万 rps まで自動伸縮します。この高スループットと超低レイテンシ特性が性能要件の出発点になります。

オンプレミスの送信元 IPv4 を Pod で正確に記録するには SNAT を避ける構成が必要です。VPC CNI で各 Pod が専用 ENI を持っていても、ターゲットタイプを instance にするとパケットは一旦ノードで DNAT され IP が変わります。Network Load Balancer のターゲットタイプを IP にし、Service の externalTrafficPolicy を Local にするとパケットは直接該当 Pod へ届き二度引きがなく、クライアント IP がそのまま残ります。hostNetwork を使わずともこの組み合わせでログ要件を満たせます。

継続的なローリング更新を無停止で行うには、Service type LoadBalancer と連携して NLB を自動生成する AWS Load Balancer Controller が適しています。annotation で proxy-protocol v2 を有効にすると TCP レイヤでもクライアント IP を安全に伝搬でき、Pod ではヘッダーを読むだけで済みます。IP ターゲットのままでも新旧 Pod が共存する間リクエストを取りこぼさず、マルチ AZ 配置で高可用性が確保されます。性能・可観測性・運用性の複数要件を総合的に満たす構成を選ぶ視点が大切です。

ヒントボタン

Auto Scaling で水平展開する EC2 が毎時 300GB を Amazon S3 に PUT する場合、NAT Gateway 経由では「データ送信×3AZ」と「1 時間単価×3AZ」の二重課金が積み上がりますが、Gateway 型 VPC エンドポイントはリージョン冗長で作成料金も転送料も不要なため、ルートテーブルに S3 プレフィックスを向けるだけでネットワーク費用を劇的に圧縮できます。
EC2 のプライベートサブネットに 0.0.0.0/0 が Internet Gateway を指したままだと Security Group で制御しても外部サイトへ直接アウトバウンドできてしまいますので、既定ルートを削除し Amazon S3 など必要先だけを VPC エンドポイント経由で明示ルーティングし、インバウンドは従来どおりパブリックサブネット上の ALB に任せる構成がセキュリティ要件を満たします。
可用性を考えると Multi-AZ にプロキシや追加 NLB を置くと Route 53 フェイルオーバーやヘルスチェック運用が増えますが、Amazon S3 と Gateway 型 VPC エンドポイントの組み合わせはサービス自体がリージョン冗長で AZ 障害時も自動迂回するため RTO 5 分・RPO 0 を設計せずに達成でき、既存のパブリック ALB の DNS 名やターゲットグループを一切変更せずにすみます。
要件を俯瞰すると、S3 への大容量転送コスト削減・直接アウトバウンドの禁止・ALB 設定維持・AZ 障害対策を一挙に満たせるのは、NAT Gateway を撤去し Gateway 型 VPC エンドポイントとルートテーブル調整だけで完結させるシンプルな案です。

ヒントボタン

VPC トラフィックミラーリングが生成する VXLAN パケットは UDP 4789 で送出されますので、受け手はこのポートをそのまま受信しヘッダーを書き換えずに転送できる必要があります。Network Load Balancer はリージョナルに配置でき UDP を扱え、IP ターゲットを使えば AZ 単位で複数の IDS を登録できるため、3AZ 2000 台の ENI からくる 25Gbps 超のミラートラフィックを一括で受け止めつつ元の L2/L3 情報を保持したまま届けられます。

Auto Scaling と連携しても ENI 側のミラーセッションを毎回更新せずに済む構成が無停止要件を満たす鍵です。Network Load Balancer ならターゲットのライフサイクルをヘルスチェックで自動追従し、障害時に即座に切り替えられます。ENI を直接ターゲットにすると 2000 台ぶんのミラー定義を手動で張り替える負荷や 1 ENI 10 セッション上限がネックとなり、将来 40Gbps への水平拡張やレイテンシ最小化の条件を満たしにくくなる点を思い出してください。

Geneve 6081 を使う Gateway Load Balancer や統計情報のみを扱う VPC フローログ＋Kinesis ではプロトコル不一致やペイロード欠落で全パケット検査の前提を崩します。UDP 4789 対応・低遅延・自動スケール・L2/L3 保持・追加サービス不要という複数要件を俯瞰すると、リージョナル NLB をミラーターゲットに据え IP ターゲット型でアプライアンスを並べる案が最も整合的で現実的な選択だと判断できます。

ヒントボタン

VPC トラフィックミラーリングでは ENI のコピー先に Network Load Balancer を指定できます。NLB は本番経路外でパケットを受け取るため Web サーバーの CPU 消費は 3% 未満で済み、ペイロードを含む完全なパケットがリアルタイムで IDS/IPS へ渡ります。コピーだけを送る設計なので解析基盤が過負荷になっても本番トラフィックのレイテンシ 1 ms 未満という厳格な SLO は揺らぎません。

IDS/IPS 側は内部 NLB のターゲットグループに IP ターゲットとして登録し、Auto Scaling グループで台数を動的に制御します。クロスゾーン負荷分散を有効にして各 AZ に NLB を持たせれば 1 つの AZ の障害でも他 AZ が透過的に引き継ぎ、サービス全体で 99.99% 以上の可用性が得られます。NLB は転送量課金のためトラフィックに応じたコストで済み、運用はヘルスチェックと ASG が自動化します。

全パケット解析という要件では VPC Flow Logs や Kinesis Data Firehose はメタデータ／バッチ処理中心で遅延が大きく、Gateway Load Balancer はインライン経路追加で 1 ms 未満を維持しにくいです。Traffic Mirroring と内部 Network Load Balancer を組み合わせ、Auto Scaling で IDS/IPS を弾力的に配置する構成が低遅延・高可用性・自動化・コスト効率の四要件を最もバランス良く満たします。