AWS Advanced Networking Specialty ANS-C01

ANS-C01 will not test "what is a VPC" — it tests address-space designs that survive years of growth + acquisitions + multi-region expansion. Get the foundation wrong and every later topology question (TGW, peering, DX) hits an overlap.

• Primary CIDR + secondary CIDRs: primary at VPC creation (immutable), up to 4 additional secondaries added later. Useful when running out of address space without rebuilding.
• RFC1918 supernet planning: reserve a region-wide supernet (e.g., 10.10.0.0/16 for eu-west-1, 10.20.0.0/16 for us-east-1) and carve VPCs from it. Leaves headroom for peering and TGW route summarization.
• Subnet sizing — reserved IPs: AWS reserves 5 IPs per subnet (.0 network, .1 router, .2 DNS, .3 reserved, .255 broadcast — all unusable). A /29 gives only 3 usable addresses, often too small for HA pairs.
• Public vs private vs isolated subnets: public = route to IGW; private = no IGW route, optional NAT; isolated = no internet route at all. Used for in-VPC-only services or in-DC mirror.
• NAT Gateway HA: NAT is single-AZ; deploy one per AZ + per-AZ private subnet route table pointing to its own NAT. Cross-AZ NAT works but adds per-GB cost. NAT Instance is legacy — avoid.
• Route-table precedence: most specific route always wins, regardless of source. 10.0.0.0/16 via TGW + 10.0.5.0/24 via peering means traffic to 10.0.5.x goes via peering. Use this to override defaults intentionally.

A global SaaS plans 5 regions × 4 VPCs (prod, non-prod, sandbox, shared services). Design: reserve 10.0.0.0/8 for AWS internal. Per-region supernet 10.{region}.0.0/16. Within each, prod 10.{r}.0.0/18, non-prod 10.{r}.64.0/18, sandbox 10.{r}.128.0/18, shared 10.{r}.192.0/18. Each VPC: 3 AZs × public+private+isolated = 9 subnets at /22. Leaves 10.0.0.0/12 free for future on-prem peering.

IPv6 questions are creeping into ANS-C01. Knowing the dual-stack subnet model and the Egress-Only IGW (the IPv6 equivalent of NAT) is the differentiator most candidates skip.

• VPC IPv6 mode: assign an Amazon-provided /56 (or BYOIP). Subnets get /64 blocks. Dual-stack VPC has both IPv4 and IPv6 — instances get both addresses.
• IPv6 is public by default: every IPv6 address is internet-routable. No NAT needed for outbound, but you must explicitly block inbound. Default IPv6 route via IGW makes the subnet "public" for IPv6 even if IPv4 is private.
• Egress-Only IGW (EIGW): stateful gateway that allows outbound IPv6 but blocks inbound — the IPv6 equivalent of NAT for IPv4. Use in IPv6 private subnets when you want internet egress without exposure.
• Mixed-stack pitfalls: a subnet can have private IPv4 (no IGW route) + public IPv6 (default IGW route). Instances are unreachable from the internet via IPv4 but reachable via IPv6 unless you block at SG/NACL.
• DNS64 + NAT64: AWS Route 53 Resolver can synthesize AAAA records from A records (DNS64), and NAT Gateway supports NAT64 — letting IPv6-only clients reach IPv4-only services. Niche but appears on exam.
• NACL IPv6 rules: separate ::/0 rules required — IPv4 rules don't apply to IPv6 traffic. Common gap when retrofitting IPv6.

A workload migrates to dual-stack for IPv6-only mobile clients. Design: assign 2406:da18:abc:1234::/56 to VPC. Public subnets get ::/64 with IGW route for both v4 and v6. Private subnets — IPv4 routes through NAT Gateway, IPv6 routes through Egress-Only IGW. SG rules added with ::/0 equivalents alongside 0.0.0.0/0. NAT64 enabled on the NAT Gateway lets v6 clients reach legacy v4-only S3 prefix-list endpoints.

Peering is the simplest VPC-to-VPC connectivity but has hard limits that force migration to TGW at scale. ANS-C01 tests peering edges that most candidates haven't seen in practice.

• Peering limits: 125 active peers per VPC (soft limit). Past ~25, the N×(N-1)/2 mesh complexity makes TGW the better choice.
• Non-transitive: A↔B + B↔C does NOT give A↔C. Always. Adding more peering connections doesn't fix it — only TGW or VPC routing tricks (NAT instance in B) can.
• Cross-region peering: works the same as same-region. Traffic encrypted automatically over the AWS backbone. Charged per-GB.
• Cross-account peering: one side initiates, the other accepts. Both VPCs must add route-table entries. Peering does NOT share security group references across accounts (use SG references in same account/region only).
• SG references in peering: within the same region, you can reference an SG from a peered VPC in your SG rules — only if it's in the same account. Cross-account uses CIDR-based rules.
• Asymmetric routing pitfall: if forward and return traffic take different paths, stateful firewalls drop the return. Common when peering exists but UDR forces traffic through a NAT/firewall — return path goes peering, breaks the flow.

Two acquired companies merge — both have 10.0.0.0/16 VPCs. They cannot peer due to overlap. Options: (1) re-IP one VPC (downtime + work); (2) use a NAT instance / NAT GW + Network Load Balancer in each VPC to translate IPs; (3) PrivateLink expose specific services without route-level peering. Most teams pick option 3 — PrivateLink eliminates the overlap problem entirely.

Direct Connect is private fiber to AWS. ANS-C01 tests the dedicated-vs-hosted distinction, the three VIF types, and the LAG / redundancy patterns Microsoft expects in production designs.

• Dedicated: entire 1/10/100 Gbps port reserved to you. Provisioned via AWS directly, 30-90 day setup, multi-month commitment. Use when you need full port capacity + your own VIF mix.
• Hosted: shared port through a DX partner. 50 Mbps - 10 Gbps, same-day provisioning. Use for sub-port-capacity needs and faster setup.
• Private VIF: connects on-prem to a single VPC (via Virtual Private Gateway) or to many VPCs (via Direct Connect Gateway). The 95% case.
• Public VIF: connects on-prem to ALL AWS public services (S3, DynamoDB, etc.) over the DX. Use to route public-service traffic over private fiber instead of internet.
• Transit VIF: connects on-prem to one or more Transit Gateways via DX Gateway. The hub-and-spoke at-scale answer. Up to 5,000 routes per TGW.
• LAG (Link Aggregation Group): bond 2-4 DX connections into a single logical link for capacity + resilience. All must be same speed + same location. Use for >10 Gbps or active/active redundancy.

A bank's HQ needs 20 Gbps to AWS with 99.9% SLA. Design: 2× 10 Gbps dedicated DX in different AWS DX locations (geo-redundant), bonded as a LAG. Private VIFs for each VPC over Direct Connect Gateway (multi-VPC routing). Additional Public VIF for S3 traffic to stay on private fiber. Backup site-to-site VPN to a different AWS region as last-resort failover. Total: 20 Gbps active/active with 99.99% effective SLA.

With DX + VPN backup, BGP decides which path traffic takes. ANS-C01 tests BGP attribute manipulation — specifically AS_PATH prepending and local preference — to control failover behavior.

• BGP attributes by priority: (1) Local preference [higher wins, AWS-side controls], (2) AS_PATH length [shorter wins, customer-side controls], (3) MED [lower wins], (4) eBGP over iBGP, (5) router ID.
• Local preference (AWS to on-prem): AWS sets local pref higher for routes learned via DX vs VPN — so AWS prefers DX for outbound. You can't change this from your side.
• AS_PATH prepending (on-prem to AWS): prepend your ASN multiple times on the VPN BGP session to make the VPN path appear longer. AWS picks the shorter (DX) path. The standard customer-side pattern.
• Symmetric routing: need both directions to take the same path. Combine local pref + AS_PATH prepending to ensure both AWS→onprem and onprem→AWS prefer DX, with VPN as failover.
• BGP community tagging: AWS supports BGP communities to tag advertised routes — e.g., 7224:9100 to advertise only to one region. Useful for selective route advertisement.
• BFD (Bidirectional Forwarding Detection): sub-second failure detection on BGP sessions. Enable on both DX and VPN to fail over faster than default BGP timers (90s hold).

DX + VPN backup: on the VPN BGP session, prepend your ASN 3× when advertising your prefixes to AWS. AWS sees AS_PATH length 4 (VPN) vs 1 (DX) — prefers DX. AWS-side already prefers DX via higher local pref. Both directions stable on DX. Enable BFD on both sessions for <1s failure detection. When DX drops, VPN takes over in seconds; when DX recovers, AS_PATH prepending re-routes traffic back automatically.

Cheaper hybrid options + the newer SiteLink for DX-to-DX traffic. ANS-C01 tests when each fits and the Client VPN mutual-auth + auth-rule mechanics.

• Site-to-Site VPN: IPsec tunnel over internet. Two tunnels by default in different AWS data centers — your CGW must support BGP for active/active. AWS-side endpoints are public — accelerated VPN routes them over AWS edge instead.
• Accelerated VPN: Site-to-Site VPN with Global Accelerator's anycast IPs in front. Reduces last-mile latency variability for global branches. Premium cost.
• VPN CloudHub: multiple branch sites VPN to a single Virtual Private Gateway. Branches can reach each other through AWS (transit through VGW). Cheap alternative to TGW for sub-10-site networks.
• Client VPN: OpenVPN-based for remote users. Authentication: mutual TLS (cert-based), Active Directory, or SAML federation. Authorization rules define which CIDRs each user/group can reach.
• Client VPN split tunnel: only AWS-destined traffic flows through the VPN; internet traffic goes direct. Saves AWS-side bandwidth and improves user latency.
• SiteLink: connects two DX locations to each other through the AWS backbone. Lets you use AWS as your global WAN backbone between offices without crossing the public internet.

A 50-branch retailer: HQ has DX (Lesson 2.1 design); branches use accelerated VPN with their own CGW supporting BGP. CGWs use AS_PATH prepending to prefer routing through HQ's DX. Remote employees: Client VPN with SAML federation to corporate IdP, split-tunnel ON, authorization rules limit access to the production VPC only. SiteLink connects HQ's DX to a partner's DX for cross-org connectivity over the AWS backbone.

Transit Gateway is the AWS hub-and-spoke primitive. ANS-C01 tests the association-vs-propagation distinction relentlessly — getting this wrong is the most common production TGW misconfiguration.

• Attachment types: VPC, VPN, Direct Connect Gateway, TGW peering (cross-region or cross-account), TGW Connect (GRE to SD-WAN). Each attachment lives in an AZ + subnet of the attached resource.
• Route table ASSOCIATION: "which route table does this attachment USE to look up routes?" Each attachment associates with exactly ONE TGW route table.
• Route table PROPAGATION: "which attachments dynamically push their CIDRs INTO this route table?" Static routes can be added manually; propagation adds them automatically from VPN/DX BGP or VPC CIDRs.
• Association ≠ Propagation: an attachment can ASSOCIATE with table A (looks up routes there) while PROPAGATING into tables A AND B (lets table B's other attachments reach it). Asymmetric route flows are exactly this pattern.
• Segmentation via multiple route tables: "production" route table (associates prod VPCs, propagates DX), "non-prod" route table (associates dev/test VPCs, propagates DX), "sandbox" route table (associates only with itself — sandbox VPCs can't reach DX).
• Appliance Mode: for VPCs with stateful inline appliances (firewalls), enable Appliance Mode on the attachment — keeps both directions of a flow on the same AZ to preserve flow stickiness.

A 3-tier topology with central inspection: 3 prod VPCs, 1 inspection VPC with a stateful firewall, DX to on-prem. Setup: TGW with 3 route tables — prod-rt (prod VPCs associated, default route 0.0.0.0/0 STATIC to inspection VPC), inspection-rt (inspection VPC associated, prod VPC CIDRs + DX prefixes propagated), dx-rt (DX attachment associated, prod CIDRs propagated). Prod VPCs → all traffic to inspection VPC → firewall inspects → re-routed to DX or other prod. Appliance Mode ON on the inspection VPC attachment for flow stickiness.

Beyond a single region, TGW peers to other TGWs and integrates SD-WAN via TGW Connect. The exam tests the cross-region pattern + GRE tunnel mechanics.

• TGW inter-region peering: connects two TGWs in different regions over the AWS backbone. Encrypted, no transit fees beyond standard inter-region data transfer. Static routing only — must manually add the remote region's prefixes to your TGW route table.
• Cross-account TGW sharing (RAM): share a TGW with other accounts via Resource Access Manager. Each account's VPCs attach independently. Central network team owns the TGW; workload accounts attach.
• TGW Connect: creates a "transport attachment" + a "Connect attachment" — the Connect attachment is a GRE tunnel + BGP session to an SD-WAN appliance running in a VPC. Used for tight integration with Cisco SD-WAN, Aviatrix, Aruba, etc.
• Network Manager: visualisation + monitoring of TGW + DX + VPN + SD-WAN as one topology. Surfaces topology diagrams, change events, and CloudWatch metrics per attachment.
• Cross-region patterns: for active-active: peering TGWs + Aurora Global Database + Route 53 + Global Accelerator. For DR: peering TGWs + ASR-style replication + manual failover via Route 53 health checks.
• Multi-region quotas: 5 TGW peering connections per region by default (soft). 5,000 routes per TGW route table (soft). Plan summarization to stay within limits at huge scale.

A multinational with TGW in us-east-1, eu-west-1, ap-southeast-1. Setup: inter-region TGW peering between each pair (full mesh — 3 peering connections). Each region's TGW route table has static routes to the other two regions' supernets. Each region also has a TGW Connect attachment to a Cisco SD-WAN appliance that handles last-mile branch connectivity. Network Manager dashboard shows the whole topology.

Cloud WAN is the managed-WAN-as-a-service layer on top of TGW. ANS-C01 introduced this in 2023 — the exam will test "is TGW enough or do I need Cloud WAN" decisions.

• Global network: the Cloud WAN umbrella resource. Contains a core network (managed segments + edges) and external networks (your on-prem branches via SD-WAN).
• Core network policy: declarative JSON describing your global topology — segments, allowed inter-segment communication, edge locations, attachment policies. AWS provisions the underlying TGWs / peering / routing from this policy.
• Segments: isolated routing domains in the global network. "production" segment, "dev" segment, "shared-services" segment. By default, segments don't communicate — explicit segment-actions allow it.
• Edge locations: AWS regions where you have Cloud WAN attachments. Cloud WAN automatically peers regions; you don't manage TGW peering manually.
• Attachment policy: rules that auto-assign new attachments to segments based on tags. E.g., "VPCs with tag env=prod join the production segment automatically".
• When TGW vs Cloud WAN: single region or 1-2 regions with manual cross-region peering — TGW. 3+ regions, multi-account, dynamic segmentation needs — Cloud WAN. Cost is higher; manage less.

A multi-cloud retailer with 5 AWS regions and 200 stores: Cloud WAN global network with edges in all 5 regions. Core network policy: three segments — retail-stores, corporate, shared-services. Segment-actions allow corporate↔shared-services but isolate retail-stores from corporate. Attachment policy: VPCs with tag workload=stores auto-join retail-stores segment. Cloud WAN auto-provisions the underlying TGWs + peering. Store SD-WAN appliances connect to the nearest edge via Cloud WAN's Site-to-Site VPN attachments.

Two flavours of VPC endpoint with very different cost models. Picking wrong leaves money on the table or breaks designs.

• Gateway endpoints (S3, DynamoDB only): route-table entries directing traffic to AWS service over backbone. Free. No ENI, no security group — controlled by endpoint policy + bucket / table policy.
• Interface endpoints (PrivateLink): ENI in your subnet with a private IP that resolves to an AWS service. Per-hour + per-GB cost. Used for all other AWS services + cross-account / cross-VPC services.
• Endpoint policies: resource-based policy ON the endpoint restricting who/what can use it. E.g., S3 endpoint policy limiting to in-org bucket ARNs prevents exfil to attacker-owned buckets.
• Private DNS: Interface endpoints have an option to enable private DNS — AWS adds a private hosted zone in your VPC so the public service hostname resolves to the private IP. Default ON for AWS services.
• VPCe Service: expose your own NLB-fronted service as a PrivateLink endpoint that other VPCs / accounts can consume. The SaaS producer pattern.
• VPCe consumer: create an Interface endpoint targeting the producer's VPCe Service. Get a private IP in your VPC that resolves to the producer's service. No peering, no overlap concerns.

A regulated VPC with no internet egress needs S3 + Secrets Manager + KMS. Design: Gateway endpoint for S3 (free, route-table entry). Interface endpoints for Secrets Manager + KMS (per-hour cost). Private DNS enabled — applications use the standard endpoint URLs. S3 endpoint policy restricts to in-org bucket ARNs. Remove NAT Gateway entirely; private subnets have no IGW route.

Exposing your own service privately to other accounts is a classic SaaS pattern. ANS-C01 tests the producer side (NLB + VPCe Service) and consumer side (Interface endpoint targeting it).

• Producer side: deploy NLB in front of your service; create a VPCe Service backed by the NLB. Allowlist consumer AWS principals (account IDs).
• Consumer side: in their VPC, create an Interface endpoint targeting the producer's VPCe Service name. Endpoint policy controls what their workloads can call.
• NLB requirement: VPCe Service requires NLB (not ALB). NLB supports TLS termination if you need cert offload at the producer side. For HTTP-aware routing inside the producer VPC, put ALB BEHIND the NLB.
• Acceptance flow: by default consumer must request connection; producer accepts. Auto-accept toggle for trusted consumers (e.g., same org).
• Cross-region PrivateLink: AWS launched cross-region PrivateLink — a consumer in region A can reach a producer's VPCe Service in region B. Useful for centralised security services.
• Source IP preservation: NLB preserves client IP. The producer service sees the consumer's source IP, not the endpoint's. Set ACLs accordingly.

A FinTech SaaS exposes a "verify SSN" service to bank customers. Architecture: NLB fronts the service Lambda. VPCe Service backed by NLB, allowlist of 12 bank AWS account IDs. Each bank creates an Interface endpoint targeting the VPCe Service in their VPC. Banks' internal services call the endpoint's private DNS name; traffic stays on the AWS backbone, never traverses internet. No peering, no overlap concerns, per-bank revocation by removing them from the allowlist.

VPC Lattice is the AWS service-network mesh (launched late 2023). ANS-C01 tests when to reach for it vs PrivateLink vs ALB.

• Service network: a logical container of services accessible to associated VPCs. Services in the network can talk to each other; VPCs associate to consume.
• Services and target groups: a service has listeners + routing rules + target groups (Lambda, EC2, ECS, IPs, or ALB). Like ALB but spanning VPCs and accounts natively.
• Auth policies: resource-based policy on a service authenticating callers via IAM SigV4 (or anonymous). Replaces "deploy ALB + WAF + Cognito" for service-to-service auth.
• Health checks + weighted routing: per-target health checks. Weighted distribution for canary deploys (90/10 split between versions). Cross-VPC by design.
• VPC Lattice vs PrivateLink: PrivateLink for "VPCs / accounts I don't control consume my service via DNS". Lattice for "shared service network across VPCs in MY org with IAM auth + L7 routing".
• VPC Lattice vs Service Mesh (App Mesh): App Mesh is sidecar-based + Envoy. Lattice is network-layer (no sidecar). Pick Lattice for simpler ops; App Mesh when you need fine-grained per-call observability.

An org with 20 microservices across 8 VPCs in 3 accounts needs service-to-service auth + canary deploys without per-service ALB sprawl. Design: VPC Lattice service network shared across all 3 accounts via RAM. Each microservice registered as a Lattice service with auth policy requiring caller's IAM role membership. Canary deploys configure 10% weighted target group. VPCs associate with the service network — applications resolve service names via Lattice's DNS, traffic routes through the mesh without per-VPC peering or ALBs.

The L7 vs L4 question. ANS-C01 tests subtle distinctions — connection draining, source IP preservation, sticky sessions, target health.

• ALB (L7): HTTP/HTTPS, gRPC, WebSocket. Path-based routing, host-based routing, header-based routing, Lambda targets, WAF integration, sticky sessions (duration or app-cookie).
• NLB (L4): TCP/UDP/TLS. Sub-millisecond latency. Static IP (one per AZ). Preserves source IP at the target. PrivateLink Service Provider requires NLB.
• Cross-zone load balancing: ALB default ON (free). NLB default OFF (per-GB cost when enabled). Without cross-zone, NLB distributes only across targets in the SAME AZ as the receiving node.
• Target health: both run health checks. ALB HTTP/HTTPS only. NLB TCP/HTTP/HTTPS. Health check failures remove targets from rotation; recovered targets re-added after consecutive successes.
• Connection draining (deregistration delay): when target is removed, existing connections drain for up to 3600s. Critical for graceful deploys.
• NLB source-IP preservation: targets see real client IP, not NLB IP. With ALB, targets see ALB IP and X-Forwarded-For has the client IP. NLB requires the target SG to allow client IPs (CIDR-based, since SG references don't work).

A SaaS API exposes HTTPS (web) + gRPC streaming + WebSocket + a TCP service to scientific instruments. Design: ALB for HTTPS + gRPC + WebSocket (L7-aware). Path-based routing splits to different target groups. NLB for the TCP scientific instrument service — instruments need static IPs to whitelist + ultra-low latency. Both behind the same Route 53 hostname via weighted DNS to different services.

GWLB is the security-appliance insertion primitive. ANS-C01 tests the GENEVE encapsulation flow and the central inspection VPC pattern.

• GWLB: L3 transparent network appliance load balancer. Uses GENEVE encapsulation (port 6081) to wrap traffic and send to inspection appliances. Appliances must support GENEVE.
• GENEVE encapsulation: the protocol that lets GWLB preserve the original packet (5-tuple, payload, metadata) when sending to appliances. Without it, appliances would see only the GWLB IP as source.
• GWLB Endpoint Service (GWLBE): the consumer-side endpoint that workload VPCs use to send traffic into the inspection VPC. Each workload VPC's route table points 0.0.0.0/0 at the GWLBE.
• Central inspection VPC: dedicated VPC hosting the GWLB + 3rd-party NGFW (Palo Alto VM-Series, Check Point CloudGuard). All other VPCs route traffic through here via TGW + GWLBE.
• Appliance stickiness: GENEVE preserves flow tuple, so the same flow always lands on the same backend appliance — required for stateful inspection.
• East-west and north-south: both can flow through GWLB. North-south (internet egress) is the common starting case; east-west (VPC-to-VPC) adds TGW routing complexity.

Enterprise with 30 VPCs needs central egress inspection by Palo Alto VM-Series. Design: dedicated inspection VPC with Palo Alto VM-Series instances as GWLB targets. Each workload VPC has a GWLBE in its egress subnet; route table sends 0.0.0.0/0 to the GWLBE. GWLBE encapsulates with GENEVE, sends to inspection VPC, Palo Alto inspects + forwards out to the internet via NAT GW in the inspection VPC. Return traffic follows the symmetric path. TGW Appliance Mode ON for cross-VPC east-west flow stickiness.

Both are global edge services, but they solve different problems. The exam pairs them in answer choices to see if you know the difference.

• Global Accelerator: two static anycast IPs at AWS edge. Traffic enters at the nearest edge, traverses AWS backbone to origin (faster than internet). Sub-30s regional failover. TCP/UDP/HTTP.
• CloudFront: CDN with edge caching. HTTP/HTTPS only. Caches static assets at 400+ POPs. Reduces origin load + global latency for cacheable content.
• Use Global Accelerator when: non-HTTP protocols (gaming UDP, IoT MQTT), TCP services needing static IPs, fast multi-region failover, NLB-fronted services where you want global reach.
• Use CloudFront when: HTTP/HTTPS, cacheable content (static assets, API responses with cache headers), edge protection via WAF + Shield Standard. Adds Lambda@Edge for dynamic logic at edge.
• They can compose: CloudFront in front of Global Accelerator in front of NLB — edge caching + global routing + load balancing. Rare but valid.
• Health checks + endpoint groups: Global Accelerator routes by region weight + health. NLBs/ALBs/EC2/Elastic IPs are valid endpoints. Failover automatic via health.

A multiplayer game has a UDP-based game server (latency-sensitive) and an HTTP API (cacheable leaderboard). Design: Global Accelerator with two endpoint groups (us-east-1, eu-west-1) for the UDP server — static IPs in the client. Players auto-route to nearest healthy region. CloudFront distribution in front of the API with 60s cache on leaderboard endpoints, edge WAF. Two services, two edge primitives, each playing its strength.

AWS Network Firewall is the managed L3-L7 stateful firewall for VPC perimeters. ANS-C01 tests where it deploys, what rule types it supports, and how it compares to the third-party-via-GWLB option.

• Deployment model: Network Firewall is a managed service — you deploy "firewall endpoints" in subnets (one per AZ). Route traffic through them via subnet route tables.
• Stateless vs stateful rule groups: stateless = 5-tuple pass/drop/forward (evaluated first). Stateful = Suricata-compatible signature-based + protocol-aware (TLS SNI, HTTP host header).
• Suricata compatibility: import open-source Suricata rules (Emerging Threats, custom IDS rules). Same rule format that on-prem IDS uses — leverage existing rulesets.
• Managed rule groups: AWS-managed sets — IP Reputation, Botnet, ATP, Suricata. Pre-tuned by AWS. Enable + go.
• Domain list rules: allow/deny by FQDN — TLS SNI inspection extracts the hostname from the handshake. Common pattern: allow-list of approved domains for egress.
• Flow logs: Network Firewall emits its own flow logs separate from VPC Flow Logs — capture rule-match outcomes for forensics.

A regulated workload needs egress filtering with TLS SNI inspection. Design: AWS Network Firewall deployed in the egress subnet of the inspection VPC. Stateless rules allow VPC-internal flows. Stateful rule group with domain list allowing only *.aws.amazon.com, *.docker.io, github.com; deny-all default. Suricata managed rule group for IP reputation. Egress traffic from workload VPCs routes via TGW → inspection VPC → Network Firewall → IGW.

The pattern Microsoft expects on every "regulated multi-VPC" scenario. Deploy inspection in a hub VPC, route all egress through it, audit centrally.

• Dedicated inspection VPC: not a workload VPC — only hosts the inspection appliances (AWS Network Firewall or 3rd-party NGFW via GWLB) + NAT Gateway for actual internet egress.
• Routing path: workload VPC → TGW → inspection VPC's firewall endpoint → NAT GW → IGW. Return path follows the reverse, with TGW Appliance Mode keeping flows on the same AZ.
• Outbound from inspection VPC: NAT Gateway in inspection VPC sends to internet. All workload VPCs share the inspection VPC's NAT egress + public IPs.
• Inbound from internet: usually NOT through inspection VPC — public ALBs / NLBs / CloudFront sit in workload VPCs directly, protected by WAF / Shield. Only east-west + egress flows through inspection.
• Cost considerations: all traffic crosses TGW twice (per direction × per flow), so per-GB cost adds up. Inter-AZ TGW costs apply if workload + inspection VPC are in different AZs.
• Multi-region: deploy inspection VPC per region. TGW peering connects them; cross-region traffic still inspects in source region.

A 20-VPC enterprise: inspection VPC in each region with AWS Network Firewall + NAT Gateway. TGW with route tables — workload VPCs' default route 0.0.0.0/0 points to inspection VPC's TGW attachment. Inspection VPC's route table sends inspected traffic to NAT GW → IGW. Appliance Mode enabled on the inspection VPC attachment to keep both flow directions on the same AZ. WAF + Shield on public-facing ALBs in workload VPCs — those bypass inspection (north-south already protected at L7).

WAF protects L7; Shield Advanced protects against volumetric DDoS. ANS-C01 tests both, with WAF rule priority being the most commonly missed detail.

• AWS WAF deployment targets: CloudFront, ALB, API Gateway, AppSync, App Runner, Cognito User Pool. One Web ACL per target.
• Rule priority order: lowest priority number = evaluated FIRST. First match (allow/block) wins. Allow exceptions need LOWER priority numbers than the managed rules they should override.
• Managed rule groups: AWS-managed (Core Rule Set, IP Reputation, Bot Control) and Marketplace. Bot Control + ATP cost extra; CRS is free.
• Rate-based rules: limit per-source-IP requests in a rolling 5-minute window. Best placed as last priority before the default action.
• Shield Standard: free, always on, protects any AWS-allocated public IP against common L3/L4 DDoS. Mitigations are transparent.
• Shield Advanced: ~$3000/month + per-org. Adds: 24/7 DRT (DDoS Response Team), cost protection during attack, advanced metrics, global threat dashboard. Protects CloudFront/Route 53/ALB/NLB/Global Accelerator/Elastic IPs.

A SaaS with global users: CloudFront distribution with WAF at edge. Web ACL priorities: P1 = Allow rule for partner CIDR exception, P2 = AWS Core Rule Set, P3 = IP Reputation List, P4 = Bot Control, P5 = Rate-based (2000 req/5min per IP). Default = Allow. Shield Advanced enrolled — protects CloudFront + ALB + Route 53 hosted zone. DRT pre-engaged with runbook covering escalation steps during volumetric attack.

Flow Logs are the audit trail; Traffic Mirroring captures actual packets. ANS-C01 tests both, plus the custom-format Flow Log fields most candidates skip.

• VPC Flow Logs scope: can attach to VPC, subnet, or ENI. ENI-level is most granular; VPC-level catches everything in one trail.
• Default vs custom format: default has ~14 fields (5-tuple, packets, bytes, action). Custom adds 30+ — TGW-id, VPC-id, instance-id, traffic path (8 = TGW), packet flags. Custom essential for complex troubleshooting.
• Destinations: CloudWatch Logs (queryable via Insights, expensive), S3 (cheap, query via Athena), Kinesis Firehose (for streaming to SIEM). Most enterprises send to S3 + Athena.
• Aggregation interval: 60s default, can drop to 10s for finer resolution (more cost). Don't change in production without budget review.
• Traffic Mirroring: packet-level capture of ENI traffic. Replicate to NLB / ENI target. Filters by traffic direction + L4 + L7. Used for IDS (Suricata-on-EC2), packet capture for forensics. Costs network bandwidth.
• Mirroring limits: only Nitro-based instances (most modern types). Mirrored bandwidth eats the source instance's network quota.

Troubleshooting "why can't A reach B": enable VPC Flow Logs with custom format including ENI-id + action. Athena query: SELECT srcaddr, dstaddr, action FROM vpc_flow_logs WHERE srcaddr='10.0.1.5' AND dstaddr='10.0.2.10' ORDER BY start DESC LIMIT 20. REJECT rows = NSG/NACL drop. ACCEPT but no return = asymmetric routing or destination SG issue. For deeper diagnosis, enable Traffic Mirroring on the source ENI capturing port 443 to an IDS NLB.

AWS-native static analysis tools that find network problems before they hit. ANS-C01 tests when each fits.

• Reachability Analyzer: point-to-point reachability check between two specific ENIs / IGW / VGW. Returns "reachable" or path-blocked + the exact NACL/SG/route hop that drops it. Run on demand.
• Network Access Analyzer: org-wide policy-based analysis. Define "no resource should be reachable from the internet on port 22" — it finds every violation. Continuous + scheduled.
• Reachability Analyzer use case: "Lambda function can't reach RDS — why?" Run analyzer Lambda ENI → RDS ENI. Returns "blocked by RDS SG inbound rule" + the specific rule preventing the connection.
• Network Access Analyzer scope: defines findings via "scope" — JSON describing source / destination / packet criteria. Org-wide scope evaluates across all accounts via delegated admin.
• Reachability cost: per analysis run. Network Access Analyzer pricing per ENI analyzed. Both are budgetable for production diagnostics.
• When NOT to use either: for dynamic / data-plane problems (the firewall is up but rejecting specific packets due to header content). Use Flow Logs + Mirroring instead.

Compliance team wants to assert "no production database is reachable from non-prod VPCs". Define a Network Access Analyzer scope: source = any ENI in non-prod VPC tag, destination = ENIs with tag tier=database. Run weekly. Any finding triggers an EventBridge → SNS alert. Reachability Analyzer used for ad-hoc "why can't this Lambda reach this RDS" investigations.

Three more ops services: TGW Network Manager for visualisation, Internet Monitor for end-user experience, Route 53 Resolver DNS Firewall for outbound DNS filtering.

• TGW Network Manager: visual topology of TGWs + DX + VPN + SD-WAN as one diagram. Shows attachment status, route propagation, and CloudWatch metrics per attachment.
• Network Manager events: EventBridge integration sends attachment-state-change events. Use to alert on unexpected TGW attachment changes.
• CloudWatch Internet Monitor: measures end-user experience to your apps from each major ISP/city/country. Surfaces health events affecting users by source location.
• Internet Monitor use case: "users in eu-west are reporting slowness". Internet Monitor shows packet loss to your CloudFront edge from a specific French ISP — caused by an upstream ISP routing issue, not your AWS infrastructure.
• Route 53 Resolver DNS Firewall: filter outbound DNS queries from your VPCs against allow/deny lists. Default lists include known C2 / phishing / DGA domains. Custom lists for org-specific blocks.
• DNS Firewall actions: ALLOW (default), BLOCK + NODATA / NXDOMAIN / OVERRIDE (return your own IP). Override is useful for sinkholing — redirect malicious lookups to a quarantine IP for forensics.

A SOC monitors network health and outbound DNS abuse. Setup: TGW Network Manager dashboard shows the full org topology + attachment-state alerts to PagerDuty. Internet Monitor tracks user experience to the production CloudFront — health events route to a daily summary. Route 53 Resolver DNS Firewall rule group with the AWS-managed malware-domains list + a custom block list. Override action sinkholes any matched query to 10.0.99.99, where a honeypot collects evidence.