Amazon VPC, CIDR & Subnets

A VPC is your logically isolated network in AWS

Amazon Virtual Private Cloud (Amazon VPC) lets you define a logically isolated virtual network and launch AWS resources into it. You choose address ranges, create subnets, configure routing, and attach security and connectivity controls around the workload. A VPC belongs to one AWS Region, but its subnets are placed in specific Availability Zones. This is why multi-AZ architectures normally create corresponding subnets in two or more AZs rather than treating one subnet as a Regional resource.

VPC design starts with IP address planning. IPv4 ranges use Classless Inter-Domain Routing (CIDR) notation such as 10.0.0.0/16; IPv6-enabled VPCs use IPv6 CIDR blocks as well. CIDR is more than notation: the prefix length determines the size of the address range, and overlapping ranges can later prevent straightforward connectivity patterns such as VPC peering. Good planning therefore leaves space for growth and for future connections to other VPCs or on-premises networks.

CIDR and subnet sizing are technical design parameters

For IPv4, AWS currently allows a VPC primary CIDR between /16 and /28. An IPv4 subnet is also sized between /16 and /28 and must fit inside a VPC IPv4 range. In every IPv4 subnet, AWS reserves the first four addresses and the last address, so a /28 has 16 total addresses but fewer usable resource addresses. These are service rules rather than generic IP networking rules and are useful when judging whether a subnet has enough usable capacity.

Subnet address space should reflect the resources likely to consume IP addresses: EC2 network interfaces, load-balancer nodes, containers using VPC networking, VPC endpoints, managed databases and other services can all require addresses. Exhaustion is an operational failure mode, so subnet planning is not merely an exam arithmetic exercise. Exact quotas can change and some are adjustable; current AWS documentation should be the source of truth before production sizing.

• A smaller prefix number means a larger address range: /16 contains more IPv4 addresses than /24, and /24 contains more than /28.
• A subnet is an Availability Zone-scoped network segment, even though the VPC itself spans the Region.
• AWS reserves five IPv4 addresses in every subnet CIDR; do not plan capacity from the raw CIDR count alone.
• Avoid overlapping address plans when networks may later need peering or hybrid routing.

Public and private are routing properties

A subnet does not become public because of its name. In the common IPv4 pattern, a public subnet has a route to an internet gateway and a resource also needs a public IPv4 address or Elastic IP as applicable for direct internet communication. A private subnet does not provide that direct route for its resources; outbound internet access is often provided through a NAT gateway while inbound application access comes through a public load balancer, API layer or another controlled entry point.

Isolated subnets go further by having no route to the public internet at all. They can still communicate with destinations permitted by their route tables, for example other private tiers or supported AWS services through VPC endpoints. The architecture should place resources according to the connectivity they require: public endpoints at the edge, application and database resources privately where direct internet reachability is unnecessary.

DNS and observability are part of VPC networking

VPC configuration also controls DNS behavior and integrates with Route 53 Resolver. Private hosted zones can provide DNS names visible from associated VPCs, while public DNS uses internet-visible hosted zones. DNS resolution and IP routing solve different layers of the path: successful name resolution only returns an address; the packet still needs a valid route and security authorization to reach that address.

For troubleshooting and security analytics, VPC Flow Logs can capture information about IP traffic flows for supported network interfaces and scopes. The default flow-log record is built around a network flow and includes fields such as source, destination and protocol. Flow logs do not replace application logs or packet inspection, but they are valuable evidence when a route or security control behaves differently from what an operator expects.