High-Performing Network Architectures
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Imagine trying to run a high-frequency trading platform where every market order must travel from a terminal in Tokyo to a matching engine in New York, and back, traversing the public internet. The speed of light in fiber optic cables strictly limits how fast that packet can theoretically move, but the real enemy is the unpredictable, congested series of public internet routers along the way. In cloud architecture, raw compute power means absolutely nothing if your network topology starves your processors of data or strands your users behind crippling latency. Designing high-performing network architectures on AWS is fundamentally an exercise in manipulating the physical paths your data takes—bending geography by moving the entry point closer to the user, untangling the internal web of network connections to scale infinitely without bottlenecks, and keeping sensitive traffic off the chaotic public internet entirely.

When you design for a global audience, latency is a physics problem. To solve it, you cannot simply increase the size of your servers; you must move the data—or the front door to your application—closer to the user. AWS provides two distinct edge networking services to accomplish this, each solving a different dimension of the latency equation.
Amazon CloudFront: The Data Cache
Amazon CloudFront is a content delivery network that caches data at AWS edge locations worldwide. The fundamental premise here is simple: caching content at AWS edge locations reduces latency for end users by serving requests closer to the user location. If a user in Sydney requests an image hosted in a Virginia data center, they only pay the latency penalty of the trans-Pacific journey once. Subsequent requests are served directly from the edge cache in Sydney.

But CloudFront is not just for static images. A massive portion of connection latency comes from establishing the connection itself. Amazon CloudFront terminates TLS connections at the edge location to reduce connection setup latency. Instead of executing the complex multi-step TCP handshake and TLS negotiation across an ocean, the user's device handshakes with a server in their own city.

CloudFront is highly flexible regarding where it pulls data from. For static assets, Amazon CloudFront supports Amazon S3 buckets as custom origins. For dynamic web traffic, Amazon CloudFront supports Application Load Balancers as custom origins.
Protecting the Origin A common architectural failure occurs when a global cache suddenly expires, sending a massive "thundering herd" of requests back to the origin database, melting your infrastructure. AWS mitigates this in two layers:
- Amazon CloudFront Regional Edge Caches sit between edge locations and the origin server. These exist in AWS Regions and consolidate requests from hundreds of localized edge locations. Amazon CloudFront Regional Edge Caches reduce the operational load on the origin server by absorbing cache misses from edge locations.
- For massive, global-scale workloads, Amazon CloudFront Origin Shield provides an additional centralized caching layer to further protect the origin server from concurrent requests.
AWS Global Accelerator: The Network Fast-Lane
What if your application cannot be cached? What if you are running a real-time multiplayer game, a VoIP service, or a live financial matching engine?
This is where AWS Global Accelerator changes the game. AWS Global Accelerator provides two static Anycast IP addresses that act as a fixed entry point to a global application. Instead of resolving to a shifting pool of IPs via DNS, your clients hardcode or resolve to these two fixed IPs, which exist at every AWS edge location globally.
When a packet hits that IP, AWS Global Accelerator ingests traffic at the edge and routes it over the AWS global network backbone to minimize internet latency. Instead of your packet bouncing through unpredictable public internet service providers, it instantly drops onto AWS's private, highly optimized fiber network. From there, AWS Global Accelerator routes user traffic to the optimal AWS endpoint based on geographic proximity and application health.

This makes it vastly different from a standard web CDN:
- Protocol Support: AWS Global Accelerator optimizes routing for non-HTTP workloads like gaming and IoT applications using TCP and UDP protocols.
- Security & Tracking: Even though traffic passes through the edge, AWS Global Accelerator preserves the source client IP address for Application Load Balancer endpoints, allowing your backend security rules and analytics to function normally.
- Deployment Control: Because it operates at the network level, assigning traffic weights to AWS Global Accelerator endpoints enables blue-green deployments across different AWS Regions. You can smoothly shift 10% of global traffic from your legacy
us-east-1deployment to a neweu-west-1deployment instantly.
| Feature | Amazon CloudFront | AWS Global Accelerator |
|---|---|---|
| Primary Mechanism | Caching content at the edge | Routing traffic over the AWS backbone |
| Protocols Supported | HTTP/HTTPS, WebSockets | TCP, UDP |
| Best Used For | Static assets, dynamic web pages, video streaming | Non-HTTP traffic, real-time gaming, VoIP, deterministic routing |
Once traffic reaches your AWS Region, how it navigates between your internal networks dictates how large your architecture can grow before it collapses under its own administrative weight.
The Direct Pipe: VPC Peering
The most fundamental way to connect networks in AWS is VPC peering. A VPC peering connection is a one-to-one networking connection between two Virtual Private Clouds.
It acts as a direct, highly performant fiber cable between two networks. Inter-region VPC peering securely routes traffic over the private AWS global network infrastructure, meaning a database sync between London and Tokyo never touches the public internet.
However, VPC peering has strict mathematical and structural constraints:
- IP Conflict Resolution: VPC peering requires non-overlapping Classless Inter-Domain Routing (CIDR) blocks between the peered Virtual Private Clouds. If both VPCs use
10.0.0.0/16, peering is impossible because the routers would not know where to send the packets. - No Hopping Allowed: VPC peering connections strictly forbid transitive routing between interconnected networks. If VPC A peers with VPC B, and VPC B peers with VPC C, A cannot talk to C.
The Hub-and-Spoke Revolution: AWS Transit Gateway
Because of the non-transitive nature of VPC peering, connecting 100 VPCs requires a "full mesh" topology of 4,950 separate peering connections. This is an administrative nightmare.
To solve this, AWS Transit Gateway acts as a central hub to connect multiple Virtual Private Clouds and on-premises networks. Because AWS Transit Gateway supports transitive routing between all attached network connections, you simply attach all 100 VPCs to the Gateway. Replacing a full-mesh VPC peering architecture with an AWS Transit Gateway significantly simplifies network management.

With routing centralized, how do we prevent the Dev network from talking to the Prod database network? AWS Transit Gateway uses distinct route tables to control and isolate traffic flow between different network attachments. You can treat the Transit Gateway like a series of virtual routers, building strict logical boundaries within a single physical hub.
The scalability extends far beyond a single region or cloud environment:
- Global Architecture: AWS Transit Gateway supports routing traffic across multiple AWS Regions using Transit Gateway peering.
- Hybrid Cloud Bandwidth: Standard IPsec VPN connections are typically bottlenecked at 1.25 Gbps. To solve this physical limit, AWS Transit Gateway supports equal-cost multi-path (ECMP) routing for attached VPN connections. By configuring multiple tunnels, equal-cost multi-path routing increases overall VPN throughput by aggregating bandwidth across multiple IPsec VPN tunnels, allowing you to achieve massive scale securely from your corporate data center.
We have solved routing between our own VPCs, but what about reaching AWS services (like Amazon S3) or third-party software vendors? In a highly secure architecture, you often deploy compute resources in private subnets with no route to the public internet.
Historically, accessing a vendor's API or an AWS service required deploying an Internet Gateway or a NAT Gateway. That introduces security exposure and potential bandwidth bottlenecks.
AWS PrivateLink and Interface VPC Endpoints
AWS PrivateLink enables private connectivity between Virtual Private Clouds and supported AWS services. By leveraging this technology, AWS PrivateLink keeps network traffic entirely within the private AWS network backbone. Most importantly for your security posture, AWS PrivateLink eliminates the need for an Internet Gateway to access external software-as-a-service applications.
How does this physical connection work without an Internet Gateway? AWS PrivateLink utilizes Interface VPC Endpoints to connect to target services.
An Interface VPC Endpoint provisions an Elastic Network Interface (ENI) with a private IP address within a designated subnet. Instead of routing traffic out of your VPC to reach a service, AWS effectively drops a private network card directly into your subnet that acts as a secure portal to that specific service.

Because it manifests as an ENI, you have granular, localized security control. Security Groups can be attached to the Elastic Network Interface of an Interface VPC Endpoint to strictly control inbound access, ensuring that only authorized EC2 instances can communicate with the endpoint.
The Provider and Consumer Model
PrivateLink is not just for AWS services; it is the canonical way to build private SaaS integrations. AWS PrivateLink operates on a provider and consumer model for sharing applications across different AWS accounts.
- The Provider: The service provider in an AWS PrivateLink architecture must route application traffic through a Network Load Balancer. This NLB acts as the highly scalable target for the PrivateLink service.
- The Consumer: When you (the consumer) subscribe to this service, an Interface VPC Endpoint is dropped into your VPC.
This model elegantly solves the IP overlap problem we discussed in VPC peering. AWS PrivateLink prevents exposing internal network CIDR blocks to external service providers by relying on endpoint network interfaces. The vendor has no idea what your internal IP space is, and you don't care about theirs. All communication is masked behind the private IP of the endpoint within your subnet.
The Special Case of Amazon S3
As an architect, you must understand a critical nuance regarding object storage. Amazon S3 supports both Gateway VPC Endpoints and Interface VPC Endpoints.
Gateway endpoints are older, free, and act as route table targets. However, because they rely on route tables, they cannot be accessed from outside the VPC (such as from a corporate data center).
If you require hybrid cloud access to storage, you must use PrivateLink. Using an Interface VPC Endpoint for Amazon S3 enables direct private access from on-premises environments over AWS Direct Connect. This allows an on-premises mainframe to privately push backups into an S3 bucket via your VPC without traversing the internet or setting up complex proxy fleets.