AWS VPC

What AWS VPC actually is

Amazon VPC is not a server you can benchmark — it is the network fabric that nearly everything else in AWS runs inside. When you launch an EC2 instance, an RDS database, or a Lambda in a VPC, the VPC defines the isolated virtual network they live in: your own CIDR block, your own subnets, your own route tables, and your own gateways. AWS introduced it in 2009, and since the EC2-VPC platform change, every new account gets a default VPC in each Region so you can launch instances without touching networking at all. That default hides how much control you actually have.

Once you move past the defaults, the building blocks are the reason we list VPC in our private networking category. Subnets carve your address space per Availability Zone. Route tables decide where traffic goes. An internet gateway gives subnets a path to the internet; a NAT gateway gives private subnets an outbound-only path. Security groups act as stateful firewalls at the instance level, network ACLs as stateless filters at the subnet level. VPC endpoints (Gateway type for S3 and DynamoDB, Interface/PrivateLink for everything else) keep traffic off the internet entirely. Peering connects two VPCs; Transit Gateway acts as a hub for many VPCs, VPNs, and Direct Connect links. VPC Flow Logs records who talked to whom, Traffic Mirroring copies packets to your own inspection appliances, and Reachability Analyzer answers "why can't this host reach that one" without a support ticket.

In our view that breadth is both the selling point and the trap. No other provider gives you this many knobs on a virtual network; no other provider makes it this easy to build something expensive by accident.

Pricing: what you really pay

Start with the part that surprises people: the VPC itself is free. AWS's documentation states plainly, "There's no additional charge for using a VPC." Create fifty VPCs with subnets, route tables, security groups, peering-free architecture — you pay nothing for the network objects themselves. Where the bill comes from is everything attached to them.

The big line item is the NAT gateway. AWS charges per "NAT Gateway-hour" — $0.045 per hour in the pricing example (US East, Ohio) — plus $0.045 per GB processed through it, plus standard data transfer charges. A regional NAT gateway spanning three Availability Zones is billed three times hourly: $0.135 per hour in the worked example, before any bytes move. A modest private-subnet setup with one NAT gateway per AZ therefore costs roughly $100/month in NAT hours alone before data processing, and the data processing charge stacks on top. AWS's own advice is sound: route S3 and DynamoDB traffic through Gateway VPC endpoints, which carry no hourly or processing charge.

Public IPv4 addresses are now billed too (the free tier includes 750 hours of public IPv4 with the EC2 service), and data transfer out to the internet is $0.09 per GB in the same pricing example. IPAM has a usable free tier for single-Region work; the Advanced tier is $0.00027 per active IP address per hour. VPC Encryption Controls is $0.15 per VPC per hour when you turn it on. Peering and Transit Gateway add per-GB and attachment charges of their own. None of this is hidden — the pricing page is detailed — but the totals depend entirely on how you wire things together.

We'd summarize it this way: $0 to build the network, real money to operate it. The most common expensive mistake we see is duplicating NAT gateways per AZ "for high availability" in a dev environment that never needed them.

Performance & infrastructure

The infrastructure underneath is AWS's, which sets a high floor. The cloud spans 39 geographic Regions and, by AWS's own count on the regions and AZ page, 124 Availability Zones (another AWS page says 123 — the number moves as regions launch), plus 750+ CloudFront edge locations and several dozen Local Zones and Wavelength Zones. Every Region has at least three isolated AZs with independent power and cooling, connected by redundant metro fiber, and all inter-AZ traffic is encrypted. EU, US, and APAC coverage is complete, with Regions in Ireland, Frankfurt, London, Paris, Stockholm, Spain, Milan, Zurich, both US coasts, Tokyo, Seoul, Singapore, Sydney, Mumbai, São Paulo, Cape Town, Tel Aviv, and more.

For a networking product, "performance" means latency placement and throughput headroom. Put your subnets and workloads close to your users, and inter-AZ design decisions (synchronous replication across AZs is explicitly supported by the network capacity) give you fault tolerance that single-datacenter VPS providers cannot match. We publish our own network and disk measurements for compute hosts at /benchmarks; VPC itself is not a benchmarkable unit, so treat provider network claims — including ours — with care and measure your own topology.

Reliability is the other side of this. The multi-AZ design is genuine engineering, not marketing: AZ failures have happened and well-architected multi-AZ deployments rode through them. The caveat is that the blast radius of a misconfiguration is yours alone. AWS gives you isolation and redundancy; it does not give you a correct routing table.

Where it falls short

Complexity is the headline complaint, and it is earned. There are dozens of VPC features, each with its own limits, quotas, and documentation chapter. New teams routinely ship a topology that works and is also 3x the price it needed to be — NAT gateways per AZ, cross-AZ traffic, public IPv4 sprawl, data transfer out.

Cost transparency is fine at the unit level and poor at the architecture level. NAT gateway hourly plus per-GB charges, public IPv4 charges, cross-AZ data transfer, and peering/Transit Gateway fees interact. A small change in routing can move hundreds of dollars a month without any obvious signal.

There is no SLA attached to VPC itself. The EC2 SLA covers instances; the VPC is the network they sit in. When the network control plane has a bad day — and it has, publicly — your recourse is whatever the service credits for the affected services give you. In our view that is a real gap in "support & SLA honesty" for a product this foundational.

The console and CLI are powerful but assume you know AWS's vocabulary. Teams coming from a VPS provider or a flat VNet experience usually need a few weeks before the mental model clicks. And once you are deep in VPC design, you are deep in AWS: porting a heavily peered, Transit Gateway-centric topology to another cloud is a project, not a weekend.

Who should pick this

We'd pick VPC when you are already committed to AWS and need network control that a default VPS provider cannot give you: multi-tier applications with private subnets, hybrid connectivity over VPN or Direct Connect, strict segmentation between environments, or compliance workloads that require flow logs and explicit egress control. Enterprises with on-premise Windows and Active Directory estates get a coherent story here that few alternatives match.

We would not point a solo developer or a small SaaS at a hand-built multi-AZ VPC design on day one. The default VPC plus security groups is enough for most early products; reach for the advanced pieces when you have a reason. If your needs are a single public server and simple firewall rules, a transparent VPS provider (see our private networking picks) will be cheaper and faster to reason about.

For Microsoft-centric shops, compare honestly with Azure's VNets before committing — the two are equivalent in capability and equivalent in complexity. For budget-conscious teams, the deciding factor is usually data transfer and NAT costs, not instance pricing.

One design point we appreciate: private IPv4 addresses (RFC 1918) inside your VPC are not charged, and Gateway VPC endpoints for S3 and DynamoDB carry no hourly or per-GB fee. Teams that route carefully can keep the network layer genuinely close to free even at scale. The opposite is also true: careless egress patterns are the fastest way to turn a $0 network into a four-figure monthly line item. We recommend modelling data flow before picking subnet design, not after.

Key takeaways

• The VPC itself is free — AWS states there is no additional charge for using a VPC; the cost lives in NAT gateways ($0.045/hour plus $0.045/GB), public IPv4, and data transfer out ($0.09/GB in AWS's own example).
• NAT gateways are billed hourly per AZ; a three-AZ regional NAT runs $0.135/hour before data processing in AWS's worked example.
• 39 Regions and roughly 124 Availability Zones, with complete EU, US, and APAC coverage and true multi-AZ fault isolation.
• Full IPv6 support (dual-stack and IPv6-only subnets) at no extra charge, and free baseline DDoS protection via AWS Shield Standard.
• No SLA on the VPC itself — the EC2 and service SLAs cover what runs inside it, which we consider a gap.
• Best fit for AWS-committed teams needing segmented networks and hybrid connectivity; overkill for a single simple server.

Sources

• https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
• https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html
• https://aws.amazon.com/vpc/pricing/
• https://aws.amazon.com/vpc/faqs/
• https://aws.amazon.com/about-aws/global-infrastructure/regions_az/
• https://aws.amazon.com/about-aws/globalinfrastructure
• https://aws.amazon.com/shield/features/
• https://en.wikipedia.org/wiki/Amazon_Web_Services