3 · Network & Infrastructure Security¶

Domain 1 — Design Secure Architectures · 30%

Two things dominate this topic on the exam: the Security Group vs Network ACL distinction (a near-guaranteed question), and the "which security service does what" service-matching questions (GuardDuty vs Inspector vs Macie vs Security Hub, WAF vs Shield). Nail those two and this topic is mostly done.

Core concept¶

Traffic into a workload passes through layers of controls, and the exam expects you to place each one:

Edge / Layer 7: CloudFront + AWS WAF filter malicious HTTP requests; Shield absorbs DDoS.
Subnet boundary: Network ACLs allow/deny by IP, port, protocol — stateless.
Instance / ENI: Security Groups allow traffic to the resource — stateful.
Detection (always-on, out of band): GuardDuty, Inspector, Macie, aggregated in Security Hub.

The first mental split to get right: Security Groups and NACLs are the two firewalls inside a VPC, and they behave differently.

Security Groups vs Network ACLs (the exam's favourite)¶

	Security Group	Network ACL (NACL)
Operates at	Instance / ENI level	Subnet level
State	Stateful — return traffic auto-allowed	Stateless — return traffic needs its own rule
Rules	Allow only (everything not allowed is implicitly denied)	*Allow and* Deny** rules
Evaluation	All rules evaluated together	Numbered order, lowest first; first match wins
Default	Denies all inbound, allows all outbound	Default NACL allows all; a custom NACL denies all until you add rules
Applies to	Whatever ENIs you attach it to	Automatically to all resources in its subnet

Two consequences that drive answers:

Because SGs are stateful, if you allow inbound port 443, the response goes back out automatically — you don't add an outbound rule for the reply.
Because NACLs are stateless, allowing inbound 443 is not enough; the response leaves from an ephemeral port (roughly 1024–65535), so you must also allow that outbound range — forgetting this is a classic "why is my connection hanging?" trap.

When do you actually reach for a NACL? Use it to explicitly deny something at the subnet edge — e.g. block a specific malicious IP or CIDR — because Security Groups can't express a deny. For "allow these instances to talk to those instances," use Security Groups (you can even reference one SG as the source in another).

The security-service zoo — match service to purpose¶

This table answers most "which service?" questions:

Service	One-line purpose	Trigger words
AWS WAF	Filter Layer-7 HTTP requests (SQLi, XSS, rate-limit, geo, IP sets)	"SQL injection", "XSS", "block by country/IP at the app", rate limiting
AWS Shield Standard	Automatic, free L3/L4 DDoS protection for everyone	"DDoS" (basic)
AWS Shield Advanced	Paid, enhanced DDoS + 24/7 response team + cost protection	"DDoS", "SLA", "reimburse scaling costs", "dedicated support during attack"
Amazon GuardDuty	Threat detection from CloudTrail, VPC Flow Logs, DNS logs (ML, agentless)	"detect", "malicious/anomalous activity", "compromised credentials", "crypto-mining"
Amazon Inspector	Automated vulnerability scanning of EC2, ECR images, Lambda (CVEs, reachability)	"vulnerabilities", "CVE", "patch/scan workloads"
Amazon Macie	Discover/classify sensitive data (PII) in S3	"PII", "sensitive data in S3"
AWS Security Hub	Aggregate findings + compliance checks across accounts	"single dashboard", "central view", "compliance standard (CIS/PCI)"
AWS Network Firewall	Managed stateful firewall for VPC traffic (deep filtering)	"filter VPC traffic", "IDS/IPS", "domain filtering"
AWS Firewall Manager	Centrally manage WAF/Shield/SG rules across an Organization	"enforce rules across all accounts"

Quick disambiguations the exam relies on:

Detection vs protection: GuardDuty detects threats; it doesn't block. WAF/Shield/NACL/SG block.
GuardDuty vs Inspector vs Macie: threats/anomalies (GuardDuty) vs software vulnerabilities (Inspector) vs sensitive-data discovery (Macie). Three different questions.
Security Hub aggregates; it doesn't itself find threats — it collects findings from GuardDuty, Inspector, Macie, etc. into one place.

Common patterns¶

Block a specific IP / CIDR reaching your subnet → NACL deny rule (SGs can't deny).
Block a country from a web app → AWS WAF geo-match rule, or CloudFront geo-restriction.
Stop SQL-injection / XSS on a public web app → AWS WAF (on ALB / CloudFront / API Gateway).
Large-scale DDoS with cost-spike protection and an SLA → Shield Advanced.
"Something is doing crypto-mining / talking to a known-bad IP — alert us" → GuardDuty.
Give private-subnet instances outbound internet without inbound exposure → NAT Gateway in a public subnet (managed, HA per-AZ) — note it bills hourly + per GB, a cost trap covered in the VPC lab and cost topics.
Reach AWS services (S3/DynamoDB) without traversing the internet → VPC endpoints (Gateway endpoints for S3/DynamoDB; Interface endpoints / PrivateLink for most others), which also lets you lock a bucket policy to a specific VPC endpoint.

Worked example — the hanging connection¶

You launch a web server in a public subnet. Its Security Group allows inbound TCP 443 from 0.0.0.0/0. You also attached a custom NACL to the subnet with a single inbound rule allowing TCP 443 from 0.0.0.0/0 and a single outbound rule allowing TCP 443 to 0.0.0.0/0. Clients can open the connection but pages never load.

What's wrong?

Answer

The NACL is stateless, so it evaluates the return traffic independently. The server's response to a client doesn't leave on port 443 — it leaves on the client's ephemeral port (≈ 1024–65535). Your outbound NACL rule only allows destination port 443, so the responses are blocked, and the connection hangs. Fix: add an outbound NACL rule allowing TCP 1024–65535 (the ephemeral range) to 0.0.0.0/0. The Security Group needed no such rule because it's stateful — this is exactly the SG-vs-NACL distinction the exam is testing.

Exam traps¶

SG = stateful & allow-only; NACL = stateless & allow/deny. Return traffic is automatic for SGs, manual (ephemeral ports) for NACLs.
To deny a specific IP, you need a NACL — Security Groups have no deny rule.
NACL rules are processed in number order, lowest first; the first match wins (put denies above broad allows).
A custom NACL denies everything until you add rules; the default NACL allows everything.
GuardDuty detects, it doesn't block; Security Hub aggregates, it doesn't detect.
Inspector = vulnerabilities/CVEs, Macie = PII in S3, GuardDuty = threats — don't swap them.
Shield Standard is automatic and free; you only "enable" (and pay for) Shield Advanced when you need the response team, SLA, and DDoS cost protection.
WAF is Layer 7 and attaches to CloudFront / ALB / API Gateway — not to raw EC2 or a subnet.

Practice questions¶

Q1. A subnet hosts several instances. The security team must block all traffic from one specific malicious IP address to everything in that subnet, while leaving other traffic unchanged. What should they use?

A. A Security Group inbound deny rule for that IP.
B. A Network ACL inbound deny rule for that IP on the subnet.
C. A route table entry blackholing the IP.
D. AWS Shield Standard.

Answer: B

B. Only NACLs support deny rules, and they apply at the subnet level to all resources — ideal for blocking one IP broadly. Security Groups (A) are allow-only and can't express a deny. Route tables (C) route by destination, not source, and don't filter security. Shield Standard (D) is automatic DDoS protection, not IP-level filtering.

Q2. After attaching a custom Network ACL, users can initiate connections to a web server but responses never arrive. The NACL allows inbound 443 and outbound 443. What is the most likely fix?

A. Add an inbound rule for port 80.
B. Add an outbound rule allowing the ephemeral port range (1024–65535).
C. Make the Security Group stateless.
D. Remove the NACL entirely.

Answer: B

B. NACLs are stateless; responses leave from the client's ephemeral port, so you must allow outbound 1024–65535. Port 80 (A) is unrelated. Security Groups can't be made stateless (C). Removing the NACL (D) might "work" but abandons the subnet-level control rather than fixing it.

Q3. A company needs to be alerted when AWS credentials appear compromised or when instances communicate with known-malicious IPs — using existing logs, with no agents to install. Which service?

A. Amazon Inspector
B. Amazon Macie
C. Amazon GuardDuty
D. AWS Config

Answer: C

C. GuardDuty is agentless threat detection that analyzes CloudTrail, VPC Flow Logs, and DNS logs with ML to flag compromised credentials, malicious IP communication, crypto-mining, etc. Inspector scans for software vulnerabilities; Macie finds PII in S3; Config tracks resource configuration/compliance, not active threats.

Q4. A public web application behind an Application Load Balancer must block SQL injection attempts and limit requests from any single IP to a rate threshold. What should be implemented?

A. AWS Shield Advanced
B. AWS WAF with a SQL-injection managed rule and a rate-based rule, associated with the ALB
C. A Network ACL on the ALB's subnet
D. Security Group rules on the ALB

Answer: B

B. AWS WAF inspects Layer-7 requests and offers SQL-injection managed rules plus rate-based rules, and it associates with the ALB. Shield (A) addresses DDoS, not SQLi. NACLs (C) and Security Groups (D) filter by IP/port/protocol and can't inspect request content or rate-limit by pattern.

Q5. A security team wants a single dashboard that aggregates findings from GuardDuty, Inspector, and Macie across many AWS accounts and checks them against the CIS benchmark. Which service?

A. AWS Security Hub
B. Amazon Detective
C. AWS CloudTrail
D. Amazon GuardDuty

Answer: A

A. Security Hub aggregates findings from other security services across accounts and runs compliance standards like CIS — the central posture dashboard. Detective (B) is for deep root-cause investigation of specific findings; CloudTrail (C) records API calls; GuardDuty (D) is one of the sources Security Hub aggregates, not the aggregator.

Next: 4 · High Availability & Fault Tolerance → · Revise — Network Security