AWS Certified Advanced Networking - Specialty (ANS-C01) Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the AWS Certified Advanced Networking - Specialty (ANS-C01). We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for AWS Certified Advanced Networking - Specialty (ANS-C01). It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
AWS Certified Advanced Networking - Specialty (ANS-C01)
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for AWS Certified Advanced Networking - Specialty (ANS-C01). It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Network Design
30%CloudFront CDN & Edge Compute (Lambda@Edge)
Global CDN caching + edge request/response customization to cut origin bandwidth and latency.
Key Insight
Caching reduces origin egress and latency; invalidations are delayed/charged; Lambda@Edge is stateless, limited, and cannot access VPC.
Often Confused With
Common Mistakes
- Expecting instant, free invalidation across all edge caches
- Treating CloudFront as a private circuit (Direct Connect/VPN)
- Assuming Lambda@Edge has VPC access or supports heavy/long-running compute
AWS Global Accelerator — Static Anycast L4
Static anycast IPs that route TCP/UDP over the AWS global network to optimal regional endpoints for lower latency and HA
Key Insight
It's a Layer‑4 anycast router (no caching or L7 features); improvement depends on endpoint placement and health routing; pair with Shield/WAF for DDoS
Often Confused With
Common Mistakes
- Expecting Global Accelerator to cache/serve content like a CDN
- Assuming it provides Layer‑7 features (rewrites, WAF, edge compute)
- Relying on GA alone for DDoS protection or guaranteed latency reduction
Route 53: Alias, Traffic Policies & Resolver
AWS DNS for public/private zones: alias for apex targets, routing policies + health checks; does NOT alter VPC route‑tbl
Key Insight
Route 53 controls DNS answers and failover via records/health checks and Resolver — it never writes VPC/Transit Gateway routes.
Often Confused With
Common Mistakes
- Treating Alias as a CNAME — alias supports zone apex and behaves differently.
- Expecting Route 53 to edit VPC/Transit Gateway route tables to steer packets.
- Assuming Resolver/private zones automatically expose names to the public internet.
Health Checks + Weighted & Latency Routing
Health probes + DNS routing: weighted for gradual shifts, latency sends clients to lowest-latency endpoints; DNS caching
Key Insight
Weights are proportional (not exact); health checks remove unhealthy records; DNS-based distribution affects new lookups only.
Often Confused With
Common Mistakes
- Assuming weights yield exact percentage traffic — TTLs and resolver caches skew real distribution.
- Expecting weighted DNS to split active connections like an ALB/NLB — DNS only affects name resolution.
- Believing weight changes instantly rebalance sessions — only future DNS queries see the change.
ALB — Application Load Balancer (HTTP/HTTPS, TLS Termination)
L7 HTTP/HTTPS proxy with path/host routing, TLS termination or re‑encrypt, integrates with Target Groups (EC2/IP/Lambda)
Key Insight
ALBs are DNS‑fronted with dynamic IPs, terminate/inspect TLS and use X‑Forwarded‑For for client IPs — not for UDP/TCP passthrough
Often Confused With
Common Mistakes
- Expect static IPs — ALBs use DNS and dynamic IPs; use NLB + Elastic IPs for static addressing
- Assume backend sees original TCP source IP — ALB inserts X‑Forwarded‑For; TCP source is the LB
- Think ALB handles UDP or TLS passthrough natively — it's an L7 proxy; use NLB for UDP/passthrough
LB Families & Schemes — ALB vs NLB vs CLB (Internal/External)
Map protocol/features to LB family: ALB=L7 HTTP/HTTPS/WebSocket/gRPC; NLB=L4 TCP/UDP with static IPs; CLB=legacy
Key Insight
Use ALB for content‑based routing and HTTP features; choose NLB for static IPs, high throughput, UDP or TLS passthrough; scheme (internal/external) ⇨V
Often Confused With
Common Mistakes
- Assume ALB can forward arbitrary TCP/UDP — ALB is L7 only; pick NLB for L4 workloads
- Expect instantaneous target registration/deregistration — health checks and grace periods control readiness
- Assume ASG immediately terminates instances on scale‑in — enable lifecycle hooks/connection draining to avoid dropped sessions
CloudWatch — Metrics, Logs & Alarms
Central AWS observability: ingest metrics, logs and events; query with Logs Insights and trigger alarms/dashboards.
Key Insight
Logs ≠ metrics — extract metrics (filters/EMF) or use custom metrics; alarms only alert unless remediation actions are wired.
Often Confused With
Common Mistakes
- Assume VPC Flow, ELB or app logs are collected automatically.
- Treat legacy CloudWatch Logs agent as identical to the unified CloudWatch Agent.
- Expect CloudWatch Alarms to automatically remediate issues without configured actions.
Network Observability — Logs to SIEM
Centralize CloudTrail, VPC Flow Logs, Config and app logs; normalize and forward via Kinesis/Firehose or log subs to SI/
Key Insight
Forwarding logs alone doesn't equal detection — you must normalize, enrich and correlate; Contributor Insights surfaces top‑talkers, not full SIEM.
Often Confused With
Common Mistakes
- Assume merely forwarding logs guarantees detection or remediation.
- Treat Contributor Insights as a full SIEM replacement.
- Expect VPC Flow Logs to contain packet payloads for app-layer inspection.
Transit Gateway (TGW) — Regional Routing Hub
Regional managed routing hub; requires TGW route tables, propagation, and attachments for reachability.
Key Insight
TGW is regional — you must configure route tables and propagation per TGW; Cloud WAN adds a separate global control plane.
Often Confused With
Common Mistakes
- Assuming TGW auto-makes all attached VPCs routable — route tables & propagation required.
- Expecting TGW to auto-propagate routes across Regions like Cloud WAN.
- Treating Cloud WAN as just a TGW UI rather than a distinct global managed WAN service.
Direct Connect Gateway (DXGW) & VIFs — BGP Cross-Connects
DXGW enables private VIFs to reach multiple VGWs/TGWs across accounts/regions; BGP controls prefix exchange and pathing.
Key Insight
DXGW is a global resource but needs explicit associations/propagation; single VIF or circuit ≠ HA — use LAGs or VPN fallback and design BGP timers.
Often Confused With
Common Mistakes
- Assuming one private VIF auto-accesses all VPCs — DXGW associations and route propagation required.
- Treating DXGW as identical to TGW for attachments and routing behaviors.
- Relying on a single DX circuit or BGP session for high availability.
VPC Peering — Regional, Non‑Transitive
Direct private VPC-to-VPC routing confined to one Region; point-to-point only, no transit or automatic cross-account DNS
Key Insight
Peering = A↔B inside one Region. No transitive routing or cross-region reach — use TGW/inter-region peering for transit or multi‑region.
Often Confused With
Common Mistakes
- Assuming peering spans Regions — it is regional only.
- Expecting transitive routes (A–B and B–C ⇒ A–C) — false.
- Permitting overlapping CIDRs or expecting automatic cross-account DNS/IAM access.
AWS PrivateLink — Interface Endpoints (Private Service Access)
Regional, ENI-based private access to provider services (cross-account) without VPC route changes; ideal for service‑per
Key Insight
PrivateLink exposes services via consumer ENI + DNS — traffic stays on AWS fabric, no route propagation or transitive behavior.
Often Confused With
Common Mistakes
- Thinking PrivateLink sends traffic over the public Internet — it uses ENIs on the AWS network.
- Expecting route-table or propagation like peering/TGW — PrivateLink relies on interface endpoints and DNS.
- Assuming cross-region access by default — endpoints and services are regional; deploy per Region.
CloudFront CDN & Edge Compute (Lambda@Edge)
Global CDN caching + edge request/response customization to cut origin bandwidth and latency.
Key Insight
Caching reduces origin egress and latency; invalidations are delayed/charged; Lambda@Edge is stateless, limited, and cannot access VPC.
Often Confused With
Common Mistakes
- Expecting instant, free invalidation across all edge caches
- Treating CloudFront as a private circuit (Direct Connect/VPN)
- Assuming Lambda@Edge has VPC access or supports heavy/long-running compute
AWS Global Accelerator — Static Anycast L4
Static anycast IPs that route TCP/UDP over the AWS global network to optimal regional endpoints for lower latency and HA
Key Insight
It's a Layer‑4 anycast router (no caching or L7 features); improvement depends on endpoint placement and health routing; pair with Shield/WAF for DDoS
Often Confused With
Common Mistakes
- Expecting Global Accelerator to cache/serve content like a CDN
- Assuming it provides Layer‑7 features (rewrites, WAF, edge compute)
- Relying on GA alone for DDoS protection or guaranteed latency reduction
Route 53: Alias, Traffic Policies & Resolver
AWS DNS for public/private zones: alias for apex targets, routing policies + health checks; does NOT alter VPC route‑tbl
Key Insight
Route 53 controls DNS answers and failover via records/health checks and Resolver — it never writes VPC/Transit Gateway routes.
Often Confused With
Common Mistakes
- Treating Alias as a CNAME — alias supports zone apex and behaves differently.
- Expecting Route 53 to edit VPC/Transit Gateway route tables to steer packets.
- Assuming Resolver/private zones automatically expose names to the public internet.
Health Checks + Weighted & Latency Routing
Health probes + DNS routing: weighted for gradual shifts, latency sends clients to lowest-latency endpoints; DNS caching
Key Insight
Weights are proportional (not exact); health checks remove unhealthy records; DNS-based distribution affects new lookups only.
Often Confused With
Common Mistakes
- Assuming weights yield exact percentage traffic — TTLs and resolver caches skew real distribution.
- Expecting weighted DNS to split active connections like an ALB/NLB — DNS only affects name resolution.
- Believing weight changes instantly rebalance sessions — only future DNS queries see the change.
ALB — Application Load Balancer (HTTP/HTTPS, TLS Termination)
L7 HTTP/HTTPS proxy with path/host routing, TLS termination or re‑encrypt, integrates with Target Groups (EC2/IP/Lambda)
Key Insight
ALBs are DNS‑fronted with dynamic IPs, terminate/inspect TLS and use X‑Forwarded‑For for client IPs — not for UDP/TCP passthrough
Often Confused With
Common Mistakes
- Expect static IPs — ALBs use DNS and dynamic IPs; use NLB + Elastic IPs for static addressing
- Assume backend sees original TCP source IP — ALB inserts X‑Forwarded‑For; TCP source is the LB
- Think ALB handles UDP or TLS passthrough natively — it's an L7 proxy; use NLB for UDP/passthrough
LB Families & Schemes — ALB vs NLB vs CLB (Internal/External)
Map protocol/features to LB family: ALB=L7 HTTP/HTTPS/WebSocket/gRPC; NLB=L4 TCP/UDP with static IPs; CLB=legacy
Key Insight
Use ALB for content‑based routing and HTTP features; choose NLB for static IPs, high throughput, UDP or TLS passthrough; scheme (internal/external) ⇨V
Often Confused With
Common Mistakes
- Assume ALB can forward arbitrary TCP/UDP — ALB is L7 only; pick NLB for L4 workloads
- Expect instantaneous target registration/deregistration — health checks and grace periods control readiness
- Assume ASG immediately terminates instances on scale‑in — enable lifecycle hooks/connection draining to avoid dropped sessions
CloudWatch — Metrics, Logs & Alarms
Central AWS observability: ingest metrics, logs and events; query with Logs Insights and trigger alarms/dashboards.
Key Insight
Logs ≠ metrics — extract metrics (filters/EMF) or use custom metrics; alarms only alert unless remediation actions are wired.
Often Confused With
Common Mistakes
- Assume VPC Flow, ELB or app logs are collected automatically.
- Treat legacy CloudWatch Logs agent as identical to the unified CloudWatch Agent.
- Expect CloudWatch Alarms to automatically remediate issues without configured actions.
Network Observability — Logs to SIEM
Centralize CloudTrail, VPC Flow Logs, Config and app logs; normalize and forward via Kinesis/Firehose or log subs to SI/
Key Insight
Forwarding logs alone doesn't equal detection — you must normalize, enrich and correlate; Contributor Insights surfaces top‑talkers, not full SIEM.
Often Confused With
Common Mistakes
- Assume merely forwarding logs guarantees detection or remediation.
- Treat Contributor Insights as a full SIEM replacement.
- Expect VPC Flow Logs to contain packet payloads for app-layer inspection.
Transit Gateway (TGW) — Regional Routing Hub
Regional managed routing hub; requires TGW route tables, propagation, and attachments for reachability.
Key Insight
TGW is regional — you must configure route tables and propagation per TGW; Cloud WAN adds a separate global control plane.
Often Confused With
Common Mistakes
- Assuming TGW auto-makes all attached VPCs routable — route tables & propagation required.
- Expecting TGW to auto-propagate routes across Regions like Cloud WAN.
- Treating Cloud WAN as just a TGW UI rather than a distinct global managed WAN service.
Direct Connect Gateway (DXGW) & VIFs — BGP Cross-Connects
DXGW enables private VIFs to reach multiple VGWs/TGWs across accounts/regions; BGP controls prefix exchange and pathing.
Key Insight
DXGW is a global resource but needs explicit associations/propagation; single VIF or circuit ≠ HA — use LAGs or VPN fallback and design BGP timers.
Often Confused With
Common Mistakes
- Assuming one private VIF auto-accesses all VPCs — DXGW associations and route propagation required.
- Treating DXGW as identical to TGW for attachments and routing behaviors.
- Relying on a single DX circuit or BGP session for high availability.
VPC Peering — Regional, Non‑Transitive
Direct private VPC-to-VPC routing confined to one Region; point-to-point only, no transit or automatic cross-account DNS
Key Insight
Peering = A↔B inside one Region. No transitive routing or cross-region reach — use TGW/inter-region peering for transit or multi‑region.
Often Confused With
Common Mistakes
- Assuming peering spans Regions — it is regional only.
- Expecting transitive routes (A–B and B–C ⇒ A–C) — false.
- Permitting overlapping CIDRs or expecting automatic cross-account DNS/IAM access.
AWS PrivateLink — Interface Endpoints (Private Service Access)
Regional, ENI-based private access to provider services (cross-account) without VPC route changes; ideal for service‑per
Key Insight
PrivateLink exposes services via consumer ENI + DNS — traffic stays on AWS fabric, no route propagation or transitive behavior.
Often Confused With
Common Mistakes
- Thinking PrivateLink sends traffic over the public Internet — it uses ENIs on the AWS network.
- Expecting route-table or propagation like peering/TGW — PrivateLink relies on interface endpoints and DNS.
- Assuming cross-region access by default — endpoints and services are regional; deploy per Region.
Network Implementation
26%Hub‑and‑Spoke (Transit Gateway Hub)
TGW-centered multi‑VPC hub: attachments + route‑table association/propagation control segmentation and flow.
Key Insight
Associations bind an attachment to a TGW route table; propagation advertises routes — both must match for traffic to traverse the hub. Cross‑account/
Often Confused With
Common Mistakes
- Assuming one TGW attachment = full connectivity — you must set association AND propagation.
- Centralizing services removes spoke security — spokes still need SGs/NACLs/IDS and least‑privilege routes.
- Treating the hub as single failure point — design AZ spread, redundant attachments and route table failover.
VPN Variants & When to Use Them
Pick IPsec site‑to‑site, Accelerated VPN, or VPN over DX by encryption, latency, throughput, and failover needs.
Key Insight
Direct Connect is not encrypted by default — VPN over DX adds confidentiality; site‑to‑site needs BGP + redundant tunnels for true HA; Accelerated VPN
Often Confused With
Common Mistakes
- Assuming Direct Connect encrypts traffic — add VPN over DX if you need encryption.
- Relying on a single VPN tunnel for HA — provision redundant tunnels and BGP for failover.
- Expecting Accelerated VPN to speed every flow — it helps long‑distance/UDP paths; not a silver bullet.
VPC Flow Logs — Centralized Metadata Audit
IP-level traffic metadata (no payload); deliver to CloudWatch, S3, or Kinesis Firehose for centralized multi-account/mid
Key Insight
Flow Logs record metadata only; choose destination by need: CloudWatch for alerts, S3+Athena for forensics, Firehose for transforms.
Often Confused With
Common Mistakes
- Expecting payload or app-layer data — Flow Logs are metadata only.
- Enabling multiple scopes (VPC/Subnet/ENI) will not deduplicate — overlapping records possible.
- Treating Flow Logs as guaranteed or real-time — records can be delayed, aggregated, or dropped.
Network Segmentation: Zones, Routes & Controls
Partition networks into security zones (subnets, VPCs, TGW route tables) and enforce least-privilege with routes, SGs, N
Key Insight
Segmentation = reachability + policy: TGW requires route-table association/propagation; routes set reachability, SGs/NACLs enforce port-level access.
Often Confused With
Common Mistakes
- Assuming subnet separation alone guarantees isolation — routing and policies determine access.
- Treating SGs and NACLs as interchangeable — SGs are stateful; NACLs are stateless.
- Assuming a TGW attachment auto-enables connectivity — must configure TGW route table associations/propagations.
Route 53 Hosted Zones — Public vs Private & TGW DNS Hub
Public vs private hosted zones: records are authoritative; private zones bind only to associated VPCs/accounts — design,
Key Insight
Private zones are visible only to explicitly associated VPCs or RAM‑shared accounts; Transit Gateway never auto‑forwards DNS — you need Resolver paths
Often Confused With
Common Mistakes
- Assuming private hosted zones are auto‑visible to all VPCs/accounts without VPC association or RAM sharing.
- Believing Transit Gateway will auto‑forward DNS queries without explicit Resolver endpoints and forwarding rules.
- Thinking centralizing DNS always improves latency and reduces risk (ignores added latency and single failure zones).
Route 53 Resolver — Endpoints, Rules & Firewall
Managed VPC resolver: inbound/outbound endpoints, conditional forwarding rules, and DNS Firewall for hybrid DNS control.
Key Insight
A forwarding rule only works if paired with an outbound endpoint and VPC association; endpoints are regional ENIs protected by SGs/NACLs.
Often Confused With
Common Mistakes
- Expecting a forwarding rule to forward queries without creating an outbound endpoint and associating the VPC.
- Assuming Resolver endpoints are public or require no network controls — they use ENIs and need SG/NACL/routing protection.
- Believing conditional rules auto‑share across accounts without explicit VPC associations or AWS RAM.
IaC: AWS CDK & CloudFormation (CLI/SDK)
Declarative, versioned automation to provision AWS network resources across accounts/regions with drift controls.
Key Insight
IaC encodes desired state — it doesn't auto-fix drift or guarantee safe rollbacks; design pipelines, drift detection, and multi-account patterns.
Often Confused With
Common Mistakes
- Treating ad-hoc CLI/SDK scripts as declarative IaC—no idempotence or state tracking.
- Assuming IaC automatically prevents drift—no built-in reconciliation unless you add it.
- Expecting safe universal rollbacks—some resource types and change sets can leave resources orphaned.
Hybrid Network Automation: On‑Prem ↔ AWS
Automate connectivity and device config across on‑prem and AWS: VPN/Direct Connect, routing, vendor APIs, and state‑reco
Key Insight
On‑prem devices are not cloud resources—use vendor adapters, per-device credentials, and active state reconciliation and monitoring.
Often Confused With
Common Mistakes
- Applying the same AWS IaC templates to devices without vendor-specific adapters.
- Automating only initial provisioning and skipping continuous monitoring/reconciliation.
- Using shared/static credentials for cloud and device automation—exposes large blast radius.
Network Management and Operation
20%VPC Sharing (AWS RAM): Shared Subnets, Owner Keeps Routes
Share subnets with participant accounts via AWS RAM — the VPC owner retains route tables, propagation, and attachments.
Key Insight
Subnet resource is shared; routing objects (route tables, TGW/VGW attachments, propagation) remain owned and controlled by the VPC owner.
Often Confused With
Common Mistakes
- Assuming participant accounts can modify route tables of a shared subnet.
- Believing shared subnets automatically inherit TGW/VGW attachments or route propagation.
- Thinking VPC sharing is cross‑Region or bypasses Organization scoping by default.
NAT Device — Gateway vs Instance: Per‑AZ, Egress Only
Enables private-subnet outbound connections; NAT Gateways are managed and per‑AZ, instances are customer‑managed; IPv6 e
Key Insight
NAT blocks inbound-initiated traffic, NAT Gateways are per‑AZ (deploy per AZ for redundancy), and IPv6 needs egress‑only IGW.
Often Confused With
Common Mistakes
- Expecting a single NAT Gateway to provide cross‑AZ redundancy.
- Assuming NAT allows inbound-initiated connections from the Internet.
- Thinking NAT Gateway natively supports IPv6 outbound traffic.
VPC Traffic Mirroring — Packet-level Capture
Out-of-band copy of ENI packets to monitoring/security appliances via mirror targets, sessions, filters and sampling.
Key Insight
Mirroring is selective and out-of-band — not flow logs, may be encapsulated/truncated, and only works for supported ENIs.
Often Confused With
Common Mistakes
- Mixing it with VPC Flow Logs — mirroring gives full packets; flow logs are metadata only.
- Thinking it's inline — it does NOT block or alter original traffic (it copies it out-of-band).
- Assuming every resource is mirrorable — only supported ENIs/resources that expose ENIs can be sources.
ICMP Ping & Traceroute — Path, Latency & PMTUD Tests
Use ICMP Echo/Time Exceeded/Destination Unreachable to check reachability, per-hop RTTs and PMTUD hints, accounting for滤
Key Insight
ICMP probes reveal probe-path and PMTUD signals but can be filtered, rate‑limited, ECMP‑affected or differ from app traffic.
Often Confused With
Common Mistakes
- Treating a successful ping as proof the TCP/UDP application is reachable.
- Assuming traceroute shows the exact app-data path — ECMP, policy routing or probe-type can differ.
- Interpreting missing/truncated hops as outages — often ICMP filtering or rate‑limiting, not a down device.
Site-to-Site VPN (IPsec)
Two IPsec tunnels for hybrid L3 connectivity; supports static or BGP routing — size by per‑tunnel throughput.
Key Insight
AWS provisions two redundant tunnels; size connections by per‑tunnel bandwidth and use BGP for fastest failover.
Often Confused With
Common Mistakes
- Thinking Accelerated VPN works with a Virtual Private Gateway — it only supports Transit Gateway.
- Trying to toggle acceleration on an existing VPN — acceleration requires creating a new connection.
- Relying on a single tunnel or ignoring per‑tunnel throughput when sizing for production.
VPC Peering vs PrivateLink vs Transit Gateway
Peering: L3 non‑transitive, no overlapping CIDRs. PrivateLink: service endpoint ENIs. Transit Gateway: transitive hub w/
Key Insight
Peering is direct VPC‑to‑VPC L3 only (no transitivity or overlapping CIDRs); PrivateLink is endpoint‑based (no routing); Transit Gateway gives transit
Often Confused With
Common Mistakes
- Believing VPC Peering is transitive — it is not.
- Assuming VPC Peering allows overlapping CIDRs — it doesn't.
- Treating PrivateLink as a router that provides full VPC‑to‑VPC routing — it's an endpoint/service connect.
Network Security, Compliance, and Governance
24%Security Groups — Stateful ENI Firewall
Instance-level, stateful allow-only firewall attached to ENIs; rules are unordered and can reference other SGs.
Key Insight
Stateful: return traffic is auto-permitted; SGs only allow rules, no DENY or priorities; attach to ENIs, not subnets.
Often Confused With
Common Mistakes
- Treating SGs as stateless — you don't need explicit return rules.
- Attaching SGs to subnets or route tables — they attach only to ENIs/instances.
- Expecting DENY entries or rule ordering — SGs evaluate all allow rules as a set.
Route Tables & Propagation — Longest‑Prefix Wins
VPC/TGW/VGW routing follows longest‑prefix‑match; propagation is per table/attachment and can be filtered or summarized.
Key Insight
Longest‑prefix decides conflicting routes; propagated routes don't automatically override static—prefix filters and associations control visibility.
Often Confused With
Common Mistakes
- Assuming propagated routes always beat static routes — prefix length and specificity decide.
- Expecting propagation everywhere — propagation must be enabled per route table/attachment.
- Interpreting a missing route as 'not advertised' — it may be filtered, overlapped by a more specific route, or misassociated.
CloudTrail — API Audit Trail (Multi‑Region & Tamper‑Evident)
Authoritative record of AWS API events; deliver to S3/CloudWatch/EventBridge, enable data events and SSE‑KMS for secure,
Key Insight
Multi‑region/org trails + explicit data‑event enablement = complete audit; use log‑file validation + SSE‑KMS for tamper evidence.
Often Confused With
Common Mistakes
- Assuming CloudTrail logs packet‑level network traffic — use VPC Flow Logs for network metadata.
- Believing a single‑region trail covers all regions — enable a multi‑region or organization trail for full coverage.
- Expecting S3/Lambda data events by default — data events must be explicitly enabled and may incur extra cost.
VPC Access Controls: SGs, NACLs & Network Firewall
Compare security groups (stateful), NACLs (stateless), and Network Firewall placement for enforcement, logging, andleast
Key Insight
NACLs (stateless) are evaluated at the subnet boundary before security groups (stateful) on ENIs; place Network Firewall in the routed path for DPI/ID
Often Confused With
Common Mistakes
- Assuming security groups evaluate before NACLs — NACLs hit first at the subnet boundary.
- Thinking an SG 'allow' cannot be blocked — NACLs can still deny traffic before SGs see it.
- Believing SGs can explicitly deny traffic — security groups only have allow rules; use NACLs/Network Firewall for denies.
Direct Connect — Private Circuit (add encryption)
Carrier‑provisioned private circuit to AWS — dedicated path but NOT automatically end‑to‑end encrypted.
Key Insight
DX = private transport; pick VIF type (Private/Transit/Public) and layer on IPsec or MACsec for confidentiality; MACsec is hop‑to‑hop, IPsec can be E2
Often Confused With
Common Mistakes
- Assuming Direct Connect auto‑encrypts all traffic
- Believing Transit VIF provides end‑to‑end encryption by default
- Thinking MACsec gives application‑level/end‑to‑end encryption across VPCs
Encryption: At‑Rest vs In‑Transit — TLS vs IPsec
Cryptographic controls for stored and moving data; use IPsec for network tunnels, TLS for app‑layer sessions and cert‑dr
Key Insight
TLS secures application sessions (not just HTTPS) and terminates at apps; IPsec secures network flows/tunnels — they differ in termination, auth, and運
Often Confused With
Common Mistakes
- Treating IPsec and TLS as always interchangeable
- Thinking TLS only secures HTTP/HTTPS traffic
- Assuming encryption removes need for auth, access control, or endpoint validation
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet
- Google Cloud Security Operations Engineer Exam Cheat Sheet