Blog / How to Design AWS Network Topologies
26 August 2026 AWS

How to Design AWS Network Topologies

Designing a robust AWS network topology is one of the most important steps when building cloud infrastructure. Your network is the foundation that everything else runs on — compute, databases, APIs, and microservices all depend on it being secure, scalable, and reliable.

This guide walks through the core building blocks of AWS networking, from VPCs and subnets to Transit Gateway and hybrid connectivity, and explains how to put them together into a production-ready architecture.

1. Overview: AWS Networking Building Blocks

AWS networking is built around a set of core services that work together to form a complete network topology:

  • VPC (Virtual Private Cloud) — your isolated network
  • Subnets — subdivisions of your VPC, tied to availability zones
  • Route Tables — control traffic routing within the VPC
  • Internet Gateway (IGW) — enables internet access for public subnets
  • NAT Gateway — allows private subnets to reach the internet
  • Security Groups & NACLs — traffic filtering at instance and subnet level
  • Transit Gateway — connects multiple VPCs and on-premises networks
  • Direct Connect / VPN — hybrid connectivity to on-premises data centres

Understanding how these components relate to each other is the first step in designing a sound AWS network topology.

2. VPC Fundamentals

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you launch resources. Each VPC is defined by a CIDR block (e.g. 10.0.0.0/16) and is specific to a single AWS region.

Key decisions when designing a VPC:

  • CIDR size: Choose a large enough range (typically /16) to allow growth without overlap with on-premises or peered VPCs.
  • One VPC or many: Larger organisations typically use one VPC per environment (dev, staging, prod) or one per application, managed through a shared services or hub-and-spoke model.
  • Non-overlapping CIDRs: If you plan to peer VPCs or connect to on-premises networks, ensure CIDR ranges do not overlap.

A common starting point is 10.0.0.0/16 for production and 10.1.0.0/16 for staging, leaving room to add more environments.

3. Subnet Design

Subnets are subdivisions of your VPC and are always associated with a single Availability Zone (AZ). Spreading resources across multiple AZs is the foundation of high availability on AWS.

A typical three-tier subnet layout looks like this:

  • Public subnets — hosts load balancers, NAT gateways, and bastion hosts. Resources here can have public IPs and direct internet access via the Internet Gateway.
  • Private application subnets — hosts compute (EC2, ECS, Lambda). No direct internet access; outbound traffic routes through a NAT Gateway in the public subnet.
  • Private data subnets — hosts databases (RDS, Redshift, ElastiCache). Should be the most isolated tier, with no NAT access needed.

Create one set of these tiers per AZ. For a three-AZ deployment you'd have nine subnets total. A consistent naming scheme (e.g. public-1a, app-1b, data-1c) makes diagrams and automation much easier.

4. Security Groups and Network ACLs

AWS provides two layers of traffic filtering:

  • Security Groups — stateful firewalls attached to individual resources (EC2 instances, RDS, ECS tasks). They operate on allow rules only; all other traffic is implicitly denied. Changes take effect immediately.
  • Network ACLs (NACLs) — stateless firewalls attached at the subnet level. They support both allow and deny rules, evaluated in numeric order. Because they are stateless, you must explicitly allow return traffic.

Best practices:

  • Use security groups as your primary control layer
  • Reference security groups by ID in rules (not CIDR) where possible
  • Use NACLs to enforce coarse-grained rules, such as blocking entire IP ranges
  • Never open 0.0.0.0/0 on sensitive ports to the internet
  • Use separate security groups per application tier

5. Internet Access: IGW and NAT Gateway

Controlling how traffic enters and exits the internet is critical for security.

  • Internet Gateway (IGW) — attach one to your VPC to allow inbound and outbound internet access for resources in public subnets. The route table for public subnets must have a 0.0.0.0/0 route pointing to the IGW.
  • NAT Gateway — deploy one per AZ in a public subnet. Private subnets route 0.0.0.0/0 to the NAT Gateway, allowing outbound internet access (e.g. for package updates) without exposing the resource to inbound traffic. NAT Gateway is managed and highly available within its AZ.
  • Egress-Only Internet Gateway — for IPv6 traffic from private resources that should not be reachable from the internet.

For cost optimisation in non-production environments, a single shared NAT Gateway is acceptable. In production, use one per AZ to avoid cross-AZ data transfer charges and single points of failure.

6. Transit Gateway

AWS Transit Gateway (TGW) acts as a regional network hub. It connects multiple VPCs, AWS accounts, and on-premises networks through a single managed resource, replacing complex VPC peering meshes.

When to use Transit Gateway:

  • You have more than two or three VPCs that need to communicate
  • You need shared services (DNS, security appliances) accessible from all VPCs
  • You want a single attachment point for VPN or Direct Connect
  • You need to route traffic through a centralised inspection firewall

Transit Gateway supports route tables that let you control which VPCs can communicate with each other and which traffic flows through inspection. A common pattern is to separate spoke VPCs from a shared services VPC, with traffic only flowing through the hub.

For multi-region architectures, use Transit Gateway inter-region peering to connect regional hubs, enabling a global backbone.

7. Hybrid Connectivity

Most organisations need to connect their AWS environment to on-premises data centres or offices. AWS provides two primary options:

  • AWS Site-to-Site VPN — an encrypted IPSec tunnel over the internet. Quick to provision (minutes), lower cost, but subject to public internet latency and throughput limits. Suitable for backup paths or lower-bandwidth workloads.
  • AWS Direct Connect — a dedicated private physical connection from your data centre to an AWS Direct Connect location. Consistent latency, higher throughput (1 Gbps to 100 Gbps), and no public internet traversal. Takes weeks to provision but is the preferred option for production workloads with high bandwidth requirements.

A common resilient design is to use Direct Connect as the primary path with a Site-to-Site VPN as failover. Both attach to a Transit Gateway for centralised management.

8. Multi-Account Architecture

AWS recommends using multiple accounts to provide security isolation, billing separation, and blast radius reduction. The standard pattern is built on AWS Organizations:

  • Management account — root of the organisation, billing, and SCPs only
  • Security / Audit account — centralised logging, GuardDuty, SecurityHub
  • Shared Services account — DNS, directory services, shared Transit Gateway
  • Workload accounts — one per environment (dev, staging, prod) or per team

The AWS Landing Zone or Control Tower service helps automate this structure. Networking typically lives in a dedicated Network account, with Transit Gateway shared via Resource Access Manager (RAM) to all spoke accounts.

9. High Availability Design

AWS guarantees availability at the service level, but your architecture must be designed for resilience. Key principles:

  • Deploy across at least two AZs — most AWS services are AZ-scoped. A single AZ outage should not take down your application.
  • Use managed load balancers — Application Load Balancer (ALB) for HTTP/HTTPS, Network Load Balancer (NLB) for TCP/UDP. Both are multi-AZ by default.
  • Use Auto Scaling — scale compute horizontally in response to demand, spread across AZs.
  • Multi-AZ databases — RDS Multi-AZ, Aurora with read replicas, ElastiCache with replica nodes.
  • One NAT Gateway per AZ — avoid routing private traffic across AZ boundaries for both cost and resilience.

10. PrivateLink and VPC Endpoints

By default, AWS API calls (e.g. to S3, DynamoDB, or SSM) traverse the public internet. VPC Endpoints keep this traffic on the AWS backbone:

  • Gateway Endpoints — free; support S3 and DynamoDB. Add routes to your route table pointing to the endpoint.
  • Interface Endpoints (PrivateLink) — provision an ENI in your subnet with a private IP. Supports hundreds of AWS services and third-party SaaS products. Charged per hour and per GB.

Use PrivateLink to expose internal services between VPCs or accounts without peering entire networks — only the specific service is reachable, not the whole VPC CIDR.

11. Monitoring and VPC Flow Logs

Good network topology design includes observability from day one.

  • VPC Flow Logs — capture metadata about IP traffic flowing through your VPC, subnets, or individual ENIs. Send to CloudWatch Logs or S3. Invaluable for troubleshooting and security investigations.
  • AWS Network Manager — centrally manage and monitor your global network, including Transit Gateway and Direct Connect.
  • Reachability Analyser — verify that a network path between two endpoints is actually open, without sending test traffic.
  • GuardDuty — threat detection that analyses VPC Flow Logs and DNS logs for suspicious activity automatically.

Enable Flow Logs on all production VPCs and set up alerts for unexpected traffic patterns.

12. Diagramming Your AWS Network

A clear network diagram is essential for communicating your architecture to the wider team and for documenting it for future reference.

What to include in an AWS network diagram:

  • AWS region and availability zone boundaries
  • VPC CIDR blocks
  • Public, application, and data subnet tiers with CIDR ranges
  • Internet Gateway, NAT Gateways, and their subnets
  • Load balancers and their listener configuration
  • Transit Gateway and VPC attachments
  • VPN or Direct Connect connections to on-premises
  • Key security group rules (at a high level)
  • VPC Endpoints / PrivateLink
  • Route table summaries

Use official AWS icon sets (available in Diagram App's icon library under the AWS category) to ensure your diagrams are immediately recognisable to any AWS engineer.

Conclusion

Designing an AWS network topology well from the start saves significant time and pain later. Starting with a well-thought-out VPC design, using multiple AZs, applying the principle of least privilege with security groups, and planning for hybrid connectivity gives you a foundation that can scale with your workloads.

Transit Gateway, PrivateLink, and multi-account architecture are the tools that take you from a single VPC proof-of-concept to a production-grade global network. And a clear, up-to-date network diagram is what keeps your team aligned as that network grows and evolves.

Ready to diagram your AWS network? Open Diagram App — free, in your browser, with AWS icons built in.