Typical AWS Network Architecture

A typical AWS network diagram is really a map of traffic paths. It shows who is allowed to enter a virtual network, how workloads reach each other, and which routes are public versus private. The icons matter less than the boundaries between them.

The base layer: region, VPC, and subnets

Most AWS application networks start with a Virtual Private Cloud, or VPC. A VPC is a logically isolated IP network inside one AWS region. Inside that VPC, teams create subnets, which are tied to individual Availability Zones. That detail is important because resilience in AWS often comes from spreading resources across zones, not from putting everything in one large subnet.

Subnets are usually divided into public and private roles. A public subnet has a route to an Internet Gateway. A private subnet does not. That separation is the foundation for a common pattern: expose load balancers or bastion-like entry points publicly, while application servers, databases, and internal services remain on private addresses.

Internet ingress and egress

The Internet Gateway, or IGW, is the attachment that lets a VPC exchange traffic with the public internet. It does not by itself make an instance public. The route table, subnet placement, and public IP assignment must all line up. Many diagrams omit this nuance and make the IGW look like a magic door. It is really just one part of the routing decision.

For outbound internet access from private subnets, the usual pattern is a NAT gateway. That lets internal instances fetch packages, call third-party APIs, or publish telemetry without accepting inbound connections from the internet. The tradeoff is cost and dependency. NAT gateways are managed and simple, but they can become an expensive default if every private workload sends large volumes of traffic through them.

Private connectivity beyond one VPC

When remote workers need access, AWS Client VPN provides a managed entry point that terminates VPN connections and places users onto private routes. When an on-premises datacentre needs a secure tunnel into AWS, a Virtual Private Gateway or Transit Gateway can sit on the AWS side of a site-to-site VPN. In larger estates, Transit Gateway is often preferred because it acts as a hub for many VPCs and VPNs instead of creating a mesh of one-off peering links.

VPC peering is simpler and lower overhead for a small number of direct connections, but it does not scale elegantly when the number of VPCs grows. Peering is not transitive, so if VPC A peers with B and B peers with C, A cannot automatically reach C through B.

Service access without public exposure

VPC endpoints solve a common problem: reaching AWS services privately. Gateway endpoints are used for services such as S3 and DynamoDB. Interface endpoints, powered by PrivateLink, expose a private network interface inside the VPC for supported AWS or partner services. This removes the need to send traffic out through the public internet or a NAT path just to reach another AWS service.

PrivateLink is also how many SaaS providers offer private consumption of their services. The benefit is tighter network control and simpler compliance stories. The constraint is that the connectivity is more explicit. DNS, endpoint policy, and per-service support all matter.

Security controls and failure domains

A good AWS network is not defined only by routes. Security groups provide stateful filtering close to the workload. Network ACLs provide stateless subnet-level filtering. Route tables decide where traffic can go, but these controls decide whether it should be allowed once it gets there.

So a "typical AWS network architecture" is not one fixed blueprint. It is a set of recurring decisions: which components are public, which stay private, how many zones carry the workload, whether connectivity is point-to-point or hub-and-spoke, and how much internet exposure is truly necessary. The diagram is only useful if you can explain those traffic decisions without looking at it.