14. Networking and Content Delivery

Networking services form the foundation of secure, high-performance connectivity and global traffic management.

AWS Client VPN

Service Introduction: A managed client-based VPN service that enables users to securely access AWS and on-premises resources from any location.

Common Usage: Providing secure remote access for employees to private VPC resources using an OpenVPN client.

Project Examples:

• Allowing a development team to securely access internal staging servers from home.
• Implementing multi-factor authentication (MFA) for remote administrative access.

Amazon CloudFront

Service Introduction: A global Content Delivery Network (CDN) that delivers data, videos, and APIs to users with low latency and high transfer speeds.

Common Usage: Caching static and dynamic content at edge locations to improve performance for global users. Key Sub-Features (exam-critical):

• Origin Access Control (OAC) — Restricts an S3 origin so it can only be reached through CloudFront, not accessed directly via its S3 URL. This is the standard answer for "prevent users from linking directly to assets in the bucket" (OAC is the modern replacement for the older OAI).
• Protocol scope: HTTP/HTTPS only — CloudFront cannot accelerate UDP traffic (e.g., gaming, VoIP, live streaming protocols); for UDP acceleration, the answer is AWS Global Accelerator instead.

Four related-but-different concepts, explained individually (easy to blur together on the exam):

• Origin Access Control (OAC), in depth — A CloudFront-side identity you attach to a distribution. When enabled, CloudFront signs every request it sends to the S3 origin with this identity. You then write an S3 bucket policy that only allows s3:GetObject when the request comes from that specific distribution's OAC (scoped by the distribution's ARN via a condition). The result: the bucket is otherwise fully private, CloudFront can still fetch objects to serve/cache them, and anyone hitting the raw https://bucket.s3.amazonaws.com/... URL directly gets Access Denied. This is a bucket-policy-level, per-distribution access control — it doesn't touch DNS, security groups, or account-wide public-access settings at all.
• S3 Block Public Access (BPA), in depth — An account-wide or bucket-level safety switch, not a fine-grained access-control tool. It has four independent settings (block new public ACLs, block new public bucket policies, ignore existing public ACLs, restrict public bucket policies) that, when enabled, override and neutralize any attempt to make the bucket or its objects public — even a mistakenly permissive bucket policy. It answers "make sure nothing in this bucket is ever public," not "let only CloudFront through." Turning BPA fully on can actually break a CloudFront setup if OAC hasn't been configured to grant CloudFront's own access, since BPA doesn't know to special-case CloudFront.
• Route 53 Alias records, in depth — A Route 53–specific DNS record type (not a standard DNS record like CNAME) that maps a domain name directly to an AWS resource — a CloudFront distribution, an ALB, an S3 static website endpoint, another Route 53 record, etc. — instead of to an IP address. Unlike CNAME, an Alias record can be used at the zone apex (e.g., example.com, not just www.example.com), and lookups are free with no extra charge. It's purely a routing/DNS mechanism: it tells browsers where to send a request, but has zero say over whether that request is allowed to reach the origin once it arrives — that's what OAC or a bucket policy would decide, not the Alias record.
• Security Group Referencing, in depth — The practice, when writing a Security Group rule, of setting the source/destination to another Security Group's ID (e.g., "allow inbound 443 from sg-0abc123") instead of a CIDR block or IP. This lets the rule automatically track a dynamic fleet — any instance/ENI currently associated with that referenced group is allowed, even as instances in an Auto Scaling group launch and terminate with new IPs. It's the standard least-privilege pattern between VPC-resident resources (e.g., ALB → EC2, EC2 → RDS). Critically, Security Groups only attach to VPC-level resources with an ENI (EC2, RDS, Lambda-in-VPC, ALB, etc.) — Amazon S3 is a regional, non-VPC service with no ENI, so there is no security group to reference in the first place, which is why this concept can't apply to securing an S3 origin at all.

Exam Example (SAA-C03 pattern): "A company wants to prevent users from accessing their S3-hosted images directly via S3 URLs, mandating that all traffic must go through an Amazon CloudFront distribution. Which feature should be used to secure the S3 origin?" Answer choices: Route 53 Alias records / Origin Access Control (OAC) / S3 Block Public Access / Security Group Referencing.

• Correct Answer: Origin Access Control (OAC) — Ties the S3 bucket policy to the specific CloudFront distribution's identity, so only that distribution can fetch objects; direct S3 URL access is denied.
• Why not S3 Block Public Access? — On its own it just blocks all public access (including via CloudFront, unless paired with OAC granting the distribution explicit access) — it doesn't selectively allow CloudFront through while blocking direct URLs.
• Why not Route 53 Alias records? — Alias records point a DNS name at an AWS resource (e.g., a CloudFront distribution or ALB); they route traffic, but don't restrict who can reach the underlying S3 origin.
• Why not Security Group Referencing? — Security Groups apply to EC2/ENI-level resources in a VPC; S3 is not inside a VPC and has no security group to attach, so this doesn't apply here.

Project Examples:

• Accelerating the delivery of a static website hosted on an S3 bucket.
• Distributing high-definition video content globally for a streaming platform.

AWS Direct Connect

Service Introduction: A cloud service that establishes a dedicated, private network connection from your premises to AWS.

Common Usage: Providing consistent, high-bandwidth connectivity and reduced egress costs compared to internet-based VPNs. Resiliency Models (exam-critical): A single DX connection is a single point of failure. True high resiliency requires DX connections at multiple DX locations (not just multiple virtual interfaces on the same connection, and not just picking a "reliable" partner). A Site-to-Site VPN can also be layered on top of DX as a lower-cost, lower-bandwidth backup path.

Project Examples:

• Establishing a 10 Gbps private link for high-volume database synchronization.
• Implementing a private VIF (Virtual Interface) for secure access to VPC subnets.

Elastic Load Balancing (ELB)

Service Introduction: Automatically distributes incoming application traffic across multiple targets (EC2, Containers, Lambdas) in one or more Availability Zones.

Common Usage: Ensuring high availability (HA) and fault tolerance; includes Application Load Balancer (ALB) for L7 and Network Load Balancer (NLB) for L4.

The Four Load Balancer Types (exam-critical — pick by OSI layer and purpose):

• Application Load Balancer (ALB) — Layer 7 (HTTP/HTTPS/WebSocket/gRPC). Routes based on request content: path (/api/* vs /images/*), host header (multiple domains on one ALB), HTTP method, or query string/headers. Natively integrates with Cognito/OIDC for authentication, supports AWS WAF, and can return fixed responses or redirects without hitting a target at all. Targets: EC2, IP addresses, Lambda functions, ECS containers. Default choice for web applications and microservices where routing decisions depend on the content of the request.
• Network Load Balancer (NLB) — Layer 4 (TCP/UDP/TLS). Just forwards connections — no awareness of HTTP. Built for extreme performance: millions of requests/second with ultra-low latency and near-instant scaling to handle traffic spikes (ALB scales too, but takes longer to "warm up" under a sudden burst). Preserves the client's source IP by default (ALB does this too, but via the X-Forwarded-For header rather than the actual packet source). The only ELB type that supports a static IP per AZ (or an Elastic IP), which is why it's the standard answer whenever a question needs a fixed IP address for a load balancer (e.g., allowlisting by IP, or exposing a service via AWS PrivateLink — an NLB is required as the target of a VPC Endpoint Service, ALB is not supported for that role). Targets: EC2, IP addresses, ALB (the NLB-in-front-of-ALB pattern), Lambda.
• Gateway Load Balancer (GLB) — Layer 3 (raw IP packets, using the GENEVE protocol on port 6081). Not for balancing application traffic at all — it's for transparently inserting third-party virtual appliances (firewalls, IDS/IPS, deep-packet-inspection tools) into the traffic path so all traffic can be centrally inspected before reaching its destination, without the appliance vendor needing custom integration work. Traffic passes through unmodified. Targets: EC2 instances running the virtual appliance software. This is the one type candidates most often confuse with the others because "Gateway" sounds like a routing concept, not a load-balancing one — but on the exam, any scenario about centralizing security appliance traffic inspection at scale points to GLB.
• Classic Load Balancer (CLB) — Legacy, previous-generation load balancer from the EC2-Classic era. Operates at basic Layer 4 and Layer 7 but lacks ALB's content-based routing and NLB's performance/static-IP features. Targets: EC2 instances only. AWS does not recommend CLB for any new workload — on the exam, if CLB appears as an answer choice for a new architecture, it's almost always the wrong one; it only makes sense for maintaining an already-existing legacy deployment.

Load Balancer	OSI Layer	Routing Basis	Static IP	Preserves Client IP	Typical Use Case
ALB	7 (HTTP/HTTPS)	Path, host, header, method	No	Via X-Forwarded-For	Web apps, microservices, content-based routing
NLB	4 (TCP/UDP/TLS)	Connection-level, no content awareness	Yes (per AZ)	Yes (native)	Extreme performance, gaming, fixed-IP/PrivateLink needs
GLB	3 (raw IP, GENEVE)	N/A — transparent pass-through	No	Yes (unmodified)	Centralized firewall/IDS/IPS traffic inspection
CLB	4 & basic 7	Limited	No	No	Legacy workloads only — not for new designs

Exam Example (SAA-C03 pattern): "A company needs to expose an internal service to other VPCs and AWS accounts via a VPC Endpoint Service (AWS PrivateLink), and also requires a fixed IP address for firewall allowlisting on the consumer side. Which load balancer should front the service?" Answer choices: Application Load Balancer / Network Load Balancer / Gateway Load Balancer / Classic Load Balancer.

• Correct Answer: Network Load Balancer — NLB is the only load balancer type that a VPC Endpoint Service can be created behind, and it's the only ELB type offering a static IP per AZ, satisfying both requirements at once.
• Why not ALB? — Not supported as the target of a VPC Endpoint Service, and doesn't offer a static IP.
• Why not GLB? — GLB is for inserting third-party inspection appliances into a traffic path, not for exposing a service to other VPCs via PrivateLink.
• Why not CLB? — Legacy, doesn't support PrivateLink integration or static IPs, and isn't recommended for new architectures.

Common Real-World Pattern (exam-relevant): NLB in front of ALB — Since NLB gives a static IP (and is required for PrivateLink) while ALB gives content-based routing, architectures that need both — a fixed entry point plus intelligent Layer 7 routing — chain them: Client → NLB (static IP / PrivateLink) → ALB (path/host routing) → EC2/ECS/Lambda targets. Recognize this pattern when a question mentions both a fixed-IP requirement and path-based routing in the same scenario.

Project Examples:

• Distributing HTTP traffic across an Auto Scaling group of web servers using ALB path-based routing.
• Handling millions of requests per second for a high-performance gaming backend using NLB.
• Deploying a fleet of third-party firewall appliances behind a Gateway Load Balancer to inspect all inbound VPC traffic.

AWS Global Accelerator

Service Introduction: A networking service that improves the availability and performance of applications using the AWS global network and static IP addresses.

Common Usage: Routing traffic to the nearest regional endpoint to reduce latency and provide rapid failover for multi-region architectures. Global Accelerator vs. CloudFront (exam-critical distinction):

• Global Accelerator supports both TCP and UDP, operates at Layer 4, uses 2 static anycast IPs, and is the correct answer for non-HTTP protocols (gaming, VoIP, IoT) needing global performance/failover.
• CloudFront is HTTP/HTTPS-only (Layer 7) and adds caching — the right choice for web content instead.

Project Examples:

• Providing two static anycast IPs for a global multi-region application.
• Reducing latency for a VoIP application by routing traffic over the AWS backbone.

AWS PrivateLink

Service Introduction: Provides private connectivity between VPCs, AWS services, and on-premises applications without exposing traffic to the public internet.

Common Usage: Securing traffic between service consumers and providers by using interface VPC endpoints. VPC Endpoint Types (exam-critical):

• Gateway endpoints — Free; only for Amazon S3 and DynamoDB. Added as a target in the route table, not an ENI.
• Interface endpoints (PrivateLink) — Hourly + data charge; an ENI with a private IP in your subnet. Used for most other AWS services (SNS, SQS, Kinesis, Secrets Manager, etc.) and for privately exposing your own service to other VPCs/accounts via a VPC Endpoint Service.

Project Examples:

• Accessing Amazon S3 or Kinesis securely from a private subnet without an Internet Gateway.
• Sharing a centralized security service with hundreds of customer VPCs privately.

Amazon Route 53

Service Introduction: A highly available and scalable cloud Domain Name System (DNS) service with health checking and domain registration.

Common Usage: Managing public and private DNS records; supports advanced routing policies. Routing Policies (exam-critical):

• Simple — Single resource, no health checks, no special logic.
• Weighted — Split traffic across resources by assigned weight (e.g., canary/blue-green deployments).
• Latency-based — Routes to the Region with the lowest measured latency for the user.
• Failover — Active-passive; routes to a standby resource when the primary fails its health check.
• Geolocation — Routes based on the user's geographic location (country/continent); supports content restriction/compliance use cases.
• Geoproximity (via traffic flow) — Routes based on geographic distance, with an optional "bias" to shift more/less traffic to a region.
• Multivalue Answer — Returns up to 8 healthy records at random; a lightweight, DNS-level alternative to a load balancer.
• IP-based — Routes based on the client's IP address ranges (e.g., to route an ISP's users to a specific endpoint).

Route 53 Resolver / Hybrid DNS Components (exam-critical): Four distinct components handle connectivity and name resolution between VPCs and on-premises environments — easy to mix up because two of them are about DNS in opposite directions:

• VPC Peering — A traffic-routing connection between two VPCs using private IPs; not DNS-related at all. Requires manual route table entries on both sides, and does not support transitive routing (A↔B and B↔C doesn't give you A↔C).
• Private Hosted Zone (PHZ) — Holds DNS records for a domain resolved only within specified VPCs (e.g., internal.example.com), keeping internal names off the public internet. Requires enableDnsSupport and enableDnsHostnames on the associated VPC.
• Inbound Endpoint — Lets DNS queries from on-premises (or another VPC) reach Route 53 to resolve AWS-hosted names (e.g., a PHZ record). Direction: on-premises → AWS. Point your on-prem resolvers at this endpoint's IP.
• Outbound Endpoint — Lets Route 53 conditionally forward queries from inside your VPC out to an on-premises DNS resolver, via forwarding rules (e.g., "queries for onprem.corp.com go to on-prem DNS server X.X.X.X"). Direction: AWS → on-premises.

Component	Function	Layer	Primary Direction
VPC Peering	Connects VPCs for traffic routing.	Network	Bidirectional (VPC ↔ VPC)
Private Hosted Zone	Stores internal DNS records for VPCs.	DNS	Internal to AWS
Inbound Endpoint	Accepts DNS queries from outside AWS.	DNS	On-premises → AWS
Outbound Endpoint	Sends DNS queries to outside AWS.	DNS	AWS → On-premises

Decision rule: "on-prem needs to resolve an AWS name" → Inbound Endpoint. "AWS needs to resolve an on-prem name" → Outbound Endpoint. Neither involves VPC Peering or a PHZ directly, though a PHZ is often what the Inbound Endpoint is exposing.

Project Examples:

• Implementing a disaster recovery failover that redirects traffic to a standby region.
• Routing global users to the closest AWS region based on latency.

AWS Site-to-Site VPN

Service Introduction: Creates a secure IPsec tunnel between your on-premises network and your VPC over the public internet.

Common Usage: Quickly establishing encrypted connectivity between a corporate data center and the AWS Cloud.

Project Examples:

• Connecting a corporate office to a VPC for internal application access.
• Implementing a cost-effective backup for an AWS Direct Connect link.

AWS Transit Gateway

Service Introduction: A network transit hub that connects VPCs and on-premises networks through a central gateway.

Common Usage: Simplifying complex networking by replacing multiple VPC peering connections with a single hub-and-spoke architecture.

Project Examples:

• Connecting 50 different VPCs and three on-premises sites together centrally.
• Implementing centralized egress filtering through a single inspection VPC.

Amazon VPC

Service Introduction: A logically isolated section of the AWS Cloud where you can launch resources in a virtual network you define.

Common Usage: The foundational network layer; allows full control over IP address ranges, subnets, route tables, and network gateways. NAT Gateway (exam-critical, heavily tested): Lets resources in a private subnet initiate outbound traffic to the internet (e.g., to call external APIs, download patches) while remaining unreachable from the internet — the opposite of an Internet Gateway, which is for subnets that need inbound+outbound public access. Key facts:

• NAT Gateway is AZ-scoped — for each AZ to keep working independently if another AZ fails, deploy one NAT Gateway per AZ (a single shared NAT Gateway is a cross-AZ single point of failure).

• Billed per-hour plus per-GB data processed — this processing charge is what shows up unexpectedly on Cost Explorer for high-throughput workloads (e.g., EMR reading S3 through a NAT Gateway). Fix: route S3/DynamoDB traffic through a free Gateway VPC endpoint instead of the NAT Gateway.

• NAT Instance (self-managed EC2) is the legacy, cheaper-but-more-operational-overhead alternative — rarely the "best" answer on the exam. Security Groups vs. Network ACLs (exam-critical distinction):

• Security Groups — Operate at the instance/ENI level; stateful (return traffic is automatically allowed); support Allow rules only; evaluate all rules before deciding. For least-privilege between tiers, reference another security group's ID as the source/destination (not CIDR ranges) — that way the rule stays correct even as instances scale in/out.

  Stateful Behavior (exam-critical): Security groups are stateful, which means they automatically allow return traffic for any established connection that was permitted by an inbound rule. This is crucial: you only need to define an inbound rule to allow traffic on port 443 (HTTPS), and the security group will automatically permit the return traffic without requiring an explicit outbound rule. This is the key differentiator from Network ACLs.

  Exam Example: A question might state: "A company requires that inbound traffic to its web servers on port 443 be allowed, while all other inbound traffic must be blocked. The solution must also ensure that return traffic for established connections is permitted without additional configuration. Which tool is best suited for this?" Answer: Security Groups — because their stateful nature automatically allows return traffic without additional configuration.

  Exam Example (ALB → EC2 least privilege, easy to get wrong): "An application is hosted on EC2 instances in an Auto Scaling group behind an Application Load Balancer. The security group on the EC2 instances should be configured to follow the principle of least privilege. What should the source of the inbound rule be for the application port?" Answer choices: the Security Group ID of the ALB / the CIDR block of the public subnet / the IP address of the Internet Gateway / a source of 0.0.0.0/0 on the application port.

  • Correct Answer: The Security Group ID of the Application Load Balancer. Referencing the ALB's security group as the source (instead of a CIDR range or IP) means only traffic that has actually passed through the ALB can reach the instances, and the rule stays correct automatically as instances in the ASG scale in/out and get new IPs.
  • Why not the subnet's CIDR block? — Broader than necessary; would allow anything else launched in that subnet to reach the instances directly, bypassing the ALB.
  • Why not the Internet Gateway's IP? — An Internet Gateway doesn't have a fixed source IP that traffic to your instances originates from; this isn't how IGW traffic works.
  • Why not 0.0.0.0/0? — The opposite of least privilege: it opens the application port to the entire internet and lets traffic bypass the ALB entirely, defeating the purpose of putting a load balancer in front of the instances in the first place.

• Network ACLs (NACLs) — Operate at the subnet level; stateless (return traffic must be explicitly allowed by a separate rule); support both Allow and Deny rules; evaluated in rule-number order, first match wins. Use NACLs for coarse subnet-wide blocking (e.g., explicitly denying a malicious IP range); use Security Groups for granular, least-privilege access control between tiers. Elastic IP Addresses (exam-critical for cost questions): A static public IPv4 address you own. It is free only while attached to a running instance; an Elastic IP that is unattached, or attached to a stopped instance, incurs an hourly charge — a common "why didn't my costs drop to zero" gotcha after stopping an EC2 fleet.

Cross-AZ Data Transfer Charges (exam-critical cost pattern): Traffic between instances in different AZs within the same Region incurs a per-GB data transfer charge in both directions — even though it stays entirely inside one VPC and never touches the internet. This is a common cause of unexpected "Data Transfer Out" charges for chatty, frequently-communicating instances. It has nothing to do with Internet Gateways (only relevant for public internet traffic), Elastic IPs (charged only when unattached/on a stopped instance), or VPC Peering (connects separate VPCs, doesn't affect intra-VPC AZ charges). Traffic between instances in the same AZ is free; the fix for high cross-AZ chatter is usually to co-locate tightly-coupled instances in the same AZ where availability requirements allow it.

Project Examples:

• Designing a secure 3-tier network with public, private, and database subnets.
• Connecting multiple VPCs together using peering for cross-application communication (remember: peering also requires route table entries on both sides — the connection alone doesn't route traffic).

14.1 VPC Traffic Control Layers (Exam-Critical Understanding)

Understanding how Route Tables, NACLs, Security Groups, and Internet Gateways work together is essential for SAA-C03. Each component serves a different purpose in controlling traffic flow:

Route Tables (Path Determination, NOT Filtering)

• Purpose: Route Tables control the path of traffic between subnets and gateways. They determine WHERE traffic goes based on destination IP address ranges.
• What They DON'T Do: Route Tables do NOT provide granular filtering of traffic based on port numbers, protocols, or application-level rules. They only route based on CIDR blocks.
• Key Detail: For traffic to leave a subnet via an Internet Gateway, there must be a route table entry pointing to the IGW as the target for 0.0.0.0/0 (all internet traffic).
• Exam Tip: When a question asks "how do we allow outbound traffic to the internet?" you need BOTH a route table entry AND an Internet Gateway — a route table alone just determines the path, it doesn't filter or allow.

NACLs (Stateless Filtering at Subnet Level)

• Stateless Nature (exam-critical): NACLs are stateless, meaning they require explicit rules for both inbound AND outbound traffic to allow complete two-way communication. If you allow inbound traffic on port 443, you must also explicitly allow outbound traffic on the corresponding ephemeral ports (1024-65535) for the response to return.
• Example: Allowing HTTPS traffic (inbound on 443) requires:
  • Inbound Rule: Allow port 443 from source CIDR
  • Outbound Rule: Allow ephemeral ports (1024-65535) to the source CIDR for responses
• Ordering Matters: Rules are evaluated in rule-number order, and the first match wins. Rule 100 allow HTTP, Rule 110 deny all = HTTP is allowed; but Rule 110 deny all, Rule 100 allow HTTP = all traffic is denied.
• Common Distractors (exam-critical): Evaluation is not simultaneous with "Deny wins" (that's not how NACLs work — order matters, not rule type), and it is not based on protocol (TCP vs. UDP order is irrelevant) — it is purely sequential by rule number, stopping at the first match.
• Use Case: Best for blocking malicious IP ranges or applying subnet-wide traffic policies, not for granular application-level access control.

Security Groups (Stateful Filtering at Instance Level)

• Stateful Nature: Unlike NACLs, Security Groups automatically allow return traffic without needing explicit outbound rules. Define inbound on port 443 → return traffic is automatically permitted.
• Granularity: Operates at the instance/ENI level, allowing you to reference other security group IDs as sources (not just CIDR ranges).
• Exam Pattern: When a question says "ensure return traffic is permitted without additional configuration," the answer is Security Groups due to their stateful nature.

Internet Gateway (Target for Internet Traffic, NOT Filtering)

• Purpose: An Internet Gateway provides a target in your route table for internet-bound traffic. It enables the VPC-to-internet connection.
• What It DOESN'T Do: An Internet Gateway does NOT filter traffic based on security rules or application ports. It doesn't care what's in the packet — it's purely a routing target.
• Required for: Public subnets that need inbound+outbound internet access. Private subnets use NAT Gateways instead.
• Exam Tip: IGW is necessary but not sufficient for allowing internet traffic — you also need:
  • A route table entry pointing to the IGW
  • Security group rules allowing the specific ports/protocols
  • NACL rules (if using restrictive NACLs) for inbound/outbound

Layering Example: Allow HTTPS to a Web Server

To allow inbound HTTPS (443) to an EC2 instance in a public subnet:

1. Route Table: Add route 0.0.0.0/0 → Internet Gateway (determines traffic goes to IGW)
2. NACL: Inbound allow port 443; Outbound allow ephemeral ports (stateless filtering)
3. Security Group: Inbound allow port 443 (stateful; return traffic auto-allowed)
4. Internet Gateway: Already attached to VPC (provides the connection point)

Without any one of these, HTTPS traffic will be blocked or dropped.

14.1.1 Security Groups vs. NACLs — Scenario Drills (the exam's favorite trap)

The exam almost never asks "define a Security Group." It asks a scenario and expects you to pick the right tool based on scope (instance vs. subnet), statefulness (auto-return-traffic vs. not), and rule type (allow-only vs. allow+deny). Below are the recurring "roles" these questions dress up as, each with the tell that gives away the answer.

The one-line decision rule: Need to explicitly DENY something, or block traffic before it reaches any instance in a subnet? → NACL. Everything else — normal least-privilege access control per resource — → Security Group. Security Groups can't deny; if a question's scenario requires blocking a specific bad actor while leaving everything else alone, NACLs are the only tool with a deny rule at all.

Scenario 1 — "Block this one malicious IP address immediately, across the whole subnet." A security team has identified 203.0.113.55 as the source of a credential-stuffing attack against every EC2 instance in a subnet, and wants it blocked network-wide right now.

• Correct Answer: Network ACL, explicit Deny rule with a low rule number (evaluated before any Allow rules further down).
• Why not Security Groups? — Security Groups only support Allow rules; there is no way to explicitly deny a single IP with a Security Group. You'd have to remove or never grant access, which doesn't help when the SG is already open more broadly (e.g., 0.0.0.0/0 on port 443 for a public web tier).
• The tell: the word "block" or "deny" paired with a specific bad IP + "across the subnet" → NACL.

Scenario 2 — "The web tier should only accept traffic that already passed through the ALB, and this must self-adjust as instances scale in/out."

• Correct Answer: Security Group on the EC2 instances, with the source set to the ALB's Security Group ID (not a CIDR range).
• Why not NACLs? — NACLs are CIDR-block based; they have no concept of "traffic that came from this other resource's identity." Referencing a security group ID is a Security-Group-only capability, and it's what makes the rule stay correct automatically as the Auto Scaling group launches/terminates instances with new IPs.
• The tell: "reference another resource," "self-adjusting," "least privilege between tiers" → Security Group (SG-to-SG reference).

Scenario 3 — "Ensure return traffic for an established connection is automatically permitted, without configuring anything extra."

• Correct Answer: Security Group — because Security Groups are stateful: an inbound Allow on port 443 automatically permits the matching outbound response, no separate outbound rule needed.
• Why not NACLs? — NACLs are stateless. Allowing inbound 443 requires you to also explicitly add an outbound rule permitting the ephemeral response ports (1024–65535); forgetting this is a classic "why can clients connect but never get a response" bug.
• The tell: "automatically," "without additional configuration," "established connections" → Security Group (statefulness is the differentiator).

Scenario 4 — "A compliance requirement says HTTP (port 80) must be denied even though a broader Allow rule exists further down the list — and the fix must apply instantly to an entire subnet without touching every instance's configuration."

• Correct Answer: NACL, with a low-numbered Deny rule for port 80 placed before the broader Allow rule.
• Why not Security Groups? — Same reasoning as Scenario 1: no deny capability, and SGs are per-instance/ENI, so you'd have to edit every instance's SG rather than applying one subnet-wide control.
• The tell: "regardless of other rules," "deny takes precedence," "rule order/priority" language, or "apply to the whole subnet at once" → NACL (first-match-wins by rule number, and it's the only layer with Deny).

Scenario 5 — "Instances in a private database subnet should only accept traffic on port 3306 from the application tier's security group — and nothing else, including other resources that might later be placed in the same subnet."

• Correct Answer: Security Group on the RDS/EC2 database resources, source = application tier's SG ID.
• Why is this NOT a NACL scenario even though it mentions "the same subnet"? — The requirement is about which specific resource is allowed in (the app tier, identified by its SG), not about blocking a CIDR range or an entire subnet's traffic pattern. Whenever the granularity needed is "this specific other AWS resource" rather than "this IP range," it's a Security Group question — NACLs can't reference other resources by ID at all, only CIDR blocks.
• The tell: the restriction is expressed in terms of which resource is allowed (not which IP range is blocked) → Security Group.

Quick-reference table:

If the scenario says…	Use
"block / deny a specific IP or CIDR range"	NACL
"return traffic automatically allowed, no extra config"	Security Group
"reference another resource's security group as the source"	Security Group
"rule order matters" / "first rule that matches wins" / "explicit deny overrides allow"	NACL
"applies to every instance in the subnet at once, including future ones"	NACL
"least privilege between application tiers" (ALB→EC2, EC2→RDS)	Security Group
Anything requiring both inbound and outbound rules to be configured separately for one flow	NACL (stateless)

14.2 AWS Gateways Overview (Domain 1 & 4 Critical)

Understanding the various gateways in AWS is critical for Domain 1 (Secure Architectures) and Domain 4 (Cost-Optimization), as they serve as the primary entry and exit points for your network traffic.

1. Internet Gateway (IGW)

• What it is: A horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet.
• When to use it: Use this to make a subnet public. It provides a target in your route table for internet-bound traffic.
• Key Detail: For an instance to use an IGW, it must have a public IP address or an Elastic IP.

2. NAT Gateway

• What it is: A managed service that allows instances in a private subnet to connect to the internet (e.g., for software updates) but prevents the internet from initiating a connection with them.
• High Availability: It is AZ-scoped; for high availability, you should deploy one NAT Gateway in each Availability Zone to avoid a single point of failure.
• Cost: Unlike the Internet Gateway, NAT Gateways incur a per-hour charge plus a per-GB data processing fee.

3. API Gateway

• What it is: A fully managed service for creating, publishing, maintaining, and securing APIs at any scale.
• When to use it: Acts as the "front door" for applications to access data or business logic from backend services like AWS Lambda, Amazon ECS, or on-premises systems.
• Types: Supports RESTful APIs (stateless) and WebSocket APIs (stateful, full-duplex communication).

4. AWS Transit Gateway

• What it is: A network transit hub used to interconnect virtual private clouds (VPCs) and on-premises networks through a central point.
• When to use it: Best for large-scale architectures (e.g., 50+ accounts) to replace complex VPC peering with a simpler hub-and-spoke model.
• Benefit: It simplifies network topology and supports transitive routing between all connected private subnets.

5. VPC Endpoints (Gateway vs. Interface)

VPC Endpoints allow you to connect your VPC to AWS services privately without needing an Internet Gateway or NAT Gateway.

• Gateway Endpoints:
  • Services: Available only for Amazon S3 and Amazon DynamoDB.
  • Placement: Added as a target in your route table.
  • Cost: FREE; no hourly or data processing charges.
• Interface Endpoints (AWS PrivateLink):
  • Services: Used for most other AWS services (SQS, SNS, Kinesis, etc.) and your own services.
  • Placement: Uses an Elastic Network Interface (ENI) with a private IP address in your subnet.
  • Cost: Incurs an hourly charge plus data processing fees.

6. VPN and Hybrid Gateways

• Customer Gateway (CGW): A physical device or software application on your on-premises side of a Site-to-Site VPN connection.
• Virtual Private Gateway (VGW): The VPN concentrator on the Amazon side that is attached to your VPC.
• Direct Connect Gateway: Used to connect a Direct Connect location to one or more VPCs in different Regions.

7. Specialized Gateways

• AWS Storage Gateway: A hybrid service giving on-premises applications access to virtually unlimited cloud storage. It comes in three variants: File Gateway (NFS/SMB to S3/EFS), Volume Gateway (iSCSI block storage), and Tape Gateway (Virtual Tape Library).
• Gateway Load Balancer (GWLB): Used to deploy and scale third-party virtual appliances (like firewalls or IDS/IPS) by acting as a single entry/exit point for all traffic that needs inspection.

Exam Summary: Choosing the Right Gateway

If the question asks for the most cost-effective way for private instances to reach S3, always choose the S3 Gateway Endpoint (it is free) over a NAT Gateway. For connecting hundreds of VPCs, choose Transit Gateway.