Sign in Subscribe

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

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

1. Introduction

On the AWS Certified Solutions Architect – Associate exam, networking questions are rarely about definitions alone. They are usually architecture tradeoff questions dressed up as service-selection questions. You are given requirements like low latency, private access, static IPs, global users, predictable bandwidth, or minimal operational overhead, and you need to map those clues to the right design.

That is what “determine high-performing and/or scalable network architectures” really means on SAA-C03. The exam is testing whether you can choose the simplest architecture that satisfies performance, availability, scale, and security requirements. Honestly, that same skill matters even more once you’re working on real projects. I’ve seen teams get into trouble when they pick the service that sounds the fanciest instead of the one that actually matches the traffic pattern.

So anyway, this guide is really about the AWS networking patterns you need to spot fast: VPC design, private access patterns, load balancing, global traffic services, multi-VPC connectivity, hybrid networking, troubleshooting, and the kind of elimination logic that saves you on exam day.

2. The core principles the exam keeps coming back to

High availability means the workload continues serving traffic despite failures, usually by spreading resources across multiple Availability Zones. For SAA-C03, I’d generally treat Multi-AZ as the starting point for production unless the question gives you a very clear reason to keep the design simpler.

Scalability usually means horizontal scaling in AWS: more instances, more tasks, more targets behind a load balancer. Vertical scaling exists, but if the question says “scalable,” “elastic,” or “bursty traffic,” horizontal designs are normally the better answer.

Stateless tiers are easier to scale and recover. If session data lives on the instance, Auto Scaling and load balancing become awkward. If state is externalized to a shared store or removed entirely, the app tier becomes much easier to distribute across AZs.

North-south traffic is traffic entering or leaving your environment, such as users hitting a public application. East-west traffic is internal service-to-service communication. That’s the sort of clue that tells you whether you’re looking at a public ALB, an internal ALB, PrivateLink, a VPC endpoint, Transit Gateway, or maybe even a hybrid routing design.

Latency is delay, throughput is data moved over time, and jitter is variation in delay. The exam often hides the real answer inside those performance words. Low-latency TCP with static IPs is not the same problem as globally cached web content, even if both sound like “networking.”

3. Build the Foundation with Amazon VPC

Most AWS networking designs, honestly, start with Amazon VPC because that’s where you set the foundation. A VPC gives you the IP range, subnets, route tables, security controls, and connection points you need to reach the internet, private AWS services, other VPCs, and even on-premises environments. If the VPC design is weak, everything built on top of it gets harder.

A subnet is considered public when its route table includes a route to an Internet Gateway and the resources that need internet access also have public IPv4 addresses or Elastic IPs as needed. A private subnet does not provide direct internet ingress or egress through an Internet Gateway for its instances, though it may still have outbound access through a NAT Gateway, an egress-only internet gateway for IPv6, VPN, Direct Connect, or Transit Gateway.

In practice, a solid Multi-AZ design usually has separate public, private application, and private data subnets in each Availability Zone. For example, in a 10.0.0.0/16 VPC, you might carve out /20 blocks for each tier in each AZ so you’ve got plenty of room to grow later. And honestly, this is one of those cases where giving yourself extra room upfront is absolutely worth it. AWS reserves five IP addresses in every subnet, so if you size them too small, you can hit scaling pain faster than you’d expect.

Route table pattern:

  • Public subnet route: 0.0.0.0/0 -> Internet Gateway
  • Private IPv4 app subnet route: 0.0.0.0/0 -> NAT Gateway
  • Private IPv6 outbound-only route: ::/0 -> Egress-only Internet Gateway

NAT Gateway is a frequent exam topic. It lives in a public subnet, and private subnets send their IPv4 internet-bound traffic to it. NAT Gateway is AZ-scoped, so the usual best practice is one NAT Gateway per AZ. If private subnets in AZ-B send traffic through a NAT Gateway in AZ-A, you’ve now created an AZ dependency and you might also pick up cross-AZ data transfer charges.

Security groups are stateful, allow-only controls attached to ENIs. Return traffic is automatically allowed. Network ACLs are stateless subnet-level controls with ordered allow and deny rules. In most exam architectures, security groups are the primary control. NACLs are useful when you need coarse subnet boundaries or explicit deny logic.

One more exam trap: poor IP planning blocks future connectivity. VPC peering and many other interconnect patterns require non-overlapping CIDR ranges. If your address spaces overlap, you can block peering, make Transit Gateway routing messier, and turn future hybrid expansion into a headache.

4. VPC Endpoints and Private Access Patterns

This area is commonly confused, so it is worth making precise. If instances in private subnets need private access to AWS services, the answer is often a VPC endpoint, not NAT Gateway.

Gateway endpoints are for S3 and DynamoDB. They are route-table based and let private resources reach those services without traversing the public internet or using NAT. If the exam says “EC2 in a private subnet needs private access to S3,” a gateway endpoint is usually the best answer.

Interface endpoints are ENI-based endpoints for many AWS services. They are powered by PrivateLink technology and give private connectivity from your VPC to supported AWS services or partner services.

PrivateLink is the broader service-publishing model. A provider exposes a specific service privately, commonly behind an NLB, and consumers connect through interface endpoints. This is private service consumption, not full network connectivity. It is typically one-directional access from consumer to provider service, not a bidirectional routed network.

Quick comparison:

  • Gateway endpoint = private access to S3 or DynamoDB
  • Interface endpoint = private access to many AWS services
  • PrivateLink = private access to a provider’s specific service
  • VPC peering / TGW = broader network connectivity

5. Choose the Right Load Balancer

Load balancer questions are high-yield on SAA-C03 because the service choice depends on protocol, routing logic, and performance requirements.

Service comparison:

  • ALB: Best for HTTP/HTTPS at Layer 7. The big clues are host-based routing, path-based routing, APIs, WebSockets, and HTTP/2 — that’s usually your ALB signal right there. It’s usually the wrong pick when you need static IPs or plain TCP/UDP delivery.
  • NLB: Best for TCP/UDP/TLS at Layer 4. Key clues include very high throughput, low latency, static IPs, and allowlisting. Usually the wrong choice when you need Layer 7 routing decisions.
  • GWLB: Best for appliance insertion. Key clues include traffic inspection, firewalls, and IDS/IPS. Usually the wrong choice when you are simply fronting a web application.

ALB is the normal answer for web apps and APIs. It supports listener rules, host and path routing, redirects, TLS termination, WebSockets, and HTTP/2. If a question says “route /api to one target group and /images to another,” think ALB immediately.

NLB is the better fit for raw TCP/UDP/TLS workloads. It provides static IP addresses per AZ and can use Elastic IPs for internet-facing deployments. It is often the right answer when clients must allowlist fixed source addresses or when the application needs very high packet throughput. NLB commonly preserves source IP for many TCP/UDP use cases, though exact behavior should always be verified by protocol and target type.

GWLB is specialized. It uses GENEVE encapsulation to steer traffic through virtual appliances. If the requirement is transparent inspection with third-party firewalls, that is GWLB territory. If the requirement is application routing, it is not.

For implementation thinking, remember the building blocks: listeners, target groups, and health checks. Health checks matter a lot because once a target turns unhealthy, the load balancer stops sending traffic there, which is exactly what you want when you’re trying to keep the app stable. And yes, internet-facing load balancers can span multiple AZs, but the design only really feels resilient when the targets are spread across those AZs as well.

TLS decision rule: terminate at ALB when you want HTTP-aware routing and certificate management there; use NLB when you need Layer 4 delivery, static IPs, or TLS pass-through style requirements. Sticky sessions do exist, sure, but I usually treat them as a workaround rather than the cleanest way to scale.

6. CloudFront, Global Accelerator, and Route 53 are easy to mix up at first, but they’re solving different problems.

People mix these three up all the time because they all sit close to user traffic, but the problems they solve are actually pretty different.

Service comparison:

  • Route 53: Primary job is DNS routing and failover. Best clues include latency policy, weighted policy, failover policy, and geolocation.
  • CloudFront: Primary job is CDN caching and edge delivery. Best clues include static assets, origin offload, and global content delivery.
  • Global Accelerator: Primary job is providing a static anycast entry point and fast failover. Best clues include global users, TCP/UDP, static IPs, and dynamic traffic.

Route 53 is DNS. Basically, it decides which endpoint a name should resolve to. Useful routing policies include weighted for traffic splitting, failover for primary/secondary, latency-based for lowest-latency region selection, geolocation for routing based on user location, and geoproximity for shifting traffic based on geographic bias. Route 53 failover isn’t instant, because DNS TTLs and client or resolver caching can slow down how quickly the change is seen.

CloudFront is the right answer for caching and origin offload. It can accelerate both static and some dynamic HTTP(S) content by terminating connections at edge locations and using the AWS backbone toward origins, but its strongest value remains caching, edge delivery, and reducing origin load. It also commonly pairs with AWS WAF.

Global Accelerator provides static anycast IP addresses and supports TCP and UDP. It improves global entry-point performance and health-check-driven failover without waiting for DNS caches to expire. That is the key distinction from Route 53 failover. It does not cache content, so it is not a CDN replacement.

Decision shortcut:

  • Name resolution logic = Route 53
  • Cache and offload content globally = CloudFront
  • Fast global ingress and static IPs = Global Accelerator

A common layered design is: Users -> Route 53 -> CloudFront -> ALB -> Auto Scaling targets. Another is: Global users -> Global Accelerator -> regional ALBs or NLBs.

7. Connect VPCs and Accounts at Scale

When AWS environments grow, point-to-point connectivity stops being enough. This is where the exam tests whether you understand scale, transitivity, and operational simplicity.

VPC peering is direct and simple for a small number of VPCs. But it is non-transitive, and it requires non-overlapping CIDR ranges. So if VPC A peers with B and B peers with C, that doesn’t mean A can automatically reach C — that’s one of the classic gotchas.

Transit Gateway is the scalable hub-and-spoke option. It provides transitive routing through the hub and supports many VPC and hybrid attachments across accounts. The key design detail is TGW route tables. They let you segment connectivity so that, for example, shared services VPCs can talk broadly while development VPCs remain isolated.

PrivateLink belongs in a different category. It does not build a routed network between VPCs. It exposes a specific service privately via interface endpoints, commonly backed by an NLB on the provider side.

Exam comparison:

  • Two VPCs, simple connectivity = peering
  • Many VPCs, many accounts, centralized routing = Transit Gateway
  • Private access to one service only = PrivateLink

8. Resilient Hybrid Connectivity Patterns

Hybrid questions usually come down to one tradeoff: speed and simplicity versus predictable performance.

Site-to-Site VPN is encrypted and quick to deploy, but it runs over the public internet, so throughput, latency, and jitter are less predictable.

Direct Connect provides dedicated private connectivity with more predictable network performance because it avoids normal internet variability. But it is not encrypted by default. If encryption is required, customers often add VPN over Direct Connect or use MACsec where supported.

At SAA level, also know the attachment models: on-premises can connect into a Virtual Private Gateway for a single-VPC style design, or into a Transit Gateway for a more scalable multi-VPC hub architecture. Enterprise designs often use Direct Connect as primary and VPN as backup.

Hybrid DNS is another exam favorite. Route 53 Resolver inbound endpoints let on-premises systems resolve private AWS names. Outbound endpoints and forwarding rules let AWS workloads resolve on-premises domains. When hybrid apps fail mysteriously, DNS is often the hidden cause.

9. Security in Network Architecture Decisions

SAA-C03 networking is not just about reachability; it is also about secure reachability.

Use security groups for least-privilege access between tiers. A classic pattern is to let the application security group reference the ALB security group, so only the load balancer can reach the app instances. Use NACLs sparingly and carefully; because they are stateless, you must account for return traffic and ephemeral ports.

For internet-facing web applications, AWS WAF often pairs with CloudFront or ALB to filter HTTP(S) requests. AWS Shield Standard provides baseline DDoS protection automatically for many AWS services, while Shield Advanced is the stronger managed option for larger or more sensitive environments.

If the requirement says “inspect traffic through third-party appliances without changing application endpoints,” then add GWLB to the picture. Otherwise, do not overcomplicate the design.

10. Troubleshooting Common AWS Networking Failures

For exam questions and real systems alike, a simple diagnostic sequence goes a long way — honestly, it saves a lot of time.

Private EC2 cannot reach the internet: verify the subnet route table, confirm 0.0.0.0/0 points to a NAT Gateway, confirm the NAT Gateway is in a public subnet, confirm that public subnet has a route to the Internet Gateway, and check security groups and NACLs. If you’re using IPv6 outbound-only access, then check the egress-only internet gateway route instead.

ALB targets are unhealthy: check the target group health check path and port, confirm the application is listening where expected, verify the instance security group allows traffic from the ALB security group, and confirm the targets are in enabled AZs. Native AWS monitoring and target health reporting provide the key signals needed to diagnose these issues.

VPC-to-VPC communication fails: check for overlapping CIDRs first, then verify routes on both sides, then confirm security groups and NACLs. And if Transit Gateway is involved, don’t forget to inspect the TGW route table associations and propagation logic too.

Hybrid name resolution fails: confirm Route 53 Resolver inbound or outbound endpoints exist in the right subnets, check forwarding rules, and verify on-premises DNS servers know where to send AWS private-zone queries.

Useful tools: VPC Flow Logs for traffic visibility, Reachability Analyzer for path analysis, Route 53 health checks for endpoint status, and CloudWatch for NAT, ELB, and VPN metrics.

11. Reference Architectures by Requirement

Public web app: Users -> Route 53 -> CloudFront + WAF -> ALB -> Auto Scaling EC2 or ECS across multiple AZs.

Global dynamic app: Global users -> Global Accelerator -> regional ALBs or NLBs -> application tiers in multiple Regions.

Private AWS service access from private subnets: EC2 in private subnets -> gateway endpoint for S3/DynamoDB or interface endpoint for supported AWS services.

Private SaaS service publishing: Consumer VPC -> interface endpoint -> provider endpoint service -> NLB -> provider application.

Enterprise multi-account network: On-premises -> Direct Connect and VPN backup -> Transit Gateway -> spoke VPCs with segmented TGW route tables.

12. Common SAA-C03 Networking Traps

These are worth memorizing because AWS uses them constantly:

  • Peering is non-transitive and requires non-overlapping CIDRs.
  • PrivateLink is not full routing; it is private service access.
  • Route 53 is DNS, not traffic acceleration.
  • CloudFront is caching and edge delivery, not static-IP global ingress.
  • Global Accelerator is fast global entry, not CDN caching.
  • NLB is not Layer 7 routing.
  • ALB is not the answer for raw TCP/UDP.
  • NAT Gateway is AZ-specific; one per AZ is the resilient pattern.
  • Direct Connect is not automatically encrypted.
  • Gateway endpoints are only for S3 and DynamoDB.

13. Exam-Day Decision Framework

Use a fast elimination process:

  1. What is the traffic type: HTTP/HTTPS, TCP, UDP, internal, external?
  2. What is the scope: one VPC, many VPCs, multi-account, hybrid, global?
  3. What is the key requirement: static IPs, caching, failover speed, private access, predictable bandwidth?
  4. What is the simplest managed service that satisfies all of it?

Keyword map:

  • Path-based routing = ALB
  • Static IPs = NLB or Global Accelerator
  • Private access to S3 = gateway endpoint
  • Private access to provider service = PrivateLink
  • Many VPCs or accounts = Transit Gateway
  • Global caching = CloudFront
  • DNS failover = Route 53
  • Predictable hybrid performance = Direct Connect
  • Fast encrypted hybrid setup = VPN

If two answers both seem possible, pick the one that solves the exact problem without solving a larger different problem. That is a very AWS exam pattern.

14. Conclusion

The networking domain on SAA-C03 is really about matching requirements to traffic patterns. ALB for HTTP routing. NLB for high-performance Layer 4 and static IPs. CloudFront for caching. Global Accelerator for fast global ingress. Transit Gateway for scalable network hubs. PrivateLink and VPC endpoints for private access. Direct Connect for predictable hybrid performance, with the reminder that encryption is separate.

If you study these services as architecture patterns instead of isolated definitions, the exam gets much easier. Read the clues, identify the boundary, and choose the simplest design that meets performance, availability, and operational goals.