Amazon ANS-C01: VPC Design and Advanced Networking — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
VPC architecture and subnetting fundamentals
A VPC is the fundamental networking boundary in AWS and the shape of your CIDR allocations defines everything that follows. Plan CIDR blocks with future growth and cross-account connectivity in mind: allocate large, non-overlapping address spaces per account/region (for example a /16 per environment) and subdivide into /20–/24 subnets to isolate workloads by function and availability zone. Remember that EKS and other container platforms consume IP addresses for pod ENIs or secondary IPs; the AWS VPC CNI assigns pod IPs from the VPC subnet and ENI/IP limits per instance (DescribeInstanceTypes) constrain maximum pod density. For IPv6 adoption prefer dual-stack design to offload public-facing services to IPv6 while keeping IPv4 for legacy integration; associate an Amazon-provided IPv6 CIDR block with the API call aws ec2 associate-vpc-cidr-block –vpc-id <vpc> –amazon-provided-ipv6-cidr-block and enable subnet-level IPv6 assignment with create-subnet and the –ipv6-cidr-block option. Plan NAT resources for IPv4 egress, and for IPv6 use an Egress-Only Internet Gateway, created with CreateEgressOnlyInternetGateway and attached to the VPC.
Route tables and subnet placement are how you enforce topology and resilience. Create distinct route tables per subnet purpose (public, private with NAT, private with Direct Connect, and isolated) using CreateRouteTable and CreateRoute. Use multiple NAT Gateways (or NAT instances with autoscaling) across AZs to avoid single-AZ egress failure; be explicit about propagated routes when using a Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable) so that on-premises prefixes are injected only where intended. For service discovery internal to an account, use Route 53 private hosted zones and associate with the VPCs that need the records to avoid DNS leakage across boundaries.
Key services and configuration details
For private connectivity there are three dominant constructs to understand: VPC Peering, AWS Transit Gateway, and AWS PrivateLink (interface VPC endpoints). VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) is simple, low-cost, point-to-point connectivity that requires route table entries and does not support transitive routing. Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) is the scalable hub that supports thousands of VPCs, central route control, and integration with Direct Connect Gateway for hybrid connectivity; use route table propagation and route table associations in the Transit Gateway to control east-west flow. PrivateLink (CreateVpcEndpointServiceConfiguration to register an NLB-backed service and CreateVpcEndpoint to create interface endpoints) exposes services across accounts without exposing a VPC to routing, providing granular, per-service security and simplified security group controls; it scales well because consumers create interface endpoints and traffic stays at the NIC level.
Load balancing and client IP preservation are common design choices to get right. Application Load Balancer (ALB) terminates TLS, routes at L7 (CreateLoadBalancer Type application), and injects X-Forwarded-For/X-Forwarded-Proto headers that backends must trust for client IP logging. Network Load Balancer (NLB) preserves source IPs for target groups and supports millions of connections; for true TLS pass-through to backends use an NLB with a TCP listener (CreateListener Protocol TCP) and register targets by IP so encrypted sessions reach the pods or instances intact. For gRPC and very high connection counts prefer NLB in front of EKS with target type ip and the AWS Load Balancer Controller annotation service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” to register pod IPs directly; that combination retains source IP, supports mTLS termination at the pod, and scales with the autoscalers.
VPC endpoints remove internet egress for AWS APIs and popular services. Gateway endpoints for S3 and DynamoDB (CreateVpcEndpoint with –service-name com.amazonaws.<region>.s3) add routes to an endpoint prefix list and are free. Interface endpoints (CreateVpcEndpoint with –vpc-endpoint-type Interface) create elastic network interfaces with private IPs and security groups; they are billed hourly and per-GB but enable PrivateLink-style consumption and cross-account access when paired with an NLB-backed service.
Design patterns and trade-offs
For a central shared service consumed by many business units across accounts, PrivateLink and endpoint services are the most secure and scalable pattern when you require per-connection control and isolation. Host the service behind a Network Load Balancer in the shared services VPC, create a VPC endpoint service (CreateVpcEndpointServiceConfiguration) and have consumer accounts create interface endpoints that you approve. This avoids a full mesh and prevents transitive routing, and security groups on the interface endpoints let you restrict which consumers may connect. The trade-off is per-endpoint cost and some management overhead to accept and audit endpoint connections.
Transit Gateway shines when you have many VPCs that need broad connectivity, central inspection, and a single place to advertise on-prem prefixes over Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Use route table segmentation and propagation controls to avoid accidental lateral movement; Transit Gateway supports route prioritization and route table associations so you can isolate production traffic from lower-trust networks. The trade-off is that Transit Gateway centralizes traffic and can incur cost for cross-VPC traffic that would otherwise be local; it also changes failure domains and requires careful CIDR planning to prevent address overlap.
For hybrid architectures with limited CIDR reuse, consider combining Direct Connect with Transit Gateway and Direct Connect Gateway (CreateDirectConnectGateway) to reduce the number of virtual interfaces. If you need per-business-unit bandwidth isolation on the shared physical link, place multiple private virtual interfaces and monitor per-VIF CloudWatch metrics (metric names like AWS/DX: BytesIn, BytesOut) and use VIF-level CloudWatch alarms. To identify heavy consumers, enable VPC Flow Logs (CreateFlowLogs) to S3 or CloudWatch Logs and analyze with Athena or CloudWatch Logs Insights; for per-VM packet capture, use Traffic Mirroring (CreateTrafficMirrorSession) for short windows.
IPv6 adoption and dual-stack designs reduce reliance on NAT, lower costs of NAT Gateway throughput, and simplify client-facing addressing. Use the API call aws ec2 associate-vpc-cidr-block to assign an Amazon-provided IPv6 prefix and create subnets with IPv6 CIDR blocks. Beware that some services and third-party appliances may not be IPv6-ready; use dual-stack on load balancers (CreateLoadBalancer with IpAddressType dualstack) to support both IPv4 and IPv6 clients while backend systems remain IPv4.
Common pitfalls and decision criteria
Neglecting IP address consumption by Kubernetes pods is a frequent source of service disruption. Account for ENI and secondary IP limits per instance type and use VPC CNI settings like WARM_IP_TARGETS or prefix delegation to improve IP availability. Failing to preserve client IPs at L7 is another common gap: if TLS must be terminated at the load balancer you must ensure the application reads X-Forwarded-For and that the ALB security controls restrict direct access so headers can be trusted. Assuming VPC peering will scale indefinitely often leads to unmanageable meshes; prefer Transit Gateway for many-to-many and PrivateLink for one-to-many service exposure where you require granular security and traffic isolation.
Security policies should use security groups and network ACLs in combination with namespace-level controls. For strict enforcement of access via Global Accelerator instead of direct ALB URLs, rely on a combination of AWS WAF IP sets that are populated with the Global Accelerator IP ranges (automated via the published ip-ranges.json) or architect the ALB as internal and front it with an NLB that Global Accelerator targets, then expose only the Global Accelerator front door. Always automate updates to any IP-based controls and validate using DescribePrefixLists and regular ip-ranges.json ingestion.
Practical Problem: Use-Case Scenario
Company: Equinox Payments. Challenge: Equinox runs an EKS-backed gRPC service needing end-to-end mTLS for thousands of concurrent connections, autoscaling via Cluster Autoscaler and HPA, and preservation of client IPs for logging. Approach: 1) Deploy the service behind a Network Load Balancer configured with a TCP listener on port 443 via the AWS Load Balancer Controller using annotation service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” so pod IPs are registered as targets; 2) terminate TLS at the pods (not the NLB) and implement mutual TLS in the application (server and client cert validation), with Kubernetes Secrets for certs and readiness probes to drive target registration; 3) use target type ip to preserve client source IPs, enable proxy protocol only if needed for intermediate appliances, and rely on pod-side logging to capture client IP from the TCP connection; 4) configure health checks as TCP or gRPC-aware readiness probes, and ensure Cluster Autoscaler policies and node instance types have sufficient ENI and IP capacity; 5) implement CloudWatch Container Insights and VPC Flow Logs (CreateFlowLogs) to monitor connection counts and VPC-level telemetry. AWS rationale: NLB with TCP listeners preserves encrypted sessions and source IPs while scaling to millions of connections; target-type ip allows pods to receive source IP directly without NAT; terminating mTLS at pods satisfies end-to-end encryption and two-way authentication; autoscaling works because pod readiness directly affects target registration and NLB scales transparently with connection load.
All domains · Hybrid Connectivity: VPN and Direct Connect →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →