AWS SAA-C03: How to Determine High-Performing and Scalable Network Architectures

Introduction: what SAA-C03 is really testing

SAA-C03 networking questions are rarely about naming services from memory. What AWS is really testing here is whether you can trace the traffic end to end, spot the hidden dependencies people tend to miss, and choose the AWS-native design that balances performance, scale, resilience, and, honestly, keeps the operational headache to a minimum. In my experience, the best answer is usually the one that keeps traffic private whenever possible, spans multiple Availability Zones, skips unnecessary hops, and uses the simplest connectivity model that still gets the job done.

The basics that really matter: VPCs, subnets, IP planning, and routing

An Amazon VPC is your isolated routing domain. Good design starts with CIDR planning. Give yourself some breathing room for growth, multi-AZ subnetting, endpoints, shared services, and whatever future connectivity you might need to other VPCs or back to on-premises. Overlapping CIDRs are one of those gotchas that can shut down VPC peering, Transit Gateway attachments, and hybrid routing pretty fast, so address planning isn’t just paperwork — it actually determines which architectures you’ll still be able to build later.

If you want a workload to be resilient, spread the subnets across at least two AZs. That part’s non-negotiable. A pattern I keep coming back to is public subnets for internet-facing load balancers, private app subnets for compute, and private data subnets for databases. And don’t forget AWS holds back five IP addresses in every subnet, so those tiny subnet designs can get cramped faster than people expect. Also, security groups hang off ENIs, so the instance is really getting its behavior through the ENI it’s attached to.

Routing is where many exam questions are won or lost. Every route table includes the local route for traffic inside the VPC CIDR. AWS then applies longest-prefix match: the most specific route wins. That explains why traffic to S3 through a gateway endpoint can bypass a default 0.0.0.0/0 NAT route. If a more specific prefix exists, it wins over the default route.

Internet Gateway enables internet connectivity for resources with public IP addresses and appropriate routes; it does not perform NAT or filtering. For IPv6, an IGW supports internet connectivity too, but private outbound-only IPv6 access uses an egress-only internet gateway, not NAT. NAT Gateway is an IPv4 egress pattern.

Example route-table logic:

Public subnet: local route + 0.0.0.0/0 to IGW.
Private app subnet: local route + 0.0.0.0/0 to same-AZ NAT Gateway.
Private app subnet with S3 gateway endpoint: local route + S3 prefix list to gateway endpoint + 0.0.0.0/0 to NAT.
Private isolated data subnet: local route only, unless specific internal or hybrid routes are required.

Route propagation is context-specific. You typically see dynamic route exchange through a virtual private gateway, Transit Gateway, VPN, or Direct Connect-related attachments, not as generic dynamic routing across ordinary subnet route tables. Also watch for blackhole routes: if an attachment or target becomes invalid, the route may remain but no longer forward traffic correctly.

Traffic flow design: ingress, egress, endpoints, and load balancing

Start with the traffic type. The first question I always ask is: is this workload internet-facing, internal-only, hybrid, or just private service-to-service traffic? That one question eliminates a surprising number of wrong answers almost immediately.

For outbound traffic, keep in mind that a NAT Gateway lives in a subnet in a specific Availability Zone. The design I usually recommend is one NAT Gateway per AZ, with each private subnet routing outbound traffic to the NAT in its own AZ. That avoids cross-AZ dependency and cross-AZ data transfer charges. A single central NAT often looks cheaper until you factor in failure risk and inter-AZ traffic cost.

But NAT should not be the default answer for AWS service access. Use gateway endpoints for S3 and DynamoDB; they are route-table based. Use interface endpoints for many other AWS services; they create ENIs in your subnets, can use security groups, and often rely on private DNS so standard public service names resolve to private addresses inside the VPC. Endpoint policies can further restrict what resources are reachable.

Mini example: a private EC2 instance needs S3 access. Best design: create an S3 gateway endpoint, associate the private route tables, and optionally restrict access with an endpoint policy. Because AWS uses longest-prefix match, S3 traffic follows the more specific endpoint route, while everything else that needs internet access can still go through NAT.

How I think about picking the right load balancer

Application Load Balancer (ALB) is for Layer 7 HTTP/HTTPS. It handles host-based and path-based routing, redirects, fixed responses, WebSockets, gRPC, TLS termination, and the usual WAF or authentication integrations you see in real-world designs. ALB target types include instances, IP addresses, and Lambda. Choose it when the application needs HTTP awareness.

Network Load Balancer (NLB) is for Layer 4 TCP, UDP, TCP_UDP, and TLS listeners. It’s a strong fit when you need very high performance, non-HTTP protocols, or static IP requirements at the zonal level. NLB is commonly chosen when source IP preservation matters, though you should not treat that as universal in every architecture without checking the target path and configuration.

Gateway Load Balancer (GWLB) is for scaling and inserting virtual appliances such as firewalls and IDS/IPS fleets. It is not the answer for ordinary web routing.

ALB distributes requests across healthy targets in enabled AZs. NLB supports cross-zone load balancing as an option. Cross-zone distribution can improve balancing but may introduce inter-AZ transfer considerations. Also remember: enabling multiple AZs on the load balancer is not enough if all healthy targets sit in one AZ.

How I decide between peering, Transit Gateway, PrivateLink, and endpoints

VPC peering is simple one-to-one private connectivity, but it is non-transitive and requires non-overlapping CIDRs. It works well when you’ve only got a small, direct relationship to support. It becomes messy in mesh topologies.

Transit Gateway (TGW) is the scalable hub-and-spoke option for many VPCs and accounts. It supports transitive routing, but real reachability still depends on TGW route tables, VPC route tables, propagation, and association settings. TGW is regional, so inter-Region connectivity needs additional design. One of its biggest strengths is segmentation: you can use separate TGW route tables for production, shared services, and inspection so that not every spoke can talk to every other spoke.

AWS PrivateLink is for private access to a specific service, not broad network connectivity. On the provider side, the service is typically exposed through an endpoint service backed by an NLB. On the consumer side, access is through interface endpoints. This sharply reduces blast radius compared with peering or TGW when consumers only need one application.

Mental model: full network connectivity suggests peering or TGW; private access to one service suggests PrivateLink; private S3/DynamoDB access suggests gateway endpoints; private access to supported AWS APIs suggests interface endpoints.

Hybrid networking and DNS

Site-to-Site VPN is usually the fast, lower-cost, encrypted hybrid answer. It usually uses BGP for dynamic route exchange and comes with two tunnels for redundancy. Direct Connect is the answer when you need more predictable throughput and lower latency, but it is not encrypted by default. If you need encryption, you’ll have to layer VPN over Direct Connect or use some other encryption approach. On supported dedicated connections, MACsec may be available, but it is not the default assumption for exam questions.

Direct Connect resilience requires more than having the connection in place. Stronger designs use multiple connections, ideally with diverse links or locations, plus VPN backup. Also know the VIF distinction at a high level: private VIF for private connectivity to VPC-related resources, public VIF for AWS public service endpoints. In larger environments, Direct Connect can integrate through a Direct Connect gateway and Transit Gateway for scalable multi-VPC access.

DNS is often the hidden dependency in hybrid designs. Route 53 Resolver inbound and outbound endpoints let AWS and on-premises systems resolve each other’s private names through forwarding rules. Private hosted zones and split-horizon DNS patterns matter. A network can be fully connected and still fail at the application layer because names do not resolve.

How I separate Route 53, CloudFront, and Global Accelerator

Route 53 is DNS-based routing. It supports failover, weighted, latency-based, geolocation, and a few other routing policies as well. But its decisions are subject to DNS TTL and client caching, so failover is not packet-level instantaneous rerouting.

CloudFront is a CDN. It caches content at edge locations and can improve performance for static content and many dynamic HTTP(S) workloads too. It is still not the right answer when the requirement is static Anycast IPs or non-cache-centric network acceleration.

AWS Global Accelerator advertises static Anycast IPs from AWS edge locations and routes traffic onto the AWS global network to the optimal healthy endpoint based on health and routing policy. Use it when the requirement emphasizes global entry performance, static IPs, or TCP/UDP-style acceleration rather than caching.

Security, segmentation, and private access patterns

Security groups are stateful, allow-only controls attached to ENIs and are usually the primary workload-level control. Network ACLs are stateless subnet-level controls with allow and deny rules, so return traffic must be explicitly allowed, including ephemeral ports. That stateless behavior is a frequent exam detail.

Use segmentation at the subnet, VPC, TGW route-table, and account levels if you want to keep the blast radius under control. Whenever you can, lean toward private exposure patterns: internal ALBs or NLBs, PrivateLink for service sharing, endpoints for AWS APIs, and Systems Manager Session Manager instead of bastion hosts when that’s a viable option. For centralized inspection, you can go with GWLB-backed appliance fleets or AWS Network Firewall, depending on what you’re trying to optimize for.

A practical least-privilege move is to allow inbound app traffic only from the ALB security group instead of opening it up to broad CIDRs. For interface endpoints, attach tight security groups and, where supported, use endpoint policies. For S3 gateway endpoints, endpoint policies can restrict access to specific buckets.

High-yield architecture patterns

Multi-AZ three-tier app: internet-facing ALB in public subnets across two AZs, app tier in private subnets across the same AZs, database tier private, one NAT Gateway per AZ, S3 gateway endpoint for private service access. It’s a pattern that scales well, holds up under failure, and shows up a lot in exam questions.

Multi-account hub-and-spoke: TGW connects application VPCs, shared services, and inspection VPCs. Separate TGW route tables help keep production isolated from non-production and cut down unnecessary east-west reachability. This beats a peering mesh in both scale and manageability.

Private service publishing: provider exposes a service with PrivateLink using an NLB-backed endpoint service; consumers connect through interface endpoints. Consumers reach only that service, not the whole provider VPC.

Hybrid resilient pattern: Direct Connect for primary predictable connectivity, VPN for encrypted backup, Route 53 Resolver for DNS integration, and BGP-based route exchange for failover behavior.

How I approach troubleshooting and diagnostics

The workflow I trust is simple: trace the packet path first, then check route tables, then security groups and NACLs, then DNS, and only after that move on to health checks and logs.

Scenario 1: private EC2 cannot reach S3. The usual suspects are: the S3 gateway endpoint isn’t associated with the right route table, the endpoint policy is too restrictive, DNS is pointing somewhere unexpected, or the traffic is needlessly going out through NAT. I’d check the route tables, the endpoint setup, and VPC Flow Logs. Fix by associating the correct private route tables and validating the endpoint policy.

Scenario 2: multi-AZ app depends on one NAT Gateway. Symptom: one AZ outage breaks egress for workloads in another AZ, or costs spike from inter-AZ traffic. Check private subnet route tables and NAT placement. The fix is usually to deploy one NAT Gateway per AZ and point each private subnet to the NAT in its own AZ.

Useful tools: VPC Flow Logs for accepted and rejected traffic, Reachability Analyzer for path validation, ELB target health and access logs for load balancer issues, Route 53 query logging for DNS behavior, and TGW route-table inspection for cross-VPC routing problems.

Common SAA-C03 traps and exam cues

• Path-based routing → ALB
• Static IPs → NLB for regional or zonal load balancing, Global Accelerator for global Anycast IPs
• Transitive routing → Transit Gateway
• Private access to one service across accounts → PrivateLink
• Private access to S3 or DynamoDB → Gateway endpoint
• Fast, encrypted hybrid setup → Site-to-Site VPN
• Predictable throughput private hybrid → Direct Connect

Wrong-answer eliminators matter just as much:

• Peering is non-transitive and requires non-overlapping CIDRs.
• PrivateLink is not full VPC connectivity.
• Direct Connect isn’t encrypted by default, so that’s something you’ve got to plan for explicitly.
• CloudFront and Global Accelerator are not the same thing, and mixing them up is a classic exam mistake.
• Route 53 works through DNS, so failover timing still depends on TTL values and client-side caching.
• IPv6 private outbound uses egress-only IGW, not NAT Gateway.

Final review checklist

1. Start by asking: what kind of traffic is this — HTTP/HTTPS, TCP/UDP, AWS service access, cross-VPC, or hybrid?
2. Then ask: is the requirement really about low latency, high throughput, static IPs, caching, DNS policy, or transitive routing?
3. Can you keep the traffic private with endpoints or PrivateLink?
4. Are there hidden single-AZ dependencies such as one NAT Gateway or one set of targets?
5. Do CIDR choices allow peering, TGW, and hybrid expansion?
6. Would a managed AWS-native service reduce operational overhead and improve resilience?

The best exam answer usually matches the traffic pattern precisely, minimizes blast radius, avoids unnecessary NAT or public exposure, and spreads critical dependencies across AZs. If you trace the path and apply that discipline, most networking questions become much easier.