Network segmentation and analysis
North/south and east/west protection, isolated subnets, Transit Gateway route tables for segmentation, VPC Reachability Analyzer, Network Access Analyzer, Inspector network reachability findings, and VPC Flow Logs for troubleshooting.
Exam tasks: 3.3 (segmentation for north/south and east/west traffic, isolated subnets; identifying unnecessary network access with Network Access Analyzer and Inspector network reachability findings)
The decision: which workloads must never talk to each other or to the internet, where do you enforce that (routing, firewall, security group), and how do you prove the rule holds as the network changes?
Two directions of traffic
| North/south | East/west | |
|---|---|---|
| What | In and out of your AWS network: internet, on-premises, partners | Between VPCs, subnets and workloads inside it |
| Main risks | Exploits from outside, exfiltration, C2 callbacks | Lateral movement after one workload is compromised |
| Controls | CloudFront + WAF + Shield, Network Firewall or GWLB in a central ingress/egress VPC, DNS Firewall, NAT | Separate VPCs, transit gateway route tables, security groups referencing security groups, Network Firewall between segments, VPC Lattice auth policies |
Exam signal
"Limit the blast radius if one application is compromised" or "prevent lateral movement" is an east/west question: separate route domains plus tight security groups, and inspection between segments if required. "Inspect all traffic to and from the internet in one place" is north/south: a centralized inspection VPC.
Subnet tiers
| Tier | Route table | Typical contents |
|---|---|---|
| Public | 0.0.0.0/0 to an internet gateway | ALBs, NAT gateways, Network Firewall endpoints for ingress |
| Private | 0.0.0.0/0 to NAT gateway or firewall endpoint | App servers that need outbound internet |
| Isolated | No route to the internet at all | Databases, regulated data processing. Reaches AWS through VPC endpoints only |
- An isolated subnet is the strongest egress control there is: nothing to filter, because there's no path. Confirm the workload's dependencies (package repos, licence servers, SaaS APIs) have a VPC endpoint or an internal mirror first.
- Use separate VPCs, not just separate subnets, for workloads with different trust levels. Inside one VPC,
every subnet has a
localroute to every other subnet, so only security groups and NACLs separate them. - Block direct internet exposure at the organization level with VPC Block Public Access (blocks IGW traffic
in either direction, with exclusions) and SCPs that deny
ec2:AttachInternetGatewayoutside network accounts.
Transit Gateway route tables for segmentation
- Each attachment is associated with exactly one transit gateway route table (which table it uses to look up destinations) and can propagate its routes into any number of tables (who can reach it).
- A typical pattern:
- A prod table that holds propagations from prod and shared services.
- A dev table that holds propagations from dev and shared services.
- A shared table that holds propagations from everything.
- Prod and dev never learn each other's routes, so there's no path between them, even if a security group is wide open. Add a blackhole route to be explicit.
- To inspect east/west traffic too, point the spoke tables' default route at the inspection attachment (a Network Firewall attachment or an inspection VPC) and enable appliance mode for symmetric flows.
- AWS Cloud WAN does the same with named segments and a central network policy, across Regions.
Disabling default route table propagation
A transit gateway created with default association and propagation turned on puts every new attachment in one table where everything can reach everything. For segmentation, turn both defaults off and associate each attachment deliberately.
Finding and proving access
| Tool | Question it answers | Scope | Sends traffic? |
|---|---|---|---|
| VPC Reachability Analyzer | "Can A reach B on port P, and if not, which component blocks it?" | One source and destination (instance, ENI, IGW, TGW attachment, VPC endpoint, peering, VPN gateway) | No. It analyzes configuration |
| Network Access Analyzer | "Which paths exist that break my policy?" (for example, anything from an IGW to a database subnet) | Whole accounts or an organization | No |
| Inspector network reachability | "Which EC2 ports are open to the internet or other networks, and through what?" | Every scanned EC2 instance | No |
| VPC Flow Logs | "What traffic actually flowed, and was it accepted or rejected?" | ENI, subnet, VPC or TGW | Records real traffic |
VPC Reachability Analyzer
- Builds a model of routes, security groups, NACLs, endpoints, peering and transit gateway tables, then reports the hop-by-hop path or the exact blocking component (for example "NACL acl-… rule 120 denies").
- Works across accounts in an organization when trusted access is enabled.
- Use it after a change breaks connectivity, and to confirm a path is not reachable after you close it.
Network Access Analyzer
- You write a Network Access Scope: MatchPaths describe paths that would be violations (source, destination, protocol, and "through" resources such as a firewall), and ExcludePaths list approved exceptions.
- Findings are paths that match and aren't excluded. Each finding shows the full path of components.
- Good scopes to know:
- Anything reachable from an internet gateway that isn't tagged as a web tier.
- Any path from dev VPCs to prod VPCs.
- Any path to the internet that doesn't go through the Network Firewall.
- Run it on a schedule (EventBridge + Lambda or Systems Manager Automation) and send findings to Security Hub for continuous verification.
Inspector network reachability findings
- Inspector checks every EC2 instance about every 12 hours for open paths, with no agent. A finding names the port range, the open path (IGW, ELB, VPN, peering) and the security group or NACL that allows it.
- Findings are raised only for ports that are actually reachable from outside the VPC, so they're a good list of unnecessary exposure to close first. They also lower or raise the Inspector score of package findings on the same instance.
Exam signal
Pick Reachability Analyzer to troubleshoot one connection. Pick Network Access Analyzer to find every path that violates a segmentation rule across many VPCs. Pick Inspector for a continuously updated list of internet-reachable ports on EC2. None of them needs test traffic.
VPC Flow Logs for troubleshooting
- Capture at VPC, subnet, ENI or transit gateway level. Publish to CloudWatch Logs, S3 (query with Athena) or Data Firehose. They don't capture packet payloads.
- A default record has source and destination IP and port, protocol, packets, bytes and action
(ACCEPT or REJECT). Add custom fields such as
tcp-flags,pkt-srcaddr,pkt-dstaddr(the original addresses behind a NAT gateway or load balancer),flow-directionandtraffic-path. - Reading NACL vs security group problems:
- Inbound REJECT: a security group or NACL blocks the request.
- Inbound ACCEPT followed by an outbound REJECT for the reply: a NACL blocks the return path, because a security group would have allowed the reply automatically.
- Not recorded: traffic to the Amazon DNS server (use Resolver query logs), instance metadata (169.254.169.254), DHCP, Amazon Time Sync, and Windows licence activation.
- See Log analysis for querying flow logs at scale.
Scenarios
Network Access Analyzer is built to express "no path of this shape may exist" across many VPCs, with tag-based matching and exclusions for approved controls, and to report every violating path. Reachability Analyzer checks one pair at a time, which doesn't scale to proving a negative. Flow logs show only traffic that happened, not paths that exist. Inspector covers EC2 only and doesn't check the firewall condition.
Separate route tables remove the path entirely while keeping both environments connected to shared services. NACL denies work but are per subnet and easy to miss as the network grows. Moving Regions is a large migration and still leaves a path if the transit gateways are peered. Appliance mode only keeps flows symmetric through an inspection appliance.
The request was accepted, so inbound rules are fine. A security group is stateful and would have allowed the reply,
so the reject on the way out comes from the stateless NACL. The local route always connects subnets in a VPC. The
client's security group also tracks the connection and allows the response.
Further reading
Hybrid and private access
VPC endpoints and endpoint policies, PrivateLink, Site-to-Site VPN, Client VPN, Direct Connect with MACsec, VPN over Direct Connect, and AWS Verified Access for VPN-less application access.
Domain 4 · Identity and access management
20% of the exam. Proving who is calling, then deciding exactly what that caller may do, for people, workloads and applications.