Network Security Controls: SGs, NACLs, Network Firewall, and Egress

You already know the mechanics; the exam tests the security design reading. A security group is stateful: return traffic for an allowed connection is permitted automatically, rules are allow-only, and every rule is evaluated. Its killer security feature is referencing other security groups as sources. A rule on the database tier allowing port 3306 from the app tier's security group is effectively identity-based micro-segmentation: membership in the source group is the credential, and the rule survives Auto Scaling, IP churn, and subnet redesigns that would break any CIDR-based rule. Least privilege here means one rule per required flow, SG references instead of CIDRs wherever the source is inside AWS, and no default-open outbound where egress matters.

A network ACL is stateless and evaluated at the subnet boundary as an ordered, numbered rule list — first match wins. Statelessness means you must explicitly allow return traffic, which in practice means allowing the ephemeral port range (for Linux clients typically 32768–60999; NACL rules commonly open 1024–65535) in the reverse direction. That cost buys you two things security groups cannot do: an explicit deny and a subnet-wide blast radius. NACLs are the coarse guardrail layer: deny a known-malicious CIDR across an entire subnet, enforce that an isolated subnet never talks to the internet regardless of what any instance's SG says, or act as an incident-response kill switch — a low-numbered deny rule cuts an attacker off mid-session, whereas removing an SG rule only prevents new connections because existing tracked flows can persist.

Defense in depth uses both: SGs express intended flows tightly; NACLs enforce what must never happen at the subnet tier.

Segmentation in a VPC is built from subnets and route tables, because a subnet's route table decides what its workloads can even attempt to reach. The three-tier reference design the exam assumes: a public tier (route to an internet gateway) holding only load balancers and NAT gateways; a private tier (default route to a NAT gateway, no inbound path from the internet) holding application compute; and an isolated tier (no route to an IGW or NAT at all) holding databases and other crown-jewel data stores, which reach AWS services only through VPC endpoints. Each tier gets its own route table — sharing one route table across tiers is how a database subnet quietly inherits a NAT route it should never have.

The guide's language of north/south versus east/west maps directly onto this: north/south is traffic crossing the perimeter (internet or hybrid), controlled by edge services, NAT placement, and egress firewalls; east/west is lateral traffic between tiers, VPCs, or accounts, controlled by SG references, NACLs, and Transit Gateway route-table segmentation. Attackers who land on an app instance pivot east-west, so a design answer that only hardens the perimeter is wrong at Specialty level.

Finally, verify the segmentation you think you have: Network Access Analyzer evaluates configuration to find network paths that violate your intent (for example, any path from the internet to the isolated tier), and Amazon Inspector's network reachability findings flag instances exposed on unintended ports — both are the guide's named tools for identifying unnecessary network access.

VPC endpoints are a security control, not just a networking convenience: they keep service traffic on the AWS network so an isolated subnet can use S3 or KMS with no internet path at all. Know both flavors. A gateway endpoint (S3 and DynamoDB only) is a route-table entry targeting a managed prefix list — free, highly available, but usable only from within that VPC. An interface endpoint (most other services, powered by AWS PrivateLink) is an ENI with a private IP in your subnet; you attach security groups to it, enable private DNS so the service's normal hostname resolves to the private IP, and it is reachable over peering, VPN, or Direct Connect — which is why a centralized shared-endpoints VPC is a common cost/design pattern.

The Specialty differentiator is the endpoint policy: a policy document attached to the endpoint that constrains what the endpoint can be used for. This is the data-perimeter angle. An S3 gateway endpoint policy can allow access only to your approved buckets, so a compromised instance cannot push data to an attacker-owned bucket through your own endpoint. At the organization level, the conditions to recognize are aws:PrincipalOrgID — only identities from your AWS Organization may use this endpoint — and aws:ResourceOrgID — the endpoint may only reach resources owned by your organization. Together they turn every endpoint into a checkpoint that keeps trusted identities talking to trusted resources over trusted networks.

PrivateLink also solves private service exposure: publish your service behind a Network Load Balancer as an endpoint service, and consumer VPCs connect via interface endpoints with no peering, no route coupling, and no CIDR overlap concerns — consumers see one ENI, not your network.

AWS Network Firewall is the managed layer 3–7 inspection engine for traffic SGs and NACLs cannot understand. It deploys as firewall endpoints in dedicated firewall subnets (one per AZ), and it inspects only what routing sends through it — route steering is the deployment. In the distributed model, each VPC gets its own firewall: workload subnets route 0.0.0.0/0 to the firewall endpoint, the firewall subnet routes onward to the NAT or internet gateway, and an ingress route table on the IGW steers return and inbound traffic back through the firewall so both directions are inspected. In the centralized model, a dedicated inspection VPC attached to a Transit Gateway inspects traffic for the whole organization — covered in the Transit Gateway section below.

Rules come in two engines. Stateless rule groups match 5-tuples with actions pass, drop, or forward to stateful — fast, no context, analogous to NACLs. Stateful rule groups are Suricata-compatible: they track connections and can match on protocol semantics, including the TLS SNI and HTTP Host header, which is what enables domain list rules — an allow list ("walled garden": permit .amazonaws.com and your approved SaaS domains, deny everything else) or a deny list of known-bad domains, applied to HTTP/HTTPS egress without decrypting traffic. You can also write raw Suricata rules for IPS-style signatures and use AWS managed rule groups for threat intelligence. Understand rule order: in the default action order, evaluation follows pass → drop → alert priorities; strict order evaluates rules exactly in the order you define, and a misordered broad pass rule sitting above a targeted drop is a classic "why is blocked traffic getting through" exam scenario.

Managing firewall policies across many accounts is AWS Firewall Manager's job — know it as the central deployment answer.

"Prevent workloads from sending data to arbitrary internet hosts" is one of the most repeatable scenario families in Domain 3, and NAT alone is not an answer — a NAT gateway grants outbound reach, it does not filter it. The layered egress design: private subnets route through NAT, with an AWS Network Firewall domain allow list in the path so only approved destinations (patch mirrors, package repos, your SaaS vendors) succeed and everything else is dropped and alerted on.

One layer up the stack sits Route 53 Resolver DNS Firewall, which filters at the resolution step: rule groups of allowed or blocked domain lists (including AWS managed threat lists) are associated with a VPC, and a query for a disallowed domain returns NXDOMAIN, an override, or is blocked before any packet ever leaves. It supports the same walled-garden pattern — allow your known-good domains, block * — and it is cheap and simple. Its limit is the flip side of its layer: it controls DNS resolution, not packets. Malware that connects to a raw IP, or that uses its own external DNS resolver, never asks the Resolver anything. That is why the strong design pairs them: DNS Firewall for broad, cheap domain policy plus visibility into query logs, and Network Firewall to block direct-to-IP egress and traffic to non-approved SNI values — and to block outbound port 53 to anything except the VPC resolver, closing the rogue-resolver hole.

A forward proxy fleet (explicit proxy with allow-listed URLs) is the third pattern to recognize at concept level: more control (full URL path filtering, authentication) at the cost of managing infrastructure and client configuration.

Most Task 3.3 questions reduce to "which control, at which layer, for this requirement." Anchor on what each control can see and what its unique capability is:

Two adjacent controls round out the picture at concept level. For hybrid connectivity, Site-to-Site VPN gives you IPsec encryption in transit over the internet; Direct Connect is a private circuit but is not encrypted by default — the exam answers are MACsec (layer 2 encryption on supported high-speed connections) or running a Site-to-Site VPN over the Direct Connect path. AWS Verified Access is the guide's named answer for VPN-less, identity- and posture-evaluated access from hybrid users to internal applications — per-request policy evaluation instead of network-level trust.

Transit Gateway is a security boundary because its route tables decide which attachments can reach which. Instead of the default single route table (full mesh), you create multiple TGW route tables and control two knobs per attachment: association (which table routes that attachment's outbound traffic) and propagation (which tables learn that attachment's CIDR). Segmentation pattern: production spokes associate with a route table that propagates only shared services and the inspection VPC — never each other — so two prod VPCs cannot talk laterally even though both hang off the same TGW.

Now walk the exam's favorite design: centralized egress and east-west inspection for an organization. Spoke VPCs in member accounts attach to the TGW (shared via AWS RAM). The spoke route table's only meaningful route is 0.0.0.0/0 → inspection VPC attachment. The inspection VPC contains firewall subnets holding Network Firewall endpoints and TGW attachment subnets; its VPC route tables steer arriving traffic into the firewall endpoints and, post-inspection, onward — back to the TGW for east-west flows, or out through a NAT/IGW in an egress VPC (or the inspection VPC itself) for north/south. A second TGW route table associated with the inspection VPC attachment propagates all spoke CIDRs so inspected traffic can return.

The detail the exam probes: enable appliance mode on the inspection VPC attachment. Without it, the TGW picks an AZ for each direction of a flow independently, so return traffic can arrive at a different firewall endpoint than the outbound path used — a stateful engine that never saw the SYN drops the reply. Appliance mode keeps both directions of a flow symmetric to the same AZ.

Troubleshooting questions give you a symptom and four plausible layers; win them with a method, not recall. Symptom: legitimate traffic broke after a segmentation change. Check in order: (1) Security group source type — a rule referencing an SG stops matching if traffic now arrives through a NAT or load balancer (source IP changes) or if instances moved to a group the rule does not reference; a CIDR rule breaks when subnets were renumbered. (2) NACL return traffic — a newly tightened NACL that forgot the ephemeral port range in the reverse direction produces the classic Flow Logs signature: inbound ACCEPT followed by outbound REJECT for the same flow. An SG block, being stateful, shows a single inbound REJECT and no accepted half. (3) Endpoint policy too strict — S3 calls failing with AccessDenied only from inside the VPC, while the same role works elsewhere, points at the endpoint policy (or an aws:ResourceOrgID condition and a legitimate third-party bucket). (4) Firewall rule order — in strict order, a drop placed above the intended pass wins.

Symptom: traffic is not being inspected. This is almost always routing, not rules: a workload subnet route table still pointing 0.0.0.0/0 at the NAT instead of the firewall endpoint, a missing IGW ingress route table so inbound replies skip the firewall, a spoke TGW attachment associated with the wrong TGW route table, or appliance mode disabled causing asymmetric drops that look like random timeouts.

Your visibility toolkit: VPC Flow Logs with custom fields (flow-direction, traffic-path, tcp-flags, pkt-dstaddr) to see where flows actually go; Reachability Analyzer to statically prove a path between two endpoints and name the blocking component without sending packets; and Traffic Mirroring when you genuinely need packet payloads for out-of-band analysis.