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.

EKSネットワーキング（CNI、ポッドネットワーキング）

Amazon EKSにおけるポッドネットワーキングは、Amazon VPC CNIプラグイン（amazon-vpc-cni-k8s）が主流です。これは各ポッドにVPCからIPアドレスを付与し、ポッドのトラフィックを直接VPCネットワーク上に配置します。この設計により、予測可能なVPCレベルのセキュリティ制御（セキュリティグループ、NACL）と低レイテンシーのルーティングが実現しますが、ENIごとのセカンダリIPv4アドレス数とインスタンスタイプごとのENI数はハードウェアによって制限されるため、IPアドレスとENIのキャパシティプランニングを慎重に行う必要があります。aws-nodeデーモンセットがIPの割り当てやアタッチ/デタッチ操作を駆動し、そのConfigMapをkubectlで編集することで挙動を調整します（例：WARM_IP_TARGET、WARM_ENI_TARGET、ENABLE_PREFIX_DELEGATIONの設定）。プレフィックスデリゲーションやポッドENIモードは、ノードがENIに/28プレフィックス全体を割り当てる（ENABLE_PREFIX_DELEGATION=true）ことや、ポッドごとに専用のENIを割り当てる（高セキュリティの分離に有用）ことで、ノードごとのIP枯渇を緩和します。

Amazon VPC CNIの代替として、Cilium（eBPF）やCalicoなどがあり、異なるトレードオフを提供します。Ciliumはkube-proxyを置き換えてeBPFを用いた高性能なL3/L4転送を実装したり、ノード間の透過的な暗号化（WireGuardまたはIPsec）を有効にしたり、オーバーレイやマスカレードのアプローチを用いてノードレベルのIPアドレスの圧迫を軽減したりできます。Ciliumを使用する場合でも、egressおよびingressのためにVPCルーティングとの統合は行いますが、頻繁なENIのアタッチ/デタッチ操作を回避できます。これはポッドのチャーンレートが高い場合に重要になります。非常に高い接続数と厳密なL7の挙動が求められる場合は、kube-proxyモード（IPVS）のチューニングやノードのカーネル設定も考慮します。例えば、conntrack_max、tcp_tw_recycle/tcp_tw_reuse、ip_local_port_rangeを調整し、これらをkubeletやデーモンセットのinitスクリプト経由で公開することで、数千の同時長寿命gRPC接続下でのエフェメラルポートの枯渇を回避します。

ECSネットワーキングモードとLambdaのVPC統合

ECSタスクネットワーキングには、主にbridge、host、awsvpcの3つのモードがあります。awsvpcモードは、各タスク（またはタスクグループ）にENIをアタッチし、プライベートIPとセキュリティグループをタスクに直接割り当てるため、Kubernetesのポッドネットワーキングに最も近いものです。awsvpcを設定するには、RunTaskまたはCreateService APIコールでawsvpcConfigurationにサブネットとsecurityGroupsを指定します。Fargateはawsvpcモードを強制するため、タスクレベルのネットワーク分離を提供し、サービスディスカバリのためにAWS Cloud Mapと統合されます。タスクごとにセキュリティグループベースのトラフィックフィルタリングが必要な場合や、標準的なVPCルーティングとメトリクスを公開する必要がある場合にawsvpcを使用します。

VPCアクセスが必要なLambda関数は、関数の設定されたサブネットとセキュリティグループ内のENIを介してVPCにアタッチされます。これらのENIはLambdaのコントロールプレーンによって作成・管理されますが、ENIのプロビジョニングはコールドスタートのレイテンシーを増加させる可能性があり、これまでは迅速なスケールアップを制限する要因となっていました。ただし、プロビジョンドコンカレンシーや、VPCエンドポイント（AWS PrivateLink）と慎重に設計されたサブネットアーキテクチャを使用することで緩和できます。多くのLambda関数をVPC内に配置する場合、サブネットに利用可能なIPがあることを確認し、必要に応じてegress用にNAT GatewayやNATインスタンスを使用し、可能な限りインターネット経由のegressルーティングを避けるためにVPCエンドポイント（AWS::EC2::VPCEndpoint経由のcom.amazonaws.*エンドポイント）を優先します。スケーリングの挙動を観察し、同時実行に関連するスロットリングのトラブルシューティングを行うために、CloudWatch LogsとVPC Flow Logsを使用してENIのアタッチ/デタッチを監視します。

App Meshとサービスディスカバリ

AWS App MeshはEnvoyサイドカーをデータプレーンとして使用し、L3–L7の可観測性、トラフィックシェーピング、リトライ、TLSのオリジネーション/ターミネーション制御を提供します。メッシュ、仮想ノード、仮想サービスは、App Mesh API（CreateMesh、CreateVirtualNode、CreateVirtualService）またはKubernetes用のApp Meshコントローラーを介して定義します。App Meshは、VirtualNodeリスナーのTLSブロックにclientPolicyと認証局を設定することでmTLSをサポートし、証明書の配布にはAWS Certificate Manager（ACM）やSDSと統合できます。ただし、App Meshのサイドカーは設計上トラフィックを終端して再暗号化することに注意してください。クライアントとアプリケーションポッド間でアプリケーションのトラフィックをエンドツーエンドで暗号化し続ける（ネットワークプロキシで復号しない）という要件がある場合は、TLSがポッドでのみ終端されるようにし、メッシュのイングレスやロードバランサーで終端しないようにする必要があります。

サービスディスカバリは、EKSではKubernetes ServiceとCoreDNS、クロスプラットフォームではCloud Map（CreateService、RegisterInstance）、DNSベースのルックアップではRoute 53プライベートホストゾーンで一般的に行われます。AWS Cloud MapはECSやApp Meshと直接統合し、SRVまたはAレコードとAPI駆動のヘルスチェックを可能にします。インスタンスが急速にスケールする動的な環境では、古い名前解決を避けるために短いDNS TTLとCloud Mapのヘルスチェックを組み合わせます。即時の一貫性が必要な場合は、DNSキャッシュに依存するのではなく、サービスメッシュのコントロールプレーンAPIを使用してエンドポイントを取得します。

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

mTLS を使用した大規模な gRPC over TLS を設計する場合、TLS をどこで終端させるかを決定する必要があります。ロードバランサー (ALB) で終端させると、証明書を ACM にオフロードでき、証明書のローテーションが簡素化されますが、エンドツーエンドの暗号化が失われます。また、転送されたクライアント証明書情報を使用してバックエンドが TLS を再確立しない限り、バックエンドの Pod に mTLS を提供することはできません。アプリケーションのエンドポイントがクライアントを直接認証する、真のエンドツーエンド mTLS を実現するには、Network Load Balancer などの L4 パススルーゲートウェイを使用し、Pod/アプリケーションに TLS/mTLS を処理させます。NLB のターゲットタイプ ip と AWS Load Balancer Controller のアノテーション service.beta.kubernetes.io/aws-load-balancer-target-type: "ip" を組み合わせて Pod の IP を直接登録します。このパターンは、NLB が数百万の接続用に設計されており、TLS を終端させることなく長期間の TCP/gRPC セッションをサポートするため、うまくスケールします。

HTTPS 終端を伴う Ingress およびパスベースのルーティングには、Application Load Balancer の方が適しています。なぜなら、ホスト/パスルール、リダイレクト、および WAF との統合をサポートしているからです。ALB が TLS を終端させる際にクライアント IP を保持するには、X-Forwarded-For ヘッダーに依存します。バックエンドの Web サーバーは X-Forwarded-For を解釈してログに記録する必要があり、検証のために ALB のアクセスログを有効にする必要があります。サーバーレイヤーで真のクライアントソケットアドレスが必要な場合 (レガシーソフトウェアなど)、proxy protocol v2 を有効にした NLB を使用し、バックエンドサービスがプロキシプロトコルをサポートしていることを確認してください。

複数の AWS アカウントと VPC にまたがるサービス接続のスケーラビリティは、パターンによって異なります。VPC peering はシンプルですが、管理が N^2 になります。Transit Gateway はルーティングを集中管理し、ルートテーブルを分離することで多数の VPC に対してより良くスケールします。AWS PrivateLink (Interface VPC Endpoints) は、最も詳細なサービス単位のアイデンティティ認識型アクセスモデルを提供します。これは、NLB を介してエンドポイントサービスを公開し、コンシューマーが自身の VPC にインターフェースエンドポイントを作成するためです。厳格なアクセス制御とスケーラブルなオンボーディングを必要とするマルチアカウント共有サービスには、PrivateLink を推奨します。なぜなら、ルーティングを分離し (コンシューマー VPC のルートテーブル変更が不要)、セキュリティグループを使用してきめ細かな制御を行うからです。

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

繰り返し発生する落とし穴は、すべてのワークロードに同じネットワークモデルが適合すると想定してしまうことです。ステートフルまたは長寿命の接続を伴うワークロード（gRPC、データベース）は、プロキシに起因するレイテンシを避けるため、ポッドレベルのTLS終端やhostPort/hostNetworkパターンを用いたL4パススルー（NLB）が適しています。一方、パスベースルーティング、WAF、またはWebSocket終端を必要とするHTTPマイクロサービスは、ALBやApp Meshの機能から恩恵を受けます。もう一つの間違いは、awsvpcモードでEKSノードやECSタスクをスケーリングする際に、ENI/IPアドレスの上限を考慮しないことです。常にEC2インスタンスタイプのENIとENIあたりのIPアドレス数のテーブルを参照し、高いポッド密度が必要な場合はプレフィックスデリゲーションやCiliumのオーバーレイを使用してください。

モニタリングとデバッグには、複数のソースが必要です。トラフィックのEgress/Ingressを確認するためのVPCフローログとENIメトリクス、AWS Load Balancer用のCloudWatchメトリクス（ActiveFlowCount、ProcessedBytes）、そしてEnvoy/App MeshやAWS X-Rayエージェントからのアプリケーションレベルのテレメトリです。LambdaとFargateについては、ENI操作に起因するコールドスタートは、プロビジョニング済み同時実行数によって、あるいは関数が広範なEgressを必要としないようにVPCエンドポイントとPrivateLinkを使用するアクセスパターンに再設計することで緩和できることを覚えておいてください。

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

企業名：Acme Payments Inc. 課題：Acme Payments社は、Amazon EKS上でgRPCサービスを運用しています。このサービスは、TCPポート443で数千の同時TLS接続をサポートし、クライアント証明書がバックエンドサービスによって検証されるように相互TLS（mTLS）を使用し、さらに接続性を損なったりロードバランサーでのTLS終端を必要とすることなく、EKSクラスターがCluster AutoscalerとHPAによってオートスケールできる必要があります。

番号付きアプローチ：

アプリケーション内、または外部クライアントからのエンドツーエンドTLSを終端しないサイドカー内に、ポッドレベルのTLSと相互認証を実装してサービスをデプロイします。サーバー/クライアント証明書をAWS Secrets Managerに保存し、Kubernetes CSI secrets store経由でマウントするか、ポッドのライフサイクルと連携する証明書配布メカニズムを使用します。
AWS Load Balancer Controllerを使用して、Serviceにアノテーションを付与し（service.beta.kubernetes.io/aws-load-balancer-type: "nlb"）、ターゲットタイプをIPに設定して（service.beta.kubernetes.io/aws-load-balancer-target-type: "ip"）、Network Load Balancerを作成します。その後、ポート443にTCPリスナーを作成します。これにより、NLBがL4パススルーを実行し、TLSを終端しないことが保証されます。
NLBのターゲットグループをプロトコルTCPで設定し、ポッドのIPを動的に登録します（Load Balancer ControllerがCreateTargetGroupとRegisterTargetsを呼び出します）。オートスケーリング中にターゲットが迅速に正常とマークされるように、ヘルスチェックをTCPまたは短い間隔のカスタムTCPベースのヘルスプローブに設定します（aws elbv2 create-target-group --protocol TCP --port 443 --target-type ip; aws elbv2 create-listener --protocol TCP --port 443 ...）。
高いポッド密度をサポートし、ENIのチャーン（頻繁な付け外し）を減らすために、Amazon VPC CNIをチューニングします。サポートされている場合はプレフィックスデリゲーションを有効にし（aws-nodeのConfigMapでENABLE_PREFIX_DELEGATION=trueを設定）、予備のアドレスを維持するためにWARM_IP_TARGETを設定し、aws-nodeのメトリクス（kube-systemのdaemonsetログとCloudWatchカスタムメトリクス）を監視します。ノードレベルのIPアドレス上限が懸念される場合は、より高いポッド密度とENI操作の削減のために、eBPFを使用したCiliumを検討します。
クラスターを安全にスケールさせます。Cluster Autoscalerが適切なノードグループのタグとIAM権限を持っていることを確認し、PodDisruptionBudgetsを設定し、スケールダウン中に長寿命のgRPC接続が切断されるのを避けるために、ターゲットグループのヘルスチェックとNLBのコネクションドレイニングが設定されていることを確認します。
証明書のローテーションと信頼をセキュアにします。ACM Private CAまたはSecrets Managerで証明書のローテーションを自動化し、ポッドがNLBの再設定を必要とせずに更新された信頼バンドルを取得できるようにします。mTLSハンドシェイクの準備状態を反映するKubernetesのreadiness/livenessプローブを使用します。

AWSの論理的根拠： IPターゲットモードのNetwork Load Balancerは、ポッドまでのTLSを維持し（真のエンドツーエンド暗号化）、数百万の永続的なTCP接続をサポートするため、数千の同時gRPCセッションに適しています。ポッドのIPを直接登録することで、ノードごとのhostPortやインスタンスターゲット登録の複雑さを回避し、ポッドのスケーリングに応じてAWS Load Balancer ControllerがポッドIPの登録と登録解除を行うため、Cluster Autoscaler/HPAとクリーンに連携します。VPC CNIをチューニングするか、eBPFベースのデータプレーンを採用することで、IPアドレスの枯渇を防ぎ、ENIのアタッチ/デタッチのレイテンシを削減できます。これは、高速なオートスケーリングと高接続数のワークロードにとって不可欠です。Secrets ManagerやCSIプロバイダーを介してmTLSアーティファクトを保存・配信することで、ロードバランサーに触れることなく証明書のライフサイクル管理が容易になります。

← 自動化、IaCとネットワーク運用 · すべてのドメイン

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