Determine High-Performing and/or Scalable Network Architectures

Core Idea

You don't need to be a networking expert, but you need enough fluency to make informed decisions and do basic troubleshooting — because the network sits between every component in your architecture and materially affects performance (bandwidth, latency, jitter, throughput), both positively and negatively.

Product Features That Optimize Traffic

Enhanced networking, EBS-optimized instances, S3 Transfer Acceleration, CloudFront — features that directly improve throughput/latency for specific traffic paths.

Features That Reduce Distance/Jitter

Route 53 latency routing, VPC endpoints, Direct Connect, Global Accelerator — plus physically placing resources near where they're used (Regions, placement groups, edge services).

Design as Code

Build your network (and the whole architecture) as infrastructure as code so it can be rebuilt/modified quickly — this is framed as a performance-efficiency practice, not just an ops nicety, because it lets you evolve the network alongside changing workload needs.

VPC Build Order (a concrete, memorizable sequence)

VPC → subnets → route tables → internet gateway → NACL → security groups → then customize: add resources, tune security groups, add a NAT gateway if needed, peer to another VPC, create endpoints.

Hybrid Connectivity Decision

• On-prem ↔ VPC private communication: VPN vs. Direct Connect — know the throughput/performance profile of each well enough to choose correctly against compliance/data-volume/performance requirements in a scenario.
• Transit Gateway works with either VPN or Direct Connect to connect many VPCs to a remote network — know its use case (simplifying peering at scale) distinct from plain VPN/DX.
• AWS CloudHub: hub-and-spoke model for connecting networks — know this exists even if it's a lower-priority topic.

VPC-to-VPC Connectivity

• VPC peering, Transit Gateway, or Direct Connect Gateway for cross-VPC/cross-account communication.
• PrivateLink / VPC endpoints: the answer when you want cross-VPC app communication without making the app public and without the overhead of peering.

Reaching AWS Public Services Privately

• Gateway endpoints sit in the AWS public zone and let a private subnet/instance (no NAT, no internet access) reach services like S3 or DynamoDB directly.

Global Traffic Routing

• Website across two Regions, want to send users to the geographically nearer Region → Route 53 geoproximity routing policy is the specific answer (not just "Route 53" generically — know the routing policy taxonomy: latency, geoproximity, failover, weighted, etc.).
• Global Accelerator: improves performance/availability by routing over the AWS global network — a distinct lever from Route 53 policies.
• CloudFront: edge caching to shorten distance to end users — know its use cases and benefits in depth, not just "it's a CDN."

Data Transfer / Migration Service Selection

Multiple services for moving data into AWS, each suited to different volume/type/source-destination combos: AWS DataSync, Snow Family, AWS Transfer Family, AWS Database Migration Service, and others — know the functional/performance differences well enough to pick the right one per scenario.

Scaling Global Applications

• Combine CloudFront + Global Accelerator + serverless to hit scale while minimizing cost.
• EC2 Auto Scaling: know launch configurations, min/max/desired capacity, scaling policy types, and integration with a load balancer for health-check-aware, application-aware scaling.
• Load balancer types: know the use case for each, and their OSI-model layer (this is explicitly flagged as a useful exam tip — load balancer type ↔ OSI layer mapping).

Achieving High Availability at Scale

AWS guidance repeated here: design for no single point of failure, and use automated monitoring, failure detection, and failover for both stateless and stateful components. Example composite pattern: load-balancer active-standby pair + Route 53 (with DNS health checks routing only to healthy endpoints) + Auto Scaling lifecycle hooks + CloudWatch Events + Lambda.

Worked Scalability Exercise (single-Region web app)

Improvements brainstormed: add CloudFront, add ElastiCache, refine ASG scaling policy (smaller instances, more granular scale-in/out increments).

Worked Exercise (global serverless, extreme scale, minimize cost)

Reference pattern: S3 static website hosting + Route 53 latency/failover routing + DynamoDB Global Tables (low latency, cross-Region replication). Further improvements: add CloudFront (performance/reliability/security/caching) and Global Accelerator with S3 Multi-Region Access Points (span buckets across Regions under one set of endpoints for improved security/reliability/performance).

Exam Angle

Expect Route 53 routing-policy selection questions (don't just say "Route 53," name the policy), VPN-vs-Direct-Connect cost/throughput trade-offs, load-balancer-to-OSI-layer mapping, and "reduce hops/avoid NAT/avoid exposing to internet" pattern-matching to Gateway Endpoints or PrivateLink.

Practical Examples

Route 53 routing policy selection, by scenario: "Send EU users to the Frankfurt Region and US users to Virginia, based on lowest network latency" → latency-based routing. "Send all traffic to the primary Region unless its health check fails, then send everyone to the backup Region" → failover routing. "Send 90% of traffic to the new app version, 10% to the old, for a canary rollout" → weighted routing. "Route German users specifically to a Region I designate, regardless of which is technically closest" → geolocation routing (note: distinct from geoproximity, which lets you bias by a configurable "bias" radius around each Region).

Gateway Endpoint saving real money: An EC2 fleet in a private subnet (no NAT Gateway, no internet route) needs to read/write S3 objects constantly. Without a Gateway Endpoint, this traffic simply can't reach S3 at all from that subnet. Adding an S3 Gateway Endpoint (a route-table entry, no ENI, no hourly charge) lets the private subnet reach S3 directly, at no data-transfer cost — versus routing it out through a NAT Gateway, which would both cost money and require the subnet to have internet egress it otherwise doesn't need.

PrivateLink vs. VPC peering, revisited from the network-performance angle: Two VPCs in different accounts need one specific microservice to talk to another, at high throughput, without exposing either VPC's other resources. PrivateLink (interface endpoint + NLB) exposes just that one service; VPC Peering would flatten the entire network boundary between the two VPCs, which is unnecessary blast radius for a one-service need.

Transit Gateway hub-and-spoke: A company with 12 VPCs across 3 accounts, all needing to talk to each other and to an on-prem data center via Direct Connect, would need 66 individual peering connections in a full mesh — unmanageable. Transit Gateway turns this into 12 spoke attachments + 1 Direct Connect attachment into a single hub, with route tables controlling who can reach whom.

CloudFront use case beyond S3: A dynamic API (not static content) benefits from CloudFront too — it can terminate TLS closer to users, keep persistent connections to the origin open (reducing repeated TCP/TLS handshake overhead), and apply AWS WAF at the edge — this is the "CloudFront isn't just a static-file CDN" point the lesson explicitly flags.

Data-transfer service selection: Migrating a 2 PB on-prem tape archive with no good network path → AWS Snowball/Snowmobile. Continuously syncing an on-prem NFS share into S3 going forward → AWS DataSync. Migrating a live Oracle database to Aurora PostgreSQL with minimal downtime → AWS DMS (with the Schema Conversion Tool for the engine change). Enabling business partners to SFTP files in nightly → AWS Transfer Family.

Global Accelerator + S3 Multi-Region Access Points: A media company serves the same asset bucket from both us-east-1 and eu-west-1 for redundancy and lower latency. S3 Multi-Region Access Points give them one endpoint that transparently routes to whichever Region's bucket is closer/healthier, and Global Accelerator improves the network path to that endpoint globally — together, a global, resilient front door without the client needing to know which Region is serving it.