VPC Security Bundle

Security Groups & NACLs, VPC Flow Logs, VPC Peering, AWS PrivateLink, Transit Gateway, VPC Traffic Mirroring, AWS Network Firewall, AWS Verified Access, and cross-account resource sharing via AWS RAM — nine pieces of the same underlying puzzle: controlling, connecting, and observing traffic at every layer of the network, including across account boundaries. The exam tests whether you can match the RIGHT layer to the RIGHT requirement.

Preventive — SGs/NACLs/Network Firewall/Verified Access Detective — Flow Logs Infrastructure Protection

Stateful

Security Groups

Stateless

NACLs

Non-transitive

VPC Peering

3 sessions

Max Traffic Mirroring sessions per source ENI

The Layered Mental Model

Six Tools, Six Different Jobs

Security Groups & NACLs — the most basic, free, always-present layer. Instance/ENI-level (SG) and subnet-level (NACL) packet filtering. No logs of their own — you only see ACCEPT/REJECT decisions if you're also running Flow Logs.
VPC Flow Logs — the observability layer. Captures metadata (not payload) about traffic hitting an ENI, subnet, or VPC: source/destination IP, port, protocol, bytes, and whether it was accepted or rejected by SG/NACL. This is detective, not preventive — it never blocks anything itself.
VPC Peering — a direct, point-to-point, non-transitive network connection between exactly two VPCs. Simple and free of any intermediary gateway, but doesn't scale gracefully — connecting many VPCs this way means building a full mesh of individual connections, which is exactly the problem Transit Gateway was built to solve.
AWS PrivateLink — the private connectivity layer. Lets you expose a service (yours or AWS's) to other VPCs/accounts via an interface endpoint, with traffic staying entirely on the AWS network backbone — never traversing the public internet.
Transit Gateway — the hub-and-spoke connectivity layer. Centralizes routing between many VPCs and on-premises networks through a single managed gateway, replacing a full mesh of VPC peering connections, and now serves as a native attachment point for centralized Network Firewall inspection.
VPC Traffic Mirroring — the deep forensic visibility layer. Copies actual packet content (not just metadata) from a network interface to an out-of-band security/monitoring appliance — fundamentally different from, and entirely independent of, Flow Logs.
AWS Network Firewall — the deep packet inspection layer. Stateful, intrusion-prevention-capable firewall providing domain/URL/IP filtering for VPC-to-VPC, VPC-to-internet, and Direct Connect/VPN traffic — something SGs/NACLs structurally cannot do (they have no Layer 7 awareness).
AWS Verified Access — the zero-trust application access layer. Replaces VPN-based remote access entirely: evaluates identity AND device posture on every single request before granting access to a specific application, not the whole network.
AWS Resource Access Manager (RAM) — the cross-account sharing layer. Lets a central account share specific resources — VPC subnets, Transit Gateways, Route 53 Resolver rules — with other accounts or an entire Organization, without duplicating infrastructure or building cross-account IAM role-assumption chains.

⚠️ The Recurring Exam Theme

VPC security questions are almost always testing whether you pick the narrowest, most appropriate tool for a described traffic-control or visibility requirement — and whether you know which of these six is PREVENTIVE (SGs, NACLs, Network Firewall, Verified Access) versus purely DETECTIVE (Flow Logs) versus purely CONNECTIVITY (PrivateLink, Transit Gateway, neither inherently security tools, though both reduce attack surface by design).

Exam Domain Mapping

Domain	Where This Bundle Shows Up
Infrastructure Security	The centerpiece — nearly every VPC-layer question across all six services
Security Logging & Monitoring	VPC Flow Logs as a foundational data source, including for GuardDuty
Identity & Access Management	Verified Access's identity + device posture evaluation model
Management & Security Governance	Transit Gateway-centralized inspection architecture, Network Firewall policy management at scale

Decision Tree — Mental Model

Threat

Unrestricted lateral movement, unfiltered egress to malicious domains, public internet exposure of internal services, unmanaged VPN-based remote access risk, lack of network traffic visibility

↓

Security Goal

Control traffic at the most appropriate layer and gain visibility into what's actually happening on the network

↓

AWS Service

The VPC Security Bundle

SGs/NACLs — basic packet filtering Flow Logs — metadata visibility Traffic Mirroring — packet-level forensics Peering / PrivateLink — point-to-point connectivity Transit Gateway — hub connectivity Network Firewall — deep inspection Verified Access — zero-trust app access RAM — cross-account sharing

↓

Implementation

Layer defenses: SGs/NACLs first, Network Firewall (often Transit Gateway-attached) for L7 inspection, PrivateLink for service exposure without internet transit, Verified Access replacing VPN for remote app access.

↓

Monitoring

Flow Logs → CloudWatch Logs/S3 → metric filters/Athena; Network Firewall logs → CloudWatch Logs Insights; Verified Access logs every access decision.

↓

Remediation

Update SG/NACL rules, Network Firewall rule groups, or Verified Access Cedar policies in response to findings — none of these self-remediate; changes are deliberate, human or automation-driven.

Final Summary

Must Memorize

SGs = stateful, instance-level. NACLs = stateless, subnet-level — both must be evaluated together for any traffic question
Flow Logs = metadata only, detective only, never blocks anything — and never captures Traffic Mirroring's mirrored packets, since the two are entirely independent features
VPC Peering is point-to-point and non-transitive — Peering A↔B and B↔C does NOT give A reachability to C
PrivateLink ≠ Transit Gateway — PrivateLink exposes a single service privately; Transit Gateway routes broadly between many networks
Network Firewall is the only one of these services with true Layer 7 (domain/URL) filtering
Verified Access replaces VPN with per-request identity + device posture evaluation, including non-HTTP(S) protocols (TCP/SSH/RDP) since Feb 2025
RAM shares the RESOURCE (e.g. a subnet or Transit Gateway) itself — the owning account retains control of the underlying infrastructure even as other accounts consume it

Must Understand

Why centralizing Network Firewall via Transit Gateway attachment eliminates the need for a separate inspection VPC
The stateful vs stateless distinction's practical effect on return-traffic rules
The distinction triangle: SGs/NACLs (basic filtering) vs Network Firewall (deep inspection) vs Verified Access (identity-aware app access)

Can De-prioritize

Exact dollar pricing per GB processed
Console UI navigation specifics
Preview-only features (e.g. Network Firewall Proxy) beyond knowing they exist

Exam appearance probability: HIGH

Core Services — Deep Dive

Security Groups Stateful, instance/ENI-level

Default behaviorDeny all inbound by default; allow all outbound by default

Rule typeAllow rules only — no explicit deny

StatefulnessReturn traffic is automatically allowed regardless of outbound rules — you don't need a matching rule for the response

Reference styleCan reference another security group ID as a source/destination, not just CIDR ranges

Network ACLs Stateless, subnet-level

Default behaviorDefault NACL allows all traffic; custom NACLs deny all by default until rules are added

Rule typeBoth allow AND explicit deny rules, evaluated in numbered order

StatefulnessStateless — you must explicitly allow BOTH the inbound request AND the outbound response (e.g. ephemeral port ranges)

⚠️ Exam-classic trap

A connection failing intermittently, or working one direction but not the other, very often traces back to a NACL missing the ephemeral port range for return traffic — because NACLs are stateless and SGs are not. This single distinction generates a large share of VPC connectivity troubleshooting questions.

VPC Flow Logs Detective only — metadata, not payload

CapturesSource/destination IP, port, protocol, packet/byte counts, ACCEPT or REJECT decision

ScopeCan be enabled at the ENI, subnet, or VPC level

DestinationsCloudWatch Logs, S3, or Kinesis Data Firehose

Does NOT capture packet payload/content — purely connection metadata, similar in spirit to a phone bill (who called whom, how long) rather than a recording of the call.
Shows whether SG/NACL ACCEPTED or REJECTED traffic, making it the natural tool for troubleshooting "why is this connection being blocked."
One of GuardDuty's foundational, automatically-consumed data sources — you don't need your own Flow Logs enabled for GuardDuty's own analysis, but you DO need them enabled yourself if you want to query/alert on this data independently.

VPC Peering Point-to-point, non-transitive

What it doesA direct, private network connection between exactly two VPCs, allowing instances in either to communicate as if on the same network

TransitivityNON-transitive — if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot reach C through B. Each pair needing connectivity needs its own explicit peering connection

ScopeWorks across accounts and across regions (inter-region peering), with traffic staying on the AWS global network rather than the public internet

CIDR constraintThe two VPCs' CIDR blocks must not overlap

No bandwidth bottleneck or single point of failure the way a gateway device would introduce — it's a direct routing construct, not an appliance.
The scaling problem: connecting N VPCs together pairwise requires roughly N×(N-1)/2 individual peering connections — this combinatorial growth is precisely the motivating problem behind Transit Gateway's hub-and-spoke model.
"Connect exactly two VPCs directly, simply, without an intermediary gateway" → Peering. "Connect MANY VPCs without managing a full mesh" → Transit Gateway, not Peering.

AWS PrivateLink Private service exposure

What it doesExposes a service (your own, a partner's, or an AWS service) to consumers in other VPCs/accounts via an Interface Endpoint, with traffic staying on the AWS network — never traversing the public internet

DirectionOne-way exposure — the consumer reaches the provider's service; it does NOT provide general bidirectional network connectivity between VPCs

Underlying mechanismAn Interface Endpoint is an ENI with a private IP in your VPC, backed by AWS's hyperplane infrastructure

Used heavily under the hood by other services in this bundle — e.g. Network Firewall's centralized Proxy and the firewall endpoint itself are deployed PrivateLink-style.
"Expose our internal API to a partner's VPC without using a NAT gateway, internet gateway, or VPC peering" → PrivateLink, precisely because it avoids broad network-level connectivity in favor of narrow, single-service exposure.

AWS Transit Gateway Hub-and-spoke connectivity

What it doesA central, managed gateway that routes traffic between many attached VPCs, VPNs, and Direct Connect connections — replacing a full mesh of pairwise VPC peering connections

Scaling benefitAdding a new VPC means one new attachment to the Transit Gateway, not N new peering connections to every existing VPC

Network Firewall integrationNetwork Firewall now supports NATIVE attachment to Transit Gateway, enabling centralized traffic inspection without a separate dedicated inspection VPC

With Transit Gateway-attached Network Firewall, traffic from Internet Gateways, Direct Connect gateways, PrivateLink, VPN (site-to-site and client), NAT gateways, and inter-VPC/subnet traffic can all be filtered through the same centralized inspection point, with symmetric routing maintained to the same zonal firewall.
This migration model also eliminates the older "inspection VPC" pattern, simplifying architecture and enabling more flexible cross-account cost allocation for the data processed.

VPC Traffic Mirroring Packet-level — independent of Flow Logs

What it doesCopies actual network traffic (full packet content, not just metadata) from a network interface to an out-of-band security/monitoring appliance for deep inspection

SourceAn interface-type ENI; supports both inbound and outbound traffic

TargetA single ENI, a Network Load Balancer with a UDP listener on port 4789, or a Gateway Load Balancer endpoint — deployed out-of-band, not in the regular traffic path

Session limitUp to 3 active mirroring sessions per source ENI, each potentially serving a different monitoring purpose

Cross-VPC mirroringSource and target ENIs can be in different VPCs, as long as those VPCs are peered or connected via Transit Gateway

Critical fact: VPC Flow Logs do NOT capture mirrored traffic. The two features are entirely independent — enabling Traffic Mirroring has zero effect on what appears in your Flow Logs, and vice versa.
Supports filters and packet truncation, letting you extract only the traffic of interest for your monitoring tooling (e.g., an IDS/IPS appliance, a packet analyzer like Zeek).
If using VPC sharing (a VPC owned by one account, with subnets shared to "participant" accounts), participants can only manage mirroring sessions/targets that belong to them — they cannot touch ones owned by the VPC owner, and vice versa.
"We need to feed full packet captures into a third-party IDS appliance for deep inspection, not just connection metadata" → Traffic Mirroring, not Flow Logs — Flow Logs structurally cannot provide payload content.

AWS Network Firewall Deep packet inspection — the L7 gap-filler

What it doesStateful firewall with intrusion prevention, providing URL, domain, and IP-based filtering that SGs/NACLs structurally cannot do

Deployment modelsDistributed (deployed per-VPC) or Centralized (as a Transit Gateway attachment)

Endpoint requirementDeployed as an endpoint service in a dedicated subnet, minimum size /28

ScopeProtects VPC-to-VPC, VPC-to-internet, and Direct Connect/VPN traffic traversing the Transit Gateway — explicitly NOT designed to mitigate volumetric DDoS attacks (that's Shield's job)

URL and Domain Category filtering (2026) — simplifies policy management by letting you control access to entire categories of websites (e.g. AI services) rather than maintaining huge manual allow/deny lists, with exceptions for approved domains and CloudWatch Logs Insights-based traffic monitoring.
Network Firewall Proxy (preview) — a managed egress proxy integrated with NAT Gateway, inspecting traffic via a three-phase model: PreDNS (before domain resolution), PreRequest (before sending to destination), PostResponse (after receiving the server's response). Powered by a PrivateLink interface endpoint; supports both TLS interception and centralized routing via Transit Gateway or Cloud WAN.
"Filter outbound traffic based on destination DOMAIN or URL, not just IP" or "block communication with known malware hosts" → Network Firewall, since SGs/NACLs have no Layer 7 awareness at all.

AWS Verified Access Zero Trust Network Access — VPN replacement

What it doesEvaluates identity AND device security posture on EVERY request before granting access to a SPECIFIC application — not broad network access the way a VPN does

Policy languageCedar — a purpose-built policy language for fine-grained, contextual access decisions

Trust providersUser identity (IAM Identity Center, or direct OIDC federation with Okta/Ping/Auth0/Cognito) AND device management (CrowdStrike, Jamf, JumpCloud) — combined for richer context

Protocol supportOriginally HTTP(S)-only; GA February 2025 added support for non-HTTP(S) protocols — TCP, SSH, and RDP

Core components: Verified Access Instance (top-level container) → Trust Provider (identity/device source) → Verified Access Group (shared policy) → Verified Access Endpoint (the specific application, mapped to a load balancer/ENI/other backend).
Integrates with AWS WAF to add broad internet-threat filtering (SQLi, XSS) on top of the identity/device-aware access decision.
Logs every single access attempt (allowed or denied), giving a built-in audit trail for security/connectivity incident response.
"Provide secure access to internal applications without a VPN, factoring in both who the user is AND whether their device is compliant" → Verified Access, precisely because it evaluates both signals per-request rather than granting broad network access once.

AWS Resource Access Manager (RAM) Cross-account resource sharing

What it doesLets an owning account share specific resources directly with other accounts, an OU, or an entire Organization — without duplicating the resource or building cross-account IAM role-assumption chains

Commonly shared resourcesVPC subnets, Transit Gateways, Route 53 Resolver rules, License Manager configurations, and a growing list of other resource types

Ownership modelThe sharing account retains full control of the underlying resource (e.g., subnet route tables/NACLs, or the Transit Gateway's route tables); consuming accounts get scoped usage rights only

Acceptance flowManual invitation acceptance for ad-hoc account-to-account sharing; automatic acceptance when shared through AWS Organizations

VPC subnet sharing — a central "networking" account owns a VPC and shares specific subnets with "participant" accounts. Participants can launch their own resources (e.g. EC2 instances) into those shared subnets and manage their own security groups, but the VPC owner retains control of the subnet, route tables, and NACLs. This is the standard "shared VPC" pattern for multi-account architectures.
Transit Gateway sharing — by default, a Transit Gateway only accepts attachments from VPCs in the SAME account. To attach VPCs from other accounts, the TGW owner must share it via RAM; the consuming account then creates its own Transit Gateway VPC attachment against the shared TGW ID.
This directly avoids the two classic anti-patterns: duplicating expensive infrastructure (a Transit Gateway, or an entire redundant VPC) in every single account, or building convoluted cross-account IAM trust relationships just to let one account use another's networking resources.
"All accounts in our Organization need to attach to one central Transit Gateway, without each account creating their own" → share the Transit Gateway via RAM, not by manually duplicating it or wiring up cross-account IAM roles.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Connection intermittently fails only in one direction across a subnet boundary

statelessreturn trafficephemeral ports

Expected Answer

Missing NACL rule for the ephemeral port range on return traffic

Distractor	Why it's wrong
Security group misconfiguration	SGs are stateful — once the inbound rule allows the request, the response is automatically permitted, making SGs a less likely root cause for this specific symmetric-traffic failure pattern

Expose an internal service to another VPC/account without internet exposure

private service exposureno internet transit

Expected Answer

AWS PrivateLink (Interface Endpoint)

Distractor	Why it's wrong
VPC Peering	Provides broad bidirectional network connectivity between two entire VPCs — far more access than exposing a single service requires
Transit Gateway	Solves hub-and-spoke routing for MANY networks, not narrow single-service exposure

Centralize traffic inspection across dozens of VPCs without a dedicated inspection VPC

centralized inspectionmany VPCseliminate inspection VPC

Expected Answer

Network Firewall natively attached to Transit Gateway

Distractor	Why it's wrong
Distributed Network Firewall (one per VPC)	Works but doesn't centralize management/inspection or eliminate per-VPC deployment overhead
Security groups	No Layer 7/domain-based filtering capability at all

Block outbound traffic to a category of websites (e.g. AI services) without maintaining a manual IP list

domain categoryURL filtering

Expected Answer

Network Firewall URL/Domain Category filtering

Distractor	Why it's wrong
Security group egress rules	Only support IP/CIDR/port — no domain or URL-category awareness

Replace VPN-based remote access with per-request identity AND device posture checks, including for SSH/RDP

zero trustno VPNSSH / RDP

Expected Answer

AWS Verified Access (non-HTTP(S) protocol support)

Distractor	Why it's wrong
Client VPN	Grants broad network-level access once connected — not the per-request, per-application, identity+device-aware model Verified Access provides
Verified Access (assuming HTTP(S)-only)	Outdated assumption — non-HTTP(S) protocol support (TCP/SSH/RDP) went GA in February 2025

Connect exactly two VPCs directly and simply, with no need to reach a third network through either

two VPCs onlydirect connection

Expected Answer

VPC Peering

Distractor	Why it's wrong
Transit Gateway	Solves the MANY-VPC hub-and-spoke problem; unnecessary complexity for a single pairwise connection
PrivateLink	Exposes one specific SERVICE, not general bidirectional network connectivity between two VPCs

Feed full packet captures (not just metadata) into a third-party IDS/IPS appliance

full packet captureIDS/IPS appliancedeep inspection

Expected Answer

VPC Traffic Mirroring

Distractor	Why it's wrong
VPC Flow Logs	Metadata only — structurally cannot provide payload/packet content, and explicitly does NOT capture mirrored traffic either, since the two features are entirely independent

Let every account in the Organization attach to one central Transit Gateway without duplicating it per account

central Transit Gatewayavoid duplicationorg-wide

Expected Answer

AWS Resource Access Manager (RAM) — share the Transit Gateway

Distractor	Why it's wrong
Create a separate Transit Gateway in every account	Expensive, redundant, and defeats the purpose of centralization
Cross-account IAM role assumption	Solves identity/permission delegation, not resource-level network attachment — RAM is the purpose-built mechanism for sharing the resource itself

Integrations

GuardDuty

WhatHas direct internal access to VPC Flow Logs as a foundational data source

WhyNo manual Flow Logs configuration is required for GuardDuty's own behavioral analysis

CloudWatch Logs / S3 / Kinesis Data Firehose

WhatDestinations for VPC Flow Logs and Network Firewall logs

PatternFlow Logs/Firewall logs → CloudWatch Logs Insights queries → metric filters/alarms for specific traffic patterns

AWS WAF

WhatIntegrates with Verified Access to add broad internet-threat filtering (SQL injection, XSS) on top of identity/device-aware access decisions

IAM Identity Center / OIDC Providers

WhatVerified Access's primary user-identity trust providers

WhySAML-based federation via Identity Center, or direct OIDC federation with providers like Okta/Cognito

Device Trust Partners (CrowdStrike, Jamf, JumpCloud)

WhatSupply device security posture signals to Verified Access policy evaluation

Direct Connect & Site-to-Site/Client VPN

WhatBoth can be attached to Transit Gateway and have their traffic filtered by a Transit Gateway-attached Network Firewall

AWS Organizations

WhatRAM shares (including VPC subnets and Transit Gateways) can target an entire Organization or specific OUs, with automatic acceptance — no manual invitation step needed when sharing this way

Network/Gateway Load Balancer

WhatTraffic Mirroring targets can be an NLB (with a UDP listener on port 4789) or a Gateway Load Balancer endpoint, fronting a scalable fleet of monitoring appliances rather than a single instance

Costs, Limits & Quotas

Pricing Model

Security Groups / NACLsNo direct cost — included with VPC

VPC Flow LogsBilled for log ingestion/storage at the chosen destination (CloudWatch Logs/S3), not a separate Flow Logs fee itself

PrivateLinkHourly charge per interface endpoint, plus data processing charges

Transit GatewayHourly charge per attachment, plus data processing charges per GB

Network FirewallHourly charge per firewall endpoint, plus data processing charges; Transit Gateway-attached mode enables flexible cross-account cost allocation

Verified AccessHourly charge per Verified Access endpoint, plus data processing

Traffic MirroringBilled based on the volume of mirrored traffic processed — separate from, and additive to, Flow Logs costs if both are enabled

RAMNo direct charge for sharing itself — you pay only for the underlying resource's normal usage/data-processing charges, split according to who's actually generating the traffic

Common Cost Mistakes

Deploying distributed (per-VPC) Network Firewall when a centralized Transit Gateway-attached deployment would consolidate endpoints and reduce overhead
Enabling VPC Flow Logs at maximum verbosity account-wide without considering CloudWatch Logs/S3 storage costs at scale
Building a full mesh of VPC peering connections instead of Transit Gateway as the network grows, multiplying connection count unnecessarily

Cost Optimization

Use Transit Gateway-attached Network Firewall for multi-VPC environments instead of per-VPC distributed deployment
Use the new flexible cost allocation for Transit Gateway-attached Network Firewall to fairly distribute data processing charges across accounts/business units
Scope Flow Logs to specific ENIs/subnets of interest rather than blanket VPC-wide logging where full coverage isn't needed

Limits & Quotas

Network Firewall endpoint subnetMust be a dedicated subnet, minimum size /28

NACL rule evaluationRules evaluated in numbered order, lowest number first; first match wins

Verified Access protocol supportHTTP(S) plus TCP/SSH/RDP (GA Feb 2025) — confirm current protocol coverage before assuming broader support

Network Firewall ProxyPublic preview, IPv4 only at preview stage, limited initial region availability

VPC Peering CIDR ruleThe two peered VPCs' CIDR blocks must not overlap

Traffic Mirroring sessionsUp to 3 active sessions per source ENI

RAM acceptanceManual invitation acceptance for direct account-to-account shares; automatic when shared via Organizations

⚠️ Exam trap

Network Firewall is explicitly NOT designed to mitigate volumetric DDoS attacks — that requirement points to AWS Shield (and Shield Advanced for more sophisticated protection), not Network Firewall.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know

SGs = stateful/instance-level; NACLs = stateless/subnet-level — always check both for a traffic question
Flow Logs = metadata only, detective only
PrivateLink = single-service private exposure; Transit Gateway = broad hub-and-spoke connectivity — don't conflate them
Network Firewall = the only one of these six with Layer 7 (domain/URL) awareness
Verified Access now supports TCP/SSH/RDP, not just HTTP(S)

Good Practice

Layer defenses: SGs/NACLs for basic filtering, Network Firewall for L7 inspection, both together rather than either alone
Centralize Network Firewall via Transit Gateway attachment for multi-VPC environments
Enable Flow Logs on sensitive subnets/ENIs and route to CloudWatch for real-time alerting
Use Verified Access trust providers combining BOTH identity and device posture for stronger access decisions

Advanced Practice

Use Domain Category filtering on Network Firewall to simplify large-scale egress policy management
Evaluate the Network Firewall Proxy (preview) for simplified managed egress without maintaining self-hosted proxy fleets
Use Verified Access's Cedar policies for fine-grained, contextual, per-application access conditions beyond simple allow/deny

9 — Common Exam Traps

Misconception	Reality
"Security groups need explicit rules to allow return traffic"	SGs are stateful — return traffic is automatically allowed once the initial request is permitted
"NACLs behave the same way as security groups"	NACLs are stateless and require explicit rules for BOTH directions, including ephemeral ports for responses
"VPC Flow Logs capture packet content"	They capture metadata only (IPs, ports, bytes, accept/reject) — never the actual payload
"PrivateLink and VPC Peering solve the same problem"	PrivateLink exposes one specific service narrowly; peering provides broad bidirectional network access between entire VPCs
"Network Firewall can mitigate DDoS attacks"	Explicitly out of scope — that's Shield's job, not Network Firewall's
"Verified Access only works for web applications"	Outdated — non-HTTP(S) protocol support (TCP/SSH/RDP) went GA in February 2025
"VPC Peering is transitive — if A peers with B and B peers with C, A can reach C"	False. Peering is strictly non-transitive; A would need its own direct peering connection (or a Transit Gateway) to reach C
"VPC Flow Logs will show me the mirrored traffic from a Traffic Mirroring session"	False, explicitly documented — Flow Logs do not capture mirrored traffic; the two features are completely independent
"RAM duplicates the shared resource into the consuming account"	False — RAM shares the SAME underlying resource; nothing is copied, and the owning account retains full control over it

Lookalike Comparisons

Comparison	What actually differs
Security Groups vs NACLs	Stateful/instance-level with allow-only rules vs stateless/subnet-level with allow+deny rules evaluated in order
PrivateLink vs Transit Gateway	Narrow, one-way single-service exposure vs broad, many-to-many hub-and-spoke network routing
Network Firewall vs Security Groups/NACLs	Layer 7 deep packet/domain/URL inspection vs Layer 3/4 IP-and-port-only filtering
Verified Access vs Client VPN	Per-request, per-application, identity+device-aware access vs one-time authentication granting broad network-level access
Network Firewall vs Shield	Deep packet/domain inspection and intrusion prevention vs volumetric DDoS mitigation — different threat models entirely
VPC Peering vs Transit Gateway	Direct, simple, non-transitive two-VPC connection vs centralized, scalable hub-and-spoke routing for many networks — peering doesn't scale past a handful of VPCs without becoming a full-mesh management burden
VPC Flow Logs vs Traffic Mirroring	Connection metadata (who/when/how much) vs full packet content (what exactly was sent) — entirely independent features serving different depths of visibility

VPC Security Bundle

The Layered Mental Model

Exam Domain Mapping

Decision Tree — Mental Model

Final Summary

Core Services — Deep Dive

AWS Exam Thinking

Integrations

Costs, Limits & Quotas

Pricing Model

Common Cost Mistakes

Cost Optimization

Limits & Quotas

Best Practices & Common Exam Traps

8 — Best Practices

9 — Common Exam Traps

Lookalike Comparisons

Flashcards — 24 Cards

Practice Quiz — 12 Questions