Networking

AWS VPC Explained – Beginner’s Guide to Networking

~ Last updated on : ~ Kiro Agent

What is AWS VPC? (AWS VPC Explained)

Amazon Virtual Private Cloud (VPC) is your own private, isolated section of the AWS cloud where you launch resources like EC2 instances, databases, and load balancers. Think of it as your own private office building within a massive business park (AWS).

Real-World Analogy: VPC as a Private Office Building

Imagine AWS as a giant business park with thousands of buildings. When you create a VPC, you get your own building with:

  • Your own address range (CIDR block) — like having your own floor numbers and room numbers
  • Your own rooms (subnets) — different departments on different floors
  • Your own security guards (security groups & NACLs) — controlling who enters and exits
  • Your own reception desk (internet gateway) — managing visitors from outside
  • Your own internal hallways (route tables) — directing people to the right rooms

Without a VPC, your AWS resources would be exposed to everyone — like working in an open field. A VPC gives you walls, doors, and locks.

AWS VPC Architecture
VPC (10.0.0.0/16)
Public Subnet (AZ-1)
EC2 (Web Server)
NAT Gateway
↕ Route to IGW
Private Subnet (AZ-1)
EC2 (App Server)
RDS (Database)
↕ Route to NAT GW
Public Subnet (AZ-2)
EC2 (Web Server)
NAT Gateway
↕ Route to IGW
Private Subnet (AZ-2)
EC2 (App Server)
RDS (Standby)
↕ Route to NAT GW
⬆⬇
Internet Gateway (IGW)
⬆⬇
Internet / Users

CIDR Notation Basics

Before diving deeper, you need to understand CIDR (Classless Inter-Domain Routing) notation — it’s how you define the size of your network.

How CIDR Works

A CIDR block looks like this: 10.0.0.0/16

  • 10.0.0.0 — the starting IP address
  • /16 — how many bits are “locked” (the network portion)

The smaller the number after the slash, the MORE IP addresses you get:

CIDR Block Number of IPs Use Case
/16 65,536 Large VPC (maximum size)
/20 4,096 Medium subnet
/24 256 Standard subnet (most common)
/28 16 Smallest allowed (minimum size)

Simple Rule: Each step from /16 to /17 to /18… cuts the number of addresses in half.

AWS-specific note: AWS reserves 5 IP addresses in each subnet (first 4 and last 1). So a /24 subnet gives you 251 usable IPs, not 256.

Common Private IP Ranges for VPCs

  • 10.0.0.0/16 — Most popular choice (10.0.0.0 to 10.0.255.255)
  • 172.16.0.0/16 — Alternative range
  • 192.168.0.0/16 — Familiar if you’ve used home routers

Default VPC vs. Custom VPC

Every AWS account comes with a default VPC in each Region. It’s like a starter apartment — convenient but limited.

Feature Default VPC Custom VPC
Created automatically? Yes (one per Region) No (you create it)
CIDR block 172.31.0.0/16 You choose (/16 to /28)
Subnets One public subnet per AZ You design the layout
Internet access Yes (by default) Only if you configure it
Best for Quick testing, learning Production workloads
Security posture Open (all subnets are public) Locked down by design

Best Practice: Use the default VPC for experimentation. Create custom VPCs for any real workload — you get full control over security, IP addressing, and network design.

Subnets: Public vs. Private

A subnet is a smaller segment of your VPC’s IP address range, placed in a specific Availability Zone (AZ). Think of subnets as individual rooms in your office building.

Public Subnet

  • Has a route to the Internet Gateway
  • Resources CAN have public IP addresses
  • Used for: Web servers, load balancers, bastion hosts
  • Analogy: The lobby of your building — visitors (internet traffic) can reach it

Private Subnet

  • NO direct route to the Internet Gateway
  • Resources cannot be reached from the internet
  • Used for: Databases, application servers, internal services
  • Analogy: The server room — only authorized internal staff can access it

Key Point: A subnet is public or private based on its route table, not a toggle switch. If the route table has a route to an Internet Gateway, it’s public.

Route Tables

A route table contains rules (routes) that determine where network traffic is directed. Every subnet must be associated with a route table.

Analogy: Route tables are like signs in a building directing you — “Lobby → left,” “Server room → right,” “Exit → through reception.”

How Route Tables Work

Destination Target Meaning
10.0.0.0/16 local Traffic within VPC stays local
0.0.0.0/0 igw-xxxxx All other traffic → Internet Gateway

Key Rules:

  • Every VPC has a main route table (default for all subnets)
  • You can create custom route tables for specific subnets
  • The local route (VPC internal traffic) cannot be removed
  • Most specific route wins (longest prefix match)

Internet Gateway (IGW)

An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet.

Analogy: The front door of your office building. Without it, nobody from outside can enter, and nobody inside can leave to the internet.

Key Characteristics

  • Only one IGW per VPC
  • Supports both IPv4 and IPv6
  • Highly available — no bandwidth constraints
  • Must be attached to the VPC AND referenced in a route table to work

Making a Subnet Public (3 Steps)

  1. Create and attach an Internet Gateway to your VPC
  2. Add a route in the subnet’s route table: 0.0.0.0/0 → IGW
  3. Ensure instances have public IP addresses (or Elastic IPs)

NAT Gateway

A NAT (Network Address Translation) Gateway allows instances in private subnets to access the internet (for software updates, API calls) WITHOUT allowing the internet to initiate connections back to them.

Analogy: A one-way mail slot. Your private servers can send letters out (make requests), but nobody outside can push mail back in unless it’s a reply.

How NAT Gateway Works

Key Points

  • NAT Gateway lives in a public subnet
  • You add a route in the private subnet’s route table: 0.0.0.0/0 → nat-xxxxx
  • Managed by AWS — no patching required
  • Supports up to 45 Gbps bandwidth (scales automatically)
  • Charged per hour + per GB of data processed
  • Zonal NAT Gateway: operates in a single AZ (traditional)
  • Regional NAT Gateway (New 2025): automatically expands across AZs for high availability without manual setup

NAT Gateway vs. NAT Instance

Feature NAT Gateway NAT Instance
Managed by AWS You
Availability Highly available in AZ Depends on your setup
Bandwidth Up to 45 Gbps Depends on instance type
Maintenance None required You patch/update
Cost Higher Lower (but more effort)
Recommendation ✓ Use this Only for cost savings

Security Groups vs. NACLs

AWS gives you two layers of network security. Understanding the difference is critical for the exam and real-world usage.

Security Groups (Instance-Level Firewall)

Analogy: A bodyguard assigned to each person (instance). The bodyguard decides who can talk to that person.

  • Operates at the instance level (attached to ENI)
  • Stateful — if inbound traffic is allowed, the response is automatically allowed
  • Supports ALLOW rules only (no deny rules)
  • All rules evaluated before deciding
  • Default: denies all inbound, allows all outbound

Example Security Group for a Web Server:

Type Protocol Port Source Description
Inbound TCP 80 0.0.0.0/0 Allow HTTP from anywhere
Inbound TCP 443 0.0.0.0/0 Allow HTTPS from anywhere
Inbound TCP 22 203.0.113.0/32 Allow SSH from my IP only
Outbound All All 0.0.0.0/0 Allow all outbound

Network ACLs (Subnet-Level Firewall)

Analogy: A security checkpoint at each floor’s entrance. Everyone passing through that floor gets checked, regardless of which room they’re going to.

  • Operates at the subnet level
  • Stateless — inbound and outbound rules are evaluated independently
  • Supports both ALLOW and DENY rules
  • Rules evaluated in order by rule number (lowest first)
  • Default NACL: allows all inbound and outbound traffic

Example NACL for a Public Subnet:

Rule # Type Protocol Port Range Source/Dest Allow/Deny
100 Inbound TCP 80 0.0.0.0/0 ALLOW
110 Inbound TCP 443 0.0.0.0/0 ALLOW
120 Inbound TCP 1024-65535 0.0.0.0/0 ALLOW
* Inbound All All 0.0.0.0/0 DENY
100 Outbound TCP 80 0.0.0.0/0 ALLOW
110 Outbound TCP 443 0.0.0.0/0 ALLOW
120 Outbound TCP 1024-65535 0.0.0.0/0 ALLOW
* Outbound All All 0.0.0.0/0 DENY

Security Groups vs. NACLs Comparison

Feature Security Group Network ACL
Level Instance (ENI) Subnet
Stateful/Stateless Stateful Stateless
Rules Allow only Allow AND Deny
Rule evaluation All rules evaluated Rules processed in order
Default (custom) Deny all inbound Deny all traffic
Default (default) Allow internal Allow all traffic
Applies to Only if associated All instances in subnet

Best Practice: Use Security Groups as your primary defense (easier to manage). Use NACLs as an additional layer for subnet-wide rules, like blocking a specific IP range.

VPC Peering

A VPC Peering Connection is a networking connection between two VPCs that enables traffic routing between them using private IP addresses. Instances in either VPC can communicate as if they are in the same network.

Analogy: Building a private bridge between two office buildings. Employees (resources) can walk between buildings directly without going outside (through the internet).

Key Rules

  • Works across different AWS accounts and different Regions
  • CIDR blocks must NOT overlap between peered VPCs
  • Not transitive — if VPC-A peers with VPC-B, and VPC-B peers with VPC-C, VPC-A CANNOT reach VPC-C through VPC-B
  • You must update route tables in BOTH VPCs
  • Security groups can reference the peered VPC’s security groups

When to Use VPC Peering

  • Connecting a development VPC to a production VPC
  • Sharing resources across AWS accounts
  • Simple one-to-one VPC connectivity

For complex multi-VPC architectures, consider AWS Transit Gateway instead — it acts as a central hub connecting multiple VPCs and on-premises networks.

VPC Endpoints

VPC Endpoints allow you to privately connect your VPC to supported AWS services without requiring an Internet Gateway, NAT Gateway, VPN, or AWS Direct Connect. Traffic never leaves the AWS network.

Analogy: Instead of leaving your building to visit the bank (AWS service), the bank opens a private counter inside your building. Faster, safer, and cheaper.

Types of VPC Endpoints

Type How it Works Supported Services Cost
Gateway Endpoint Route table entry pointing to the endpoint S3, DynamoDB only Free
Interface Endpoint (PrivateLink) ENI with private IP in your subnet Most AWS services (100+) Per hour + per GB

Why Use VPC Endpoints?

  • Security: Traffic stays within AWS network (never traverses the internet)
  • Performance: Lower latency, more reliable
  • Cost savings: No NAT Gateway data processing charges for AWS service traffic
  • Compliance: Keep sensitive data off the public internet

Example: S3 Gateway Endpoint

Without endpoint: EC2 → NAT Gateway → Internet Gateway → S3 (over the internet)

With endpoint: EC2 → S3 Gateway Endpoint → S3 (private AWS network)

Step-by-Step: Creating a VPC with Public and Private Subnets

Here’s how to create a production-ready VPC from scratch using the AWS Console:

Step 1: Create the VPC

  1. Go to VPC Console → “Create VPC”
  2. Choose “VPC and more” (creates subnets, route tables, and gateways automatically) OR “VPC only” for manual setup
  3. Name: my-app-vpc
  4. IPv4 CIDR: 10.0.0.0/16 (65,536 addresses — plenty of room)
  5. Click “Create VPC”

Step 2: Create Subnets

  1. Create a Public Subnet: 10.0.1.0/24 in AZ us-east-1a
  2. Create a Private Subnet: 10.0.2.0/24 in AZ us-east-1a
  3. Create a Public Subnet: 10.0.3.0/24 in AZ us-east-1b (for high availability)
  4. Create a Private Subnet: 10.0.4.0/24 in AZ us-east-1b

Step 3: Create and Attach an Internet Gateway

  1. Create an Internet Gateway: my-app-igw
  2. Attach it to your VPC

Step 4: Configure Route Tables

  1. Public Route Table: Add route 0.0.0.0/0 → igw-xxxxx
  2. Associate public subnets (10.0.1.0/24, 10.0.3.0/24) with this route table
  3. Private Route Table: Keep only the local route (or add NAT Gateway route)
  4. Associate private subnets (10.0.2.0/24, 10.0.4.0/24) with this route table

Step 5: Create a NAT Gateway (for private subnet internet access)

  1. Create a NAT Gateway in one of the public subnets
  2. Allocate an Elastic IP for the NAT Gateway
  3. Update the Private Route Table: add 0.0.0.0/0 → nat-xxxxx

Step 6: Configure Security Groups

  1. Web-SG: Allow inbound HTTP (80), HTTPS (443) from 0.0.0.0/0
  2. App-SG: Allow inbound from Web-SG only on app port
  3. DB-SG: Allow inbound from App-SG only on database port (3306/5432)

Quick Reference Table

Component What It Does Key Facts
VPC Isolated virtual network Max size /16, min /28. Up to 5 CIDRs per VPC (adjustable to 50).
Subnet Segment of VPC in one AZ Public = has IGW route. AWS reserves 5 IPs per subnet.
Internet Gateway Connects VPC to internet One per VPC. Highly available. No bandwidth limit.
NAT Gateway Private subnet → internet (outbound only) Lives in public subnet. Up to 45 Gbps. Charged per hour + data.
Route Table Directs traffic Local route always present. Most specific route wins.
Security Group Instance-level firewall Stateful. Allow rules only. All rules evaluated.
Network ACL Subnet-level firewall Stateless. Allow + Deny. Rules processed in order.
VPC Peering Connect two VPCs privately Non-transitive. No overlapping CIDRs. Cross-account/region OK.
VPC Endpoint Private access to AWS services Gateway (S3, DynamoDB – free). Interface (most services – paid).
Elastic IP Static public IPv4 address Free when attached to a running instance. Charged when unused.

Practice Questions

Question 1

You have an EC2 instance in a private subnet that needs to download software updates from the internet. Which combination enables this?

  1. Attach an Internet Gateway and assign a public IP to the instance
  2. Create a NAT Gateway in a public subnet and add a route in the private subnet’s route table
  3. Create a VPC Endpoint for the update server
  4. Add a route to 0.0.0.0/0 in the private subnet pointing to the Internet Gateway
Show Answer

Answer: B – A NAT Gateway in a public subnet allows private instances to access the internet for outbound traffic without being directly accessible from the internet. Option A would make it a public subnet. Option D would not work without a public IP on the instance.

Question 2

What makes a subnet “public” in AWS?

  1. It has “public” in its name tag
  2. Auto-assign public IP is enabled
  3. Its route table has a route to an Internet Gateway
  4. It is in the default VPC
Show Answer

Answer: C – A subnet is public when its associated route table contains a route directing internet-bound traffic (0.0.0.0/0) to an Internet Gateway. The name and auto-assign IP settings don’t determine this.

Question 3

Your security team wants to block all traffic from a specific IP range (203.0.113.0/24) at the subnet level. Which should you use?

  1. Security Group with a deny rule
  2. Network ACL with a deny rule
  3. Route table blackhole route
  4. AWS WAF rule
Show Answer

Answer: B – Network ACLs support both ALLOW and DENY rules and operate at the subnet level. Security Groups only support ALLOW rules, so you cannot explicitly deny specific IPs with them.

Question 4

VPC-A (10.0.0.0/16) is peered with VPC-B (172.16.0.0/16). VPC-B is peered with VPC-C (192.168.0.0/16). Can instances in VPC-A communicate with VPC-C through VPC-B?

  1. Yes, VPC peering is transitive
  2. Yes, if route tables are configured correctly in VPC-B
  3. No, VPC peering is NOT transitive
  4. Yes, but only for ICMP traffic
Show Answer

Answer: C – VPC peering is non-transitive. VPC-A must create a direct peering connection with VPC-C to communicate. Traffic cannot pass through VPC-B as an intermediary.

Question 5

An application in a private subnet needs to access S3 without traversing the internet. What’s the most cost-effective solution?

  1. Create a NAT Gateway and access S3 over the internet
  2. Create an S3 Gateway Endpoint
  3. Create an S3 Interface Endpoint (PrivateLink)
  4. Peer the VPC with the S3 VPC
Show Answer

Answer: B – S3 Gateway Endpoints are free and provide private access to S3 without requiring a NAT Gateway. Interface Endpoints (Option C) would also work but incur hourly and data charges. NAT Gateway (Option A) would add unnecessary cost.

What’s New in AWS VPC (2025-2026)

  • VPC Encryption Controls (Nov 2025): Enforce encryption in transit for all traffic within and across VPCs using monitor and enforce modes — no application changes needed.
  • Regional NAT Gateways (Nov 2025): A single NAT Gateway that automatically expands across Availability Zones based on your workload, providing automatic high availability without manual multi-AZ setup.
  • Amazon VPC Lattice: A fully managed service for connecting, securing, and monitoring service-to-service communication across VPCs and accounts — ideal for microservices architectures.
  • Amazon VPC IPAM: Centrally plan, track, and monitor IP addresses across your AWS organization.

Summary

AWS VPC is the foundation of cloud networking. Every resource you deploy sits inside a VPC. Here’s the key takeaway:

  • VPC = Your private network in AWS (an isolated building)
  • Subnets = Rooms in your building (public-facing or private)
  • Route Tables = Signs directing traffic to the right destination
  • Internet Gateway = Your front door to the internet
  • NAT Gateway = One-way outbound access for private resources
  • Security Groups = Personal bodyguards (stateful, allow-only)
  • NACLs = Floor-level security checkpoints (stateless, allow + deny)
  • VPC Peering = Private bridge between two VPCs
  • VPC Endpoints = Private counter for AWS services inside your VPC

Start with the default VPC for learning, then build custom VPCs for production. Always place databases in private subnets and web servers in public subnets. Use security groups as your primary defense, and add NACLs for subnet-wide rules.

Frequently Asked Questions

What is a VPC in AWS?

A Virtual Private Cloud (VPC) is your own isolated network within AWS where you launch resources. Think of it like renting a private floor in an office building — you control the layout (subnets), doors (gateways), and security (security groups/NACLs).

What is the difference between a public and private subnet?

A public subnet has a route to an Internet Gateway, allowing resources with public IPs to communicate directly with the internet. A private subnet has no internet route — resources can only access the internet through a NAT Gateway for outbound traffic.

Do I need to create a VPC to use AWS?

No, every AWS account comes with a default VPC in each region with public subnets, an internet gateway, and default security groups. However, for production workloads, creating a custom VPC with public and private subnets is recommended for better security.

Related Posts

Global Accelerator vs CloudFront – When to Use Each

~ Last updated on : ~ Kiro Agent

AWS Global Accelerator vs CloudFront

AWS Global Accelerator and Amazon CloudFront both leverage the AWS global edge network to improve application performance for distributed users, but they solve fundamentally different problems. Understanding when to use each — or both together — is critical for AWS certification exams and real-world architecture decisions.

  • CloudFront is a Content Delivery Network (CDN) that caches content at edge locations and serves it directly to users, reducing latency and origin load for HTTP/HTTPS workloads.
  • Global Accelerator is a network-layer traffic accelerator that uses anycast static IP addresses to route TCP/UDP traffic over the AWS backbone to the optimal regional endpoint — without caching.

The critical distinction: CloudFront optimizes what is delivered (content caching and edge compute). Global Accelerator optimizes how packets travel (network path optimization via the AWS backbone).

CloudFront (CDN)
User Request (HTTP/S)
↓
750+ Edge Locations
↓ Cache HIT → Response
↓ Cache MISS ↓
Regional Edge Cache
↓
Origin (ALB/S3/EC2)
Layer 7 | Caches content | HTTP/S only
Global Accelerator
User Request (TCP/UDP)
↓
Anycast Static IPs
↓
Nearest AWS Edge
↓ AWS Private Backbone
Endpoint (ALB/NLB/EC2)
↕ Health checks → Failover
Layer 4 | No caching | TCP/UDP/HTTP

Architecture Comparison

CloudFront Architecture: Edge Caching

  • Uses 750+ Points of Presence (PoPs) in 100+ cities across 50+ countries, plus 1,140+ Embedded PoPs within ISP networks.
  • Operates at Layer 7 (Application layer) — understands HTTP/HTTPS, headers, cookies, query strings.
  • Multi-tier caching: Edge Locations → Regional Edge Caches (RECs) → Origin Shield → Origin.
  • Users connect to the nearest edge location via DNS-based routing (anycast DNS). CloudFront resolves to the optimal edge IP.
  • If content is cached (cache hit), it’s served directly from the edge — origin is never contacted.
  • If content is not cached (cache miss), CloudFront fetches from origin over the AWS backbone, caches it, then serves it.
  • Supports edge compute via CloudFront Functions (lightweight, sub-ms) and Lambda@Edge (full Node.js/Python).
  • Since November 2024, supports Anycast Static IPs for allowlisting and apex domain support (up to 21 IPs).

Global Accelerator Architecture: Anycast IP + AWS Backbone

  • Uses 130 PoPs in 95 cities across 53 countries.
  • Operates at Layer 4 (Transport layer) — works with TCP and UDP packets regardless of application protocol.
  • Provides two static anycast IPv4 addresses (optionally two IPv6 for dual-stack) per accelerator, serviced by independent network zones.
  • Users connect to the nearest edge location via anycast IP routing — traffic enters the AWS global network at the closest PoP.
  • Traffic then travels over the AWS private backbone (not the public internet) to the optimal endpoint in the target AWS Region.
  • No caching — every request is proxied to the backend endpoint.
  • Supports Custom Routing accelerators for deterministic routing to specific EC2 instances (e.g., gaming matchmaking).
  • Health checks continuously monitor endpoints and failover happens in under 30 seconds without DNS changes.

Detailed Feature Comparison Table

Feature Amazon CloudFront AWS Global Accelerator
Service Type Content Delivery Network (CDN) Network traffic accelerator (anycast routing)
OSI Layer Layer 7 (Application) Layer 4 (Transport)
Protocol Support HTTP, HTTPS (TLSv1.3), WebSocket, gRPC TCP, UDP (any application protocol)
Caching Yes — Edge + Regional Edge Caches + Origin Shield No — proxies all requests to endpoint
Edge Locations 750+ PoPs + 1,140+ Embedded PoPs 130 PoPs in 95 cities
Static IP Addresses Yes — Anycast Static IPs (Nov 2024), up to 21 IPs; BYOIP via IPAM Yes — 2 anycast IPv4 + 2 IPv6 (dual-stack); BYOIP supported
Performance Approach Serve cached content from edge (eliminate round-trips to origin) Route traffic over AWS backbone (reduce internet hops and congestion)
Health Checks Origin failover (GET/HEAD only) via origin groups Continuous TCP/HTTP/HTTPS health checks with configurable thresholds
Failover DNS-based; origin failover for GET/HEAD; subject to DNS TTL Instant (<30 seconds); no DNS change needed (same static IPs)
DDoS Protection AWS Shield Standard (auto); Shield Advanced optional; built-in bot management AWS Shield Standard (auto); Shield Advanced optional; rate-limit mitigations based on endpoint capacity
WAF Integration Yes — AWS WAF with managed rules, rate limiting, bot control No — WAF not supported
Client Affinity No (stateless edge caching); sticky sessions via cookies at ALB origin Yes — Source IP affinity (NONE or SOURCE_IP) to maintain endpoint stickiness
Origins/Endpoints S3, ALB, NLB, EC2, API Gateway, MediaStore, custom HTTP origins; VPC Origins (private ALB/NLB/EC2) ALB, NLB, EC2 instances, Elastic IP addresses (in any Region)
Multi-Region Single origin or origin group (primary + secondary) Multiple endpoint groups across Regions with traffic dials (0-100%)
Edge Compute CloudFront Functions + Lambda@Edge No
Custom Routing No Yes — deterministic routing to specific EC2 instances (port mapping)
IPv6 Support Yes (dual-stack distributions); Anycast Static IPs IPv6 (Nov 2025) Yes (dual-stack accelerators with NLB endpoints)

Pricing Comparison

Pricing Component Amazon CloudFront AWS Global Accelerator
Fixed Cost No fixed fee (pay-as-you-go); Flat-rate plans available from Nov 2025 $0.025/hour per accelerator (~$18/month)
Data Transfer $0.085/GB (first 10TB, US/EU); tiered pricing down to $0.020/GB at 5PB+ Standard EC2 data transfer out + DT-Premium fee ($0.015–$0.105/GB depending on source/destination)
Request Charges $0.0075–$0.016 per 10,000 HTTP requests (varies by region) No per-request charges
Free Tier 1 TB data transfer out + 10M requests/month (always free) No free tier
Billing Model Charged on all outbound data + requests; or flat-rate plan Charged only on dominant direction (inbound OR outbound, whichever is higher per hour)
Public IPv4 Charges N/A (DNS-based routing by default) Standard public IPv4 address charges apply
Cost Optimization Caching reduces origin fetches; Price Class selection limits expensive regions; Flat-rate plans for predictability Traffic dials to shift traffic between regions; dominant-direction billing saves on bidirectional traffic

Use Cases — When to Use Each

Choose CloudFront When:

  • Serving static content globally — images, CSS, JavaScript, video, software downloads. Caching at 750+ edge locations dramatically reduces latency and origin load.
  • API acceleration with caching — cacheable API responses (GET requests), dynamic site delivery, and personalization at the edge.
  • Video streaming — live and on-demand streaming with Embedded PoPs in ISP networks for large-scale delivery.
  • Web application security — need AWS WAF integration for rate limiting, geo-blocking, bot management, or SQL injection/XSS protection.
  • Edge compute requirements — A/B testing, URL rewrites, header manipulation, authentication at edge via CloudFront Functions or Lambda@Edge.
  • Cost-sensitive workloads — free tier (1TB/month), and caching eliminates repeated origin fetches, reducing overall data transfer costs.
  • S3 origin delivery — serving S3 content with Origin Access Control (OAC) for security.

Choose Global Accelerator When:

  • Non-HTTP protocols — gaming (UDP), IoT (MQTT over TCP), VoIP (SIP/RTP over UDP), custom TCP protocols.
  • Static IP addresses required — firewall allowlisting, DNS-independent addressing, compliance requirements for fixed IPs.
  • Instant failover needed — multi-region active-active or active-passive with <30 second failover, no DNS propagation delay.
  • Dynamic, uncacheable content — every request must reach the origin (financial transactions, real-time data).
  • Client affinity (session stickiness) — route the same client to the same endpoint for stateful connections.
  • Multi-region traffic management — traffic dials to gradually shift traffic between regions (blue/green deployments, disaster recovery).
  • Custom routing to specific instances — gaming matchmaking, multiplayer session routing to specific EC2 instances.
  • Consistent performance for TCP workloads — eliminate internet congestion and variable routing for any TCP/UDP application.

Use Both Together When:

  • You need cacheable content delivery (CloudFront) AND fixed IPs with instant failover for the origin infrastructure (Global Accelerator as the origin for CloudFront).
  • A multi-region application where CloudFront caches static assets and Global Accelerator handles the dynamic API layer requiring TCP-level optimization.
  • Gaming platforms: CloudFront delivers game patches/updates while Global Accelerator handles real-time multiplayer (UDP).

Decision Flowchart Guidance

Step-by-Step Decision Process

Step 1: What protocol does your application use?

  • → If UDP (gaming, VoIP, IoT) → Global Accelerator
  • → If TCP (non-HTTP) (custom protocols, MQTT, database proxying) → Global Accelerator
  • → If HTTP/HTTPS → Continue to Step 2

Step 2: Is your content cacheable?

  • → If Yes (static assets, cacheable API responses, video) → CloudFront
  • → If No (fully dynamic, uncacheable) → Continue to Step 3

Step 3: Do you need static IP addresses for firewall allowlisting?

  • → If Yes → Global Accelerator (or CloudFront Anycast Static IPs if HTTP-only)
  • → If No → Continue to Step 4

Step 4: Do you need instant failover without DNS propagation delay?

  • → If Yes → Global Accelerator (failover <30 seconds, no DNS change)
  • → If No → Continue to Step 5

Step 5: Do you need WAF, edge compute, or bot management?

  • → If Yes → CloudFront
  • → If No → Continue to Step 6

Step 6: Do you need client affinity (same client → same endpoint)?

  • → If Yes → Global Accelerator
  • → If No → CloudFront (better global coverage with 750+ PoPs, lower cost with free tier)

Integration with ALB, NLB, and EC2

Integration CloudFront Global Accelerator
ALB Yes — as custom origin (public or private via VPC Origins). Full Layer 7 features (path-based routing, host-based routing). Yes — as endpoint in an endpoint group. Supports multiple ALBs across regions with weighted traffic.
NLB Yes — as custom origin (public or private via VPC Origins). Useful for TCP/TLS passthrough to origin. Yes — as endpoint. Supports dual-stack NLB endpoints. Ideal for TCP/UDP workloads behind NLB.
EC2 Yes — as custom origin (public IP or private via VPC Origins). Must run a web server (HTTP/HTTPS). Yes — as endpoint (via Elastic IP). Custom Routing accelerators can map to specific EC2 instance ports.
S3 Yes — native S3 origin with Origin Access Control (OAC). No — S3 is not a supported endpoint type.
API Gateway Yes — as custom origin for caching API responses. No — API Gateway is not a supported endpoint.
Multi-Region Origin groups (primary + secondary) in different regions; failover for GET/HEAD only. Multiple endpoint groups across any number of regions with traffic dials and automatic health-check failover for all traffic types.

DDoS Protection Deep Dive

  • Both services automatically include AWS Shield Standard at no additional cost, protecting against common Layer 3/4 DDoS attacks.
  • Both support AWS Shield Advanced ($3,000/month + DRT support) for enhanced detection, mitigation, and cost protection against DDoS-related scaling costs.
  • CloudFront additionally provides:
    • AWS WAF integration for Layer 7 (application-layer) DDoS mitigation (HTTP flood protection, rate limiting).
    • Built-in bot management and geographic restrictions.
    • Distributed architecture with 750+ PoPs absorbs volumetric attacks closer to the source.
  • Global Accelerator provides:
    • Shield mitigations enforce rate limits based on endpoint capacity — only valid traffic reaches listeners.
    • Anycast distribution across 130 PoPs absorbs DDoS traffic at the edge.
    • Particularly effective for TCP/UDP DDoS attacks (SYN floods, UDP reflection) targeting non-HTTP workloads.
    • Shield Advanced health check integration enables proactive DDoS response.

Performance Optimization Approaches

Optimization CloudFront Global Accelerator
Latency Reduction Eliminates round-trip to origin via cached content; persistent connections to origin for cache misses Routes traffic off public internet at nearest PoP; AWS backbone provides consistent low-latency path (up to 60% improvement)
Throughput High throughput via distributed caching; TCP optimizations (congestion window tuning) AWS backbone provides higher, more consistent throughput than public internet paths
Connection Optimization TLS termination at edge; persistent connections to origin; HTTP/2 and HTTP/3 (QUIC) support TCP termination at edge PoP; optimized TCP connections to endpoints over AWS backbone
Availability Origin failover (GET/HEAD); cached content continues serving during origin outages Instant multi-region failover (<30s); traffic dials for gradual migration; health checks on all traffic types

AWS Certification Exam Practice Questions

Question 1:

A gaming company runs a multiplayer online game that communicates via UDP. Players are distributed globally and experience high latency due to internet routing inefficiencies. The company needs static IP addresses for players to configure in their game clients. Which AWS service should be used to improve performance?

  1. Amazon CloudFront
  2. AWS Global Accelerator
  3. Amazon Route 53 with latency-based routing
  4. Application Load Balancer with cross-zone load balancing
Show Answer

Answer: B –

Explanation: Global Accelerator is the correct choice for UDP workloads requiring static IP addresses. CloudFront only supports HTTP/HTTPS/WebSocket/gRPC (not UDP). Global Accelerator provides two static anycast IPs and routes UDP traffic over the AWS backbone to the nearest healthy regional endpoint, reducing latency. Route 53 provides DNS-based routing but doesn’t optimize the network path or provide static IPs for non-DNS traffic.

Question 2:

A media streaming company serves video content to millions of viewers globally. During peak events, origin servers experience heavy load. The company wants to reduce origin load and serve content with minimal latency. They also need AWS WAF to block malicious requests. Which solution meets these requirements?

  1. AWS Global Accelerator with ALB endpoints and AWS WAF on the ALB
  2. Amazon CloudFront with S3 origin and AWS WAF associated with the distribution
  3. AWS Global Accelerator with CloudFront as an endpoint
  4. Amazon Route 53 with geolocation routing to regional ALBs
Show Answer

Answer: B –

Explanation: CloudFront is designed for content delivery with edge caching, which reduces origin load during peak events. It natively integrates with AWS WAF at the distribution level for Layer 7 protection. Global Accelerator doesn’t cache content (wouldn’t reduce origin load) and doesn’t support WAF integration. Option A places WAF on ALB but doesn’t solve the origin load problem since every request reaches the ALB.

Question 3:

A financial services company runs a trading application across us-east-1 and eu-west-1. The application handles real-time transactions over HTTPS that cannot be cached. They require failover between regions in under 30 seconds without DNS propagation delay, and the application needs fixed IP addresses for partner firewall rules. Which architecture meets these requirements?

  1. Amazon CloudFront with origin groups configured for both regions
  2. AWS Global Accelerator with endpoint groups in both regions and health checks
  3. Amazon Route 53 failover routing with health checks and low TTL
  4. Amazon CloudFront with Anycast Static IPs and Lambda@Edge for routing
Show Answer

Answer: B –

Explanation: Global Accelerator provides static anycast IPs (for firewall rules), instant failover under 30 seconds (no DNS change needed since the same IPs are used), and works well with uncacheable HTTPS content. CloudFront origin failover only works for GET/HEAD requests (not suitable for financial transactions using POST). Route 53 failover depends on DNS TTL propagation. While CloudFront now offers Anycast Static IPs, it cannot provide deterministic sub-30-second failover for POST requests.

Question 4:

A company wants to deploy a global web application that serves both static assets (images, CSS, JS) and dynamic API requests. Static assets are cacheable, but API responses are personalized and uncacheable. They need the lowest possible latency for both content types and instant multi-region failover for the API layer. Which combination of services should be used?

  1. CloudFront for everything with cache behaviors (cache static, bypass cache for API)
  2. Global Accelerator for everything with ALB endpoints in multiple regions
  3. CloudFront for static assets + Global Accelerator for the dynamic API endpoints
  4. CloudFront for static assets + Route 53 latency-based routing for API
Show Answer

Answer: C –

Explanation: Using both services together provides the best of both worlds. CloudFront caches static assets at 750+ edge locations for lowest latency delivery. Global Accelerator handles the dynamic API layer by routing traffic over the AWS backbone with instant failover across regions. Option A would work for caching but doesn’t provide instant failover for the API. Option B doesn’t cache static content, increasing origin load and latency. Option D depends on DNS TTL for failover.

Question 5:

A company operates an IoT platform that receives MQTT messages (over TCP) from 500,000 devices worldwide. They need to ensure devices always connect to the nearest healthy regional endpoint, with automatic failover if a region becomes unavailable. Devices have hardcoded IP addresses and cannot resolve DNS. Which solution is most appropriate?

  1. Amazon CloudFront with WebSocket support for MQTT
  2. Network Load Balancer with Elastic IPs in each region
  3. AWS Global Accelerator with Custom Routing to endpoint groups across regions
  4. AWS Global Accelerator with standard routing and NLB endpoints in multiple regions
Show Answer

Answer: D –

Explanation: Global Accelerator is ideal because: (1) it provides static anycast IPs that devices can hardcode without DNS dependency, (2) it routes TCP traffic (MQTT) to the nearest healthy regional endpoint, (3) it provides automatic failover when a region’s health check fails. CloudFront doesn’t support raw TCP/MQTT (only HTTP/HTTPS/WebSocket). Option B requires devices to know which regional IP to use and doesn’t provide cross-region failover. Custom Routing (Option C) is for deterministic routing to specific instances, not for nearest-region routing.

Key Takeaways for AWS Certification Exams

  • CloudFront = CDN = Caching = HTTP/HTTPS = Layer 7. Think web content, APIs, video streaming, edge compute.
  • Global Accelerator = Network Optimization = No Caching = TCP/UDP = Layer 4 = Static IPs. Think gaming, IoT, VoIP, instant failover.
  • If the question mentions UDP or non-HTTP protocols → Global Accelerator.
  • If the question mentions static IPs for firewall allowlisting + instant failover → Global Accelerator (though CloudFront now has Anycast Static IPs for HTTP workloads).
  • If the question mentions caching, WAF, edge compute, or reducing origin load → CloudFront.
  • If the question mentions both cached content AND non-HTTP/instant failover needs → Use both together.
  • Global Accelerator failover is instant (no DNS); CloudFront/Route 53 failover depends on DNS TTL propagation.

Frequently Asked Questions

What is the difference between Global Accelerator and CloudFront?

CloudFront is a CDN that caches content at 750+ edge locations for HTTP/HTTPS traffic. Global Accelerator uses anycast IPs to route TCP/UDP traffic over AWS’s private backbone to the nearest healthy endpoint, without caching.

When should I use Global Accelerator instead of CloudFront?

Use Global Accelerator for non-HTTP protocols (TCP/UDP gaming, IoT, VoIP), when you need static IP addresses, instant failover between regions, or for applications that can’t benefit from caching like real-time APIs.

Can I use Global Accelerator and CloudFront together?

Yes, you can place CloudFront behind Global Accelerator to get both static IPs and edge caching. This is useful when you need deterministic IPs for firewall allowlisting plus CDN benefits.

Related Posts

References

AWS Certified Advanced Networking – Specialty ANS-C01 Exam Learning Path

AWS Certified Advanced Networking - Specialty Certificate
~ Last updated on : ~ jayendrapatil

AWS Certified Advanced Networking – Specialty ANS-C01 Exam Learning Path

⚠️ EXAM RETIREMENT NOTICE

The AWS Certified Advanced Networking – Specialty (ANS-C01) exam is being retired. The last day to take the exam is August 25, 2026.

Certifications earned prior to the retirement will remain active for the standard three-year period. New AWS Certified Advanced Networking – Specialty certifications will not be issued after the retirement date.

If you plan to take this exam, schedule it before August 25, 2026.

I recently certified/recertified for the AWS Certified Advanced Networking – Specialty (ANS-C01). Frankly, Networking is something that I am still diving deep into and I just about managed to get through. So a word of caution, this exam is inline or tougher than the professional exams, especially for the reason that some of the Networking concepts covered are not something you can get your hands dirty with easily.

AWS Certified Advanced Networking – Specialty ANS-C01 Exam Content

  • AWS Certified Advanced Networking – Specialty (ANS-C01) exam focuses on the AWS Networking concepts. It basically validates
    • Design and develop hybrid and cloud-based networking solutions by using AWS
    • Implement core AWS networking services according to AWS best practices
    • Operate and maintain hybrid and cloud-based network architecture for all AWS services
    • Use tools to deploy and automate hybrid and cloud-based AWS networking tasks
    • Implement secure AWS networks using AWS native networking constructs and services

Refer to AWS Certified Advanced Networking – Specialty Exam Guide AWS Certified Advanced Networking - Specialty ANS-C01 Exam Domains

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Resources

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Summary

  • Specialty exams are tough, lengthy, and tiresome. Most of the questions and answers options have a lot of prose and a lot of reading that needs to be done, so be sure you are prepared and manage your time well.
  • ANS-C01 exam has 65 questions to be solved in 170 minutes which gives you roughly 2 1/2 minutes to attempt each question. 65 questions consists of 50 scored and 15 unscored questions.
  • ANS-C01 exam includes two types of questions, multiple-choice and multiple-response.
  • ANS-C01 has a scaled score between 100 and 1,000. The scaled score needed to pass the exam is 750.
  • Each question mainly touches multiple AWS services.
  • Specialty exams currently cost $ 300 + tax.
  • You can get an additional 30 minutes if English is your second language by requesting Exam Accommodations. It might not be needed for Associate exams but is helpful for Professional and Specialty ones.
  • As always, mark the questions for review and move on and come back to them after you are done with all.
  • As always, having a rough architecture or mental picture of the setup helps focus on the areas that you need to improve. Trust me, you will be able to eliminate 2 answers for sure and then need to focus on only the other two. Read the other 2 answers to check the difference area and that would help you reach the right answer or at least have a 50% chance of getting it right.
  • AWS exams can be taken either remotely or online, I prefer to take them online as it provides a lot of flexibility. Just make sure you have a proper place to take the exam with no disturbance and nothing around you.
  • Also, if you are taking the AWS Online exam for the first time try to join at least 30 minutes before the actual time as I have had issues with both PSI and Pearson with long wait times.

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Topics

  • AWS Certified Networking – Specialty (ANS-C01) exam focuses a lot on Networking concepts involving Hybrid Connectivity with Direct Connect, VPN, Transit Gateway, Direct Connect Gateway, and a bit of VPC, Route 53, ALB, NLB & CloudFront.

Networking & Content Delivery

  • Virtual Private Cloud – VPC
    • Understand VPC, Subnets
    • AWS allows extending the VPC by adding a secondary VPC
    • Understand Security Groups, NACLs
    • VPC Flow Logs
      • help capture information about the IP traffic going to and from network interfaces in the VPC and can help in monitoring the traffic or troubleshooting any connectivity issues
      • NACLs are stateless and how it is reflected in VPC Flow Logs
        • If ACCEPT followed by REJECT, inbound was accepted by Security Groups and ACLs. However, rejected by NACLs outbound
        • If REJECT, inbound was either rejected by Security Groups OR NACLs.
      • Use pkt-dstaddr instead of dstaddr to track the destination address as dstaddr refers to the primary ENI address always and not the secondary addresses.
      • Pattern: VPC Flow Logs -> CloudWatch Logs -> (Subscription) -> Amazon Data Firehose -> S3/OpenSearch.
      • (New – Jun 2026) VPC Flow Logs now supports EC2 resource tags and next-hop interface metadata, simplifying network monitoring by eliminating the need to manually correlate flow log data with resource metadata.
    • DHCP Option Sets esp. how to resolve DNS from both on-premises data center and AWS.
    • VPC Peering
      • helps point-to-point connectivity between 2 VPCs which can be in the same or different regions and accounts.
      • know VPC Peering Limitations esp. it does not allow overlapping CIDRs and transitive routing.
    • Placement Groups determine how the instances are placed on the underlying hardware
    • VRF – Virtual Routing & Forwarding can be used to route traffic to the same customer gateway from multiple VPCs, that can be overlapping.
  • VPC Endpoints
    • VPC Gateway Endpoints for connectivity with S3 & DynamoDB i.e. VPC -> VPC Gateway Endpoints -> S3/DynamoDB.
    • VPC Interface Endpoints or Private Links for other AWS services and custom hosted services i.e. VPC -> VPC Interface Endpoint OR Private Link -> S3/Kinesis/SQS/CloudWatch/Any custom endpoint.
    • S3 gateway endpoints cannot be accessed through VPC Peering, VPN, or Direct Connect. Need HTTP proxy to route traffic.
    • S3 Private Link can be accessed through VPC Peering, VPN, or Direct Connect. Need to use an endpoint-specific DNS name.
    • VPC endpoint policy can be configured to control which S3 buckets can be accessed and the S3 Bucket policy can be used to control which VPC (includes all VPC Endpoints) or VPC Endpoint can access it.
    • (New – Nov 2025) Cross-Region PrivateLink — AWS PrivateLink now supports cross-region connectivity, allowing interface VPC endpoints to connect to AWS services in other Regions within the same partition without needing inter-region peering or Transit Gateway.
    • Private Link Patterns
  • VPC Network Access Analyzer
    • helps identify unintended network access to the resources on AWS.
  • Transit Gateway
    • helps consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
    • Appliance Mode ensures that network flows are symmetrically routed to the same AZ and network appliance
    • Transit Gateway Connect attachment can be used to connect SD-WAN to AWS Cloud. This supports GRE.
    • Transit Gateways are regional and Peering can connect Transit Gateways across regions.
    • Transit Gateway Network Manager includes events and metrics to monitor the quality of the global network, both in AWS and on-premises.
    • Transit Gateway Flow Logs — enables capturing detailed information such as source/destination IPs, ports, protocol, traffic counters, timestamps, and metadata for all network flows traversing through the Transit Gateway. Can be published to CloudWatch Logs and S3.
    • (New – Nov 2024) Transit Gateway now supports Path MTU Discovery (PMTUD) for both IPv4 and IPv6 protocols, improving performance for large packet workloads.
  • AWS Cloud WAN (New)
    • provides a central dashboard to create a global wide-area network connecting resources across your cloud and on-premises environments.
    • uses a central network policy to define network management and security policies in one location.
    • now supports direct integration with AWS Direct Connect gateways, enabling routes to be advertised directly between Cloud WAN segments and on-premises environments.
    • supports Service Insertion for routing traffic through middlebox appliances (firewalls, IDS/IPS).
    • for organizations with complex multi-region networking needs, Cloud WAN simplifies what would otherwise require multiple Transit Gateways with peering.
  • VPC Routing Priority
  • NAT Gateways
    • for HA, Scalable, Outgoing traffic. Does not support Security Groups or ICMP pings.
    • times out the connection if it is idle for 350 seconds or more. To prevent the connection from being dropped, initiate more traffic over the connection or enable TCP keepalive on the instance with a value of less than 350 seconds.
    • supports Private NAT Gateways for internal communication.
    • (New – Nov 2025) Regional NAT Gateway — a single NAT Gateway that automatically expands and contracts across availability zones based on workload presence, maintaining high availability without needing to deploy one per AZ. Supports Amazon-provided IPs and BYOIP.
  • Amazon VPC Lattice (New)
    • fully managed application networking service for service-to-service and service-to-resource communication across VPCs and accounts.
    • abstracts IP address dependencies — services communicate without direct network routing.
    • provides fine-grained Auth policies using IAM for consistent access controls.
    • supports TCP resources (databases, domain names, IP addresses) across VPCs and accounts via Resource Gateway.
    • eliminates the need for VPC peering, Transit Gateway, or PrivateLink for service mesh connectivity.
    • useful for microservices architectures where services span multiple VPCs/accounts.
  • Virtual Private Network
    • to establish connectivity between the on-premises data center and AWS VPC
  • Direct Connect
    • to establish connectivity between the on-premises data center and AWS VPC and Public Services
    • Direct Connect connections – Dedicated and Hosted connections
    • Understand how to create a Direct Connect connection
      • LOA-CFA provides the details for partners to connect to the AWS Direct Connect location
    • Virtual interfaces options – Private Virtual Interface for VPC resources and Public Virtual Interface for Public Resources
      • Private VIF is for resources within a VPC
      • Public VIF is for AWS public resources
      • Transit VIF is for connecting to Transit Gateways via Direct Connect Gateway
      • Private VIF has a limit of 100 routes and Public VIF of 1000 routes. Summarize the routes if you need to configure more.
    • (New – Jun 2026) VIF Rate Limiters — allows setting a maximum bandwidth allocation for up to 10 VIFs on a dedicated connection, with capacity increments from 50 Mbps to 1.6 Tbps (when using LAG). Rate limiting applies to traffic both ingressing and egressing the AWS network, helping prevent network congestion on shared connections.
    • (New – Mar 2025) CloudWatch VIF Metrics — new metrics for VirtualInterfaceBgpStatus, VirtualInterfaceBgpPrefixesAccepted, and VirtualInterfaceBgpPrefixesAdvertised for monitoring BGP health and prefix counts.
    • Understand setup Private and Public VIF
    • Understand High Availability options based on cost and time i.e. Second Direct Connect connection OR VPN connection
    • Direct Connect Gateway
      • it provides a way to connect to multiple VPCs from an on-premises data center using the same Direct Connect connection.
      • can connect to VGW or TGW.
      • (New – Nov 2024) Direct Connect Gateway can now be attached directly to AWS Cloud WAN core networks, enabling routes to be advertised between Cloud WAN segments and on-premises.
    • Understand Active/Passive Direct Connect
    • supports MACsec which delivers native, near line-rate, point-to-point encryption ensuring that data communications between AWS and the data center, office, or colocation facility remain protected.
    • Understand Route Propagation, propagation priority, BGP connectivity
      • BGP prefers the shortest AS PATH to get to the destination. Traffic from the VPC to on-premises uses the primary router. This is because the secondary router advertises a longer AS-PATH.
      • AS PATH prepending doesn’t work when the Direct Connect connections are in different AWS Regions than the VPC.
      • AS PATH works from AWS to on-premises and Local Pref from on-premises to AWS
      • Use Local Preference BGP community tags to configure Active/Passive when the connections are from different regions. The higher tag has a higher preference for 7224:7300 > 7224:7100
      • NO_EXPORT works only for Public VIFs
      • 7224:9100, 7224:9200, and 7224:9300 apply only to public prefixes. Usually used to restrict traffic to regions. Can help control if routes should propagate to the local Region only, all Regions within a continent, or all public Regions.
        • 7224:9100 — Local AWS Region
        • 7224:9200 — All AWS Regions for a continent, North America–wide, Asia Pacific, Europe, the Middle East and Africa
        • 7224:9300 — Global (all public AWS Regions)
      • 7224:8100 — Routes that originate from the same AWS Region in which the AWS Direct Connect point of presence is associated.
      • 7224:8200 — Routes that originate from the same continent with which the AWS Direct Connect point of presence is associated.
      • No-tag — Global (all public AWS Regions).
  • Route 53
    • provides a highly available and scalable DNS web service.
    • Routing Policies and their use cases Focus on Weighted, Latency, and Failover routing policies.
    • supports Alias resource record sets, which enables routing of queries to a CloudFront distribution, Elastic Beanstalk, ELB, an S3 bucket configured as a static website, or another Route 53 resource record set.
    • CNAME does not support zone apex or root records.
    • Route 53 DNSSEC
      • secures DNS traffic, and helps protect a domain from DNS spoofing man-in-the-middle attacks.
      • Requirements
        • Asymmetric Customer Managed Keys
        • us-east-1 with ECC_NIST_P256 spec
    • Route 53 Resolver DNS Firewall
      • protection for outbound DNS requests from the VPCs and can monitor and control the domains that the applications can query.
      • allows you to define allow and deny list.
      • can be used for DNS exfiltration.
      • supports FirewallFailOpen configuration which determines how Route 53 Resolver handles queries during failures.
        • disabled, favors security over availability and blocks queries that it is unable to evaluate properly.
        • enabled, favors availability over security and allows queries to proceed if it is unable to properly evaluate them.
    • Route 53 Resolver (Hybrid DNS)
      • Inbound Endpoint for On-premises -> AWS
      • Outbound Endpoint for AWS -> On-premises
    • Route 53 DNS Query Logging
      • Can be logged to CloudWatch logs, S3, and Amazon Data Firehose
    • Route 53 Resolver rules take precedence over privately hosted zones.
    • Route 53 Split View DNS helps to have the same DNS to access a site externally and internally
    • Know the Domain Migration process
  • CloudFront
    • provides a fully managed, fast CDN service that speeds up the distribution of static, dynamic web, or streaming content to end-users.
    • supports geo-restriction, WAF & AWS Shield for protection.
    • provides Cloud Functions (Edge location) & Lambda@Edge (Regional location) to execute scripts closer to the user.
    • supports encryption at rest and end-to-end encryption
    • CloudFront Origin Shield
      • helps improve the cache hit ratio and reduce the load on the origin.
      • requests from other regional caches would hit the Origin shield rather than the Origin.
      • should be placed at the regional cache and not in the edge cache
      • should be deployed to the region closer to the origin server
    • (New – Nov 2024) CloudFront VPC Origins
      • allows CloudFront to point directly to ALBs, NLBs, or EC2 instances in private subnets.
      • eliminates the need for public internet access to origins — CloudFront becomes the only entry point.
      • removes need for Origin Access Identity workarounds for non-S3 origins.
      • supports cross-account VPC origin sharing via AWS RAM.
    • (New – 2025) CloudFront Flat-Rate Pricing Plans — combines CDN, WAF, DDoS protection, bot management, Route 53, CloudWatch Logs, edge compute, and S3 storage into tiered monthly plans (Free, Pro $15/mo, Business $200/mo, Premium $1,000/mo).
  • Global Accelerator
    • provides 2 static IPv4 IPs (or 4 addresses with dual-stack: 2 IPv4 + 2 IPv6)
    • (Updated) Global Accelerator now supports dual-stack accelerators with IPv6 for ALB, NLB, and EC2 endpoints, enabling end-to-end IPv6 connectivity.
    • does not support client IP address preservation for NLB and Elastic IP address endpoints.
    • know CloudFront vs Global Accelerator
  • Understand ELB, ALB and NLB
    • Differences between ALB and NLB
    • ALB provides Content, Host, and Path-based Routing while NLB provides the ability to have a static IP address
    • Maintain original Client IP to the backend instances using X-Forwarded-for and Proxy Protocol
    • (Updated – Nov 2023) ALB now supports Mutual TLS (mTLS) — ALB can authenticate clients using X.509 certificates, offloading client certificate verification to the load balancer. Uses Trust Stores to manage CA certificates. Supports both verify mode (validates and passes headers) and passthrough mode.
    • For NLB with mTLS requirements, still use NLB with TCP listener on port 443 and terminate TLS on the instances.
    • (New – Nov 2025) Post-Quantum TLS — Both ALB and NLB now support post-quantum key exchange options (ML-KEM) for TLS, providing protection against future quantum computing threats.
    • NLB
      • also provides local zonal endpoints to keep the traffic within AZ
      • can front Private Link endpoints and provide static IPs.
    • ALB supports Forward Secrecy, through Security Policies, that provide additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key.
    • Supports sticky session feature (session affinity) to enable the LB to bind a user’s session to a specific target. This ensures that all requests from the user during the session are sent to the same target. Sticky Sessions is configured on the target groups.
    • (New – May 2024) Dual-Stack ALB without public IPv4 — internet-facing ALBs can now be provisioned without public IPv4 addresses, enabling IPv6-only client connectivity.
  • Gateway Load Balancer – GWLB
    • helps deploy, scale, and manage virtual appliances, such as firewalls, IDS/IPS systems, and deep packet inspection systems.
  • Athena integrates with S3 only and not with CloudWatch logs.
  • Transit VPC
    • helps connect multiple, geographically disperse VPCs and remote networks in order to create a global network transit center.
    • Use Transit Gateway or AWS Cloud WAN instead now.
  • Know CloudHub and its use case

Security

  • AWS GuardDuty
    • managed threat detection service
    • provides Malware protection
  • AWS Shield
    • managed DDoS protection service
    • AWS Shield Advanced provides 24×7 access to the AWS Shield Response Team (SRT), protection against DDoS-related spike, and DDoS cost protection to safeguard against scaling charges.
    • (New – May 2026) AWS Shield Advanced now supports DDoS attack flow logs for enhanced visibility into attack traffic patterns.
  • WAF as Web Traffic Firewall
    • helps protect web applications from attacks by allowing rules configuration that allow, block, or monitor (count) web requests based on defined conditions.
    • integrates with CloudFront, ALB, API Gateway to dynamically detect and prevent attacks
  • Network Firewall
    • provides IDS/IPS – Stateless and Stateful firewall rules – Allow, Deny, Forward
    • Used with Private Workspaces
    • (Updated – 2025) TLS Inspection Enhancements
      • Session holding for TLS Inspection prevents TCP/TLS establishment packets from reaching servers until SNI-based rules are evaluated.
      • New application layer drop and alert established default stateful actions for modern TLS and large HTTP requests.
      • No additional data processing charges for Advanced Inspection (TLS inspection) — price reduction announced Feb 2026.
    • supports PrivateLink Endpoint analysis in the console dashboard.
  • AWS Inspector
    • is a vulnerability management service that continuously scans the AWS workloads for vulnerabilities
  • AWS Verified Access (New)
    • provides secure, VPN-less access to corporate applications using zero trust principles.
    • evaluates each request based on user identity and device security posture rather than network location.
    • uses Cedar policy language for fine-grained access policies.
    • (Feb 2025) now supports non-HTTP(S) protocols (SSH, RDP) — eliminates need for separate VPN solutions for all application types.
    • achieved FedRAMP High and Moderate authorization (Mar 2025).
    • alternative to traditional VPN for remote workforce access scenarios.

Monitoring & Management Tools

  • Understand AWS CloudFormation esp. in terms of Network creation.
    • Custom resources can be used to handle activities not supported by AWS
    • While configuring VPN connections use depends_on on route tables to define a dependency on other resources as the VPN gateway route propagation depends on a VPC-gateway attachment when you have a VPN gateway.
  • AWS Config
    • fully managed service that provides AWS resource inventory, configuration history, and configuration change notifications to enable security, compliance, and governance.
    • can be used to monitor resource changes e.g. Security Groups and invoke Systems Manager Automation scripts for remediation.
  • CloudTrail for audit and governance

Integration Tools

Networking Architecture Patterns

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Day

  • Make sure you are relaxed and get some good night’s sleep. The exam is not tough if you are well-prepared.
  • If you are taking the AWS Online exam
    • Try to join at least 30 minutes before the actual time as I have had issues with both PSI and Pearson with long wait times.
    • The online verification process does take some time and usually, there are glitches.
    • Remember, you would not be allowed to take the take if you are late by more than 30 minutes.
    • Make sure you have your desk clear, no hand-watches, or external monitors, keep your phones away, and nobody can enter the room.

Finally, All the Best 🙂

GKE Networking – VPC, Gateway API & Dataplane V2

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – Networking

📅 Last Updated: June 2026 — Added GKE Dataplane V2, Gateway API, Network Isolation simplification, Multi-Pod CIDR, Multi-Network support, IPv6 Dual-Stack, and GKE Inference Gateway sections.

IP allocation

Kubernetes uses various IP ranges to assign IP addresses to Nodes, Pods, and Services.

  • Node IP
    • Each node has an IP address assigned from the cluster’s VPC network.
    • Node IP provides connectivity from control components like kube-proxy and kubelet to the Kubernetes API server.
    • Node IP is the node’s connection to the rest of the cluster.
  • Pod CIDR or Address Range
    • Each node has a pool of IP addresses that GKE assigns the Pods running on that node (a /24 CIDR block by default).
    • With Multi-Pod CIDR (GKE 1.29+), additional Pod IP address ranges can be added to an existing cluster without recreating it.
  • Pod Address
    • Each Pod has a single IP address assigned from the Pod CIDR range of its node.
    • Pod IP address is shared by all containers running within the Pod and connects them to other Pods running in the cluster.
  • Service Address Range
    • Each Service has an IP address, called the ClusterIP, assigned from the cluster’s VPC network.
  • For Standard clusters
    • a maximum of 110 Pods can run on a node with a /24 range, not 256 as you might expect. This provides a buffer so that Pods don’t become unschedulable due to a transient lack of IP addresses in the Pod IP range for a given node.
    • For ranges smaller than /24, roughly half as many Pods can be scheduled as IP addresses in the range.
  • Autopilot clusters can run a maximum of 32 Pods per node.

GKE Cluster Networking Types

  • GKE, clusters can be distinguished according to the way they route traffic from one Pod to another Pod.
    • VPC-native cluster: A cluster that uses alias IP address ranges (recommended and default)
    • Routes-based cluster: A cluster that uses custom static routes in a VPC network (legacy, not recommended for new clusters)
  • GKE clusters can also be distinguished by their dataplane:
    • GKE Dataplane V2 (default for Autopilot): Uses eBPF/Cilium for packet processing, replacing iptables and kube-proxy
    • Legacy Dataplane: Uses iptables and kube-proxy with Calico for network policy

VPC-Native Clusters

  • VPC-native cluster uses alias IP address ranges
  • VPC-native is the default and recommended network mode for all new clusters
  • VPC-native clusters have several benefits:
    • Pod IP addresses are natively routable within the cluster’s VPC network and other VPC networks connected to it by VPC Network Peering.
    • Pod IP address ranges, and subnet secondary IP address ranges in general, are accessible from on-premises networks connected with Cloud VPN or Cloud Interconnect using Cloud Routers.
    • Pod IP addresses are reserved in the VPC network before the Pods are created in the cluster. This prevents conflict with other resources in the VPC network and allows you to better plan IP address allocations.
    • Pod IP address ranges do not depend on custom static routes and do not consume the system-generated and custom static routes quota. Instead, automatically generated subnet routes handle routing for VPC-native clusters.
    • Firewall rules can be created that apply to just Pod IP address ranges instead of any IP address on the cluster’s nodes.
    • Supports GKE Dataplane V2 with eBPF-based networking
    • Required for multi-network support for Pods (multi-NIC)

VPC-Native Clusters IP Allocation

Google Kubernetes Engine Networking VPC-Native Cluster IP Management

  • VPC-native cluster uses three unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are assigned from the primary IP address range of the subnet associated with the cluster.
      • Both node IP addresses and the size of the subnet’s secondary IP address range for Pods limit the number of nodes that a cluster can support
    • One secondary IP address range for all Pod IP addresses.
      • Pod IP addresses are taken from the cluster subnet’s secondary IP address range for Pods.
      • By default, GKE allocates a /24 alias IP range (256 addresses) to each node for the Pods running on it.
      • On each node, those 256 alias IP addresses support up to 110 Pods.
      • Pod Address Range previously could not be changed once created. However, with Multi-Pod CIDR (available since GKE 1.29), additional Pod IP address ranges can now be added to an existing cluster.
        • Allows adding discontiguous secondary ranges for Pod IPs without recreating the cluster.
        • If the original range is exhausted, add a new Pod CIDR range using gcloud container clusters update.
        • Alternatively, node pools can be recreated with decreased --max-pods-per-node settings.
    • Another secondary IP address range for all Service (cluster IP) addresses.
      • Service (cluster IP) addresses are taken from the cluster’s subnet’s secondary IP address range for Services.
      • Service address range should be large enough to provide addresses for all the Kubernetes Services hosted in the cluster.
  • Node, Pod, and Services IP address ranges must all be unique and subnets with overlapping primary and secondary IP addresses cannot be created.

Routes-based Cluster

⚠️ Note: Routes-based clusters are legacy and not recommended for new clusters. VPC-native clusters are the default and recommended mode. To create a routes-based cluster, you must explicitly disable the VPC-native option.
  • Routes-based cluster that uses custom static routes in a VPC network i.e. it uses Google Cloud Routes to route traffic between nodes
  • In a routes-based cluster,
    • each node is allocated a /24 range of IP addresses for Pods.
    • With a /24 range, there are 256 addresses, but the maximum number of Pods per node is 110.
    • With approximately twice as many available IP addresses as possible Pods, Kubernetes is able to mitigate IP address reuse as Pods are added to and removed from a node.
  • Routes-based cluster uses two unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are taken from the primary range of the cluster subnet
      • Cluster subnet must be large enough to hold the total number of nodes in your cluster.
    • Pod address range
      • A routes-based cluster has a range of IP addresses that are used for Pods and Services
      • Last /20 (4096 addresses) of the Pod address range is used for Services and the rest of the range is used for Pods
      • Pod address range size cannot be changed after cluster creation. So ensure that a large enough Pod address range is chosen to accommodate the cluster’s anticipated growth during cluster creation
  • Maximum number of nodes, Pods, and Services for a given GKE cluster is determined by the size of the cluster subnet and the size of the Pod address range.
  • Routes-based clusters do not support GKE Dataplane V2, multi-network Pods, or many newer GKE networking features.

GKE Dataplane V2

  • GKE Dataplane V2 is a modern dataplane optimized for Kubernetes networking, powered by eBPF and Cilium.
  • Enabled by default for all new Autopilot clusters.
  • Replaces iptables and kube-proxy with eBPF programs for packet processing, routing, load balancing, and network policy enforcement.
  • Key benefits:
    • Scalability: Removes iptables bottlenecks; supports up to 260,000 endpoints across all services via eBPF maps.
    • Security: Kubernetes NetworkPolicy is always enabled without needing third-party add-ons like Calico.
    • Observability: Built-in network policy logging and Hubble integration for real-time traffic visibility.
    • Consistency: Unified networking behavior across GKE environments.
    • SCTP Support: Supports Stream Control Transmission Protocol workloads.
  • Implementation:
    • Deploys a DaemonSet named anetd in the kube-system namespace on each node.
    • anetd interprets Kubernetes objects and programs network topologies using eBPF.
    • Does not use kube-proxy or iptables for service routing.
  • Cluster scale with Dataplane V2:
    • Up to 15,000 nodes per regional cluster (65,000 with scale-optimized mode that disables network policy enforcement).
    • Up to 400,000 Pods per cluster.
    • Up to 10,000 ClusterIP Services.
  • Limitations:
    • Can only be enabled at cluster creation time; existing clusters cannot be upgraded.
    • Custom eBPF programs are not supported on Dataplane V2 nodes.
    • Third-party eBPF tools may interfere with Dataplane V2 programs.
  • Supports Cilium Cluster-wide Network Policies for centralized network rule enforcement across all namespaces.
  • Refer GKE Dataplane V2

GKE Network Isolation (Control Plane & Node Access)

  • As of January 2025, GKE has simplified cluster networking by decoupling control-plane access from node-pool IP configuration.
    • The terms “public cluster” and “private cluster” are being replaced with flexible network isolation settings.
    • Control plane access and node configuration can now be changed at any time without recreating the cluster.
  • Control Plane Access Methods:
    • DNS-based endpoint (new, recommended): Uses IAM and authentication-based policies for dynamic, flexible access. Works with VPC Service Controls for multi-layer security.
    • Public IP-based endpoint: Traditional external access with authorized networks.
    • Private IP-based endpoint: Access restricted to private networks (VPC Peering or Private Service Connect-based clusters). Can now be locked down to specific RFC-1918 addresses.
  • All three endpoints can be enabled simultaneously or in any combination.
  • Node Pool Flexibility:
    • Each node pool has its own network configuration (public/private IP).
    • Public IPs can be attached or detached from node pools independently at any time.
    • Traffic between nodes and the control plane is always private regardless of configuration.
  • Private Service Connect (PSC): Newer clusters use PSC instead of VPC Peering for control-plane connectivity, eliminating VPC peering complexity.
  • Refer GKE Network Isolation

Gateway API (Recommended for Service Networking)

  • The Gateway API is the recommended evolution of Kubernetes service networking, replacing traditional Ingress resources.
  • Key advantages over Ingress:
    • Role-oriented: Separate API resources for cluster operators (Gateway), developers (HTTPRoute), and infrastructure providers (GatewayClass).
    • Expressive: Built-in support for header-based matching, traffic weighting, and traffic splitting without custom annotations.
    • Portable: Consistent concepts across environments with a core conformance model.
    • Multi-namespace: A single Gateway can serve routes across multiple namespaces.
  • GKE Gateway supports:
    • External and Internal Application Load Balancers
    • Frontend mTLS (client certificate validation) — 2025
    • Cloud CDN integration
    • Multi-cluster Gateways for cross-cluster load balancing
  • All Ingress resources are directly convertible to Gateway and HTTPRoute resources.
  • Refer GKE Gateway API

GKE Inference Gateway

  • GKE Inference Gateway is a specialized networking layer for AI/ML inference workloads, announced in 2025.
  • Extends the GKE Gateway to optimize serving of generative AI applications.
  • Key features:
    • Model-aware routing: Routes traffic to inference pools of model replicas based on model name.
    • Predicted latency-based routing: Routes requests to the model server with the lowest predicted latency.
    • Body-based routing: Routes based on request body content.
    • Prefix caching: Accelerates inference by caching common prompt prefixes.
    • Multi-cluster support: Scale AI workloads across clusters and regions.
  • Benchmarks show 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency vs. competing solutions.
  • Refer GKE Inference Gateway

Multi-Network Support for Pods

  • GKE supports attaching multiple network interfaces (multi-NIC) to Pods, removing the single-interface limitation.
  • Requires GKE Dataplane V2 and VPC-native clusters.
  • Use cases:
    • Separating control plane traffic from data plane traffic.
    • Network isolation between different workload types.
    • Multicast capability for Pods.
    • High-performance RDMA networking for AI/GPU workloads (via DRANET).
  • Pods can connect to up to 8 networks (default + 7 additional).
  • DRANET (Dynamic Resource Allocation for Networking): Specifically designed for AI workloads running across multiple GPUs, enabling RDMA network interface allocation for high-throughput inter-GPU communication.
  • Supports multi-network network policies for per-interface traffic control.
  • Refer Multi-Network Support for Pods

IPv6 Dual-Stack Networking

  • GKE supports dual-stack (IPv4 and IPv6) networking for clusters.
  • Available for Standard clusters (GKE 1.24+) and Autopilot clusters (GKE 1.25+).
  • Dual-stack clusters assign both IPv4 and IPv6 addresses to Pods and Services.
  • Requirements:
    • VPC-native clusters only.
    • Dual-stack subnets with both IPv4 and IPv6 ranges.
    • For internal IPv6, VPC must be custom mode with ULA internal IPv6 enabled.
  • Enables applications to serve both IPv4 and IPv6 clients without separate infrastructure.

Related Reads

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Questions on GKE Networking Updates:

  1. Your organization runs a GKE cluster that is running out of Pod IP addresses. What is the best approach to address this without downtime?
    1. Recreate the cluster with a larger Pod CIDR range
    2. Use Multi-Pod CIDR to add additional Pod IP address ranges to the existing cluster
    3. Migrate to a routes-based cluster with more IP space
    4. Reduce the number of Pods per node
    Show Answer

    Answer: b – Multi-Pod CIDR (GKE 1.29+) allows adding discontiguous Pod IP ranges to existing VPC-native clusters without recreation.

  2. Which of the following are advantages of GKE Dataplane V2 over the legacy dataplane? (Choose THREE)
    1. Uses eBPF instead of iptables for packet processing
    2. Built-in Kubernetes NetworkPolicy enforcement without third-party add-ons
    3. Can be enabled on existing clusters via an upgrade
    4. Provides real-time network observability via Hubble
    5. Requires manual installation of Calico for network policies
    Show Answer

    Answer: a, b, d – Dataplane V2 uses eBPF/Cilium replacing iptables/kube-proxy, has built-in NetworkPolicy (no Calico needed), and integrates Hubble for observability. It can only be enabled at cluster creation.

  3. A company wants to change their GKE cluster from publicly accessible to private without recreating it. Which GKE networking feature enables this?
    1. VPC Peering-based private clusters
    2. Routes-based cluster configuration
    3. GKE flexible network isolation with DNS-based endpoints
    4. Cloud NAT configuration
    Show Answer

    Answer: c – Since January 2025, GKE allows changing control-plane access and node-pool configuration at any time without cluster recreation. DNS-based endpoints provide IAM-based dynamic security.

  4. Your team needs to expose multiple HTTP services across different namespaces using a single load balancer with traffic splitting capabilities. Which GKE networking resource should you use?
    1. Kubernetes Ingress with annotations
    2. GKE Gateway with HTTPRoute resources
    3. LoadBalancer Service per application
    4. Cloud DNS with round-robin
    Show Answer

    Answer: b – Gateway API is the recommended approach for HTTP service networking in GKE. A single Gateway can serve routes across namespaces with built-in traffic splitting.

  5. An AI team needs high-throughput RDMA networking between GPU pods in their GKE cluster. Which feature should they use?
    1. Standard Pod networking with increased MTU
    2. Multi-network support for Pods with DRANET
    3. Routes-based cluster with custom routes
    4. GKE Inference Gateway
    Show Answer

    Answer: b – DRANET (Dynamic Resource Allocation for Networking) enables allocation of RDMA network interfaces for high-throughput inter-GPU communication in AI workloads.

  6. What is the maximum number of nodes supported in a GKE regional cluster with Dataplane V2?
    1. 5,000 nodes
    2. 15,000 nodes
    3. 65,000 nodes with scale-optimized mode
    4. 1,000 nodes
    Show Answer

    Answer: c – GKE supports up to 65,000 nodes in regional clusters with Dataplane V2 scale-optimized mode (which disables network policy enforcement). Standard regional clusters support up to 15,000 nodes.

 

AWS Certified Advanced Networking – Speciality (ANS-C00) Exam Learning Path

~ Last updated on : ~ jayendrapatil ~ 29 Comments

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Learning Path

⚠️ EXAM RETIREMENT NOTICE

AWS Certified Advanced Networking – Specialty (ANS-C01) is being retired. The last day to take the exam is August 25, 2026.

Certifications earned prior to retirement will remain active for the standard three-year period. New AWS Certified Advanced Networking – Specialty certifications will not be issued after the retirement date.

Note: The original ANS-C00 version was retired in July 2022 and replaced by ANS-C01. This page has been updated to reflect the current ANS-C01 exam content.

I recently cleared the AWS Certified Advanced Networking – Specialty (ANS-C01), which was my first, en route my path to the AWS Specialty certifications. Frankly, I feel the time I gave for preparation was still not enough, but I just about managed to get through. So a word of caution, this exam is inline or tougher than the professional exam especially for the reason that the Networking concepts it covers are not something you can get your hands dirty with easily.

AWS Certified Advanced Networking – Specialty (ANS-C01) exam focuses on AWS Networking concepts. It validates the ability to

  • Design, implement, manage, and secure AWS and hybrid network architectures at scale
  • Design and maintain network architecture for all AWS services
  • Leverage tools to automate AWS networking tasks
  • Implement network security, compliance, and governance controls

ANS-C01 Exam Domains

The ANS-C01 exam is structured into four domains (compared to six in the retired ANS-C00):

  • Domain 1: Network Design (30%) — Design solutions incorporating edge networking, DNS, load balancing, routing, and connectivity
  • Domain 2: Network Implementation (26%) — Implement routing, connectivity, multi-Region/multi-account solutions
  • Domain 3: Network Management and Operation (20%) — Maintain, monitor, and troubleshoot network solutions
  • Domain 4: Network Security, Compliance, and Governance (24%) — Implement and maintain network security controls

Refer to AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Guide

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Resources

AWS Certified Advanced Networking – Specialty (ANS-C01) Exam Summary

  • AWS Certified Advanced Networking – Specialty exam covers extensive Networking concepts like VPC, VPN, Direct Connect, Transit Gateway, Route 53, ALB, NLB, Gateway Load Balancer, AWS Network Firewall, VPC Lattice, and Cloud WAN.
  • One of the key tactics when solving questions is to read the question and use paper and pencil to draw a rough architecture and focus on the areas that you need to improve. You will be able to eliminate 2 answers for sure and then need to focus on only the other two.
  • Be sure to cover the following topics
    • Networking & Content Delivery
      • You should know everything in Networking.
      • Understand VPC in depth
      • AWS Transit Gateway
        • Understand Transit Gateway as the primary hub-and-spoke architecture for connecting VPCs and on-premises networks (replaces Transit VPC pattern)
        • Know Transit Gateway route tables, associations, propagations, and peering across Regions
        • Understand Transit Gateway Connect attachments for SD-WAN integration using GRE tunnels and BGP
        • Know Transit Gateway Network Manager for global network visibility
      • AWS Cloud WAN
        • Know AWS Cloud WAN for building and managing global WANs using a central dashboard and network policies
        • Understand Core Network, segments, attachments, and policies
        • Know when to use Cloud WAN vs Transit Gateway (Cloud WAN for multi-Region global networks; Transit Gateway for single-Region hub-and-spoke)
        • Understand Service Insertion for centralized inspection architectures
      • Amazon VPC Lattice
        • Know Amazon VPC Lattice as an application-layer networking service for service-to-service connectivity
        • Understand service networks, services, target groups, and listeners
        • Know that VPC Lattice works across VPCs and accounts without requiring VPC peering or Transit Gateway
        • Understand the difference: VPC Lattice (Layer 7 application networking) vs Transit Gateway (Layer 3 network connectivity)
      • AWS VPC IPAM
        • Know VPC IP Address Manager (IPAM) for planning, tracking, and monitoring IP addresses at scale
        • Understand IPAM pools, scopes, and allocations across multi-account environments
      • Virtual Private Network to establish connectivity between on-premises data center and AWS VPC
        • Understand Site-to-Site VPN, accelerated VPN (using Global Accelerator), and VPN over Direct Connect
        • Know CloudHub for connecting multiple VPN sites
      • Direct Connect to establish connectivity between on-premises data center and AWS VPC and Public Services
        • Make sure you understand Direct Connect in detail — without this you cannot clear the exam
        • Understand Direct Connect connections – Dedicated (1, 10, 100, 400 Gbps) and Hosted connections
        • Understand how to create a Direct Connect connection (hint: LOA-CFA provides the details for partner to connect to AWS Direct Connect location)
        • Understand virtual interfaces options – Private VIF for VPC resources, Public VIF for public resources, and Transit VIF for Transit Gateway
        • Understand Route Propagation, propagation priority, BGP connectivity, and BFD (Bidirectional Forwarding Detection)
        • Understand High Availability options: Second Direct Connect connection, VPN as backup, or LAG (Link Aggregation Group)
        • Understand Direct Connect Gateway – provides connectivity to multiple VPCs across Regions from on-premises using a single DX connection
        • Know Direct Connect SiteLink – enables sending data between Direct Connect locations bypassing AWS Regions (site-to-site connectivity)
        • Understand Direct Connect + Cloud WAN integration (direct gateway association with Core Network)
        • Understand MACsec encryption for Direct Connect (Layer 2 encryption for dedicated connections)
      • Route 53
        • Understand Route 53 and Routing Policies and their use cases. Focus on Weighted, Latency, Geolocation, and Geoproximity routing policies
        • Understand Route 53 Split View DNS for same DNS to access a site externally and internally
        • Understand Route 53 Resolver – inbound/outbound endpoints for hybrid DNS resolution between on-premises and AWS
        • Know Route 53 Resolver DNS Firewall – filters outbound DNS queries, blocks malicious domains, prevents DNS tunneling and DGA attacks
        • Know Route 53 Resolver DNS Firewall Advanced (launched Nov 2024) – provides intelligent protection with real-time threat detection
      • Understand CloudFront and use cases including Origin Shield and real-time logs
      • AWS Global Accelerator
        • Know Global Accelerator for improving global application availability and performance using the AWS global network
        • Understand the difference between CloudFront (content caching/CDN) and Global Accelerator (network-layer acceleration with static anycast IPs)
        • Know dual-stack support for NLB endpoints
      • Load Balancer
        • Understand ALB, NLB, and Gateway Load Balancer (GWLB)
        • Understand the difference: ALB (Layer 7 – content, host, path-based routing), NLB (Layer 4 – static IP, ultra-low latency, TLS passthrough), GWLB (Layer 3 – transparent network gateway for third-party appliances)
        • Know Gateway Load Balancer for deploying, scaling, and managing third-party virtual appliances (firewalls, IDS/IPS) with GENEVE encapsulation
        • Know how to design VPC CIDR block with NLB (Hint – minimum number of IPs required are 8)
        • Know how to pass original Client IP to the backend instances (Hint – X-Forwarded-For for ALB, Proxy Protocol for NLB, and client IP preservation for GWLB)
      • Know WorkSpaces requirements and setup
    • Security
      • AWS Network Firewall
        • Know AWS Network Firewall as a managed stateful network firewall and IDS/IPS for VPCs
        • Understand rule groups (stateless and stateful), firewall policies, and deployment models (centralized, distributed)
        • Know integration with Gateway Load Balancer for centralized inspection architectures
      • AWS Verified Access
        • Know AWS Verified Access for secure application access without VPN using Zero Trust principles
        • Evaluates each request based on user identity and device health rather than network location
        • Now supports non-HTTP(S) protocols (announced re:Invent 2024)
      • Know AWS GuardDuty as managed threat detection service
      • Know AWS Shield esp. Shield Advanced and features (DDoS cost protection, SRT access, advanced mitigation)
      • Know WAF as Web Traffic Firewall — (Hint – WAF can be attached to CloudFront, ALB, API Gateway, AppSync, and Cognito User Pools)
      • Know AWS Firewall Manager for centrally managing firewall rules across accounts and resources in AWS Organizations

Key Differences: ANS-C01 vs ANS-C00

  • Structure: ANS-C01 has 4 domains (vs 6 in ANS-C00) — more streamlined and focused
  • New Services: Transit Gateway, Cloud WAN, VPC Lattice, IPAM, Network Firewall, Gateway Load Balancer, Global Accelerator, Verified Access, Route 53 Resolver endpoints
  • Deprecated Patterns: Transit VPC pattern replaced by Transit Gateway; complex VPN hub-and-spoke designs replaced by Transit Gateway with Cloud WAN
  • Emphasis Changes: Greater focus on multi-account/multi-Region networking, Zero Trust architecture, network automation, and centralized security
  • Direct Connect: Transit VIF, SiteLink, MACsec encryption, 400 Gbps connections, and Cloud WAN integration are new topics

AWS Network Connectivity Options

~ Last updated on : ~ jayendrapatil ~ 3 Comments

AWS Network Connectivity Options

Internet Gateway

  • provides Internet connectivity to VPC
  • is a horizontally scaled, redundant, and highly available component that allows communication between instances in your VPC and the internet.
  • imposes no availability risks or bandwidth constraints on your network traffic.
  • serves two purposes: to provide a target in the VPC route tables for internet-routable traffic and to perform NAT for instances that have not been assigned public IPv4 addresses.
  • supports IPv4 and IPv6 traffic.

NAT Gateway

  • enables instances in a private subnet to connect to the internet or other AWS services, but prevents the Internet from initiating connections with the instances.
  • Public NAT gateway allows instances in private subnets to connect to the internet through the NAT gateway’s Elastic IP address.
  • Private NAT gateway allows instances in private subnets to connect to other VPCs or the on-premises network using its private IP address for source NAT.
  • Regional NAT Gateway (New – Nov 2025) – automatically expands across Availability Zones based on workload presence. Unlike standard (zonal) NAT gateways which operate in a single AZ, regional NAT gateways follow workloads to provide automatic high availability without requiring a public subnet to host the gateway.

Egress Only Internet Gateway

  • NAT devices are not supported for IPv6 traffic, use an Egress-only Internet gateway instead
  • Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component
  • Egress-only Internet gateway allows outbound communication over IPv6 from instances in the VPC to the Internet and prevents the Internet from initiating an IPv6 connection with your instances.

VPC Endpoints

  • VPC endpoint provides a private connection from VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • Instances in the VPC do not require public IP addresses to communicate with resources in the service. Traffic between the VPC and the other service does not leave the Amazon network.
  • VPC Endpoints are virtual devices and are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and services without imposing availability risks or bandwidth constraints on the network traffic.
  • VPC Endpoints are of three types
    • Interface Endpoints – is an elastic network interface with a private IP address that serves as an entry point for traffic destined to supported services.
    • Gateway Endpoints – is a gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service. Currently only Amazon S3 and DynamoDB.
    • Resource Endpoints (New – Dec 2024) – enables private access to a specific resource (e.g., RDS database, IP address, or domain name) in another VPC or on-premises environment shared via AWS RAM, without requiring an NLB.
  • Cross-Region PrivateLink (Nov 2025) – Interface VPC endpoints now support cross-region connectivity, breaking the previous limitation that endpoints were regional-only. This enables connecting to VPC endpoint services hosted in other AWS Regions within the same partition.

VPC Private LinksAWS Private Links

  • provides private connectivity between VPCs, AWS services, and your on-premises networks without exposing your traffic to the public internet.
  • helps privately expose a service/application residing in one VPC (service provider) to other VPCs (consumer) within an AWS Region in a way that only consumer VPCs initiate connections to the service provider VPC.
  • With ALB as a target of NLB, ALB’s advanced routing capabilities can be combined with AWS PrivateLink.
  • VPC Resource Gateway (Dec 2024) – allows sharing any VPC resource (RDS databases, domain names, IP addresses) via AWS RAM. Consumers access these resources privately using VPC endpoints without needing an NLB, simplifying hybrid networking.
  • Cross-Region Connectivity (Nov 2025) – PrivateLink now supports native cross-region access for both AWS services and customer endpoint services, enabling global private connectivity from a single Region deployment.

VPC Peering

  • enables networking connection between two VPCs to route traffic between them using private IPv4 addresses or IPv6 addresses
  • connections can be created between your own VPCs, or with a VPC in another AWS account.
  • enables full bidirectional connectivity between the VPCs
  • supports inter-region VPC peering connection
  • Inter-region peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth (Mar 2025)
  • uses existing underlying AWS infrastructure
  • does not have a single point of failure for communication or a bandwidth bottleneck.
  • VPC Peering connections have limitations
    • cannot be used with Overlapping CIDR blocks
    • does not provide Transitive peering
    • does not support Edge to Edge routing through Gateway or private connection
  • is best used when resources in one VPC must communicate with resources in another VPC, the environment of both VPCs is controlled and secured, and the number of VPCs to be connected is less than 10
  • supports a limit of 125 active peering connections per VPC
  • Simplified Billing (Apr 2025) – AWS simplified VPC Peering billing; no changes to data transfer pricing but billing structure is streamlined.

VPN CloudHub

  • AWS VPN CloudHub allows you to securely communicate from one site to another using AWS Managed VPN or Direct Connect
  • AWS VPN CloudHub operates on a simple hub-and-spoke model that can be used with or without a VPC
  • AWS VPN CloudHub can be used if you have multiple branch offices and existing internet connections and would like to implement a convenient, potentially low cost hub-and-spoke model for primary or backup connectivity between these remote offices.
  • AWS VPN CloudHub leverages VPC virtual private gateway with multiple gateways, each using unique BGP autonomous system numbers (ASNs).

Transit VPC

⚠️ Note: Transit VPC is a legacy architecture pattern. AWS recommends using AWS Transit Gateway or AWS Cloud WAN for new deployments, which provide managed, highly available hub-and-spoke connectivity without the operational overhead of managing EC2-based virtual appliances.

  • A transit VPC is a common strategy for connecting multiple, geographically disperse VPCs and remote networks in order to create a global network transit center.
  • A transit VPC simplifies network management and minimizes the number of connections required to connect multiple VPCs and remote networks
  • Transit VPC can be used to support important use cases
    • Private Networking – You can build a private network that spans two or more AWS Regions.
    • Shared Connectivity – Multiple VPCs can share connections to data centers, partner networks, and other clouds.
    • Cross-Account AWS Usage – The VPCs and the AWS resources within them can reside in multiple AWS accounts.
  • Transit VPC design helps implement more complex routing rules, such as network address translation between overlapping network ranges, or to add additional network-level packet filtering or inspection.
  • Transit VPC
    • supports Transitive routing using the overlay VPN network — allowing for a simpler hub and spoke design.
    • supports network address translation between overlapping network ranges.
    • supports vendor functionality around advanced security (layer 7 firewall/IPS/IDS) using third-party software on EC2
    • leverages instance-based routing that increases costs while lowering availability and limiting the bandwidth.
    • Customers are responsible for managing the HA and redundancy of EC2 instances running the third-party vendor virtual appliance

Transit Gateway

Transit Gateway

  • is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
  • is a Regional resource and can connect thousands of VPCs within the same AWS Region.
  • TGWs across different regions can peer with each other to enable VPC communications within the same or different regions.
  • provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
  • enables you to attach VPCs (across accounts) and VPN connections in the same Region and route traffic between them.
  • support dynamic and static routing between attached VPCs and VPN connections
  • removes the need for using full mesh VPC Peering and Transit VPC
  • Transit Gateway Flow Logs – enables capturing detailed telemetry (source/destination IPs, ports, protocol, traffic counters, timestamps) for all network flows traversing the Transit Gateway. Logs can be published to CloudWatch Logs, S3, or Firehose.
  • Flexible Cost Allocation (Nov 2025) – provides granular control over how Transit Gateway data processing costs are allocated across AWS accounts within AWS Organizations.

AWS Cloud WAN

  • is a managed wide area networking (WAN) service that helps build, manage, and monitor a unified global network connecting cloud and on-premises resources.
  • provides a central dashboard and network policies to create a global network spanning multiple locations, removing the need to configure and manage different networks using different technologies.
  • uses a policy-based automation system to define network segments, attach VPCs, VPN connections, and SD-WAN products.
  • simplifies global network management compared to manually managing Transit Gateways across regions.
  • key features include:
    • Central Dashboard – manage branch offices, data centers, VPN connections, SD-WAN, VPCs, and Transit Gateways from one place.
    • Network Policies – define how traffic is routed between segments with policy-based controls.
    • Service Insertion (2024) – streamlines integrating security and inspection services (e.g., Network Firewall) into global networks.
    • Routing Policy (Nov 2025) – enables route filtering, summarization, and BGP path manipulation for fine-grained traffic control at scale.
    • Security Group Referencing & Enhanced DNS (Jun 2025) – simplifies security group management and DNS resolution across Cloud WAN segments.
  • can be used as a migration path from Transit Gateway for organizations needing global, multi-Region network management.
  • available in AWS GovCloud (US) Regions as of Jun 2026.

Hybrid Connectivity

AWS Network Connectivity Decision Tree

Virtual Private Network (VPN)

VPC Managed VPN Connection

AWS Site-to-Site VPN

  • VPC provides the option of creating an IPsec VPN connection between remote customer networks and their VPC over the internet
  • AWS managed VPN endpoint includes automated multi–data center redundancy & failover built into the AWS side of the VPN connection
  • AWS managed VPN consists of two parts
    • Virtual Private Gateway (VPG) on AWS side
    • Customer Gateway (CGW) on the on-premises data center
  • AWS Site-to-Site VPN only provides Site-to-Site VPN connectivity. It does not provide Point-to-Site VPC connectivity (use AWS Client VPN for that).
  • Virtual Private Gateway are Highly Available as it represents two distinct VPN endpoints, physically located in separate data centers to increase the availability of the VPN connection.
  • High Availability on the on-premises data center must be handled by creating additional Customer Gateway.
  • AWS Site-to-Site VPN connections are low cost, quick to setup and start with compared to Direct Connect. However, they are not reliable as they traverse through Internet.
  • 5 Gbps Bandwidth Tunnels (Nov 2025) – supports VPN connections with up to 5 Gbps bandwidth per tunnel, a 4x improvement from the previous 1.25 Gbps limit. Beneficial for bandwidth-intensive hybrid applications, big data migrations, and disaster recovery. Bandwidth can be modified on existing connections without changing on-premises configuration (May 2026).
  • IPv6 Support for Outer Tunnel IPs (Jul 2025) – supports IPv6 addresses on outer tunnel IPs, enabling full IPv6-only VPN connectivity (IPv6-in-IPv6) and mixed (IPv4-in-IPv6) configurations without IPv6>IPv4>IPv6 translation.
  • VPN Concentrator (Nov 2025) – a new feature that simplifies multi-site connectivity for distributed enterprises with 25+ remote sites needing low bandwidth (under 100 Mbps each). Connects multiple remote sites through a single VPN attachment to Transit Gateway with 5 Gbps aggregate bandwidth.

AWS Client VPN

  • is a fully managed, scalable VPN service that provides an endpoint for users to establish a secure remote access (Point-to-Site) connection to the AWS network.
  • uses OpenVPN-based VPN client software for secure connectivity.
  • handles Point-to-Site VPN connectivity that AWS Site-to-Site VPN does not provide (e.g., remote worker/mobile access).
  • supports authentication via Active Directory, SAML-based federated authentication, and mutual certificate authentication.
  • IPv6 Connectivity (Aug 2025) – now supports full IPv6 connectivity for Client VPN endpoints, allowing connections to IPv6 resources in VPCs and from clients on IPv6 networks.

Software VPN

  • VPC offers the flexibility to fully manage both sides of the VPC connectivity by creating a VPN connection between your remote network and a software VPN appliance running in your VPC network.
  • Software VPNs help manage both ends of the VPN connection either for compliance purposes or for leveraging gateway devices that are not currently supported by Amazon VPC’s VPN solution.
  • Software VPNs allows you to handle Point-to-Site connectivity (though AWS Client VPN is now the recommended managed alternative).
  • Software VPNs, with the above design, introduces a single point of failure and needs to be handled.

Direct Connect – DX

  • AWS Direct Connect helps establish a dedicated private connection between an on-premises network and AWS.
  • Direct Connect can reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than internet-based or VPN connections
  • Direct Connect uses industry-standard VLANs to access EC2 instances running within a VPC using private IP addresses
  • Direct Connect lets you establish
    • Dedicated Connection: A 1G, 10G, or 100G physical Ethernet connection associated with a single customer through AWS.
    • Hosted Connection: A physical Ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. Speeds range from 50 Mbps to 10 Gbps.
  • Direct Connect provides the following Virtual Interfaces
    • Private virtual interface – to access a VPC using private IP addresses.
    • Public virtual interface – to access all AWS public services using public IP addresses.
    • Transit virtual interface – to access one or more transit gateways associated with Direct Connect gateways.
  • Direct Connect connections are not redundant as each connection consists of a single dedicated connection between ports on your router and an Amazon router
  • Direct Connect High Availability can be configured using
    • Multiple Direct Connect connections
    • Back-up IPSec VPN connection
  • SiteLink – enables sending data between AWS Direct Connect locations to create private network connections between offices and data centers in a global network, bypassing AWS Regions. Data travels over the shortest path between locations using the AWS global network backbone.
  • VIF Rate Limiters (Jun 2026) – supports Virtual Interface Rate Limiters on dedicated connections to prevent network congestion caused by unexpected traffic spikes on a VIF, protecting other VIFs on the same connection.

LAGs

  • Direct Connect link aggregation group (LAG) is a logical interface that uses the Link Aggregation Control Protocol (LACP) to aggregate multiple connections at a single AWS Direct Connect endpoint, allowing you to treat them as a single, managed connection.
  • LAGs need the following
    • All connections in the LAG must use the same bandwidth.
    • A maximum of four connections in a LAG. Each connection in the LAG counts toward the overall connection limit for the Region.
    • All connections in the LAG must terminate at the same AWS Direct Connect endpoint.

Direct Connect Gateway

  • is a globally available resource to enable connections to multiple VPCs across different regions or AWS accounts.
  • allows you to connect an AWS Direct Connect connection to one or more VPCs in the account that are located in the same or different regions
  • allows connecting any participating VPCs from one private VIF, reducing Direct Connect management.
  • can be created in any public region and accessed from all other public regions
  • can also access the public resources in any AWS Region using a public virtual interface.
  • supports connecting up to 20 VPCs (via VGWs) globally over a single private VIF.

AWS Interconnect – Multicloud

  • is a new managed connectivity service (GA Apr 2026) that simplifies multicloud connectivity between AWS and other cloud service providers.
  • provides simple, resilient, high-speed private connections to other CSPs without needing to manage physical cross-connects or third-party providers.
  • attaches to a Direct Connect Gateway on the AWS side.
  • supported CSPs:
    • Google Cloud – Generally Available
    • Oracle Cloud Infrastructure (OCI) – Preview (May 2026)
    • Microsoft Azure – Coming later in 2026
  • offers a Free Tier – fully managed 500 Mbps interconnect to another CSP at no charge on the AWS side (May 2026).
  • eliminates complex multicloud networking setups that previously required physical Direct Connect connections and manual peering arrangements.

Amazon VPC Lattice

  • is an application networking service that consistently connects, monitors, and secures communications between services and resources across VPCs and accounts.
  • automatically manages network connectivity and application layer routing between services across different VPCs and AWS accounts.
  • abstracts IP address dependencies, allowing applications to communicate securely without direct network routing.
  • supports HTTP, HTTPS, gRPC, TLS, and TCP protocols.
  • key features include:
    • Service Networks – logical grouping of services with shared access and observability policies.
    • Service Network VPC Endpoints – allows VPCs to connect to service networks via VPC endpoints.
    • VPC Resources Support (re:Invent 2024) – enables connectivity to TCP resources such as databases, domain names, and IP addresses across VPCs and accounts.
    • Auth Policies – fine-grained access control using IAM-based policies at the service network and service level.
  • can replace complex Transit Gateway and PrivateLink configurations for service-to-service communication within a Region.
  • does not natively support cross-Region service access; requires a proxy solution for external Region connectivity.

Amazon VPC Route Server

  • is a new managed service (GA Apr 2025) that enables dynamic routing within Amazon VPC using Border Gateway Protocol (BGP).
  • allows deploying endpoints in a VPC and peering them with virtual appliances to advertise routes using BGP.
  • filters received routes using standard BGP attributes and propagates selected routes to specified VPC route tables.
  • dynamically updates VPC and internet gateway route tables with preferred IPv4 or IPv6 routes for routing fault tolerance.
  • eliminates the need for complex scripting or Lambda-based failover mechanisms for virtual appliance routing.
  • key use cases:
    • Automatic active/standby failover for inspection appliances
    • Dynamic routing between cloud applications and on-premises systems via virtual appliances
    • Integration with Transit Gateway for centralized inspection architectures
  • Logging Enhancements (Jun 2025) – provides real-time monitoring of BGP and BFD session states, historical peer-to-peer session data, with delivery via CloudWatch, S3, Data Firehose, or AWS CLI.

References