AWS SAA-C03: Networking & Connectivity — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #networking #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

VPC Design and CIDR Planning

Every VPC begins with a CIDR block, and the choice made at creation time has downstream consequences for peering, Transit Gateway attachments, and hybrid connectivity. The primary CIDR must be between /16 and /28, chosen from RFC 1918 space, and it must not overlap with any network you intend to peer with, route through a Transit Gateway, or reach over Direct Connect or VPN. Overlapping CIDRs are the single most common cause of broken hybrid designs because AWS cannot route between two networks sharing address space — Transit Gateway will accept the attachment but propagation will fail or silently blackhole traffic.

When a VPC runs out of address space, you do not need to rebuild it. Up to four secondary IPv4 CIDR blocks can be attached (and additional ranges from a broader pool for a default total of five, extensible via quota increase). Secondary blocks can come from the same RFC 1918 range or from 100.64.0.0/10 shared address space, which is useful when 10.0.0.0/8 has been exhausted or when carrier-grade NAT space is needed. Secondary CIDRs let you carve new subnets for expansion — EKS pod networking, a new tier — without renumbering existing workloads.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

A robust design reserves a /17 or /18 for future growth, aligns subnet boundaries with Availability Zones (a /20 per AZ per tier is a common pattern), and leaves headroom for the ENIs consumed by interface endpoints, NAT gateways, and load balancers.

A VPC is a regional construct partitioned into subnets each bound to a single AZ. The distinction between “public” and “private” is purely a routing decision: a public subnet has a route 0.0.0.0/0 → igw-xxxx pointing at an Internet Gateway, while a private subnet either has no default route or points 0.0.0.0/0 at a NAT device. Instances in a public subnet also need a public or Elastic IP to be reachable inbound; the IGW performs 1:1 NAT between the private and public IP.

NAT Gateways, NAT Instances, and IPv6 Egress

For outbound-only IPv4 internet access from private subnets, NAT gateways are the correct primitive. A managed NAT gateway scales automatically to 45–100 Gbps, supports 55,000 simultaneous connections per unique destination, is patched by AWS, and is highly available within its AZ. NAT gateways are billed per hour and per GB processed.

NAT instances — self-managed EC2 with source/destination check disabled — are legacy. They are bounded by the throughput of a single instance, must be scripted for failover, and become a bottleneck under sustained load. They are appropriate only for atypical needs like custom filtering, and even then a Gateway Load Balancer appliance is usually preferable.

The canonical highly-available pattern is one NAT gateway per AZ, each in that AZ’s public subnet, with a distinct private route table per AZ whose default route points to the local NAT gateway:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Deploying a single NAT gateway shared across AZs is a trap for two reasons. First, it is a single point of failure: an AZ outage takes down egress for every private subnet. Second, every packet from instances in other AZs crosses an AZ boundary, incurring cross-AZ data transfer charges (currently $0.01/GB each way) on top of NAT gateway processing. On workloads doing hundreds of TB of egress, this dwarfs the cost of the extra NAT gateways. A second frequent misconfiguration is placing the NAT gateway itself in a private subnet — it then has no path to the IGW and does not function.

For IPv6, NAT is neither needed nor available because every IPv6 address is globally routable. To allow outbound-only IPv6 while blocking unsolicited inbound, attach an egress-only internet gateway and route ::/0 to it from private subnets. A regular IGW is bidirectional and would expose instances.

VPC Endpoints: Gateway vs. Interface

VPC endpoints keep traffic between your VPC and AWS services on the AWS backbone, avoiding the internet, NAT gateways, and internet gateways entirely. There are two fundamentally different implementations, and confusing them is one of the most common architectural mistakes.

Gateway endpoints exist only for Amazon S3 and DynamoDB. They are a route table entry — a prefix list (for example pl-63a5400a for S3 in us-east-1) targeting the endpoint itself. There is no ENI, no DNS change, no hourly cost, and no security group (access is controlled by the route table plus the endpoint policy). Because they are route-based, they only work for resources inside the VPC — on-premises networks reaching S3 over Direct Connect cannot use them.

Interface endpoints (AWS PrivateLink) are ENIs with private IPs placed in your subnets, billed hourly per AZ plus per-GB. They work for nearly every other service — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS, and hundreds more — as well as third-party services published as endpoint services. Interface endpoints support private DNS, which overrides the public service hostname to resolve to the endpoint’s private IP so SDKs and CLIs need no code changes. Because they are ENI-backed, security groups apply.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

The cost logic matters: any traffic leaving a private subnet to a public AWS service by default traverses a NAT gateway at roughly $0.045/GB. For a containerized workload pushing 1 TB per day to S3, the difference between a NAT gateway path and a gateway endpoint is thousands of dollars per month. Interface endpoints are worthwhile when they replace NAT egress at scale or when compliance forbids internet routing.

Traps: attaching a security group to a gateway endpoint (they have no ENI); assuming a gateway endpoint is reachable from on-premises (it is not — use an interface endpoint or the hybrid pattern EC2 → S3 gateway endpoint → separate DX path); disabling private DNS on an interface endpoint and expecting unmodified SDK calls to work (they will hit the public endpoint over the internet, defeating the endpoint entirely); creating a gateway endpoint but forgetting to associate the private subnet’s route table (traffic silently continues to use the public path); trying to use a gateway endpoint for a service that has no gateway endpoint (KMS, for example) — only S3 and DynamoDB qualify.

Inter-VPC Connectivity: Peering vs. Transit Gateway

VPC peering is a one-to-one, non-transitive Layer 3 connection between two VPCs, same or different account, same or different Region. Traffic traverses the AWS backbone, there is no bandwidth bottleneck, and there is no per-hour charge — you pay only for cross-AZ or inter-Region data transfer. Two properties limit peering: (1) it is non-transitive — if A peers with B and B peers with C, A cannot reach C through B; and (2) CIDR ranges must not overlap. Connecting N VPCs full-mesh requires N(N-1)/2 peerings with route table edits in both directions of each; at 30 VPCs, that is 435 peerings. Expecting peering to scale to hundreds of VPCs is a trap.

Transit Gateway (TGW) is a regional cloud router. Each VPC, VPN, or Direct Connect gateway is an attachment, and TGW route tables control which attachment can reach which prefix. This converts an O(n²) mesh into O(n) attachments and enables hub-and-spoke topologies where a security VPC hosts firewalls that inspect all inter-VPC traffic. TGW supports transitive routing, natively terminates VPN and Direct Connect gateway associations, and can be shared across AWS Organizations via Resource Access Manager so central networking teams control routing while workload accounts own VPCs. TGW adds an hourly per-attachment fee and roughly $0.02/GB processed.

For inter-Region connectivity, TGW peering connects TGWs in different Regions over the AWS global backbone with encrypted traffic — one TGW per Region, peered in a mesh or hub design. This avoids the N-squared problem across Regions that inter-Region VPC peering reintroduces.

Route table hygiene is the silent killer here. Creating a peering connection or a TGW attachment does nothing until explicit CIDR routes are added in both VPCs’ subnet route tables pointing at the pcx- or tgw- target, and security groups permit the traffic. Silent connectivity failures nearly always trace back to a missing route or an implicit deny in a security group referencing the wrong source CIDR.

Hybrid Connectivity: Site-to-Site VPN vs. Direct Connect

The choice between Site-to-Site VPN and Direct Connect is a trade-off between speed of deployment plus built-in encryption on one hand, and consistent low latency, dedicated bandwidth, and predictable throughput on the other.

Site-to-Site VPN establishes two IPsec tunnels between a customer gateway (on-prem router) and either a Virtual Private Gateway or a Transit Gateway. Each tunnel caps at approximately 1.25 Gbps. Traffic is encrypted at the network layer, satisfying requirements for encryption at the network and session layers when combined with TLS. It traverses the public internet, so latency and jitter are variable, but it is available in minutes and costs cents per hour. Use it when connectivity is needed immediately, when bandwidth is modest, or as a backup path.

Direct Connect (DX) provides a dedicated fiber connection (1, 10, or 100 Gbps) from an on-premises router to an AWS Direct Connect location. It bypasses the public internet, yielding consistent latency and higher throughput. DX egress pricing is substantially lower than internet egress, which matters when moving hundreds of gigabytes per day. Provisioning takes weeks — cross-connects, LOAs, BGP configuration.

Two traps dominate here. First, Direct Connect alone does not encrypt traffic. A private circuit is not a cryptographically protected channel. To satisfy an encryption requirement over DX, layer a Site-to-Site VPN on top, or use MACsec for Layer-2 encryption on supported dedicated ports. Second, a raw DX connection does not by itself route to multiple VPCs. A private VIF connects to a single Virtual Private Gateway attached to a single VPC. To reach many VPCs — especially across accounts and Regions — use a Direct Connect Gateway associated with a Transit Gateway via a transit VIF, and attach each VPC to the TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

The canonical production pattern uses two DX connections at two DX locations terminating on separate customer routers, with Site-to-Site VPN as automatic BGP failover — BGP AS-path prepending or MED steers traffic to DX while it is up; if it fails, BGP withdraws the DX routes and the VPN takes over.

Load Balancers: ALB, NLB, and GWLB

ALB is Layer 7 and understands HTTP semantics — host and path routing, WebSockets, redirects, cookie-based sticky sessions. It is the wrong tool for anything that isn’t HTTP: MQTT, raw TCP, syslog over UDP, SMTP. ALB uses DNS-based addressing with IPs that change over time; it cannot be assigned Elastic IPs. When clients whitelist destination IPs, an ALB alone is unsuitable — use NLB with EIPs, or front the ALB with Global Accelerator’s two static anycast IPs. “Just resolve the ALB DNS once and pin the IPs in firewall rules” is a trap: AWS changes them without notice.

NLB is Layer 4 and scales to millions of flows per second. It preserves the true client source IP by default (targets see the real client), supports assigning a static Elastic IP per AZ, and handles high-throughput TCP/UDP workloads. Historically NLB did not support security groups on the load balancer itself — client CIDRs had to be permitted directly on the target’s SG. AWS added optional NLB security groups in 2023, but many designs still assume the classic behavior.

The canonical public-facing pattern is:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Referencing the ALB’s security group as the source on the backend — rather than a CIDR — is the least-privilege pattern and automatically covers health check traffic, which originates from the ALB’s ENIs. The ALB itself lives in public subnets in at least two AZs (routes to IGW); targets live in private subnets. Placing an internet-facing ALB in a private subnet is a classic misconfiguration — target registration succeeds but clients cannot reach it.

Gateway Load Balancer (GWLB) is purpose-built for transparent insertion of third-party virtual appliances (firewalls, IDS/IPS, DPI). It operates at Layer 3, forwarding all IP protocols using GENEVE encapsulation on UDP 6081. Traffic reaches GWLB through a GWLB endpoint (GWLBe) — an interface endpoint that sits in a subnet and appears in route tables as a target:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

The endpoint forwards packets over PrivateLink to the GWLB, which load-balances across the appliance fleet using flow stickiness so both directions of a flow hit the same appliance. In a hub-and-spoke inspection design, spoke VPCs attach to a TGW whose route tables force east-west traffic through the inspection VPC (containing the GWLB and appliances) before reaching destination VPCs. Ingress inspection uses edge route tables that redirect IGW-to-web-tier traffic through the GWLBe first:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

This is the correct answer for centralized, cross-account inspection — home-rolling with EC2, custom route table hacks, and failover scripts reinvents what GWLB provides natively.

PrivateLink for Consumer-to-Provider Services

Beyond powering interface endpoints for AWS services, PrivateLink enables private connectivity to services published by third parties or other AWS accounts. The provider places their service behind an NLB and creates a VPC endpoint service. Consumers create interface endpoints in their own VPCs that target it.

The critical directionality rule: the connection is always initiated from the consumer toward the provider. The provider cannot initiate connections into the consumer’s VPC. Traffic never touches the internet, only the specific target service is reachable (not the whole provider VPC, as with peering), and no CIDR overlap issues arise because only endpoint IPs are exposed on each side. This is the canonical answer for a SaaS or vendor-database access pattern where the consumer VPC has no IGW, no VPN, and no Direct Connect. VPC peering exposes entire CIDR ranges and requires non-overlapping IPs; a TGW attachment routes broadly; a public API over the internet is not private.

Global Accelerator and Route 53

AWS Global Accelerator assigns two static anycast IPv4 addresses advertised from AWS edge locations worldwide. Client traffic enters the closest edge and rides the AWS backbone to the nearest healthy regional endpoint (ALB, NLB, EIP, or EC2). This solves two problems at once: static IPs in front of ALBs (fixing the whitelisting gap), and reduced jitter/latency for globally distributed users by shortcutting the public internet. It accelerates non-cacheable TCP/UDP traffic to origins where CloudFront (which caches content) is not applicable.

Route 53 solves a different problem — DNS-level traffic steering. Global Accelerator affects the data plane itself; Route 53 affects only DNS resolution, after which the TCP connection goes wherever the resolved IP lives. The two are frequently combined: a Route 53 alias points to a Global Accelerator that fronts regional ALBs.

Route 53 routing policies:

Latency and geolocation are frequently confused: latency minimizes user-perceived RTT; geolocation enforces data residency regardless of latency. Multi-Region failover requires health checks on the primary. Alias records are AWS-specific, resolve directly to ALB, NLB, CloudFront, S3 website, and API Gateway endpoints at no query charge, and — unlike CNAMEs — work at the zone apex.

Route 53 Resolver answers DNS queries inside a VPC via the .2 address (VPC CIDR base + 2). For hybrid DNS, inbound endpoints let on-premises resolvers query private hosted zones in AWS; outbound endpoints with forwarding rules let VPC resources resolve on-premises names. Without these, EC2 instances cannot resolve corp.internal and on-prem servers cannot resolve db.prod.internal — a subtle break that surfaces only when applications begin cross-environment lookups. Interface endpoints require Enable Private DNS for SDK calls to hit the endpoint ENI; without it, calls still reach the public endpoint over the internet, defeating the purpose.

Security Groups, NACLs, and Least Privilege

Security groups are stateful — return traffic is automatically permitted — and act at the ENI level. NACLs are stateless and act at the subnet boundary. Any TCP rule in a NACL requires an explicit inbound and outbound rule; because clients pick a source port from the ephemeral range, the return-direction rule must allow ports 1024–65535 (Linux uses 32768–60999 by default; the broader range covers Windows and other stacks). Forgetting the ephemeral return rule is a classic cause of connections that complete SYN but hang on response.

For least privilege between tiers, security group rules should reference other security group IDs, not CIDRs. This scales with Auto Scaling and avoids brittle IP whitelists:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACLs are a coarse blast-radius control, not a substitute for security groups. Tightening NACLs “for defense in depth” without matching security group changes commonly breaks outbound-initiated flows such as yum/apt updates through a NAT gateway because the stateless return traffic is silently dropped. Route tables ultimately determine reachability: even a permissive security group cannot deliver traffic if the route table lacks an entry for the destination, and conversely a gateway endpoint is only effective when the S3 prefix list route is actually installed in the route tables of the subnets that host the workload.

Decision Reference

← Previous: Data Transfer · All domains · Next: Content Delivery →

Practice Networking questions → · Timed practice on ExamRoll.io →

Browse Amazon →