AWS Certified Advanced Networking – Specialty (ANS-C01)
A documentation-first study guide. AWS writes the exam from its own documentation, so reading the docs is the highest-leverage thing you can do. This guide is a curated index into the canonical references, FAQs, and a selection of whitepapers — organised around the four exam domains, not around services.
Maps to the published AWS Certified Advanced Networking — Specialty (ANS-C01) exam guide. Domain weights and task statements are quoted from that PDF.
About the exam
Current exam code: ANS-C01 (first released July 2022, exam guide v2.0). No C02 announcement as of April 2026.
Format: 65 questions (50 scored + 15 unscored) · 170 minutes · $300 USD · scaled score 100–1000, pass at 750.
The four domains:
- Domain 1 — Network Design — 30%
- Domain 2 — Network Implementation — 26%
- Domain 3 — Network Management and Operation — 20%
- Domain 4 — Network Security, Compliance, and Governance — 24%
Primary official sources (bookmark these):
- Official ANS-C01 certification page
- ANS-C01 Exam Guide (PDF, v2.0)
- Official sample questions (PDF)
- Exam Readiness: Advanced Networking – Specialty (free on Skill Builder)
Whitepapers worth reviewing:
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure (updated 2026)
- Hybrid Networking Lens — AWS Well-Architected Framework (added 2026; the current authoritative reference for hybrid design thinking)
- Hybrid Connectivity (AWS has marked this “for historical reference only” but its BGP / DX design thinking is still tested — cross-reference anything it says against the current Direct Connect User Guide and the newer Hybrid Networking Lens.)
Priority tiers: The published domain weights (30/26/20/24) tell you how the exam is balanced across the four domains, but they don’t tell you that within each domain a handful of services account for most of the questions. Every section in this guide carries a tier badge based on triangulating the AWS exam guide, the experience reports of recent test takers, and the patterns that appear in the practice-exam community:
- ★★★ Core Heavily tested. Multiple questions will lean on this. Spend hours, not minutes — if you don’t know it well, you fail.
- ★★ Important Reliably tested, usually one or two questions. Read every linked page in the section, do the FAQ, understand the comparison points. A few hours per topic.
- ★ Light Known to appear, but typically as one distinguishing question or as wrong-answer distractors. Skim the docs, learn the one-line distinction, move on. Twenty minutes to an hour.
For an 8–12 week prep cycle the rough split that the data supports is about 60% of your time on Core topics, 30% on Important, and 10% on Light. The biggest single concentration of questions across the whole exam is the cluster around VPC + Transit Gateway + Direct Connect + Route 53 + CloudFront + Network Firewall — know those six cold and you have the foundation of a pass.
How to use this guide:
- Each section opens with a one-paragraph summary explaining what to focus on, then has up to three link sections: Core docs (user/developer guides — the canonical reference), FAQ (exam writers love edge cases from FAQs — do not skip), and Deeper reading (whitepapers, blog posts, re:Post articles).
- If a link 404s, AWS has reorganised the docs. Search the page title to find the new location — the content almost always still exists.
- The What’s New feed is worth a weekly scan in the last month before your exam; the exam lags new features by ~12 months but recent launches are a good prompt to revisit older chapters.
Part I — Domain 1: Network Design (30%)
Chapter 1 — Edge networking: CloudFront, Global Accelerator, and the edge
Maps to Task Statement 1.1 — Design a solution that incorporates edge network services to optimize user performance and traffic management for global architectures
Knowledge of:
- Design patterns for the usage of content distribution networks (for example, Amazon CloudFront)
- Design patterns for global traffic management (for example, AWS Global Accelerator)
- Integration patterns for content distribution networks and global traffic management with other services (for example, Elastic Load Balancing, Amazon API Gateway)
Skills in:
- Evaluating requirements of global inbound and outbound traffic from the internet to design an appropriate content distribution solution
- Optimizing data transfer costs using Amazon CloudFront
- Designing patterns and architectures for global traffic management
- Securing content at the edge using encryption and access control
- Integrating edge services with DDoS mitigation solutions
1.1 Amazon CloudFront ★★★ Core
CloudFront is heavily tested. Know origin types (S3, ALB, custom), cache behaviours, OAC vs OAI, signed URLs/cookies, and the CloudFront Functions vs Lambda@Edge decision. Expect 3-5 questions.
Core docs
- What is Amazon CloudFront? — the foundational overview; skim first, return as reference
- How CloudFront delivers content — edge locations, regional caches, cache hits/misses
- Origins and origin groups — S3, ALB, custom HTTP; origin failover
- Cache behaviours, cache policies, origin request policies — path patterns, TTLs, what gets forwarded
- Origin Access Control (OAC) for S3 origins — modern replacement for OAI; required for SSE-KMS
- VPC origins (private ALB / NLB / EC2) — serve private content without exposing to internet
- CloudFront Functions vs Lambda@Edge — lightweight JS at edge vs full Lambda in regions
- Field-level encryption — encrypt sensitive POST fields at edge before origin
- Signed URLs and signed cookies — time-limited or restricted access to private content
- Geo-restriction — allow/deny by country using CloudFront or WAF
- SSL/TLS and SNI — viewer and origin protocols, custom certs require us-east-1
FAQ
1.2 AWS Global Accelerator ★★★ Core
Know when to choose Global Accelerator over CloudFront: static anycast IPs, TCP/UDP (not just HTTP), client IP preservation, and instant failover. Understand traffic dials and endpoint weights.
Core docs
- What is AWS Global Accelerator? — static anycast IPs, routes over AWS backbone
- How Global Accelerator works — accelerators, listeners, endpoint groups, endpoints
- Standard vs custom routing accelerators — standard for load balancing, custom for 1:1 mapping (gaming)
- Traffic dial and endpoint weights — control traffic % to each region/endpoint
- Client IP address preservation — see real client IP at ALB/EC2; requires specific config
FAQ
1.3 Choosing between CloudFront and Global Accelerator ★★ Important
A frequent exam pattern: “HTTP caching at edge” → CloudFront; “TCP/UDP with static IPs or instant failover” → Global Accelerator. Both use the AWS backbone; the use case determines the choice.
- AWS blog: CloudFront vs Global Accelerator — when to use which — decision matrix for edge services
- Using CloudFront with an ALB origin — HTTP caching with dynamic backend
- Using Global Accelerator with ALB/NLB/EC2 — TCP/UDP without caching, static IPs
Chapter 2 — DNS design with Amazon Route 53
Maps to Task Statement 1.2 — Design DNS solutions that meet public, private, and hybrid requirements
Knowledge of:
- DNS protocol (for example, DNS records, timers, DNSSEC, DNS delegation, zones)
- DNS logging and monitoring
- Amazon Route 53 features (for example, alias records, traffic policies, resolvers, health checks)
- Integration of DNS with other AWS services (for example, Amazon VPC)
- Integration of DNS with hybrid, multi-account, and multi-Region options
- Domain registration
Skills in:
- Using Route 53 public hosted zones
- Using Route 53 private hosted zones
- Using Route 53 Resolver endpoints in hybrid and AWS architectures
- Using Route 53 for global traffic management
- Creating and managing domain registrations
2.1 Route 53 core concepts ★★★ Core
Foundation for every DNS question. Know public vs private hosted zones, alias vs CNAME (alias works at zone apex, no charge for alias to AWS resources), and the full list of routing policies.
Core docs
- What is Amazon Route 53? — DNS + domain registration + health checking
- Public hosted zones — internet-resolvable domains
- Private hosted zones — VPC-only resolution; associate with multiple VPCs
- Supported DNS record types — A, AAAA, CNAME, MX, TXT, NS, SOA, and more
- Alias records vs CNAME records — alias works at zone apex, no charge for AWS resources
- Domain registration — register domains directly in Route 53
2.2 Routing policies (traffic management) ★★★ Core
Memorise all eight routing policies and when to use each. Weighted for blue/green, latency for performance, geolocation for compliance, failover with health checks for HA. Traffic flow for complex chaining.
- Choosing a routing policy — all eight policies explained; core exam topic
- Traffic flow policies — visual editor for complex routing trees
- Route 53 health checks — endpoint, CloudWatch, calculated; triggers failover
- Calculated health checks and DNS failover — combine multiple checks with AND/OR logic
2.3 Route 53 Resolver (hybrid DNS) ★★★ Core
The most-tested DNS topic for hybrid scenarios. Inbound endpoints let on-prem resolve AWS names; outbound endpoints let VPCs resolve on-prem names. Resolver rules are shared via RAM. DNS Firewall blocks malicious domains.
- What is Route 53 Resolver? — the VPC’s DNS resolver at .2 address
- Inbound and outbound Resolver endpoints — inbound: on-prem→AWS; outbound: AWS→on-prem
- Resolver rules and rule types — forward, system, recursive; conditional forwarding
- Sharing Resolver rules with AWS RAM — centralise DNS rules across accounts
- Resolver query logging — log all VPC DNS queries to S3/CW/Firehose
- Resolver DNS Firewall — block/allow domains; protect against DNS exfiltration
2.4 DNSSEC ★ Light
Light coverage. Know that Route 53 supports DNSSEC signing for public hosted zones and validation for domains registered elsewhere. Understand it protects against DNS spoofing.
- Configuring DNSSEC signing in Route 53 — enable signing for public hosted zones
- How DNSSEC works in Route 53 — cryptographic validation prevents DNS spoofing
2.5 Application Recovery Controller (zonal and routing controls) ★ Light
Occasional questions on ARC for multi-region failover. Know that routing controls let you manually or automatically shift traffic, and readiness checks validate replica readiness before failover.
- Route 53 Application Recovery Controller (ARC) overview — highly reliable failover for multi-region apps
- Readiness check — verify replica readiness before failover
- Routing controls and safety rules — flip traffic with guardrails to prevent mistakes
FAQ
Deeper reading
- DNS resolution in hybrid environments (blog, multi-part) — multi-account DNS patterns
- Centralised DNS management of hybrid cloud with Route 53 Resolver — TGW + Resolver architecture
Chapter 3 — Load balancing design
Maps to Task Statement 1.3 — Design solutions that integrate load balancing to meet high availability, scalability, and security requirements
Knowledge of:
- How load balancing works at layer 3, layer 4, and layer 7 of the OSI model
- Different types of load balancers and how they meet requirements for network design, high availability, and security
- Connectivity patterns that apply to load balancing based on the use case (for example, internal, external, multi-Region)
- Scaling factors for load balancers
- Integrations with AWS services (for example, Global Accelerator, CloudFront, AWS WAF, Route 53, Amazon EKS, AWS Config, AWS PrivateLink)
- Configuration options for load balancer health checks
Skills in:
- Selecting an appropriate load balancer based on the use case
- Integrating auto scaling with load balancing solutions
- Integrating load balancers with existing application deployments
- Configuring load balancer targets and target groups
- Configuring listener rules
- Designing target group health checks
3.1 The ELB family ★★ Important
Know the four load balancer types and when to use each. ALB for HTTP/HTTPS with path/host routing; NLB for TCP/UDP with static IPs; GWLB for inline security appliances; CLB is legacy.
Core docs
- Elastic Load Balancing — what is it? — managed load balancing across AZs
- Load balancer comparison table — ALB vs NLB vs GWLB vs CLB feature matrix
3.2 Application Load Balancer (Layer 7) ★★ Important
Know listener rules, target types (instance, IP, Lambda), routing algorithms, sticky sessions, and authentication with Cognito/OIDC. Mutual TLS (mTLS) is a newer feature worth knowing.
- What is an ALB? — Layer 7 load balancing for HTTP/HTTPS
- Listeners and listener rules — path/host/header routing; redirect, fixed response
- Target groups and target types (instance, IP, Lambda) — where traffic goes; health checks
- Routing algorithms — round robin, least outstanding requests, weighted random — control target selection
- Sticky sessions — bind user to same target via cookies
- ALB authentication with Cognito / OIDC — offload auth to the load balancer
- Mutual TLS (mTLS) on ALB — client certificate verification
- Access logs — detailed request logs to S3
3.3 Network Load Balancer (Layer 4) ★★★ Core
Heavily tested. Know static IPs per AZ, client IP preservation options, TLS termination vs passthrough, cross-zone behaviour and its cost implications, and zonal DNS affinity for latency-sensitive apps.
- What is an NLB? — Layer 4 load balancing; millions of requests/sec
- NLB target groups (TCP, UDP, TLS, TCP_UDP) — protocol-level routing
- Preserving the client’s source IP (client IP preservation) — depends on target type; instance vs IP
- TLS listeners and TLS termination on NLB — offload TLS or passthrough
- NLB cross-zone load balancing — off by default; has data transfer cost
- Zonal DNS affinity / availability-zone DNS entries — keep traffic in same AZ for latency
3.4 Gateway Load Balancer (security-appliance insertion) ★★ Important
GWLB is the answer whenever a question mentions “third-party firewall appliances” or “inline inspection.” Know GENEVE encapsulation (port 6081), GWLB endpoints, and the traffic flow for centralised inspection.
- What is a Gateway Load Balancer? — deploy third-party appliances transparently
- GENEVE target groups (port 6081) — encapsulation protocol for appliance inspection
- GWLB endpoints and traffic flow — route traffic through inspection VPC
3.5 Proxy protocol and cross-zone ★★ Important
Proxy Protocol v2 passes client IP when targets can’t see it natively. Cross-zone load balancing distributes traffic evenly across all AZs but has data transfer cost implications on NLB.
- Proxy protocol v2 on NLB — pass client IP when preservation unavailable
- Cross-zone load balancing explained — even distribution vs AZ isolation trade-off
3.6 Load Balancer Controller for Kubernetes ★ Light
Light coverage. Know that the AWS Load Balancer Controller provisions ALB/NLB for Kubernetes Ingress and Service resources. Annotations control target type (IP vs instance) and other settings.
- AWS Load Balancer Controller (for EKS) — provisions ALB/NLB for Kubernetes Ingress/Service
- IngressClass and service annotations — configure LB behaviour via K8s manifests
FAQ
Chapter 4 — Logging and monitoring design
Maps to Task Statement 1.4 — Define logging and monitoring requirements across AWS and hybrid networks
Knowledge of:
- Amazon CloudWatch metrics, agents, logs, alarms, dashboards, and Insights in architectures with hybrid connectivity
- AWS Transit Gateway Network Manager in architectures with hybrid connectivity
- VPC Reachability Analyzer, Transit Gateway Route Analyzer, VPC flow logs, and Traffic Mirroring in architectures with hybrid connectivity
- Access logging (for example, load balancers, CloudFront)
Skills in:
- Identifying the logging and monitoring requirements
- Recommending appropriate metrics to provide visibility of the network status
- Capturing baseline network performance
4.1 Amazon CloudWatch ★★ Important
Know CloudWatch metrics for networking (NetworkIn/Out, connections), Logs Insights for querying flow logs, and alarms for automated response. Contributor Insights surfaces top talkers.
- CloudWatch concepts (metrics, alarms, dashboards) — namespaces, dimensions, periods, statistics
- CloudWatch agent on EC2 / on-premises — collect custom metrics and logs
- CloudWatch Logs and Logs Insights — centralise logs, query with SQL-like syntax
- Contributor Insights — find top talkers and anomalies in log data
4.2 VPC Flow Logs ★★★ Core
Core troubleshooting tool. Know the record fields (srcaddr, dstaddr, action, bytes), how to interpret ACCEPT/REJECT, limitations (no packet payload, no DNS queries), and destinations (S3, CloudWatch Logs, Firehose).
- Flow Logs overview — capture IP traffic metadata at VPC/subnet/ENI level
- Flow log record fields (base and extended) — srcaddr, dstaddr, action, bytes, packets
- Flow log limitations — no packet payloads, no DNS queries, no DHCP
4.3 VPC Traffic Mirroring ★★ Important
For deep packet inspection and forensics. Know sources (ENIs on Nitro instances), targets (NLB, ENI, GWLB endpoint), and filters. Traffic Mirroring captures actual packets, unlike Flow Logs.
- Traffic Mirroring overview — copy actual packets for deep inspection
- Sources, targets, filters, sessions — ENI source, NLB/GWLB/ENI target
- Traffic Mirroring considerations and limits — Nitro instances only, bandwidth implications
4.4 VPC Reachability Analyzer and Network Access Analyzer ★★ Important
Reachability Analyzer tests path connectivity without sending packets — ideal for troubleshooting SG/NACL/route issues. Network Access Analyzer finds unintended network access across your VPCs.
- Reachability Analyzer — test path connectivity without sending packets
- Network Access Analyzer — find unintended network access across VPCs
4.5 Transit Gateway Network Manager ★ Light
Provides a global view of your network. Route Analyzer validates TGW routing. Events integrate with CloudWatch for monitoring connectivity changes. Light exam coverage.
- Network Manager overview — global view of your AWS + on-prem network
- Route analyzer for Transit Gateway — validate TGW routing without traffic
- Network Manager events and CloudWatch integration — alerts on connectivity changes
4.6 Access logs (edge / load balancer) ★★ Important
Know where to find logs: ALB/NLB access logs go to S3, CloudFront has standard logs (S3) and real-time logs (Kinesis). Use these for request-level troubleshooting beyond what Flow Logs provide.
- ALB access logs — detailed HTTP request logs to S3
- NLB access logs — TLS connection logs to S3
- CloudFront standard logs (access logs) — viewer requests to S3; delayed
- CloudFront real-time logs — stream to Kinesis Data Streams
FAQ
Chapter 5 — Hybrid connectivity design: on-premises ↔ AWS
Maps to Task Statement 1.5 — Design a routing strategy and connectivity architecture between on-premises networks and the AWS Cloud
Knowledge of:
- Routing protocol concepts (for example, static, dynamic, BGP)
- High availability architectures (for example, clustering, active/passive)
- Connectivity options for AWS and hybrid networks (for example, AWS VPN, AWS Direct Connect, AWS Transit Gateway, Transit VPC, SD-WAN, AWS PrivateLink, AWS Marketplace appliances)
- Encryption options for AWS Site-to-Site VPN connectivity
- Connectivity patterns for hybrid networks (for example, at the VPC level, at the TGW level, through a shared services VPC)
Skills in:
- Designing a redundant hybrid network based on use case requirements (for example, Direct Connect, VPN)
- Designing a BGP design that accounts for private ASNs, path prepending, and MED
- Designing a routing policy based on use case requirements (for example, load balancing across links, BFD)
- Designing an encapsulated traffic architecture using GRE
- Designing VPN connectivity architectures (for example, static/dynamic, certificate-based, CloudHub)
- Selecting AWS Marketplace appliances for a hybrid network
5.1 Routing fundamentals and BGP on AWS ★★★ Core
BGP is everywhere on this exam. Know AS_PATH prepending, local preference communities (7224:7100/7200/7300), MED, longest-prefix match, and BFD for fast failover. This section alone could be 5-8 questions.
- BGP at AWS — concepts — dynamic routing between AWS and on-prem
- Direct Connect routing policies and BGP communities — how AWS handles route advertisements
- Influencing AWS-to-on-prem path (local preference communities 7224:7100/7200/7300) — set outbound preference from AWS
- Influencing on-prem-to-AWS path (AS_PATH prepending, more-specific routes) — control inbound traffic to AWS
- BGP MD5 authentication on DX — secure BGP sessions with shared key
- Bidirectional Forwarding Detection (BFD) — fast failover; sub-second detection
5.2 AWS Site-to-Site VPN ★★★ Core
Know the two-tunnel design, accelerated VPN (uses Global Accelerator), static vs BGP routing, and IPsec options. VPN is the quick/cheap option; DX is for performance/consistency. 1.25 Gbps per tunnel limit.
- Site-to-Site VPN user guide — IPsec over internet to AWS
- How Site-to-Site VPN works (two tunnels per connection) — HA design; 1.25 Gbps per tunnel
- Accelerated Site-to-Site VPN (Global Accelerator-powered) — uses AWS backbone for better performance
- Static vs dynamic (BGP) routing for VPN — BGP for automatic failover
- Tunnel options and cipher suites — IKE versions, encryption algorithms, DPD
- Tested customer gateway devices — vendor configs for common routers
5.3 AWS Direct Connect ★★★ Core
The biggest topic on the exam. Know dedicated vs hosted connections, private/public/transit VIFs, DXGW for multi-region, LAGs for aggregation, MACsec for encryption, SiteLink for DX-to-DX, and the resiliency models.
- Direct Connect user guide (start here) — private connectivity to AWS
- Dedicated vs hosted connections — dedicated: your port; hosted: partner’s port
- Virtual interfaces (VIFs) — private, public, transit — private→VPC, public→AWS endpoints, transit→TGW
- Direct Connect gateway (DXGW) — connect VIFs to multiple VGWs/TGWs across regions
- DXGW with Transit Gateway (transit VIF association) — scalable multi-VPC via TGW
- Link Aggregation Groups (LAGs) — bundle multiple connections; same speed required
- Jumbo frames over Direct Connect — up to 9001 MTU; end-to-end support required
- MACsec encryption on Direct Connect — Layer 2 encryption on dedicated 10G/100G
- SiteLink (DX-to-DX data movement) — route between DX locations without traversing on-prem
- Resiliency Toolkit — models and SLA — dev/prod, high/maximum resiliency patterns
- Resiliency Recommendations page — official design guidance per SLA level
5.4 Encapsulation and encrypted overlays ★★ Important
Private IP VPN runs IPsec over DX transit VIF for encryption without public IPs. VPN CloudHub enables hub-and-spoke over VGW. TGW Connect uses GRE+BGP for SD-WAN integration.
- Private IP VPN over Direct Connect — IPsec over transit VIF; no public IPs needed
- AWS VPN CloudHub (hub-and-spoke over a VGW) — connect multiple sites via single VGW
- Transit Gateway Connect attachments (GRE + BGP for SD-WAN) — native GRE tunnels with BGP peering
5.5 SD-WAN integration ★ Light
TGW Connect attachments let SD-WAN appliances peer via GRE tunnels with BGP. Cloud WAN offers native SD-WAN-like policy. Light exam coverage but know the pattern.
- Transit Gateway Connect for SD-WAN — peer SD-WAN appliances with TGW via GRE
- AWS Cloud WAN — SD-WAN integration pattern — policy-based global network management
FAQ
Deeper reading
- Hybrid Connectivity whitepaper — consolidated BGP and DX design thinking (historical)
- AWS VPC Connectivity Options whitepaper — comprehensive connectivity patterns
Chapter 6 — Multi-account, multi-region, multi-VPC design
Maps to Task Statement 1.6 — Design a routing strategy and connectivity architecture that include multiple AWS accounts, AWS Regions, and VPCs to support different connectivity patterns
Knowledge of:
- Inter-VPC and multi-account connectivity options (for example, VPC peering, AWS Transit Gateway, AWS PrivateLink)
- Private application connectivity options (for example, DNS name resolution with Route 53, internal load balancers, EC2 instances)
- Multi-Region connectivity options and considerations (for example, latency, convergence, cost)
- AWS network sharing architectures (for example, shared services VPC, Transit Gateway, shared subnets)
- Address overlap mitigation options
Skills in:
- Connecting VPCs in different Regions and accounts based on business requirements
- Evaluating the impact of address overlapping on connectivity options
- Designing a multi-VPC solution based on multiple connectivity requirements
- Selecting appropriate connectivity patterns based on performance, cost, and security requirements
- Using IP Address Manager (IPAM) to design and implement IP allocation across AWS accounts, Regions, and VPCs
6.1 VPC fundamentals for designers ★★★ Core
Foundation for everything. Know route table precedence (longest prefix wins, local always wins within VPC), secondary CIDRs and their restrictions, IPv6 dual-stack, BYOIP, and IPAM for address management.
- VPC User Guide — isolated virtual networks in AWS
- Subnets, route tables, and routing precedence — how traffic flows; local route always wins
- Route priority / longest-prefix match — more-specific CIDR wins
- Secondary CIDRs — extend VPC address space; restrictions apply
- IPv6 in VPC — dual-stack and IPv6-only subnets
- Bring Your Own IP (BYOIP) — use your own public IPv4/IPv6 ranges
- VPC IP Address Manager (IPAM) — centralise IP allocation across accounts
6.2 VPC peering ★★★ Core
Simple 1:1 connectivity. Critical limitations: no transitive routing, no edge-to-edge routing (can’t route through a peered VPC to reach on-prem). Inter-region peering works but has latency. Good for few VPCs.
- VPC peering user guide — 1:1 connectivity between VPCs
- Peering limitations — no transitive routing, edge-to-edge restrictions — can’t route through peered VPC to third network
- Inter-region VPC peering — cross-region peering with encryption
6.3 AWS Transit Gateway ★★★ Core
The hub for multi-VPC networking. Know attachments (VPC, VPN, DX, peering, Connect), route tables, associations vs propagations, inter-region peering, and appliance mode for stateful inspection. Expect 5+ questions.
- Transit Gateway user guide — regional hub for many-to-many connectivity
- How Transit Gateway works (attachments, route tables, associations, propagations) — core concepts for exam
- Attachment types (VPC, VPN, DX, peering, Connect) — what can connect to TGW
- Transit Gateway peering (inter-region and intra-region) — connect TGWs for global reach
- Appliance mode (critical for stateful inspection) — ensures symmetric routing through firewalls
- Multicast on TGW — one-to-many distribution
6.4 AWS Cloud WAN ★ Light
Newer service for global network management with policy-based routing. Know it exists as an alternative to TGW for very large, complex networks. Segments replace TGW route tables. Light exam coverage.
- Cloud WAN overview — global network with policy-based routing
- Core network, segments, and network policy — segments replace TGW route tables
- Cloud WAN vs Transit Gateway decision — when to use each
6.5 AWS PrivateLink and VPC endpoints ★★★ Core
Interface endpoints (ENIs with private IPs) vs gateway endpoints (route table entries for S3/DynamoDB). PrivateLink lets you expose services across accounts without VPC peering. Endpoint policies control access.
- PrivateLink and VPC endpoints overview — private access to services without internet
- Interface endpoints (powered by PrivateLink) — ENI with private IP; per-hour + per-GB cost
- Gateway endpoints (S3, DynamoDB only) — route-table entry; free
- Endpoint services (publishing your own service behind NLB/GWLB) — expose services to other accounts
- Endpoint policies — restrict what can be accessed through endpoint
6.6 VPC sharing (RAM) and IP overlap strategies ★★ Important
Shared VPCs reduce VPC sprawl — participants deploy into owner’s subnets. RAM shares TGWs, subnets, Resolver rules. For IP overlaps: PrivateLink or NAT. Know when each pattern applies.
- Shared VPCs — owner and participant roles — deploy into owner’s subnets; reduce VPC sprawl
- Sharing a Transit Gateway with AWS RAM — share TGW across accounts
- Handling IP overlaps with PrivateLink — access service without routing CIDRs
- Handling IP overlaps with NAT — translate addresses when CIDRs conflict
FAQ
Deeper reading (must-read whitepaper for this domain)
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure — the canonical multi-VPC reference
- VPC-to-VPC connectivity patterns — decision matrix for peering vs TGW vs PrivateLink
- VPC peering considerations — when peering makes sense
- Transit Gateway patterns — hub-and-spoke, shared services, inspection
- Transit VPC solution (legacy but testable) — pre-TGW pattern using EC2 routers
- VPC sharing — when to share vs peer
- Centralised network security — inspection VPC architecture
Part II — Domain 2: Network Implementation (26%)
Chapter 7 — Implementing on-premises ↔ AWS connectivity
Maps to Task Statement 2.1 — Implement routing and connectivity between on-premises networks and the AWS Cloud
Knowledge of:
- Routing protocol concepts (for example, static, dynamic, BGP, ECMP)
- VPN connectivity over AWS Direct Connect (public VIF, private VIF, transit VIF)
- Connectivity options for hybrid networks (for example, AWS Site-to-Site VPN, AWS Direct Connect)
Skills in:
- Configuring the physical components of AWS Direct Connect (for example, LOA-CFA, cross-connects, link aggregation groups [LAGs])
- Ordering AWS Direct Connect connections and hosted connections
- Configuring AWS Direct Connect virtual interfaces (private VIF, public VIF, transit VIF)
- Configuring AWS Site-to-Site VPN (static, dynamic)
7.1 Physical layer and colocation ★★ Important
Know the LOA-CFA process, cross-connect ordering, and port speeds (1G/10G/100G/400G). Dedicated connections are physical ports you own; hosted connections come from partners.
- Direct Connect locations — find colocation facilities near you
- Letter of Authorization / Connecting Facility Assignment (LOA-CFA) — document to give colocation provider
- Cross-connect instructions — physical cable from your router to AWS
- Port speeds and optics (1G, 10G, 100G, 400G) — dedicated connection speeds available
7.2 Configuring the Site-to-Site VPN ★★ Important
Two tunnels per connection for HA. Know Dead Peer Detection, NAT-T, and the importance of configuring both tunnels. Download config files for specific CGW vendors from the console.
- Step-by-step: create a Site-to-Site VPN connection — VGW or TGW attachment walkthrough
- Configuring two tunnels for high availability — both tunnels should be active
- Dead Peer Detection and NAT-T — keepalives and NAT traversal
- Example configurations for common CGW vendors — download config for your router
7.3 Configuring Direct Connect VIFs ★★★ Core
Private VIF → VGW/DXGW for VPC access. Public VIF → AWS public services. Transit VIF → DXGW+TGW for scalable multi-VPC. Know the limits: 10 VGWs per DXGW, 3 TGWs per DXGW, 20 prefixes per TGW association.
- Create a private VIF — access VPC via VGW or DXGW
- Create a public VIF — access AWS public endpoints over DX
- Create a transit VIF and associate to DXGW — connect to TGW via DXGW
- DXGW association limits (10 VGWs; 3 TGWs; 20 prefixes per TGW) — quotas that appear in scenarios
- Allowed prefixes when associating a DXGW with a TGW — filter what’s advertised to on-prem
7.4 Load balancing implementation details ★★ Important
Practical implementation: registering targets, cross-zone behaviour (enabled by default on ALB, opt-in on NLB), and the newer NLB security groups feature for easier access control.
- Register targets in a target group — add instances, IPs, or Lambdas
- Cross-zone load balancing behaviour and pricing — NLB cross-zone has data transfer cost
- NLB security groups (now supported) — optional SGs for easier access control
7.5 Testing connectivity ★★ Important
Use Reachability Analyzer for path analysis, TGW Route Analyzer for TGW routing validation, and DX failover tests to verify resiliency. These tools help without sending production traffic.
- VPC Reachability Analyzer walkthroughs — test path without sending packets
- Transit Gateway Route Analyzer — validate TGW routing tables
- Direct Connect failover test — verify resiliency before go-live
FAQ
Chapter 8 — Implementing multi-account, multi-region, multi-VPC connectivity
Maps to Task Statement 2.2 — Implement routing and connectivity across multiple AWS accounts, Regions, and VPCs to support different connectivity patterns
Knowledge of:
- Inter-VPC and multi-account connectivity options (for example, VPC peering, AWS Transit Gateway, AWS PrivateLink)
- Routing protocol concepts (for example, static, dynamic)
- How to configure Direct Connect Gateway for multiple accounts in AWS Organizations
- AWS Resource Access Manager (AWS RAM) for multi-account resource sharing
Skills in:
- Configuring network connectivity using VPC peering and Transit Gateway
- Configuring VPNs for Transit Gateway
- Configuring inter-Region Transit Gateway peering
- Configuring Direct Connect Gateway for multiple accounts in AWS Organizations
- Configuring AWS PrivateLink to share services with other accounts
8.1 AWS Organizations and Resource Access Manager (RAM) ★★ Important
RAM shares networking resources across accounts: TGWs, subnets, DXGW, Resolver rules, prefix lists. Organizations enables sharing within the org without explicit invitations.
- AWS Organizations user guide — multi-account management and SCPs
- AWS RAM user guide — share resources across accounts
- Shareable networking resources (TGW, subnets, DXGW, Route 53 rules, PHZ, prefix lists) — what can be shared via RAM
8.2 Building a hub-and-spoke with Transit Gateway ★★★ Core
Core pattern. Associations determine which route table an attachment uses for routing decisions. Propagations populate routes automatically. Use multiple route tables for segmentation (prod/dev/shared).
- TGW route table associations vs propagations — association: which table to use; propagation: populate routes
- Segmenting with multiple TGW route tables (prod/dev/shared services) — isolate traffic by environment
- TGW inter-region peering — static routes required; no propagation across peers
- TGW Flow Logs — capture traffic metadata at TGW level
8.3 AWS Client VPN ★ Light
Remote access VPN for users. Know mutual auth (certificates) vs federated auth (SAML), authorization rules, and split-tunnel (only AWS traffic through VPN) vs full-tunnel. Light exam coverage.
- Client VPN user guide — remote access VPN for end users
- Mutual auth and federated auth (SAML) — certificates or SSO
- Authorization rules — control which users access which networks
- Split-tunnel vs full-tunnel — send only AWS traffic through VPN or all traffic
8.4 Security at network boundaries ★★★ Core
Security groups are stateful (return traffic auto-allowed), NACLs are stateless (need explicit rules for both directions). Know the numbered-rule evaluation for NACLs and SG referencing across peered VPCs.
- Security groups — stateful; allow-only rules; instance level
- Network ACLs — stateless; numbered rules; subnet level
- Security group vs NACL comparison — when to use each
FAQ
Chapter 9 — Implementing complex hybrid and multi-account DNS
Maps to Task Statement 2.3 — Implement complex hybrid and multi-account DNS architectures
Knowledge of:
- When to use private hosted zones and Resolver endpoints
- How to use Route 53 Resolver endpoints
- AWS RAM for sharing Route 53 resources
Skills in:
- Configuring Route 53 public, private, and split-horizon DNS
- Configuring Route 53 Resolver endpoints in a hybrid network
- Configuring Route 53 Resolver rules to forward DNS queries for multi-account architecture and for integration with on-premises DNS infrastructure
- Using AWS RAM to share Route 53 Resolver rules
9.1 Hybrid DNS patterns ★★★ Core
Inbound endpoints: on-prem resolvers forward to AWS. Outbound endpoints: VPC resolver forwards to on-prem. Conditional forwarding rules determine which domains go where. Share rules via RAM.
- Route 53 Resolver inbound endpoints (on-prem -> AWS) — on-prem DNS servers forward to AWS
- Route 53 Resolver outbound endpoints (AWS -> on-prem) — VPCs forward queries to on-prem DNS
- Conditional forwarding rules — route specific domains to specific resolvers
- DNS resolution in VPCs (DHCP option sets, .2 resolver, +2 offset) — VPC base + 2 is the resolver
9.2 Multi-account DNS with RAM ★★ Important
Share Resolver rules and PHZ associations across accounts. PHZ cross-account association requires CLI/API — can’t be done in console. Centralise DNS in a shared-services account.
- Sharing Resolver rules across accounts — centralise DNS forwarding rules
- Associating a private hosted zone with a VPC in another account — requires CLI/API; cross-account PHZ
9.3 Private hosted zone behaviour ★★ Important
PHZs resolve only within associated VPCs. enableDnsHostnames and enableDnsSupport must be true. Overlapping namespaces: most-specific match wins. Split-horizon: same domain, different answers public vs private.
- PHZ and split-horizon DNS — same domain, different answers public vs private
- Required VPC settings — enableDnsHostnames, enableDnsSupport — both must be true for PHZ to work
- PHZ overlapping namespaces — most-specific match wins
9.4 Monitoring and logging DNS ★ Light
Query logging for public zones goes to CloudWatch Logs. Resolver query logs capture VPC-level DNS queries. Use for troubleshooting resolution issues and security analysis.
- Route 53 query logging (public hosted zones) — internet queries to CloudWatch Logs
- Resolver query logs (VPC-level) — VPC DNS queries to S3/CW/Firehose
- CloudWatch metrics for Route 53 — health check status and DNS queries
Deeper reading
- Multi-VPC whitepaper: DNS section — patterns for shared DNS infrastructure
- Centralized DNS management blog — TGW + Resolver architecture walkthrough
Chapter 10 — Network automation and infrastructure as code
Maps to Task Statement 2.4 — Automate and configure network infrastructure
Knowledge of:
- How to script interactions with AWS APIs using the AWS CLI
- How to use AWS CloudFormation to deploy automation
- How to use Amazon EventBridge to trigger events
Skills in:
- Creating and managing AWS CloudFormation StackSets
- Implementing automation for VPC subnet and NACL creation
- Implementing automation for VPC route management
- Implementing automation for DNS (for example, Route 53 private hosted zone associations, Route 53 Resolver endpoints)
- Implementing automation for load balancers (for example, ALB, NLB, GWLB)
- Using CloudFormation to create Lambda functions for network automation
10.1 AWS CloudFormation for networking ★ Light
Know that CloudFormation can provision VPCs, TGWs, and all networking resources. StackSets deploy across accounts/regions. Light exam coverage — focus on what you can automate, not deep CFN syntax.
- CloudFormation user guide — infrastructure as code for AWS
- EC2/VPC resource reference (AWS::EC2::*) — VPC, subnet, TGW, and more
- StackSets for multi-account / multi-region rollout — deploy to many accounts at once
10.2 AWS CDK ★ Light
CDK uses familiar programming languages to define infrastructure. The aws-ec2 module covers VPCs, subnets, SGs. Light exam coverage.
- CDK developer guide — define infra with TypeScript, Python, etc.
- CDK aws-ec2 (VPC, SGs, subnets) — high-level networking constructs
10.3 Event-driven network automation ★ Light
EventBridge captures VPC/TGW events; Lambda can respond automatically. Example: auto-approve TGW attachment requests. Know the pattern exists; deep implementation details are rare on the exam.
- Amazon EventBridge — event bus for AWS and custom events
- EventBridge rules for VPC / TGW events — react to attachment state changes
- AWS Lambda for network automation — serverless functions for auto-remediation
10.4 AWS CLI and SDKs ★ Light
CLI and SDKs for scripting network operations. Know they exist for automation scenarios. Exam rarely tests specific CLI commands.
- AWS CLI user guide — command-line access to AWS APIs
- EC2 network commands — VPC, subnet, route table, SG operations
FAQ
Part III — Domain 3: Network Management and Operation (20%)
Chapter 11 — Maintaining routing and connectivity
Maps to Task Statement 3.1 — Maintain routing and connectivity on AWS and hybrid networks
Knowledge of:
- Industry-standard routing protocols that are used in AWS hybrid networks (for example, BGP over Direct Connect)
- Routing tables for AWS services (for example, Amazon VPC, Transit Gateway)
- Connectivity options for AWS and hybrid networks (for example, AWS VPN, AWS Direct Connect, Transit Gateway)
- How to analyze route tables and BGP advertisements
Skills in:
- Diagnosing asymmetric routing issues
- Extending a VPC CIDR
- Correcting asymmetric routing issues
- Maintaining Direct Connect connectivity
- Maintaining VPN connectivity
11.1 BGP operations over Direct Connect and VPN ★★★ Core
Operational BGP knowledge is heavily tested. Know how to troubleshoot BGP sessions, interpret route advertisements, and use DXGW allowed prefixes to filter. Understand route priority in VPCs.
- Troubleshooting BGP on Direct Connect — common issues and fixes
- Route advertisement and filtering (DXGW allowed prefixes) — control what’s advertised to on-prem
- Route table route priority in a VPC — most-specific route wins
- Longest-prefix match and route precedence — how VPC selects routes
11.2 Quotas that matter for the exam ★★ Important
Know key limits: 5 VPCs/region (soft), 200 subnets/VPC, 5000 SG rules, 1.25 Gbps per VPN tunnel, 100 Gbps per DX, 50 routes per TGW route table (soft). Quotas appear in “what’s wrong” scenarios.
- VPC quotas — VPCs, subnets, SG rules, route table entries
- Transit Gateway quotas — attachments, routes per table
- Direct Connect quotas — VIFs, DXGW associations
- Site-to-Site VPN quotas (1.25 Gbps per tunnel) — throughput and connection limits
- Route 53 quotas — hosted zones, records, health checks
- NAT gateway bandwidth and throughput — 45 Gbps; scales automatically
11.3 Route table operations ★★ Important
TGW propagations auto-populate routes; static routes override. Blackhole routes drop traffic intentionally. Route table sizing: default 50, up to 1000. Know how to interpret route table conflicts.
- Automatic route propagation from TGW — attachments populate routes automatically
- Blackhole routes — intentionally drop traffic to a CIDR
- Route table sizing (default 50, up to 1000) — request increase if needed
11.4 Public vs private access to AWS services ★★★ Core
Gateway endpoints (S3/DynamoDB) use route table entries — free. Interface endpoints use ENIs with private IPs — charged per hour and per GB. Public VIF on DX reaches all AWS public endpoints.
- Gateway endpoints for S3 / DynamoDB — route-table based; free
- Interface endpoints for other services — ENI-based; per-hour + per-GB
- Accessing S3 over DX (via public VIF) — use public VIF for AWS public endpoints
Chapter 12 — Monitoring and troubleshooting connectivity
Maps to Task Statement 3.2 — Monitor and analyze network traffic to troubleshoot and optimize connectivity patterns
Knowledge of:
- Network troubleshooting tools (for example, VPC flow logs, Traffic Mirroring, VPC Reachability Analyzer, Transit Gateway Network Manager)
- Network metrics and statistics (for example, packet drop, latency)
- CloudWatch metrics and agents
Skills in:
- Analyzing VPC flow logs to identify traffic anomalies and patterns
- Implementing Traffic Mirroring solutions to capture and inspect network traffic
- Implementing CloudWatch alarms to alert on network issues
- Using VPC Reachability Analyzer to verify and troubleshoot network paths
- Using Transit Gateway Route Analyzer to verify routes
12.1 Flow Logs for troubleshooting ★★★ Core
Interpret flow log records: ACCEPT means SG/NACL allowed, REJECT means blocked. Query with Athena or CloudWatch Logs Insights. Know the action field patterns for troubleshooting connectivity.
- Flow log record fields reference — understand each field for troubleshooting
- Flow log action field (ACCEPT / REJECT) — identify SG/NACL blocks
- Querying flow logs with Athena — SQL queries on S3-stored logs
- CloudWatch Logs Insights queries for flow logs — real-time analysis and alerting
12.2 Traffic Mirroring for packet capture ★★ Important
When you need actual packets (not just metadata). Mirror to NLB or ENI running packet capture tools. Filters select which traffic to mirror. Use for deep troubleshooting and security forensics.
- Deep-packet analysis with Traffic Mirroring — copy packets for security/forensics tools
- Filters — protocol, port, CIDR — select which traffic to mirror
- Target types (NLB, GWLB endpoint, ENI) — where mirrored traffic goes
12.3 Reachability Analyzer ★★ Important
Tests path connectivity by analysing config — no packets sent. Identifies where traffic would be blocked (SG, NACL, route table). Great for “why can’t I connect” troubleshooting.
- How Reachability Analyzer works — analyses config, not live traffic
- Supported resource types — EC2, ENI, IGW, TGW, VPC endpoints, etc.
- Interpreting results and explanation codes — understand why path is blocked
12.4 Packet-size and MTU troubleshooting ★★ Important
VPC supports 9001 MTU (jumbo frames) within a VPC. TGW/DX may have lower limits. Path MTU discovery requires ICMP type 3 code 4 — ensure SGs/NACLs allow it. Common exam troubleshooting scenario.
- MTU on EC2 instances — default 1500; jumbo up to 9001
- Jumbo frames within a VPC (9001) — requires same-placement or no hops
- Path MTU discovery (ICMP type 3 code 4 must be allowed) — SG/NACL must allow ICMP
- TGW / DX jumbo frame support — check supported MTU on each hop
12.5 CloudTrail for network-config auditing ★ Light
CloudTrail logs API calls for compliance auditing. Know it captures who made VPC/TGW changes, not traffic data. Use for investigating configuration changes.
- CloudTrail user guide — audit trail of all API calls
- Logging VPC and EC2 API calls — who changed network config
FAQ
Chapter 13 — Performance, reliability, and cost optimisation
Maps to Task Statement 3.3 — Optimize AWS networks for performance, reliability, and cost-effectiveness
Knowledge of:
- How enhanced networking on EC2 instances works
- Networking costs (for example, data transfer costs, NAT gateway data processing costs)
- Different methods for sizing network bandwidth (for example, VPN, Direct Connect)
- How network loads affect cost and performance
Skills in:
- Designing a VPC connectivity solution that accounts for cost and performance
- Optimizing bandwidth for hybrid networks (for example, VPN, Direct Connect)
- Optimizing edge network services (for example, CloudFront, Global Accelerator)
- Optimizing EC2 networking (for example, placement groups, enhanced networking)
13.1 Network performance on EC2 ★★ Important
ENA enables up to 200 Gbps on supported instances. EFA adds OS-bypass for HPC/ML. Cluster placement groups for lowest latency. Network bandwidth scales with instance size.
- Enhanced networking (ENA) — up to 200 Gbps; lower latency
- Elastic Fabric Adapter (EFA) for HPC — OS-bypass for MPI/NCCL workloads
- Placement groups (cluster, spread, partition) — cluster for low latency; spread for HA
- Network performance by instance type — baseline vs burst bandwidth
13.2 Choosing connectivity: peer, TGW, PrivateLink, or VPN ★★★ Core
Decision tree: few VPCs → peering; many VPCs or hybrid → TGW; specific service exposure → PrivateLink; encrypted over internet → VPN. Know data transfer costs: peering is cheapest within-region.
- TGW vs peering vs PrivateLink decision (whitepaper) — choose based on scale, cost, complexity
- Data transfer charges — the cost table to memorise — peering cheapest within-region
13.3 Multicast ★ Light
TGW Multicast enables one-to-many distribution. Know it exists for media streaming and financial data use cases. IGMPv2 support for dynamic group membership. Light exam coverage.
- Transit Gateway Multicast — one-to-many distribution on TGW
- Multicast domains and IGMPv2 support — dynamic group membership
13.4 NAT options ★★★ Core
NAT gateway for internet egress (45 Gbps, scales automatically). Private NAT gateway for VPC-to-VPC with overlapping CIDRs. Egress-only IGW for IPv6 outbound. NAT instances are legacy but may appear.
- NAT gateway — managed; 45 Gbps; scales automatically
- Private NAT gateway (for overlapping CIDRs / TGW scenarios) — VPC-to-VPC with conflicting IPs
- NAT instances (for comparison) — legacy; self-managed EC2
- Egress-only internet gateway (IPv6) — outbound IPv6; no inbound
13.5 Subnet and IP optimisation ★★ Important
Plan CIDR ranges to avoid overlaps. Secondary CIDRs have restrictions (can’t overlap with existing). IPAM automates IP allocation across accounts. 5 IPs reserved per subnet.
- Designing VPC CIDR ranges — plan to avoid overlaps
- Secondary CIDRs — constraints on what you can add — can’t overlap existing CIDRs
- IPAM tiers and pools — automated IP allocation across org
13.6 Global Accelerator for performance ★★ Important
Static anycast IPs route to nearest AWS edge, then traverse the AWS backbone. Custom routing accelerators map clients 1:1 to endpoints — useful for gaming. Know when GA beats CloudFront.
- Anycast IPs and AWS global network — route to nearest edge, then AWS backbone
- Custom routing accelerators (1-to-1 mapping use cases, e.g. gaming) — deterministic routing to specific endpoints
FAQ
Part IV — Domain 4: Network Security, Compliance, and Governance (24%)
Chapter 14 — Implementing network security controls
Maps to Task Statement 4.1 — Implement and maintain network features to meet security and compliance needs and requirements
Knowledge of:
- Different threat models based on application architecture
- Common security threats (for example, DDoS, SQL injection, cross-site scripting, credential stuffing, session hijacking, web scraping)
- How to implement security mechanisms (for example, security groups, network ACLs, AWS WAF, AWS Shield, AWS Firewall Manager)
- Network access controls in AWS environments (for example, NAT gateways, VPC endpoints, AWS PrivateLink)
- Infrastructure as code (IaC) tools (for example, Terraform, CloudFormation, AWS CDK)
Skills in:
- Designing an AWS Network Firewall architecture
- Configuring security groups and network ACLs to meet security requirements
- Configuring NAT gateways
- Configuring VPC endpoints
- Configuring AWS WAF to protect web applications
- Configuring AWS Shield to protect applications
14.1 Ingress protection: WAF, Shield, CloudFront ★★★ Core
WAF protects against SQLi, XSS, bad bots via web ACLs and rules. Shield Standard is free DDoS protection; Advanced adds 24/7 SRT support and cost protection. Know which resources WAF attaches to.
- AWS WAF developer guide — web application firewall for CloudFront, ALB, API GW
- Web ACLs, rules, rule groups — attach to resources; evaluated in order
- Managed rule groups (AWS Managed Rules, Marketplace) — pre-built OWASP, IP reputation, etc.
- Rate-based rules — throttle by IP; DDoS mitigation
- AWS Shield Standard vs Advanced — Standard free; Advanced adds SRT and cost protection
- Shield Advanced — automatic app-layer DDoS mitigation — auto-creates WAF rules during attack
- Shield Response Team (SRT) engagement — 24/7 DDoS experts
14.2 AWS Network Firewall ★★★ Core
Managed firewall for VPC. Stateless rules evaluate first (like NACLs), then stateful (Suricata-compatible). Deployment models: centralised (inspection VPC) vs distributed. Know logging options: alert, flow, TLS.
- Network Firewall developer guide — managed stateful/stateless firewall for VPCs
- Stateless and stateful rule groups (Suricata-compatible) — stateless first, then stateful
- Deployment models — centralised, distributed, combined — inspection VPC vs per-VPC
- Firewall policy evaluation order — stateless pass/drop/forward, then stateful
- Logging (alert, flow, TLS) — S3, CloudWatch Logs, Firehose
14.3 Centralised egress and inspection VPCs ★★★ Core
Core design pattern: route all traffic through a central inspection VPC with Network Firewall or GWLB+appliances. TGW appliance mode ensures symmetric routing for stateful inspection. Know the traffic flow.
- Multi-VPC whitepaper: centralised egress — single NAT/egress point for all VPCs
- Multi-VPC whitepaper: centralised inspection — route all traffic through firewall VPC
- Gateway Load Balancer with third-party appliances — Palo Alto, Fortinet, Check Point, etc.
- TGW appliance mode for stateful inspection — ensures symmetric routing through firewalls
14.4 AWS Firewall Manager ★★ Important
Central management for WAF, Shield, SGs, Network Firewall, and DNS Firewall policies across accounts. Requires Organizations. Auto-remediates non-compliant resources.
- Firewall Manager overview — central security policy management across org
- Supported policy types (WAF, Shield, SG, Network Firewall, Route 53 Resolver DNS Firewall) — auto-remediate non-compliant resources
14.5 Security groups, NACLs, and endpoint policies ★★★ Core
SGs: stateful, allow-only, evaluated all rules. NACLs: stateless, numbered rules, evaluated in order. Endpoint policies restrict which principals/actions are allowed through a VPC endpoint. Know prefix lists.
- Security group rule reference and stateful behaviour — return traffic automatically allowed
- Network ACL stateless evaluation and numbered rules — lowest numbered rule that matches wins
- VPC endpoint policies — restrict which principals/actions allowed
- Prefix lists (managed and customer-owned) — reusable CIDR sets for SGs/routes
FAQ
Deeper reading
- AWS Best Practices for DDoS Resiliency whitepaper — architecture patterns for DDoS protection
Chapter 15 — Auditing and logging for security
Maps to Task Statement 4.2 — Validate and audit security by using network monitoring and logging services
Knowledge of:
- AWS network-related logging and monitoring services (for example, CloudWatch, AWS CloudTrail, VPC flow logs, VPC Traffic Mirroring, Transit Gateway Network Manager)
- AWS security services (for example, AWS Firewall Manager, AWS Config, Amazon GuardDuty, Amazon Inspector)
Skills in:
- Verifying network security controls by using VPC flow logs, Traffic Mirroring, and CloudTrail logs
- Configuring logging for security purposes (for example, VPC flow logs, access logs, AWS WAF logs)
- Configuring CloudWatch alarms for network security events
- Capturing baseline network performance
15.1 Multi-source log strategy ★★ Important
Combine multiple log sources: Flow Logs for metadata, Traffic Mirroring for packets, CloudTrail for API calls. Send to S3, CloudWatch Logs, or Firehose. Know which log answers which question.
- VPC Flow Logs (recap) — metadata: who talked to whom
- Traffic Mirroring for packet-level forensics — actual packets for deep inspection
- CloudTrail log file integrity validation — detect tampering with audit logs
15.2 Delivery destinations ★ Light
Flow Logs, Resolver query logs, and other network logs can go to S3 (long-term, cheap), CloudWatch Logs (search/alerts), or Firehose (real-time streaming). Know the trade-offs.
- Logs to S3, CloudWatch Logs, or Kinesis Data Firehose — choose based on cost vs real-time needs
- Route 53 Resolver query logs to S3/CW/Firehose — same destinations as flow logs
- Amazon Kinesis Data Firehose — stream to S3, Redshift, OpenSearch, Splunk
15.3 CloudWatch alarms and automation ★ Light
Set alarms on network metrics (high traffic, dropped packets). Composite alarms combine multiple conditions. EventBridge + SSM Automation can auto-remediate. Light exam coverage.
- Alarm states and composite alarms — OK, ALARM, INSUFFICIENT_DATA
- Creating custom metrics (embedded metric format) — emit metrics from Lambda/apps
- Automated remediation with EventBridge + Systems Manager — auto-fix on alarm
15.4 Config and Trusted Advisor ★ Light
Config records resource configurations and evaluates compliance rules (e.g., “all VPCs must have flow logs”). Trusted Advisor checks for SG rules allowing 0.0.0.0/0. Light exam coverage.
- AWS Config — recording configuration changes — compliance auditing and drift detection
- Managed Config rules (networking) — e.g., “all VPCs must have flow logs”
- Trusted Advisor checks — security groups with 0.0.0.0/0, etc.
FAQ
Chapter 16 — Confidentiality and encryption in transit
Maps to Task Statement 4.3 — Implement and maintain confidentiality of data and communications of the network
Knowledge of:
- Network encryption options that are available on AWS
- VPN connectivity over AWS Direct Connect
- Encryption methods for data in transit (for example, IPsec, TLS)
- Network encryption under the AWS shared responsibility model
- Security methods for DNS communications (for example, DNSSEC)
Skills in:
- Implementing network encryption by using AWS services (for example, Site-to-Site VPN, Client VPN)
- Implementing network encryption by using third-party vendor appliances
- Implementing TLS on AWS network services (for example, CloudFront, load balancers, API Gateway)
- Implementing MACsec for Direct Connect connections
16.1 TLS on AWS edge services ★★ Important
ACM provides free public certificates (auto-renewed). ACM Private CA for internal PKI. Know TLS termination points: ALB, NLB (TLS listener), CloudFront, API Gateway. mTLS for client certificate auth.
- ACM — issuing and managing certificates — free public certs; auto-renewal
- ACM Private CA (AWS Private Certificate Authority) — internal PKI; per-cert cost
- TLS termination on ALB / NLB — offload TLS to load balancer
- TLS passthrough on NLB (TCP listener) vs termination (TLS listener) — end-to-end encryption vs offload
- CloudFront viewer/origin protocol policies — HTTPS between viewer↔CF↔origin
- API Gateway TLS (custom domain and mTLS) — client certificate verification
16.2 IPsec / VPN encryption ★★ Important
Site-to-Site VPN uses IPsec with configurable cipher suites. IKEv2 preferred. Private IP VPN runs IPsec over DX transit VIF — encryption without public IPs. Know FIPS endpoints exist.
- Site-to-Site VPN cipher suites and tunnel options — IKE, encryption, integrity algorithms
- AWS VPN and FIPS endpoints — for US government compliance
- Private IP VPN over Direct Connect transit VIF — IPsec without public IP addresses
16.3 MACsec on Direct Connect ★★ Important
MACsec provides Layer 2 encryption on dedicated DX connections (10G/100G). Know it’s hop-by-hop between your router and AWS, requires MACsec-capable hardware. For compliance when DX encryption is required.
- MACsec on dedicated DX connections — Layer 2 encryption; line-rate performance
- MACsec prerequisites and supported port speeds — 10G/100G dedicated; MACsec-capable router
16.4 Shared-responsibility boundary for network encryption ★ Light
AWS encrypts backbone traffic between regions/AZs. You’re responsible for encrypting within VPCs and to on-prem. Know where encryption responsibility lies for each connectivity option.
- AWS Shared Responsibility Model — AWS secures infrastructure; you secure your data
- Inter-region / intra-region encryption of AWS backbone traffic — AWS encrypts backbone automatically
16.5 Secure DNS ★ Light
DNSSEC prevents DNS spoofing via cryptographic signatures. DNS Firewall blocks queries to known-bad domains. Light exam coverage but know both exist for DNS security.
- DNSSEC in Route 53 (recap) — cryptographic signatures prevent spoofing
- Route 53 Resolver DNS Firewall (domain filtering) — block malicious/unwanted domains
FAQ
Appendix A — Services list (in-scope) quick-link index
A concise alphabetical index of every in-scope service from the exam guide, each linking to its canonical user/developer guide and FAQ.
| Service | User guide | FAQ |
|---|---|---|
| API Gateway | Guide | FAQ |
| App Mesh | Guide | FAQ |
| Auto Scaling (EC2) | Guide | FAQ |
| Certificate Manager (ACM) | Guide | FAQ |
| Client VPN | Guide | FAQ |
| Cloud Map | Guide | FAQ |
| Cloud WAN | Guide | FAQ |
| CloudFormation | Guide | FAQ |
| CloudFront | Guide | FAQ |
| CloudTrail | Guide | FAQ |
| CloudWatch | Guide | FAQ |
| Config | Guide | FAQ |
| Direct Connect | Guide | FAQ |
| EC2 | Guide | FAQ |
| EKS | Guide | FAQ |
| Elastic Load Balancing | Guide | FAQ |
| EventBridge | Guide | FAQ |
| Firewall Manager | Guide | FAQ |
| Global Accelerator | Guide | FAQ |
| IAM | Guide | FAQ |
| Lambda | Guide | FAQ |
| Network Firewall | Guide | FAQ |
| Organizations | Guide | FAQ |
| PrivateLink | Guide | FAQ |
| Resource Access Manager | Guide | FAQ |
| Route 53 | Guide | FAQ |
| S3 | Guide | FAQ |
| Shield | Guide | FAQ |
| Site-to-Site VPN | Guide | FAQ |
| Transit Gateway | Guide | FAQ |
| Trusted Advisor | Guide | (see Support FAQ) |
| VPC | Guide | FAQ |
| WAF | Guide | FAQ |
Appendix B — Essential whitepapers and reference guides
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure — the canonical multi-VPC reference; must-read
- AWS VPC Connectivity Options — comprehensive connectivity patterns
- Hybrid Networking Lens — AWS Well-Architected — current hybrid design thinking
- Hybrid Connectivity — BGP and DX design (historical reference)
- IPv6 on AWS — dual-stack and IPv6-only architectures
- AWS Best Practices for DDoS Resiliency — architecture patterns for DDoS protection
- Logical Separation on AWS — how isolation works at AWS
- AWS Well-Architected Framework — Reliability Pillar — HA and DR patterns
- AWS Well-Architected Framework — Security Pillar — security best practices
- AWS Architecture Center — Networking & Content Delivery — reference architectures and diagrams
- AWS Networking & Content Delivery Blog — latest patterns and announcements
Appendix C — A suggested 8-week study plan
- Weeks 1–2: Chapters 1–6 (Domain 1 — Network Design). Read both whitepapers while going.
- Week 3: Chapters 7–10 (Domain 2 — Implementation). Build a TGW hub-and-spoke in a sandbox account.
- Week 4: Chapters 11–13 (Domain 3 — Operations). Practise with Reachability Analyzer and Flow Logs on your sandbox.
- Week 5: Chapters 14–16 (Domain 4 — Security). Deploy Network Firewall in a centralised inspection VPC.
- Week 6: Cycle through every FAQ page in Appendix A. These are gold for distractor-elimination on exam day.
- Week 7: Practice exams (Tutorials Dojo, official AWS sample questions). Note the topics you miss and revisit the relevant chapter.
- Week 8: Focused review on weak areas. Take the official Exam Readiness course on Skill Builder again at 1.5x speed.
Last refreshed against AWS documentation: April 2026. If a link returns 404, AWS has reorganised the docs — search the page title to find its new home.