Amazon ANS-C01: VPC設計と高度なネットワーキング — 学習ガイド

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

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

VPCアーキテクチャとサブネット化の基礎

VPCはAWSにおける基本的なネットワーキングの境界であり、CIDRの割り当て方がその後のすべてを決定します。将来の成長とアカウント間の接続性を考慮してCIDRブロックを計画してください。アカウント/リージョンごとに重複しない大きなアドレス空間（例えば、環境ごとに/16）を割り当て、それを/20～/24のサブネットに分割して、機能やアベイラビリティーゾーンごとにワークロードを分離します。EKSや他のコンテナプラットフォームは、ポッドのENIやセカンダリIPのためにIPアドレスを消費することを覚えておいてください。AWS VPC CNIはVPCサブネットからポッドのIPを割り当て、インスタンスごとのENI/IP制限（DescribeInstanceTypes）が最大ポッド密度を制約します。IPv6を導入する際は、パブリック向けサービスをIPv6にオフロードし、レガシーシステムとの統合のためにIPv4を維持するデュアルスタック設計が推奨されます。APIコール aws ec2 associate-vpc-cidr-block –vpc-id <vpc> –amazon-provided-ipv6-cidr-block を使用してAmazon提供のIPv6 CIDRブロックを関連付け、create-subnet と –ipv6-cidr-block オプションでサブネットレベルのIPv6割り当てを有効にします。IPv4のegress用にはNATリソースを計画し、IPv6用には CreateEgressOnlyInternetGateway で作成してVPCにアタッチしたEgress-Only Internet Gatewayを使用します。

ルートテーブルとサブネットの配置は、トポロジーと耐障害性を実現するための手段です。CreateRouteTable と CreateRoute を使用して、サブネットの目的（パブリック、NAT付きプライベート、Direct Connect付きプライベート、分離）ごとに個別のルートテーブルを作成します。単一AZでのegress障害を避けるために、複数のAZにまたがって複数のNAT Gateway（またはautoscalingを使用するNATインスタンス）を使用します。Transit Gateway（CreateTransitGateway, CreateTransitGatewayRouteTable）を使用する際は、オンプレミスのプレフィックスが意図した場所にのみ注入されるように、伝播されるルートを明示的に設定してください。アカウント内部のサービスディスカバリには、Route 53 プライベートホストゾーンを使用し、境界を越えたDNSリークを避けるために、レコードを必要とするVPCに関連付けます。

主要なサービスと設定の詳細

プライベート接続には、理解すべき3つの主要な構成要素があります：VPC Peering、AWS Transit Gateway、そしてAWS PrivateLink（インターフェイスVPCエンドポイント）です。VPC Peering（CreateVpcPeeringConnection, AcceptVpcPeeringConnection）は、シンプルで低コストのポイントツーポイント接続であり、ルートテーブルエントリが必要で、推移的ルーティングはサポートしません。Transit Gateway（CreateTransitGateway, CreateTransitGatewayVpcAttachment）は、数千のVPC、中央集権的なルート制御、ハイブリッド接続のためのDirect Connect Gatewayとの統合をサポートするスケーラブルなハブです。Transit Gateway内のルートテーブルの伝播とルートテーブルの関連付けを使用して、east-west（東西）トラフィックフローを制御します。PrivateLink（NLBをバックエンドに持つサービスを登録するためのCreateVpcEndpointServiceConfigurationと、インターフェイスエンドポイントを作成するためのCreateVpcEndpoint）は、VPCをルーティングに公開することなくアカウント間でサービスを公開し、サービスごとのきめ細かなセキュリティと簡素化されたセキュリティグループ制御を提供します。利用者がインターフェイスエンドポイントを作成し、トラフィックがNICレベルに留まるため、うまくスケールします。

ロードバランシングとクライアントIPの保持は、正しく設計すべき一般的な選択肢です。Application Load Balancer (ALB) はTLSを終端し、L7でルーティングを行い（CreateLoadBalancer Type application）、クライアントIPのロギングのためにバックエンドが信頼する必要があるX-Forwarded-For/X-Forwarded-Protoヘッダーを挿入します。Network Load Balancer (NLB) はターゲットグループのソースIPを保持し、数百万の接続をサポートします。バックエンドへの真のTLSパススルーのためには、TCPリスナー（CreateListener Protocol TCP）を持つNLBを使用し、暗号化されたセッションがポッドやインスタンスにそのまま到達するようにターゲットをIPで登録します。gRPCや非常に高い接続数の場合は、EKSの前にNLBを配置し、ターゲットタイプをipとし、AWS Load Balancer Controllerのアノテーション service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” を使用してポッドのIPを直接登録することが推奨されます。この組み合わせは、ソースIPを保持し、ポッドでのmTLS終端をサポートし、オートスケーラーと共にスケールします。

VPCエンドポイントは、AWS APIや一般的なサービスへのインターネットegressを不要にします。S3とDynamoDB用のゲートウェイエンドポイント（CreateVpcEndpoint と –service-name com.amazonaws.<region>.s3 を使用）は、エンドポイントのプレフィックスリストへのルートを追加し、無料です。インターフェイスエンドポイント（CreateVpcEndpoint と –vpc-endpoint-type Interface を使用）は、プライベートIPとセキュリティグループを持つElastic Network Interfaceを作成します。これらは時間単位およびGB単位で課金されますが、NLBをバックエンドに持つサービスと組み合わせることで、PrivateLink形式の利用やアカウント間のアクセスを可能にします。

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

複数のアカウントにまたがる多くのビジネスユニットが利用する中央共有サービスの場合、接続ごとの制御と分離が必要なときには、PrivateLinkとエンドポイントサービスが最も安全でスケーラブルなパターンです。サービスを共有サービスVPC内のNetwork Load Balancerの背後でホストし、VPCエンドポイントサービスを作成（CreateVpcEndpointServiceConfiguration）し、コンシューマーアカウントにインターフェイスエンドポイントを作成させて、それを承認します。これにより、フルメッシュを回避し、推移的なルーティングを防ぎます。また、インターフェイスエンドポイントのセキュリティグループにより、どのコンシューマーが接続できるかを制限できます。トレードオフは、エンドポイントごとのコストと、エンドポイント接続を承認・監査するための管理オーバーヘッドです。

Transit Gatewayは、多くのVPCが広範な接続性、中央での検査、そしてDirect Connect経由でオンプレミスのプレフィックスを広報する単一の場所を必要とする場合に、その真価を発揮します（CreateTransitGatewayRoute, CreateTransitGatewayRouteTable）。ルートテーブルのセグメンテーションと伝播制御を使用して、偶発的なラテラルムーブメント（水平展開）を避けてください。Transit Gatewayはルートの優先順位付けとルートテーブルの関連付けをサポートしているため、本番トラフィックを信頼性の低いネットワークから分離できます。トレードオフは、Transit Gatewayがトラフィックを集中させ、本来ローカルであったはずのVPC間トラフィックにコストが発生する可能性があることです。また、障害ドメインが変更され、アドレスの重複を防ぐために慎重なCIDR計画が必要になります。

CIDRの再利用が制限されるハイブリッドアーキテクチャでは、Direct ConnectとTransit Gateway、Direct Connect Gateway（CreateDirectConnectGateway）を組み合わせて、仮想インターフェイスの数を減らすことを検討してください。共有物理リンク上でビジネスユニットごとの帯域幅分離が必要な場合は、複数のプライベート仮想インターフェイスを配置し、VIFごとのCloudWatchメトリクス（メトリクス名：AWS/DX: BytesIn, BytesOutなど）を監視し、VIFレベルのCloudWatchアラームを使用します。ヘビーコンシューマーを特定するには、VPC Flow Logs（CreateFlowLogs）をS3またはCloudWatch Logsに有効化し、AthenaまたはCloudWatch Logs Insightsで分析します。VMごとのパケットキャプチャには、短い期間、Traffic Mirroring（CreateTrafficMirrorSession）を使用します。

IPv6の採用とデュアルスタック設計は、NATへの依存を減らし、NAT Gatewayのスループットコストを削減し、クライアント向けのIPアドレッシングを簡素化します。APIコール

undefined

を使用してAmazon提供のIPv6プレフィックスを割り当て、IPv6 CIDRブロックを持つサブネットを作成します。一部のサービスやサードパーティ製アプライアンスがIPv6に対応していない可能性があることに注意してください。ロードバランサーでデュアルスタック（IpAddressType dualstack を指定して

undefined

）を使用し、バックエンドシステムはIPv4のままで、IPv4とIPv6の両方のクライアントをサポートします。

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

KubernetesポッドによるIPアドレスの消費を軽視することは、サービス中断の頻繁な原因です。インスタンスタイプごとのENIとセカンダリIPの上限を考慮し、VPC CNIの設定（WARM_IP_TARGETSやプレフィックス委任など）を使用してIPの可用性を向上させます。L7でクライアントIPを保持できないことも、よくある欠陥です。TLSをロードバランサーで終端する必要がある場合、アプリケーションがX-Forwarded-Forを読み取ること、そしてヘッダーが信頼できるようにALBのセキュリティ制御が直接アクセスを制限していることを確認する必要があります。VPCピアリングが無限にスケールすると想定すると、管理不能なメッシュにつながることがよくあります。多対多の接続にはTransit Gatewayを、詳細なセキュリティとトラフィック分離が必要な一対多のサービス公開にはPrivateLinkを優先してください。

セキュリティポリシーでは、セキュリティグループとネットワークACLを名前空間レベルの制御と組み合わせて使用する必要があります。直接のALB URLではなくGlobal Accelerator経由のアクセスを厳密に強制するには、Global AcceleratorのIP範囲で構成されたAWS WAFのIPセット（公開されているip-ranges.jsonを介して自動化）の組み合わせに依存するか、ALBを内部として設計し、Global AcceleratorがターゲットとするNLBを前面に配置し、Global Acceleratorのフロントドアのみを公開します。IPベースの制御の更新は常に自動化し、DescribePrefixListsと定期的なip-ranges.jsonの取り込みを使用して検証してください。

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

企業：Equinox Payments。課題：Equinox社は、EKSベースのgRPCサービスを運用しており、数千の同時接続に対するエンドツーエンドのmTLS、Cluster AutoscalerとHPAによるオートスケーリング、およびロギングのためのクライアントIPの保持が必要です。アプローチ：1) AWS Load Balancer Controllerを使用し、アノテーション

undefined

を用いて、サービスをNetwork Load Balancerの背後にデプロイします。NLBはポート443でTCPリスナーを設定し、ポッドのIPがターゲットとして登録されるようにします。2) TLSをポッドで終端し（NLBではなく）、アプリケーションで相互TLS（サーバーとクライアントの証明書検証）を実装します。証明書にはKubernetes Secretsを使用し、readiness probeでターゲット登録を制御します。3) ターゲットタイプipを使用してクライアントのソースIPを保持し、プロキシプロトコルは中間アプライアンスで必要な場合にのみ有効にし、TCP接続からクライアントIPをキャプチャするためにポッド側のロギングに依存します。4) ヘルスチェックをTCPまたはgRPC対応のreadiness probeとして設定し、Cluster Autoscalerのポリシーとノードのインスタンスタイプが十分なENIとIP容量を持つことを確認します。5) CloudWatch Container InsightsとVPC Flow Logs（CreateFlowLogs）を実装し、接続数とVPCレベルのテレメトリを監視します。AWSの論理的根拠：TCPリスナーを持つNLBは、暗号化されたセッションとソースIPを保持しながら、数百万の接続にスケールします。ターゲットタイプipにより、ポッドはNATなしでソースIPを直接受信できます。ポッドでmTLSを終端することで、エンドツーエンドの暗号化と双方向認証が満たされます。ポッドの準備完了状態がターゲット登録に直接影響し、NLBが接続負荷に応じて透過的にスケールするため、オートスケーリングが機能します。

すべてのドメイン · ハイブリッド接続: VPNとDirect Connect →

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