After passing the AWS Certified DevOps Engineer – Professional, I decided to take the AWS Certified Solutions Architect – Professional route – but with a detour first. Networking underpins almost everything in the SA Pro exam, so I sat the AWS Certified Advanced Networking – Specialty first to shore up the foundations.

These are my study notes from the AWS Certified Advanced Networking Specialty path on Pluralsight.

Fair warning: they’re the longest set of notes I’ve ever taken, because the exam domain is genuinely enormous – from BGP path selection to GENEVE encapsulation. I’ve organised them by the exam’s four domains, and I’ve flagged the things that tripped me up along the way.

Contents

1. Domain 1: Design and implement AWS networks
2. Domain 2: Configure network integration with application services
3. Domain 3: Hybrid networking – VPN, Direct Connect, and transit architectures
4. Domain 4: Design and implement for security and compliance

Domain 1: Design and implement AWS networks

Public vs. private services

• Public services have publicly reachable endpoints by default – think S3, IAM, and SQS.
• Private services aren’t reachable by default: anything you deploy inside a custom VPC.

Availability vocabulary (know this cold)

The exam loves the distinction between these two terms:

• Highly available – the system maintains uptime almost always, even if degraded. Designed to remove single points of failure.
• Fault tolerant - the system always maintains uptime, typically active/active across multiple AZs or regions.

Subnetting math

IPv4 addresses are calculated from the left in bits. For a /N subnet, usable hosts = 2^(32−N) − 5 (the five reserved addresses):

That “minus 5” matters: network address, VPC router (.1), DNS (.2), future use (.3), and broadcast (.255 of the block).

IPv4 vs. IPv6 in VPCs

• IPv4: required on every VPC resource; you choose the CIDR (between /16 and /28); addresses can be public or private.
• IPv6: optional; AWS assigns a fixed-size /56 block per VPC (or you can BYOIP from /48 down to /60); every address is publicly routable – security comes from routing and security groups, not address privacy. IPv6-only subnets are supported.
• Remember the pairing: you choose IPv4 CIDRs; AWS assigns IPv6 (unless BYOIP).

Exam tip: IPv6 operations in a VPC are bound to the IPv4 structure – the subnet’s /64 IPv6 block hangs off the VPC’s /56, the same way IPv4 subnets subdivide the VPC’s primary CIDR.

Choosing your CIDR blocks

Subnets must fall between /28 and /16 (65,536 addresses max, 16 minimum). Before picking, consider: overlap with other VPCs you might peer (you cannot resize a VPC CIDR later), on-premises networks for hybrid connectivity, and how many subnets you’ll need.

For private space, 10.0.0.0/8 gives you 256 × /16s to play with – the roomiest canvas. And when splitting subnets across AZs, divide binary (2, 4, 8…) and size for more AZs than you currently use. Example: splitting 172.31.0.0/16 into four /18s covers four AZs with room to grow:

172.31.0.0/18
172.31.64.0/18
172.31.128.0/18
172.31.192.0/18

Domain 2: Configure network integration with application services

DNS fundamentals

DNS translates domain names to IP addresses. The exam expects you to understand hierarchy and delegation:

• FQDN (Fully Qualified Domain Name): subdomain.second-level-domain.top-level-domain. (note the trailing root dot)
• Record types you’ll see on the exam:
  • A / AAAA: host to IPv4 / IPv6
  • CNAME: alias for a host (can’t be used at zone apex)
  • NS: name server delegation
  • MX, TXT, PTR, SOA, CAA: mail, text, reverse lookup, authority, certificate authority authorisation
• Name servers: authoritative ones know the answers; non-authoritative ones point elsewhere or serve cached content.

Exam tip: You cannot put a CNAME record at the zone apex (root domain). This is why Route 53 Alias records exist-they return an IP address to the client, not an FQDN, and can sit at the apex.

Route 53 hosted zones and routing policies

CNAME vs. Alias (know the difference cold)

Alias records are specifically for AWS service objects (ELBs, CloudFront distributions, S3 buckets). They’re the right choice for production workloads.

Routing policies (each solves a different problem)

Exam tip: With geolocation routing, some IP addresses won’t have a location. If you need to lock traffic to a specific region, don’t set a default location-the unrouted queries will fall through.

Health checks

• Endpoint monitoring: public IP or domain
• CloudWatch alarm: useful for private hosted zones
• Pricing: 50 free AWS endpoints, then $0.50/check; non-AWS endpoints are $0.75/check

Private hosted zones and split-view DNS

• Split-view/split-horizon DNS: separate internal and external zones with fully overlapping namespaces.
• Private hosted zones are associated with VPCs; the default VPC router performs DNS resolution.
• Public zones cannot delegate subdomains to private zones (and vice versa)-they live in separate DNS silos.

Exam tip: For hybrid networks, Route 53 Resolver endpoints let on-premises systems reach private hosted zones (inbound endpoints) and let AWS resources reach on-prem DNS (outbound endpoints). Each ENI handles up to 10,000 queries/second-far better than a single EC2 DNS resolver’s 1,024 qps limit.

VPC DHCP and Route 53 Resolver

AWS reserves specific addresses within each VPC CIDR:

The Route 53 Resolver lives at +2, not the router (+1). Don’t confuse them-they’re separate components even though the IPs are adjacent.

DHCP option sets are immutable once created. If you need custom DNS servers, configure them explicitly rather than relying on defaults.

Elastic Load Balancers (ELBs)

Types at a glance

Exam tip: CLB is legacy and only available for EC2-Classic (accounts created after Dec 2013 don’t have it). Don’t pick CLB for new designs-ALB or NLB depending on your layer.

Cross-zone load balancing

Enabling cross-zone lets ALBs forward to targets in any AZ regardless of where the request came in. For NLBs, it matters more-you’ll incur data transfer charges between AZs if enabled.

Target groups

Target groups define who gets the traffic:

• Target types: EC2 instance IDs, IP addresses (VPC CIDR, RFC 1918, RFC 6598), or a single Lambda function
• Health checks: optional for Lambda, mandatory for others
  • HTTP/HTTPS: path-based, configurable success codes
  • TCP: no path, timeout fixed at 10 seconds
• Deregistration delay: puts targets in draining state so in-flight requests complete
• Session stickiness: disabled by default, can use ELB-generated cookies (AWSALB/AWSELB) or application-based cookies

Exam tip: You can register the same target in multiple target groups-useful for path-based routing to different backends. But target group attributes (like health check paths) can’t be changed after creation.

Application Load Balancers (ALB)

Key features that show up on the exam:

• Listeners: protocol/port combinations; each can have rules with conditions (host header, path, headers, methods, query string, source IP)
• Rules: must have a default rule (lowest priority), conditions are ANDed, comparisons within a condition are ORed
• X-Forwarded headers: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port (pass client info to targets)
• Scheme: internet-facing (public subnets) or internal (private subnets)
• Dualstack IPv6: only works with internet-facing scheme; subnets must support IPv6

Exam tip: You cannot change the ALB scheme after creation. Plan internet-facing vs. internal correctly upfront. Also, ALBs require at least two subnets across different AZs for high availability.

Network Load Balancers (NLB)

• Layer 4, routes on protocol/port, supports static IPs (Elastic IPs for IPv4, manual assignment for IPv6)
• Static IPs cannot be changed after assignment-plan carefully
• Proxy Protocol v2: delivers source IP to targets (separate from “preserve client IP” setting)
• TLS termination: NLB can terminate TLS, but session stickiness by source IP doesn’t work with TLS targets
• No IPv6 support for GWLB (important distinction!)

Exam tip: NLB preserves the client IP at the packet level. Unlike ALB’s X-Forwarded-For headers, NLB targets see the actual source IP unless you disable “preserve client IP.”

Gateway Load Balancers (GWLB)

This one’s weird enough to deserve its own section:

• Not a traditional LB-it forwards traffic to security/appliance targets, then sends it back to the original destination
• Uses GENEVE encapsulation; original IP data stays intact
• No FQDN, accessible only as a VPC endpoint service
• Requires route table configuration to send traffic to GWLB endpoints
• IPv6 not supported
• Targets must support GENEVE protocol and allow traffic from GWLB

Exam tip: GWLB traffic flows like this: client → GWLB endpoint → target (security appliance) → original destination. The endpoint has no DNS name; you route traffic there via VPC route tables. It’s for inline inspection, not serving client requests directly.

CloudFront

CloudFront is AWS’s global CDN. Understanding cache behaviors and security is exam-critical.

Core concepts

Origin Access Control (OAC) vs. OAI

OAC is the modern choice-it grants more permissions and works with SSE-KMS buckets.

Viewer protocol policies (HTTPS enforcement)

• HTTP and HTTPS: default, allows both
• Redirect HTTP to HTTPS: returns 302, but pre-HTTP/1.1 clients get 403
• HTTPS only: rejects plain HTTP with 403

Exam tip: CloudFront certificates must be issued in us-east-1, even if your distribution serves users globally. Custom origins (EC2/on-prem) need externally trusted certs; S3 handles this automatically.

Signed URLs and cookies

• Signed URLs: individual files, good for clients that don’t support cookies
• Signed cookies: multiple files, better UX for video streaming
• Both expire after a configurable duration

Cache key customisation

The cache key determines whether CloudFront serves a cached object or fetches from origin. Default includes:

• Distribution FQDN
• URL path

Customising it (headers, query strings, cookies) can cause duplicate caching or reduced hit ratios. Be deliberate-invalidation is expensive (first 1,000 paths/month free, then charged per path).

Exam tip: Use versioned filenames (e.g., style.v3.css) instead of invalidation for frequent updates. Invalidation takes time to propagate; versioning returns immediately.

Lambda@Edge vs. CloudFront Functions

Both run code at edge locations, but they’re not interchangeable.

Exam tip: Choose CloudFront Functions for lightweight transformations (header manipulation, A/B testing). Use Lambda@Edge when you need more compute power or access to origin response logic.

Global Accelerator

Unlike CloudFront (HTTP-only), Global Accelerator handles TCP/UDP with static Anycast IPs.

• Two static IPs (standard) or four (dual-stack IPv4 + IPv6)
• Routes traffic based on user location, health, and weights
• Standard accelerator: ALBs, NLBs, EC2, EIPs
• Custom accelerator: VPC subnets with custom application logic

Exam tip: Global Accelerator is perfect for non-HTTP protocols (game servers, VoIP, real-time apps). The static IPs don’t change, which matters for firewalls and allow-lists.

Lambda in VPCs

By default, Lambda runs in AWS-owned VPC with public internet access. Deploying to your VPC requires:

• Hyperplane ENIs: managed resources that provide VPC-to-VPC NAT
• Security Groups: must be assigned to Hyperplane ENIs
• NAT Gateway: required for internet access (Lambda gets no public IP)

Exam tip: Functions sharing the same subnet and security group can share Hyperplane ENIs-this reduces ENI count and improves performance.

EKS networking

• Clusters are always created in a VPC with ≥2 subnets in different AZs
• DNS resolution and hostnames must be enabled on the VPC
• Control plane lives in AWS-managed VPC; worker nodes in your VPC
• Traffic flows between VPCs; ALB for ingress, NLB for LoadBalancer services

Exam tip: EKS admin endpoint access is public by default. Lock it down with VPC endpoint policies if your security posture requires it.

WorkSpaces and AppStream 2.0

WorkSpaces (Desktop-as-a-Service)

• Operates from AWS-managed VPC, not your VPC
• Requires Multi-AZ directory services (Simple AD, Managed Microsoft AD, or AD Connector)
• Reserves 5 IPs per subnet + 1 for directory service per subnet
• CIDR ranges are region-dependent: 172.31.0.0/16, 192.168.0.0/16, 198.19.0.0/16

AppStream 2.0 (App streaming)

• Streams desktop apps via HTML5 browser
• Instances spawn fresh for each user
• Internet access depends on concurrent users:
  • >100 users: private subnets + NAT gateway
  • <100 users: public subnets + IGW acceptable
• Management ENI uses 198.19.0.0/16 range

Exam tip: AppStream port 443 is for HTTPS; port 8433 is for UDP over HTTPS (Windows-native clients). Don’t forget port 53 if you’re using custom DNS.

Domain 3: Hybrid networking – VPN, Direct Connect, and transit architectures

This is the heaviest domain. The exam loves BGP path selection, VIF types, and Transit Gateway routing rules-and it loves mixing them up in scenario questions.

Virtual Private Gateways (VGW)

• One VGW attaches to one VPC at a time, but can carry multiple VPN or Direct Connect connections
• ASNs: AWS’s default is 64512 in all regions (7224 in most regions prior to June 30, 2018)
• Private ASN ranges for your side: 64512–65534 (16-bit) or 4200000000+ (32-bit). Public ASNs are controlled by IANA-don’t try to use one you don’t own.

Exam tip: The single most important VGW limitation: VGWs are not transitive. Traffic cannot traverse a VPC to reach another VPC or another VPN/DX connection. This is exactly why Transit Gateway exists.

Route learning and propagation

AWS routing conflict logic (the exam WILL test this):

1. Longest prefix match wins first (VPC route beats overlapping propagated route)
2. VPC static routes beat matching propagated routes
3. Among propagated routes: DX → Static VPN → BGP VPN

So Direct Connect is preferred over VPN when both are propagated. Keep this order memorised-you’ll need it for failover scenarios.

BGP path selection (memorise the sequence)

BGP builds tables of prefixes (routes) shared between configured peers over TCP 179. Nothing is advertised automatically-you control exactly what your peers learn. Path selection order:

1. Highest Weight (local to this router only; Cisco default 32,768 for own prefixes, 0 for learned)
2. Highest Local Preference (default 100; shared with iBGP peers)
3. Shortest AS Path
4. eBGP over iBGP
5. Lowest MED/Metric (not passed beyond the neighboring AS)

The three ways you influence path selection on your side:

• Local preference – raise it for prefixes you want preferred on outbound iBGP
• AS path prepending – add your ASN multiple times to a path (e.g., 65301 65301 65301 i) to make it less attractive. This is how you signal “backup path” to the outside world.
• Multi-Exit-Discriminator (MED) – advertise a lower metric to your peer to make yourself look better (remember: peers don’t forward it onward)

Exam tip: AS path prepending makes a route less preferred, not more. If a question asks how to prefer a primary DX link over a backup VPN, you prepend on the backup path-or use local pref on AWS-managed routes via BGP communities.

Rules worth knowing:

• Prefixes learned from an iBGP peer are never re-advertised to other iBGP peers (that’s why route reflectors exist on-prem)
• VGWs automatically advertise everything they learn from BGP peers
• You cannot directly configure BGP on AWS’s BGP services-you influence them through communities and path attributes

VPN and IPSec fundamentals

How a tunnel establishes (IKE phases matter for troubleshooting questions):

1. Interesting traffic triggers tunnel establishment (traffic initiated on-prem → AWS, by default)
2. IKE Phase 1: peers authenticate, negotiate key-exchange settings, run Diffie-Hellman, then re-authenticate with the derived key. One bidirectional SA for management traffic.
3. IKE Phase 2: negotiates new SAs and keys-two one-way SAs for actual site-to-site traffic
4. Tunnels eventually expire (Phase 2 has shorter lifetimes)

Policy-based vs. route-based VPNs (classic exam topic):

Exam tip: AWS VPN tunnels support only a single pair of one-way IPSec SAs. If you configure policy-based VPN with multiple rule sets, subsequent SAs have to wait until existing tunnels expire. The fix: use one catch-all policy, or switch to route-based VPN. This exact scenario shows up constantly.

Site-to-Site VPN architecture

Customer gateway (CGW) requirements:

• Support IKE (v2 supported since Feb 2019) and IPSec
• Public IP or ACM certificate (pre-shared key is default authentication)
• Dead Peer Detection (required)
• BGP for dynamic routing

Ports to allow (both directions): UDP 500, IP protocol 50 (ESP), and UDP 4500 for NAT traversal.

Every VPN connection gets:

• Two tunnel endpoints in different AZs, active/passive by default
• BGP peering over a /30 from 169.254.0.0/16 (IPv4) or /126 from fd00::/8 (IPv6)
• Both endpoints must be configured on your CGW

Exam tip: VGW VPN throughput caps at 1.25 Gbps across all connections, and the VGW uses a single tunnel endpoint for return traffic. Need more throughput or true active/active? That’s Transit Gateway with ECMP territory.

Accelerated Site-to-Site VPN:

• Routes on-prem traffic into the nearest Global Accelerator edge, then over the AWS backbone
• Requires Transit Gateway – not compatible with VGW
• To “convert” an existing VGW VPN, create a new accelerated VPN (there’s no in-place upgrade)
• Pricing: connection hours + accelerator hourly + data transfer premium

Client VPN and VPN CloudHub

Client VPN (AWS-managed OpenVPN)

• Endpoint attaches to one VPC; use DNS to reach others
• Client IP CIDR cannot overlap target networks
• Authentication: Active Directory, mutual (certificate), or SAML 2.0
• Split tunnel avoids hairpinning all client traffic through AWS - full tunnel sends internet-bound traffic out the VPC’s IGW instead
• Optional: client connect handler (Lambda, runs after auth) and CloudWatch logging

VPN CloudHub

• Hub-and-spoke VPN between your own sites via a VGW – with or without a VPC attachment (detached mode)
• Each CGW needs a unique BGP ASN
• No overlapping IP ranges; up to 10 CGWs
• Cheaper than site-to-site meshes; sometimes used as office-to-office backup

Exam tip: The common thread across VPN questions: overlapping CIDRs are unsupported everywhere - peering, CloudHub, DX. When a scenario offers a “third-party VPN appliance” answer, the trigger conditions are usually non-IPSec protocols (GRE, DMVPN), overlapping CIDRs, or needing transitivity.

Direct Connect

Connection types

Dedicated requests take up to 72 hours. The LOA-CFA (valid 90 days) authorises the DX location to physically patch your equipment to AWS hardware.

Hardware requirements: single-mode fiber, 1000BASE-LX or 10GBASE-LR transceivers, auto-negotiation disabled, 802.1Q VLANs, BGP with MD5. BFD is supported (milliseconds-fast failure detection vs. BGP’s default 270-second timeout) but not required.

Virtual interfaces (VIFs) – THE exam table

DX connections are Layer 2; VIFs provide the Layer 3. Each VIF rides its own VLAN.

DX Gateway pairing rule: a DXGW connects with either private VIFs → VGWs (up to 10 VGWs, 30 VIFs) or transit VIFs → TGWs (up to 3 TGWs). Never a mix.

Prefix limits (customer → AWS): 100 prefixes on private VIFs, 1,000 on public. Exceed them and BGP sessions drop to IDLE.

AWS → customer advertisements depend on the gateway:

• VGWs attached to private VIFs advertise all known routes
• VGWs behind a DX Gateway advertise only your declared allowed prefixes
• Public VIFs: AWS advertises everything public, plus non-regional services like CloudFront and Route 53 – filter what you learn with ACLs or BGP communities

BGP communities (worth memorising verbatim)

Applied by AWS to prefixes advertised TO your public VIF:

Applied by YOU to control where your prefixes propagate:

Applied by you on private/transit VIFs to steer AWS→you return traffic:

Equal-preference prefixes are load-balanced - this is your primary/backup and load-sharing toolkit across multiple DX connections. All AWS-advertised prefixes also carry the no_export community.

Link Aggregation Groups (LAGs)

• Up to 4 connections per LAG, all same bandwidth, same DX location
• Max 10 LAGs per region
• Minimum links setting: if active links drop below the threshold, the whole LAG goes down (default 0 = no minimum)
• Adding existing connections interrupts connectivity briefly; you can’t remove a connection if it breaches the minimum-links threshold

MACsec

• Layer 2 encryption on the DX link itself: adds 8-byte header and 16-byte trailer per Ethernet frame
• Configure via a CKN/CAK key pair on both the DX interface/LAG and your router
• Options per connection: should_encrypt, must_encrypt, or no_encrypt
• Doesn’t replace IPSec for end-to-end encryption – but covers the “AWS doesn’t encrypt DX traffic” gap at Layer 2

Resiliency tiers and troubleshooting

Well-Architected resiliency ladder: single connection → LAG (one location, multi-link) → multiple connections at one DX location → multiple DX locations → optionally VPN as BGP-preferred failover (create VPN backups with automated routing that flips when DX paths withdraw prefixes).

Troubleshooting flowchart (symptom → layer):

• Can’t reach the AWS device from the LOA-CFA? Layer 1: cables, ports, transceivers, auto-negotiation
• Connection up, VIFs down? Layer 2: 802.1Q / VLAN configuration mismatch
• VIF up, BGP won’t establish? Wrong ASN, wrong peer IP, MD5 key mismatch, prefix limit exceeded, or TCP 179 blocked
• Everything up, no reachability? Layer 3+: route tables, NACLs, security groups, application config

Monitoring note: DX connections have CloudWatch metrics (ConnectionState, ConnectionBpsEgress/Ingress, ConnectionPpsEgress/Ingress, ConnectionCRCErrorCount, ConnectionLightLevelTx/Rx) - but VIFs have no CloudWatch metrics; check them manually.

MTU reference (fixed and consolidated)

I had inconsistencies in my original notes – here’s the corrected, single table:

Jumbo frames give you more payload per packet – private VIFs move from 1,500 to 9,001. Caveats: toggling jumbo frames disrupts all VIFs on the connection for up to 30 seconds, and it’s unsupported via VGW static routes. Set the “Do Not Fragment” flag and undersized paths will drop oversized packets rather than fragment them.

The break-even math

When does DX beat internet egress pricing? With internet DTO at $0.05/GB, DX DTO at $0.02/GB, and port hours added on top: a 1 Gbps port breaks even around 7,200 TB of monthly transfer; a 10 Gbps port around 54 PB. The point of the exercise: DX is rarely justified on price alone until your egress is enormous – the real drivers are consistency, latency, and privacy.

Hybrid DNS

The core problem: EC2 instances always use the Route 53 Resolver (VPC+2 address) by default, and on-prem systems can’t reach it.

Resolver search order within a VPC: private hosted zones → VPC domain name → public DNS.

The fix ladder, worst to best:

1. EC2-hosted DNS resolvers – you run and HA-design them yourself; a single ENI tops out at 1,024 queries/second and most clients won’t spread load across servers
2. Simple AD as a forwarder – better, but still self-managed
3. Route 53 Resolver endpoints – the real answer:
   • Inbound endpoints: on-prem → AWS, so on-prem resolvers can query your private hosted zones
   • Outbound endpoints: AWS → on-prem, governed by forwarding rules matched on FQDN patterns
   • 2–8 ENIs per endpoint, 10,000 qps per ENI, one AZ-scoped SG set at creation, priced per ENI-hour

Rule conflict resolution: most specific FQDN wins, and forward rules beat system rules. System rules exist automatically for private hosted zones, VPC domain names, and publicly reserved domains.

Exam tip: For inbound endpoints to resolve private hosted zones, the zones must be associated with the same VPC where the endpoint ENIs live. People lose points assuming the association can be anywhere in the Region.

Inter-VPC connectivity and the transit decision tree

Other peering notes: intra-region peering supports SG ID references (cross-region must use CIDR blocks), and request/accept with manual route entries on both sides is mandatory. PrivateLink consumers must be in the same region as the provider, and providers approve access per AWS account, IAM user, or role.

Transit Gateway (TGW)

The centerpiece of Domain 3. A TGW interconnects thousands of VPCs, VPNs, DX gateways, and even peer TGWs across regions/accounts.

Creation-time settings

• TGW ASN (AWS side of BGP): 64512–65534 or 4200000000–4294967294
• DNS support, VPN ECMP, multicast toggles
• Default route table association/propagation - leave these on and every attachment can reach every other attachment; the moment you need isolation, turn them off and create per-segment route tables
• Soft limit of 5 TGWs per account; 20 route tables per TGW

Attachments and routing

Attachments are billed hourly (VPC owner pays for VPC attachments, TGW owner for VPN, DX owner for DX, both sides for peering) plus per-GB data processed.

• Associations: each attachment associates with exactly one TGW route table
• Propagations: an attachment can propagate its CIDRs to multiple route tables (association not required for propagation)
• VPC attachments propagate their local CIDR; VPN/DX attachments propagate BGP-learned prefixes
• Static routes: one default route per table, blackhole routes for deliberate drops, and static routes are required to reach peered TGWs
• TGW → VPC: routes must be manually added to VPC route tables pointing at the TGW

TGW routing conflict logic (different from VGW!)

Longest prefix wins → static beats propagated → among propagated: VPC > DX > VPN.

Note the flip compared to VGW conflict logic (where DX beat VPN): at TGW level, the VPC attachment’s route is preferred when things collide.

Exam tip: The isolation pattern the exam keeps testing: default settings = full mesh, zero security segmentation. The correct secure design disables default association/propagation and gives each workload segment (prod/dev/shared services) its own TGW route table. Check for Cloud WAN on the exam too – it wraps this same policy model in a declarative document, with segments, segment actions, and core network edges (TGW under the hood per region).

Limits worth memorising

• 5,000 attachments per TGW, of which max 20 DX Gateway attachments and 50 peering attachments
• 10,000 static routes; 20 route tables
• DX Gateway side: 3 TGWs per DXGW, 30 transit VIFs
• VPN fleet per region: 5 VGWs, 10 VPNs per VGW, 50 site-to-site VPNs total

Monitoring

TGW CloudWatch metrics include BytesIn/Out, PacketsIn/Out, PacketDropCountBlackhole, BytesDropCountBlackhole, and BytesDropCountNoRoute / PacketDropCountNoRoute. Flow logs only work within attached VPCs – TGW itself has no flow logs, so deeper visibility into transitive traffic means a transit VPC or Network Firewall in the path. And remember: CloudTrail does not monitor network traffic, anywhere.

Domain 4: Design and implement for security and compliance

This domain overlaps heavily with the Security specialty exam, but AN-C01 tests it through a networking lens – perimeter control, traffic inspection, and encryption in flight.

Traffic control services

AWS Shield

• Standard: free, automatic, protects Route 53, CloudFront, and Global Accelerator at every edge location. Covers roughly 96% of known Layer 3/4 attacks.
• Advanced: $3,000/month with a 1-year commitment. Adds protection for EC2, EIPs, and ELBs, volumetric bot attack coverage, DDoS cost-protection (EDoS coverage), 24/7 SRT engagement, WAF charges included, and centralised management via Organisations/Firewall Manager.

Exam tip: Shield is hosted at CloudFront, Global Accelerator, and Route 53 edge locations only – an unprotected ALB sitting behind no CDN doesn’t benefit until you buy Advanced. Also memorise the Advanced finding metrics: DDoSDetected, DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, DDoSAttackRequestsPerSecond (viewed by AttackVector dimension; CloudFront/Route 53 metrics land in us-east-1).

AWS WAF

WAF inspects HTTP/HTTPS requests and allows, denies, or counts them against ALBs, API Gateway, and CloudFront. Structure matters:

• Conditions contain one or more filters (ORed together): cross-site scripting, country of origin, IP address, request-property size, SQL injection, string/regex matching
• Rules contain one or more conditions (ANDed), and can be regular or rate-based
• ACLs contain rules processed in listed order, plus a default action
• Rate-based rules trigger only after a request threshold, with counters resetting every 5 minutes

Quotas to remember: 10 conditions per rule, 10 rules per ACL, 5 rate-based rules per account/region, and 10 regex conditions (non-raisable).

Exam tip: Once an ACL is associated with an object type, it can only be associated with other objects of that same type – and ALB/API Gateway associations make the ACL region-restricted. Web ACLs for CloudFront metrics live in us-east-1.

Network Firewall

The managed stateful/stateless firewall for VPC perimeters - sits in-line at IGWs, NAT gateways, VPNs, and DX entry points. Uses Suricata rules for stateful inspection, supports domain-name filtering (via TLS SNI, not decryption), and does smart protocol detection (recognises HTTPS even off port 443).

Architecture: traffic from your private subnets gets routed to a firewall endpoint (its own dedicated subnets, referenced as a VPC endpoint ID in route tables), passes the rules engine, and permitted traffic continues to its destination.

Components: firewall (per VPC) ↔ firewall policy (one per firewall, many firewalls per policy) ↔ rule groups.

Stateless actions are pass, drop, or forward (forward hands the packet to the stateful engine) – no analog in NACL-land. Stateful rule types: standard rules (translated to Suricata), Suricata rules proper, and domain list rules.

Exam tip: Unlike an EC2-based firewall appliance, Network Firewall endpoints scale and are managed – but traffic mirroring-based IDS and marketplace appliances still have their place. The exam tests knowing which fits “managed perimeter inspection with domain filtering.”

Firewall Manager

Centralised, cross-account deployment and compliance enforcement of firewall policy types: WAF, Shield Advanced, security groups, Network Firewall, Route 53 Resolver DNS Firewall, plus the third-party CNF options (Palo Alto Cloud NGFW, FortiGate CNF). Out-of-compliance resources generate findings sent to Security Hub.

Detection services

GuardDuty

Continuous threat detection using threat intelligence and ML; findings include credential exposure, escalated privileges, malicious IP interactions, and cryptocurrency mining. Centrally managed via Organisations. It consumes VPC Flow Logs, DNS logs, and CloudTrail events as input sources.

Inspector

Automated vulnerability and network reachability scanning. Network assessments (agentless, for EC2 and Lambda) run every 24 hours and report overly permissive security groups/NACLs; host assessments use SSM Agent. Centralise findings with a delegated administrator.

Traffic Mirroring

Copies ENI traffic out-of-band to a security or monitoring appliance.

• Source (the monitored ENI) → filter (inbound/outbound rules, numbered, processed low-to-high) → target (another ENI, an NLB, or a GWLB) via session
• Targets behind an NLB/GWLB may receive out-of-order packets
• Mirror targets must support VXLAN decapsulation
• Supported on Nitro-based instances; enhanced networking metrics to watch: NetworkMirrorIn/Out, NetworkSkipMirrorIn/Out

Exam tip: Traffic Mirroring captures traffic at the ENI level – inside security groups but you control scope via filters. It complements VPC Flow Logs (which only see L3/L4 metadata, and notably do NOT capture Route 53 resolver traffic, DHCP, instance metadata, Windows license activation, time sync, or traffic to the default VPC router).

Encryption in flight

Certificate landscape

• ACM: free, integrates with ELB/CloudFront/API Gateway/etc., auto-renews, keys and certificates cannot be exported, per-region, CloudFront requires us-east-1, public certs valid 13 months, domain-validated via DNS or email
• IAM certificate store: legacy path - can’t create certs, no console management
• ACM Private CA: $400/month per CA plus per-certificate charges – for internal PKI
• CloudHSM: FIPS 140-2 Level 3 hardware, single-tenant, ENIs into your subnets – not integrated with AWS services, but it’s the answer for private CA root keys, Oracle TDE master keys, and offloading TLS crypto

Exam tip: The recurring trap is cert location: CloudFront and edge-optimised API Gateway custom domains need us-east-1; regional ALB/API Gateway certs must be in their own region; custom origins (EC2/on-prem) need publicly trusted certs (ACM or otherwise); S3 static website endpoints don’t support HTTPS at all.

Protocol enforcement quick reference

• CloudFront: Viewer Protocol Policy = HTTP+HTTPS (default) / Redirect / HTTPS-only (403s otherwise)
• S3: aws:SecureTransport: false bucket-policy condition to deny non-HTTPS
• ELBs: ALB = HTTPS listeners; NLB = TLS listeners; CLB = HTTPS or SSL
• RDS: engine-specific enforcement; apply the AWS root cert bundle to clients
• Intra-instance: EBS encryption at rest, EFS mount-time TLS, FSx encryption with SMB 3/4.2+

Governance and compliance

Keep the framing crisp: governance is control, compliance is proof.

• Organisations + SCPs set the maximum effective permissions across child accounts
• CloudTrail audits every API call (multi-account trails into one bucket) but never network traffic
• AWS Config tracks resource configuration drift and auto-remediates via rules
• Service Catalog forces approved CloudFormation products so nobody hand-builds a VPC
• Security Hub aggregates findings from GuardDuty, Inspector, Firewall Manager, and third parties
• EventBridge + Lambda + SNS close the loop with automated response

Exam tip: When a question mixes “we need to detect” with “we need to prevent,” map services accordingly: Config/Inspector/GuardDuty detect, SCPs/WAF/Network Firewall/SCPs prevent, and Security Hub consolidates. Least-privilege IAM plus separate accounts is always at least half the right answer to governance questions.

Automation appendix (small domain, quick points)

CloudFormation essentials for networkers

Fn::Cidr generates subnet CIDRs from a parent block - perfect for consistent subnetting:

# !Cidr [ ipBlock, count, cidrBits ]
!Cidr [ '10.0.0.0/16', 6, 8 ]
# → 10.0.0.0/24 ... 10.0.5.0/24
# cidrBits 8 means subnet mask = 32 - 8 = /24

Deployment ordering: CloudFormation deploys in parallel by default; DependsOn forces sequencing when one resource must exist first (e.g., route table entries that need a peering connection ID).

Stack policies:

• CreationPolicy - pause resource completion until signals (typically from cfn-init/ASG instances)
• DeletionPolicy - Retain/Snapshot/Delete on stack teardown
• UpdatePolicy - controls in-place replacement behaviour during updates

Cross-account peering: create a role in the accepting account (PeerRoleArn) with sts:AssumeRole from the requester, then pass PeerVpc + PeerRoleArn (+ PeerRegion for cross-region) on AWS::EC2::VPCPeeringConnection.

Troubleshooting ladder: stack Events tab → Get System Log for instance boot logs → /var/log and c:\cfn\log for cfn-init output → CloudWatch log streams.

Cloud Map

Service discovery for dynamic backends: create a namespace, create a service per resource type, instances self-register via RegisterInstance, and consumers resolve via DiscoverInstances. Deeply integrated with ECS; EKS works via the ExternalDNS connector. Supports DynamoDB, S3, SQS, and more as discoverable services.

CDK

Infrastructure-as-code in TypeScript, JavaScript, Python, Java, C#, and Go – it synthesises to CloudFormation under the hood.

The Advanced Networking Specialty rewards two things above all else: pattern recognition across hybrid architectures and tolerance for very specific numbers. When I sat down for the exam, the questions weren’t really “what is a transit VIF”-they were “given THIS topology with THESE constraints, which design satisfies ALL the requirements?” The answers that feel obviously wrong get eliminated instantly; the pain lives in choosing between the two plausible remainder options.

Good luck – and if these notes saved you some head-scratching, pass them on to the next person staring down the same blueprint.