Cloud Networking on AWS: The Design Decisions That Actually Matter (2026)

Cloud networking is the set of decisions that determine how your workloads reach each other, reach the internet, and reach the systems you still run yourself. On AWS that means four things, and they are not equally reversible: how you carve up address space, how VPCs connect to one another, how the cloud reaches your on-premises estate, and where traffic gets inspected on the way out.

Most cloud network guides explain what a VPC is. This one covers the decisions we get called in to unpick — usually eighteen months after they were made, when the estate has grown past the point where they were free to change.

The one decision that is expensive to reverse: CIDR planning

Everything else on this page can be changed in an afternoon. Address space cannot.

A VPC's primary CIDR block is fixed for the life of the VPC. You can add secondary blocks later, but you cannot resize or replace the primary, and you cannot change a subnet's range at all. The failure mode is predictable: someone picks 10.0.0.0/16 for the first VPC because it is the console default, then picks 10.0.0.0/16 again for the second account, and now those two networks can never be peered or attached to the same Transit Gateway, because overlapping ranges cannot route to each other.

What to settle before the first VPC exists:

• One range for the whole organisation, carved per account and per region, written down somewhere that is not a person's memory. A /16 per region per environment is generous and costs nothing.
• Leave room between allocations. Contiguous blocks look tidy and remove your ability to extend anything.
• Check what your on-premises estate already uses, including anything a future acquisition might use. Overlaps with a partner network are the reason PrivateLink exists.
• Subnets are per-availability-zone. Three AZs and three tiers is nine subnets per VPC, not three. Size them for the tier that grows — an EKS cluster consumes IPs far faster than an EC2 fleet, because every pod takes one.

The IPv4 shortage made this sharper. AWS charges for every public IPv4 address, in use or idle, so designs that used to reach for public subnets by default now cost real money to leave unexamined.

Connecting VPCs: peering, Transit Gateway or PrivateLink

Three mechanisms, three different jobs. Teams pick the wrong one because they compare them on price rather than on what they connect.

VPC peering is a one-to-one link between two VPCs. It is not transitive — if A peers with B and B peers with C, A cannot reach C. There is no hourly charge for the connection itself, only for the data crossing it. Peering is right when you have a handful of VPCs and a stable, small number of paths between them. It stops being right somewhere around five VPCs, when the number of connections you have to manage starts growing faster than the number of VPCs.

Transit Gateway is a hub. Every VPC attaches once and routes to every other attachment through route tables you control, which is the point: you can segment. Separate route tables let production attachments reach shared services without reaching development, which is the mechanism auditors are actually asking about when they ask how environments are isolated. It costs an hourly charge per attachment plus a charge per GB processed, so it is more expensive than peering at small scale and cheaper in operational terms the moment the topology stops being trivial.

PrivateLink does something the other two do not: it exposes a single service, not a network. The consumer gets an endpoint in their own VPC, and no route exists between the two networks at all. Use it when you are consuming a third-party SaaS privately, when you are publishing a service to a customer, or when the two sides have overlapping CIDR ranges and always will.

The rule we apply: peering for a couple of VPCs with a reason to be joined, Transit Gateway once segmentation matters, PrivateLink whenever the requirement is "reach this one service" rather than "join these two networks".

Reaching your own datacentre: VPN or Direct Connect

Site-to-Site VPN runs over the public internet, encrypted. It provisions in minutes, costs an hourly rate plus normal data-transfer charges, and gives you per-tunnel bandwidth in the low gigabits. Its weakness is not throughput, it is variance — latency and jitter follow whatever the public internet is doing that afternoon.

Direct Connect is a dedicated circuit into an AWS location, ordered through a partner. It takes weeks to provision, costs a port charge plus lower per-GB egress rates, and delivers consistent latency. It pays for itself in two situations: sustained high egress volumes, where the reduced transfer rate outruns the port cost, and workloads that are sensitive to jitter rather than to bandwidth — database replication, VDI, voice, anything doing chatty synchronous calls across the link.

The pattern we deploy most often is both: Direct Connect as the primary path with a Site-to-Site VPN as automatic failover. A single circuit is a single point of failure, and a second circuit costs far more than a VPN that sits idle.

Segmentation, and what an auditor is really asking

"Is the environment segmented?" is a networking question with a compliance answer, and the evidence has to come from configuration, not from a diagram.

• Security groups are stateful and attach to resources. Return traffic is allowed automatically. They are the primary control and should reference other security groups rather than IP ranges wherever possible — a rule that says "from the app tier" keeps meaning the right thing when the app tier's addresses change.
• Network ACLs are stateless and attach to subnets. Every rule needs a matching return rule, which is why hand-written NACLs are a common source of failures that look like application bugs. Use them as a coarse backstop, not as the main control.
• Route tables are the real segmentation boundary. Two subnets with no route between them cannot talk regardless of what any security group permits.
• A centralised inspection VPC — traffic from every spoke routed through a firewall before it leaves — is what turns "we have security groups" into egress filtering you can produce evidence for. PCI DSS scope reduction and ISO 27001 network-control objectives both land here.

For regulated estates, the practical detail is that the design has to make evidence cheap to produce. If demonstrating isolation requires an engineer to export route tables by hand each quarter, the design is wrong even if the isolation is real.

The costs that appear in month three

Nothing in AWS networking is expensive per unit. The bills that surprise people come from architecture, not from rates.

• NAT Gateway charges an hourly rate and a rate per GB processed. Every private subnet pulling packages, container images or OS updates through NAT pays the per-GB charge on all of it. A VPC endpoint for S3 and ECR removes that traffic from NAT entirely and is usually the single largest network saving available in a standard estate.
• Cross-AZ traffic is charged in both directions. A chatty service spread across three AZs for resilience is paying for that resilience on every request. It is often still the right call — but it should be a decision, not an accident.
• Transit Gateway charges per attachment and per GB, so routing traffic through the hub that could have gone direct has a running cost.
• Idle public IPv4 addresses cost money. Elastic IPs held "just in case" are a line item now.

None of these have fixed rates worth quoting — they vary by region and change. What does not change is the shape: the costs sit in NAT, in cross-AZ, and in anything that traverses a hub unnecessarily. Those are the three places to look first.

Monitoring the network layer

Networking failures rarely announce themselves. They show up as latency, retries and intermittent timeouts that get blamed on the application for a week.

VPC Flow Logs are the primary evidence source — they record accepted and rejected connections at the interface level, which answers both "what is talking to what" and "what tried to". Route them to CloudWatch Logs or S3 and query with Logs Insights or Athena; the rejected-connection view is usually where a misconfigured security group finally becomes visible.

Beyond that, the useful signals are NAT Gateway processed bytes and error counts, Transit Gateway per-attachment throughput, VPN tunnel state, and Direct Connect connection state and light levels. CloudWatch carries all of them — our AWS CloudWatch monitoring guide covers how to alarm on them without generating noise. For estates that do not stop at the AWS boundary, we run these alongside on-premises device polling in Zabbix, and cover the whole picture in our NOC monitoring services — the hybrid case is set out in network infrastructure monitoring in hybrid cloud environments.

Frequently asked questions

What is cloud networking?

Cloud networking is the configuration and operation of connectivity between cloud resources, the internet, and any infrastructure you run yourself. On AWS it consists of VPCs and subnets for address space, security groups and route tables for control, and Transit Gateway, PrivateLink, VPN or Direct Connect for connecting networks together.

Should I use VPC peering or Transit Gateway?

Peering for a small, stable number of VPCs with a clear reason to be joined — it has no hourly cost and is simple. Transit Gateway once you need segmentation between environments or the number of paths starts growing awkwardly, because it centralises routing into route tables you can audit.

Is Direct Connect worth it over a VPN?

It is worth it for sustained high egress volumes, where the lower per-GB rate outruns the port charge, and for workloads sensitive to jitter rather than bandwidth. For everything else a Site-to-Site VPN is faster to provision and cheaper. Most production estates run Direct Connect primary with VPN failover.

Why is my AWS data transfer bill higher than expected?

Usually NAT Gateway processing charges on traffic that should have used a VPC endpoint, and cross-AZ traffic between chatty services. Check those two before anything else — S3 and ECR endpoints alone often remove a large share of NAT volume.

How do I prove network segmentation to an auditor?

Route tables and security group rules are the evidence, not the diagram. A centralised inspection VPC with egress filtering, separate Transit Gateway route tables per environment, and VPC Flow Logs retained for the audit period cover what ISO 27001 and PCI DSS assessors ask for.

Can I change a VPC CIDR block later?

No. The primary CIDR is fixed for the life of the VPC and subnet ranges cannot be changed at all. You can add secondary CIDR blocks, but overlapping ranges between VPCs can never be peered or routed to each other — which is why address planning is the one decision worth getting right before the first VPC exists.

Who designs this for you?

We do — cloud infrastructure services covers VPC and connectivity design, migration and ongoing operation, as an AWS Advanced Consulting Partner and a CERT-In empanelled auditor, so the network design and the evidence an audit needs get built at the same time.