Network controls and segmentation

Security groups vs network ACLs

Skill 3.3.1 starts with the two built-in VPC firewalls. A security group (SG) is attached to a network interface (ENI), so it protects one resource. A network ACL (NACL) is attached to a subnet, so it protects everything in that subnet. Traffic from outside the subnet passes the NACL first, then the SG.

The exam loves three differences: SGs are stateful and NACLs are stateless; SGs have allow rules only while NACLs can also deny; and SGs can use another security group as the source, which NACLs can’t.

Limits and SG references

Default quotas: 60 inbound and 60 outbound rules per SG, 5 SGs per ENI (adjustable up to 16), and SGs per ENI × rules per SG can’t exceed 1,000. A NACL has 20 rules each way by default, adjustable to 40. An SG reference counts as one rule no matter how many instances it covers; a customer-managed prefix list counts as its maximum size. You can reference an SG in the same VPC, in a peered VPC, or (inbound rules only) in a VPC on the same transit gateway when SG referencing is turned on. A reference doesn’t work if traffic passes through a middlebox such as a firewall appliance: then use CIDRs.

$ aws ec2 authorize-security-group-ingress --group-id sg-0db \
    --ip-permissions 'IpProtocol=tcp,FromPort=5432,ToPort=5432,UserIdGroupPairs=[{GroupId=sg-0app}]'

$ aws ec2 create-network-acl-entry --network-acl-id acl-0pub \
    --ingress --rule-number 50 --protocol -1 \
    --cidr-block 198.51.100.0/24 --rule-action deny

$ aws ec2 create-network-acl-entry --network-acl-id acl-0pub \
    --egress --rule-number 140 --protocol tcp \
    --port-range From=1024,To=65535 --cidr-block 0.0.0.0/0 --rule-action allow

Troubleshooting traffic: flow logs and Reachability Analyzer

Many exam questions describe traffic that doesn’t arrive and ask how to find out why. There are two kinds of evidence. VPC Flow Logs record real traffic that happened. Reachability Analyzer reads your configuration and tells you whether a path could work, and if not, which component blocks it.

Flow log records and recent fields

The default format (version 2) has 14 fields: version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status. Custom formats can add vpc-id, subnet-id, tcp-flags, pkt-srcaddr/pkt-dstaddr (the original IPs behind a NAT gateway), flow-direction and traffic-path. A newer reject-reason field shows BPA when traffic was dropped by VPC Block Public Access, an account-level setting that can block internet gateway traffic in a whole Region (bidirectional or ingress-only), with exclusions for chosen VPCs or subnets. Delivery is best effort, roughly 5 minutes to CloudWatch Logs and 10 minutes to S3.

2 111122223333 eni-0web 203.0.113.9 10.0.1.20 49152 443 6 4 240 1791633600 1791633660 ACCEPT OK
2 111122223333 eni-0web 10.0.1.20 203.0.113.9 443 49152 6 4 180 1791633600 1791633660 REJECT OK

$ aws ec2 create-network-insights-path --source igw-0abc --destination i-0web \
    --protocol tcp --destination-port 443
$ aws ec2 start-network-insights-analysis --network-insights-path-id nip-0123

AWS Network Firewall

Security groups and NACLs only look at IPs, ports and protocols. AWS Network Firewall is a managed, stateful firewall with intrusion prevention (IPS) for whole VPCs. It can filter by domain name, match Suricata rules on traffic patterns, and even decrypt TLS to look inside. It is the exam’s answer for “filter egress to approved domains” and “IPS for VPC traffic”.

Domain lists, TLS inspection and deployment models

A domain list rule group checks the TLS SNI (HTTPS) and the HTTP Host header. .example.com matches the domain and all subdomains. An allowlist drops other traffic of that protocol; a denylist drops only matches. It doesn’t look up DNS, so a client could fake the SNI; add IP rules if that matters. TLS inspection decrypts, inspects and re-encrypts traffic. Inbound inspection uses your server certificate in ACM; outbound inspection uses a CA certificate imported into ACM, which issues certificates on the fly, so clients must trust that CA. Deployment models: distributed (a firewall in each VPC), centralized (an inspection VPC behind a Transit Gateway with appliance mode on), or combined. Newer: a transit gateway-attached firewall attaches Network Firewall directly to a Transit Gateway, with appliance mode always on and routing done in TGW route tables. Firewall Manager can deploy Network Firewall policies across accounts.

"RulesSource": { "RulesSourceList": {
    "Targets": [".amazonaws.com", "github.com"],
    "TargetTypes": ["TLS_SNI", "HTTP_HOST"],
    "GeneratedRulesType": "ALLOWLIST" } }

# Suricata-compatible stateful rule (strict order rule group)
drop tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:"badsite.example"; nocase; msg:"blocked SNI"; sid:1000001; rev:1;)

"StatefulEngineOptions": { "RuleOrder": "STRICT_ORDER" },
"StatefulDefaultActions": ["aws:drop_established"]

Route 53 Resolver DNS Firewall

Every VPC has a built-in DNS server, the Route 53 Resolver (called VPC Resolver in newer AWS docs), at the VPC base address plus two. Malware often uses DNS to find its command server or to exfiltrate data inside DNS queries. SGs, NACLs and Network Firewall can’t see or block queries to the Resolver, so AWS gives you DNS Firewall for this path.

DNS Firewall Advanced and logging

DNS Firewall Advanced adds protections that don’t need a list: it detects DNS tunneling and domain generation algorithm (DGA) domains from query patterns, and offers threat and content categories (for example phishing or gambling). Log queries with Resolver query logging to CloudWatch Logs, S3 or Firehose to see which rule matched. Remember the split: DNS Firewall covers the Resolver path, Network Firewall covers the network path; together they give domain filtering on both.

$ aws route53resolver create-firewall-rule-group --name block-malware \
    --creator-request-id 2026-10-10-a

$ aws route53resolver create-firewall-rule --name malware \
    --firewall-rule-group-id rslvr-frg-0abc \
    --firewall-domain-list-id rslvr-fdl-0managedmalware \
    --priority 100 --action BLOCK --block-response NXDOMAIN \
    --creator-request-id 2026-10-10-b

$ aws route53resolver associate-firewall-rule-group --name prod \
    --firewall-rule-group-id rslvr-frg-0abc --vpc-id vpc-0prod --priority 101 \
    --creator-request-id 2026-10-10-c

$ dig +short controldomain1.malwarelist.firewall.route53resolver.us-east-1.amazonaws.com
(no answer: NXDOMAIN)

Gateway Load Balancer and third-party appliances

Some companies already use a firewall vendor and want the same appliances in AWS. Gateway Load Balancer (GWLB) makes that easy: it sends traffic transparently through a fleet of virtual appliances, scales them, and removes unhealthy ones. On the exam, “use our existing third-party firewall / IDS / IPS” almost always means GWLB.

# IGW ingress (edge) route table, associated with the internet gateway
Destination      Target
10.0.0.0/16      local
10.0.2.0/24      vpce-0gwlbe1a      # app subnet in AZ a -> GWLB endpoint in AZ a

# App subnet route table (AZ a)
Destination      Target
10.0.0.0/16      local
0.0.0.0/0        vpce-0gwlbe1a      # replies go back through the same endpoint

# GWLB endpoint subnet route table
0.0.0.0/0        igw-0abc

Network segmentation: north/south and east/west

Skill 3.3.4 is about segmentation: splitting the network so one compromised part can’t reach everything. North/south traffic crosses the boundary between your network and the internet (or on-premises). East/west traffic moves between workloads inside your network: subnet to subnet, VPC to VPC, account to account. Good designs protect both.

Inspection VPC, TGW route tables, SG referencing and VPC Lattice

For many VPCs, a Transit Gateway hub lets you control east/west traffic with separate route tables (for example prod can’t route to dev) and send traffic to an inspection VPC running Network Firewall or GWLB appliances, with appliance mode on that attachment. North/south egress can go through a central egress VPC with NAT gateways. SG referencing over a transit gateway works for inbound rules only, must be turned on for the TGW and the attachment, doesn’t work across TGW peering, and doesn’t work through an inspection VPC. Over VPC peering, you can reference the peer’s SGs in the same Region. Amazon VPC Lattice is another east/west option: it connects services across VPCs and accounts at the application layer, with auth policies (IAM, requests signed with SigV4) on the service network or service, plus SGs on the VPC association, so you control which service may call which.

$ aws ec2 describe-route-tables --route-table-ids rtb-0iso \
    --query "RouteTables[0].Routes[].[DestinationCidrBlock,DestinationPrefixListId,GatewayId]"
[ ["10.0.0.0/16", null, "local"],
  [null, "pl-6ca54005", "vpce-0s3gw"] ]

{ "Statement": [{ "Effect": "Allow", "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::corp-data-bucket/*" }] }

Cheatsheet extras: NAT gateway vs NAT instance, bastions, IPv6 egress and custom DNS

Your cheat sheet says “make sure you can build a custom VPC from memory”. Sections 01–06 covered the firewalls. This section adds the VPC plumbing the cheat sheet tests: how private subnets reach the internet (NAT gateway, NAT instance, egress-only internet gateway), bastion hosts, the VPC’s DNS settings and DHCP option sets, reserved IPs, and a troubleshooting order.

Bastion hosts (jump boxes)

A bastion is a hardened instance in a public subnet that admins SSH/RDP into first, then hop to private instances. For a highly available bastion: at least two in public subnets in two AZs, an Auto Scaling group (minimum 1), and SGs that allow 22/3389 only from the company’s IP range; private instances allow SSH only from the bastion’s security group. Never copy private keys onto the bastion; use SSH agent forwarding or, better, skip the bastion: Session Manager and EC2 Instance Connect Endpoint (Day 4) need no open inbound ports.

VPC DNS, DHCP option sets and reserved IPs

Troubleshooting order: “it can’t connect”

Walk the packet. 1. Route table: does the subnet have a route to the IGW, NAT gateway, VGW/TGW or peering connection, in both VPCs for peering? 2. NACL: allow in and out, including ephemeral ports. 3. Security group: inbound rule on the target; for peering, reference the peer SG or CIDR. 4. Host firewall (iptables, Windows Firewall). 5. Public IP or Elastic IP on the instance if it must be reached from the internet. Confirm with flow logs (REJECT records) and Reachability Analyzer. VPN traffic: the route table must send on-premises CIDRs to the VGW (or enable route propagation).

$ aws ec2 create-nat-gateway --subnet-id subnet-public-a --allocation-id eipalloc-0a1
$ aws ec2 create-route --route-table-id rtb-private-a \
    --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0a1
$ aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0123
$ aws ec2 create-route --route-table-id rtb-private-a \
    --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-0b2

$ aws ec2 create-dhcp-options --dhcp-configurations \
    "Key=domain-name-servers,Values=10.0.5.10,10.0.6.10" \
    "Key=domain-name,Values=corp.example.com"
$ aws ec2 associate-dhcp-options --dhcp-options-id dopt-0d4 --vpc-id vpc-0123

Lecture summary map

Day 2 on one screen.

1. Mind map

2. Match the requirement to the control

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 3.

Practice test questions (from your mock exams)

These 9 questions come from your own SCS-003 mock exams (the last 1 are new questions added in the October 2026 review for features AWS changed in 2025–2026), matched to today’s topics. Each one was checked against current AWS behaviour: where a mock answer used old features (OAI, Classic Load Balancer, Inspector Classic) the wording was updated, and the explanation says so. The source is shown at the end of each explanation, for example “(Mock 5 · Q12)”.

Hands-on lab (30 minutes, low cost)

1. In a test VPC, launch one small Amazon Linux instance in a public subnet running a web server on port 80. Give its security group inbound TCP 80 from your IP only, and check the page loads.
2. Turn on VPC Flow Logs for the VPC to CloudWatch Logs with a 1-minute aggregation interval.
3. Create a custom network ACL with inbound TCP 80 from your IP and outbound TCP 80 only, and associate it with the subnet. The page stops loading. After a few minutes, find the inbound ACCEPT and outbound REJECT records for your IP in the flow logs.
4. Create a Reachability Analyzer path from the internet gateway to the instance on port 80 and run it. Read the explanation that names the NACL. Then add outbound TCP 1024-65535, run the analysis again and reload the page.
5. Create a DNS Firewall rule group with the AWS managed malware domain list, action BLOCK with NXDOMAIN, and associate it with the VPC. From the instance, run dig controldomain1.malwarelist.firewall.route53resolver.us-east-1.amazonaws.com (use your Region in the name) and see NXDOMAIN.
6. Clean up: disassociate and delete the DNS Firewall rule group, delete the flow log and its log group, re-associate the default NACL and delete the custom one, terminate the instance. Reachability Analyzer charges per analysis and DNS Firewall charges per query. Don’t create a Network Firewall or Gateway Load Balancer for practice unless you delete it the same day: both charge every hour they exist, even with no traffic.