AWS VPC Explained for Beginners: Subnets, CIDR, Routing, and Gateways

AWS VPC networking diagram showing public, private, and isolated subnets, IP address ranges, routing, an Internet Gateway, and a NAT Gateway.

Understand AWS VPC networking from the beginning. Learn how IP addresses, CIDR blocks, subnets, route tables, Internet Gateways, and NAT Gateways work together, with clear examples.

AWS VPC networking becomes much easier to understand when we start with one simple idea: a VPC defines your network, a subnet divides that network into smaller address ranges, and routing determines where traffic can travel.

Imagine you have a company with three servers: one runs your website, another handles backend requests, and the third stores customer information. All three need to communicate, but they should not necessarily have the same network access.

This is where IP addresses, CIDR, VPCs, subnets, route tables, and gateways become important.

We'll explore each concept using the same examples throughout the article. No AWS account, deployment, or prior networking experience is required.

What you'll learn:

  • What an IP address represents and how private IP addressing works.

  • How CIDR notation defines an IP address range.

  • How to calculate subnet boundaries using /16, /24, /25, /26, and other prefixes.

  • How to choose valid VPC and subnet CIDR blocks.

  • Why AWS reserves certain IP addresses in every subnet.

  • Why networks are divided into public, private, and isolated subnets.

  • How routing, Internet Gateways, NAT Gateways, and Security Groups work together.

  • How to reason about network communication without relying on memorized configurations.

1. First, What Is a Network?

Before understanding AWS VPCs, let's understand an ordinary computer network.

Suppose you have three devices connected to the same Wi-Fi router at home.

DeviceIP AddressLaptop192.168.1.10Mobile phone192.168.1.11Desktop computer192.168.1.12Router192.168.1.1

These devices can communicate with one another because they are connected through a network.

For example, suppose your laptop needs to send a file to your desktop.

The laptop needs to know where to send the information. An IP address helps identify the destination.

What is an IP address?

IP stands for Internet Protocol.

An IP address identifies a network interface and is used to route packets of data between devices.

Think of it like a postal address.

A delivery service uses an address to determine where a parcel should go. Similarly, network devices use IP addresses to decide where packets should be delivered.

An example IPv4 address is:

192.168.1.10

An IPv4 address contains four numbers separated by dots. Each number is called an octet and represents eight binary bits.

Each octet can have a value from 0 to 255.

Because there are four octets, an IPv4 address contains 32 bits in total.

Public IP vs. Private IP

IPv4 addresses are commonly divided into public and private address spaces.

Private IP addresses are intended for communication inside private networks. They are not directly routed across the public internet.

The standard private IPv4 ranges are:

Private RangeCIDR Block10.0.0.0 – 10.255.255.25510.0.0.0/8172.16.0.0 – 172.31.255.255172.16.0.0/12192.168.0.0 – 192.168.255.255192.168.0.0/16

Public IP addresses are globally routable addresses used for internet connectivity.

For example, 8.8.8.8 is a public IPv4 address.

In AWS, an EC2 instance may have a private IPv4 address, a public IPv4 address, or both, depending on its configuration.

But before discussing EC2 connectivity, we need to understand how networks define their IP ranges.

2. What Is CIDR?

CIDR stands for Classless Inter-Domain Routing.

It is a way to represent a network's IP address range using an address and a prefix length.

Consider:

10.0.2.0/24

This contains two parts:

  • 10.0.2.0 — the network address.

  • /24 — the network prefix length.

The prefix tells us how many bits belong to the network portion of the address.

What does /24 mean?

An IPv4 address has 32 bits.

For a /24 network:

  • 24 bits identify the network.

  • 8 bits remain for addresses within the network.

The first three octets contain exactly 24 bits, so in this example they remain fixed:

10.0.2

The fourth octet can vary from 0 through 255.

Therefore, the full address range is:

10.0.2.0 to 10.0.2.255

That's 256 IPv4 addresses.

How do we calculate the total number of addresses?

The formula is:

Total IPv4 addresses = 2^(32 − CIDR prefix)

For /24:

  • 32 − 24 = 8

  • 2⁸ = 256

For /16:

  • 32 − 16 = 16

  • 2¹⁶ = 65,536

For /26:

  • 32 − 26 = 6

  • 2⁶ = 64

Here's the comparison:

CIDRNetwork BitsRemaining BitsTotal IPs/16161665,536/2020124,096/23239512/24248256/25257128/2626664/2828416

One important rule:

As the CIDR prefix number increases, the IP address range becomes smaller.

This happens because more bits are reserved to identify the network, leaving fewer bits for individual addresses.

3. What Is a Subnet Mask?

A subnet mask is another way to represent the network and host portions of an IP address.

For example:

CIDRSubnet Mask/16255.255.0.0/20255.255.240.0/23255.255.254.0/24255.255.255.0/25255.255.255.128/26255.255.255.192

But why does /24 become 255.255.255.0?

Let's look at binary.

Each IPv4 octet contains eight bits.

A binary 1 in the subnet mask identifies a network bit. A 0 identifies a host bit.

For /24:

  • First octet: 11111111 = 255

  • Second octet: 11111111 = 255

  • Third octet: 11111111 = 255

  • Fourth octet: 00000000 = 0

Therefore:

/24 = 255.255.255.0

For /26, the first 26 bits are network bits:

  • First three octets: 255.255.255

  • Fourth octet: 11000000 = 192

Therefore:

/26 = 255.255.255.192

You don't need to memorize every subnet mask immediately. The important thing is to understand that the mask tells us which bits are fixed and which can change.

Now let's see why this matters when creating subnets.

4. Understanding Subnets: The Most Important Part

A subnet, or subnetwork, is a smaller logical network carved out of a larger IP address block.

Imagine you own a building with 256 numbered rooms.

Rather than treating the entire building as one department, you divide it into four sections:

  • Department A: Rooms 0–63

  • Department B: Rooms 64–127

  • Department C: Rooms 128–191

  • Department D: Rooms 192–255

The building is our larger network.

Each department is a subnet.

Each room represents an individual address.

Dividing the building does not create more rooms. It simply organizes the existing rooms into smaller groups.

Subnetting works in exactly the same way.

Example A: Dividing a /24 network into two /25 subnets

Suppose we start with:

10.0.2.0/24

Its complete address range is:

10.0.2.0 – 10.0.2.255

That's 256 addresses.

Now we want two equally sized subnets.

A /25 contains 128 addresses, so we can split the original block into:

SubnetCIDRAddress RangeSubnet A10.0.2.0/2510.0.2.0 – 10.0.2.127Subnet B10.0.2.128/2510.0.2.128 – 10.0.2.255

Notice the difference between their network addresses.

The first starts at .0.

The second starts at .128.

Why .128?

Because each /25 occupies 128 consecutive addresses.

Starting at 0, the first block ends at 127.

The next block must start at 128.

We now have two separate, non-overlapping address ranges.

Example B: Dividing the same /24 into four /26 subnets

Let's go one step further.

A /26 contains:

2^(32 − 26) = 64 addresses.

The original /24 has 256 addresses, so we can divide it into four equal /26 blocks.

SubnetCIDRFirst AddressLast AddressA10.0.2.0/2610.0.2.010.0.2.63B10.0.2.64/2610.0.2.6410.0.2.127C10.0.2.128/2610.0.2.12810.0.2.191D10.0.2.192/2610.0.2.19210.0.2.255

Each subnet contains 64 addresses.

The valid starting points for a /26 within this /24 are:

0, 64, 128, 192

These boundaries are determined by the subnet mask, not by an AWS-specific naming convention.

Example C: Why is 10.0.2.70/26 not the network address?

Let's examine:

10.0.2.70/26

Since the /26 blocks start at 0, 64, 128, and 192, the address .70 falls inside the block beginning at .64.

Its network is:

10.0.2.64/26

Its complete range is:

10.0.2.64 – 10.0.2.127

So .70 is an address within that subnet, not its network identifier.

You might see 10.0.2.70/26 used to describe a host interface, but the canonical CIDR block is 10.0.2.64/26.

This distinction is useful when reading server network configurations.

Example D: What if the subnet is larger than /24?

So far, our examples have used prefixes larger than /24.

Now consider:

10.0.2.0/23

A /23 contains:

2^(32 − 23) = 512 addresses.

Its range is:

10.0.2.0 – 10.0.3.255

Notice that the third octet changes.

This happens because a /23 does not keep all the first three octets fixed.

Its subnet mask is:

255.255.254.0

The third octet is grouped in blocks of two.

Some valid /23 boundaries are:

  • 10.0.0.0/23

  • 10.0.2.0/23

  • 10.0.4.0/23

  • 10.0.6.0/23

For example:

10.0.2.0/23 includes everything from 10.0.2.0 through 10.0.3.255.

Therefore, if this /23 subnet already exists, we cannot create 10.0.3.0/24 as another subnet in the same VPC because it overlaps the existing range.

Example E: Understanding /20

Consider:

10.0.16.0/20

The subnet mask is:

255.255.240.0

Its total size is:

2^(32 − 20) = 4,096 addresses.

The full range is:

10.0.16.0 – 10.0.31.255

Why does the third octet end at 31?

Because the relevant block size in the third octet is:

256 − 240 = 16

So the valid third-octet boundaries are:

0, 16, 32, 48, 64, ...

A /20 starting at 10.0.16.0 therefore covers third-octet values 16 through 31.

The next /20 begins at:

10.0.32.0/20

A simple method for calculating subnet boundaries

For common IPv4 subnet calculations:

  1. Convert the CIDR prefix into its subnet mask.

  2. Find the octet where the mask is neither 255 nor 0.

  3. Calculate the block size using 256 − mask value.

  4. Find the appropriate starting boundary.

  5. Identify the last address immediately before the next boundary.

For /26:

  • Mask: 255.255.255.192

  • Block size: 256 − 192 = 64

  • Boundaries: 0, 64, 128, 192

For /20:

  • Mask: 255.255.240.0

  • Block size in the third octet: 256 − 240 = 16

  • Boundaries: 0, 16, 32, 48, ...

This method makes subnetting easier to calculate without memorizing every possible CIDR block.

5. What Is an AWS VPC?

Now that we understand IP ranges and subnetting, AWS VPCs become much easier to explain.

Amazon VPC (Virtual Private Cloud) is a logically isolated virtual network within AWS.

A VPC provides an address space where AWS resources can communicate using network routes and security controls.

Suppose we create a VPC with:

10.0.0.0/16

That block covers:

10.0.0.0 – 10.0.255.255

It contains 65,536 IPv4 addresses.

We can create smaller subnets inside this range, assign resources to them, and configure how their traffic flows.

Can I choose any IP address for my VPC?

No. The address block must be valid, correctly aligned, and comply with AWS restrictions.

For a typical VPC, use an appropriate private IPv4 range.

Examples of valid, correctly aligned VPC CIDR choices include:

  • 10.0.0.0/16

  • 10.1.0.0/16

  • 10.100.0.0/16

  • 172.20.0.0/16

  • 192.168.0.0/16

AWS generally allows an IPv4 VPC CIDR block between /16 and /28 in size. Additional CIDR blocks and some non-RFC1918 IPv4 ranges are supported subject to restrictions.

For normal applications, private RFC1918 ranges are the preferred starting point.

Why do we use 10.0.0.0/16?

There is nothing magical about 10.0.0.0.

We chose it because:

  • It belongs to private IPv4 address space.

  • It provides a convenient range for creating smaller subnets.

  • Its /16 prefix makes the calculations straightforward.

We could use 10.100.0.0/16 instead.

The main consideration is that the address range must be valid and should avoid conflicts with networks we may need to connect to later.

For example, overlapping CIDR blocks can create complications when connecting VPCs or on-premises networks.

6. How Do We Choose Subnets Inside a VPC?

Suppose our VPC is:

10.0.0.0/16

We decide to create four /24 subnets.

Remember that a /16 VPC allows third-octet values from 0 to 255, with the fourth octet ranging from 0 to 255.

We could choose:

SubnetCIDRTotal IPsA10.0.1.0/24256B10.0.2.0/24256C10.0.3.0/24256D10.0.4.0/24256

These subnets are valid because:

  1. Each subnet is contained within the VPC's address range.

  2. Each /24 block begins on a proper network boundary.

  3. None of the subnets overlap.

Why not 10.1.0.0/24?

Because our VPC uses:

10.0.0.0/16

Its full range ends at:

10.0.255.255

10.1.0.0/24 is outside that range.

However, if the VPC were 10.1.0.0/16, that subnet could be valid.

Why not 10.0.2.1/24?

For a /24 subnet, the canonical network address has the fourth octet set to zero.

10.0.2.1 is an address inside 10.0.2.0/24.

When describing the subnet itself, use:

10.0.2.0/24

A host configuration using 10.0.2.1/24 describes an interface address and its network prefix, not a separate subnet range.

Can we create 10.0.2.0/24 and 10.0.2.128/25?

No.

The first subnet covers:

10.0.2.0 – 10.0.2.255

The second subnet covers:

10.0.2.128 – 10.0.2.255

The second range is already contained in the first.

AWS does not permit overlapping subnet CIDR blocks in the same VPC.

Can subnets have different sizes?

Yes.

For example:

PurposeExample CIDRTotal IPsSmall internal service10.0.1.0/2816Application service10.0.2.0/24256Larger workload10.0.4.0/221,024

These three subnet blocks do not overlap and fit within 10.0.0.0/16.

You are not required to give every subnet the same number of IP addresses.

The appropriate size depends on expected resource requirements, service constraints, and future growth.

7. Why Does AWS Reserve Five IP Addresses in Every IPv4 Subnet?

This is another important AWS-specific concept.

Suppose we create:

10.0.2.0/24

We calculated that this network contains 256 IPv4 addresses.

But AWS does not make all 256 addresses assignable to resources.

AWS reserves the first four and the last address.

IP AddressAWS Reservation10.0.2.0Network address10.0.2.1VPC router10.0.2.2DNS-related reservation10.0.2.3Reserved for future use10.0.2.255Reserved network broadcast address

AWS VPCs do not support traditional broadcast traffic, but the last address is still reserved.

Therefore:

256 − 5 = 251 assignable addresses

For this subnet, the assignable private IPv4 range is:

10.0.2.4 – 10.0.2.254

A server might receive 10.0.2.10, provided that address is available.

What happens with a smaller /28 subnet?

A /28 contains:

2^(32 − 28) = 16 addresses.

AWS still reserves five addresses.

Therefore:

16 − 5 = 11 assignable IPv4 addresses

This is one reason subnet sizing matters.

A network may technically contain enough total addresses, but the number available to AWS resources can be smaller than expected.

Some AWS services also require spare addresses for scaling or maintenance.

See AWS documentation on subnet CIDR blocks.

8. Why Do We Need Multiple Subnets?

If all the resources belong to the same VPC, why not place everything in one large subnet?

Technically, a VPC can contain just one subnet. But multiple subnets give us more control over network organization.

There are three especially useful reasons.

Reason 1: Different routing requirements

A public-facing web server may require an internet route.

A backend server may require only outbound access to external APIs.

A database may not need any direct internet route.

By placing these resources in different subnets, we can associate different route tables with their subnets.

Reason 2: Availability Zones

An AWS VPC belongs to a Region and spans its Availability Zones.

However, each subnet resides entirely within one Availability Zone.

For example:

SubnetAvailability ZoneCIDRPublic AAZ-A10.0.1.0/24Public BAZ-B10.0.2.0/24Private AAZ-A10.0.3.0/24Private BAZ-B10.0.4.0/24

These are conceptual AZ labels.

By distributing resources across different Availability Zones, applications can be designed to tolerate the failure of one zone.

Reason 3: Organized network planning

Separating workloads into subnets makes it easier to understand:

  • Which resources use a particular IP range.

  • Which resources require internet routes.

  • Where applications are deployed.

  • Which subnet-level security controls apply.

  • How much address capacity remains.

However, there is an important distinction:

Creating multiple subnets does not automatically isolate their resources from each other.

Subnets within the same VPC ordinarily have local connectivity through VPC routing.

Security Groups, Network ACLs, and other controls determine which traffic is actually allowed.

9. Public, Private, and Isolated Subnets

These terms describe how subnets are connected to other networks.

Public subnet

A public subnet has an appropriate route to an Internet Gateway.

Example:

10.0.1.0/24

An EC2 instance in this subnet may communicate directly over the public IPv4 internet when it has a public IPv4 address and suitable security configuration.

A public subnet does not automatically make every instance publicly accessible.

Private subnet

A private subnet does not have a direct route to an Internet Gateway.

Example:

10.0.2.0/24

It may have an outbound route through a NAT Gateway.

An application server in this subnet can initiate permitted outbound connections without accepting unsolicited direct IPv4 internet connections.

Isolated subnet

An isolated subnet has no default route to the internet, including through a NAT Gateway.

Example:

10.0.3.0/24

This is useful for resources that do not require internet connectivity.

A database might use this configuration.

It can still communicate with authorized resources inside the VPC using local routes and appropriate security permissions.

Comparison

PropertyPublicPrivate with NATIsolatedDirect route to IGWYesNoNoDefault outbound IPv4 routeIGWNAT GatewayNoneTypical resourcePublic web endpointBackend serviceInternal databaseInternet-initiated IPv4 accessPossible with correct configurationNot directly through NATNo direct internet route

These examples focus on IPv4. IPv6 connectivity has some different addressing and gateway behavior.

10. What Is a Route Table?

A route table is a collection of rules that determines where network traffic should be forwarded.

Think of it as a road map for your network.

Suppose a server has private IP:

10.0.1.10

It wants to communicate with:

10.0.2.10

Both addresses belong to the VPC:

10.0.0.0/16

AWS route tables contain a local route for the VPC address range.

An example route table is:

DestinationTarget10.0.0.0/16local0.0.0.0/0Internet Gateway

The route table evaluates the packet's destination IP.

If the packet is intended for 10.0.2.10, it matches the local VPC route.

If it is intended for 8.8.8.8, it does not match 10.0.0.0/16, so it matches the default route.

What does 0.0.0.0/0 mean?

This CIDR block represents all IPv4 destinations.

But it does not override more specific routes.

AWS uses the most specific matching route, called the longest prefix match.

Therefore:

  • 10.0.2.10 → local route

  • 8.8.8.8 → default route

  • 1.1.1.1 → default route

The route's target determines where the packet goes next.

A route table does not itself give an EC2 instance permission to receive traffic. Security Groups and Network ACLs still apply.

11. What Is an Internet Gateway?

An Internet Gateway, commonly abbreviated as IGW, is a VPC component that provides a connection between the VPC and the public internet.

Imagine your VPC is an office building.

The Internet Gateway represents the connection between that building and the outside road network.

For an EC2 instance to communicate directly with the internet over IPv4, the usual requirements include:

  • An Internet Gateway attached to the VPC.

  • A route to the Internet Gateway.

  • A public IPv4 address or Elastic IP on the instance.

  • Appropriate Security Group and Network ACL rules.

Consider this example:

  • VPC: 10.0.0.0/16

  • Public subnet: 10.0.1.0/24

  • Web server private IP: 10.0.1.10

  • Web server public IP: Assigned separately by AWS

When an external user connects to the web server using its public endpoint, the Internet Gateway participates in forwarding traffic between the internet and that instance.

For IPv4, it also provides the public-to-private address translation needed for the instance.

But if an EC2 instance has only a private IPv4 address, an Internet Gateway route alone does not provide it with direct IPv4 internet access.

This distinction is important when troubleshooting network connectivity.

12. What Is a NAT Gateway, and Why Do Private Subnets Need It?

NAT stands for Network Address Translation.

Imagine your backend server is in a private subnet:

10.0.2.10

The server should not accept direct incoming connections from arbitrary users on the internet.

However, it may need to:

  • Download software updates.

  • Access a third-party API.

  • Retrieve external dependencies.

  • Communicate with an internet-hosted service.

How can it initiate those connections without having a public IPv4 address?

One common solution is a public NAT Gateway.

How NAT works

Suppose the backend server sends an outbound request to an external API.

The conceptual traffic path is:

Private Server → NAT Gateway → Internet Gateway → External API

The NAT Gateway performs address translation so the request can proceed using the NAT infrastructure's addresses.

The external service sends its response back along the established connection.

The NAT Gateway then forwards that response to the original private server.

But an unrelated internet user cannot initiate a direct connection to that private server through the NAT Gateway.

Why not simply use an Internet Gateway?

A private EC2 instance without a public IPv4 address cannot directly access the IPv4 internet merely by pointing its default route at an IGW.

A public NAT Gateway provides a different approach: it allows outbound connectivity for private instances without requiring public IPv4 addresses on those instances.

Does every private subnet need a NAT Gateway?

No.

A private subnet needs NAT-based outbound access only when the workloads require connectivity that the chosen NAT solution provides.

If a database only communicates with an internal API, it may not need internet access at all.

Some AWS services can also be reached privately using VPC endpoints, avoiding a NAT route for that service.

AWS supports both zonal and regional NAT Gateway architectures. A conventional zonal public NAT Gateway lives in a public subnet, while the regional option manages availability across supported Availability Zones without requiring a dedicated public subnet for the gateway.

NAT Gateways are managed AWS resources and can incur hourly and data-processing charges.

13. Security Groups vs. Network ACLs

So far, we've focused on IP addressing and routing.

But routing alone does not determine whether a connection should succeed.

We also need security rules.

AWS provides two important traffic controls.

Security Groups

A Security Group is a stateful virtual firewall applied to resource network interfaces.

Suppose we have:

  • Web server: 10.0.1.10

  • API server: 10.0.2.10

  • Database: 10.0.3.10

We could define the following inbound permissions:

ResourceAllowed TrafficWeb serverHTTPS on TCP 443 from usersAPI serverTCP 3000 from Web Server Security GroupDatabaseTCP 5432 from API Server Security Group

This limits database access to the application resources that actually need it.

A Security Group is stateful, so response traffic for an allowed connection is automatically permitted.

Network ACLs

A Network Access Control List, or NACL, operates at the subnet level.

Unlike Security Groups, NACLs can explicitly allow or deny traffic.

They are also stateless, meaning return traffic must match applicable rules separately.

FeatureSecurity GroupNetwork ACLApplied toResource network interfacesSubnetStatefulYesNoRule typesAllowAllow and denyCommon rolePrimary resource firewallAdditional subnet-level controls

For most beginner scenarios, Security Groups are the primary control to understand.

NACLs provide an additional layer when subnet-wide rules are needed.

14. How All These AWS Networking Components Work Together

Let's connect everything using a conceptual full-stack application.

Suppose we have:

  • A Next.js web server

  • A Node.js API server

  • A PostgreSQL database

Our network plan is:

ComponentNetworkIP AddressVPC10.0.0.0/16Entire address rangePublic subnet10.0.1.0/24Web server: 10.0.1.10Private app subnet10.0.2.0/24API server: 10.0.2.10Isolated DB subnet10.0.3.0/24Database: 10.0.3.10

This example uses a simplified single-Availability-Zone layout.

Scenario A: A visitor opens the website

The visitor connects to the public-facing web endpoint.

The connection uses the Internet Gateway and the route to the public subnet resource.

The web server's Security Group must allow the required incoming traffic.

Scenario B: The website needs API data

Suppose the Next.js server makes a server-side request to:

10.0.2.10:3000

The destination belongs to the same VPC.

Traffic follows the local VPC route.

The backend Security Group must allow the connection.

The request does not need to travel through the public internet.

Note that this assumes server-to-server communication. A browser on a user's laptop cannot directly reach a private VPC address over the public internet.

Scenario C: The API queries PostgreSQL

The backend connects to:

10.0.3.10:5432

Again, the destination is inside the same VPC.

Traffic uses local VPC connectivity.

The database Security Group permits the application server to connect.

No Internet Gateway or NAT Gateway is required for this internal database request.

Scenario D: The backend calls an external API

The private application server needs to access a public third-party API.

Its route table may direct default outbound IPv4 traffic through a public NAT Gateway.

The NAT infrastructure provides the necessary outbound translation and return path.

This is a different use case from communicating with another resource inside the VPC.

What changes in a production environment?

A more resilient application may use:

  • Public load balancers rather than public application instances.

  • Private application subnets across multiple Availability Zones.

  • Appropriate outbound connectivity for each workload.

  • Managed databases with high availability.

  • Security Groups that restrict application and database access.

The underlying concepts remain the same.

15. Common Misunderstandings About VPCs and Subnets

“If my VPC is /16, every subnet must be /24.”

No.

You can choose different supported subnet sizes, provided they fit inside the VPC and do not overlap.

“10.0.2.0/24 and 10.0.2.128/25 are separate networks.”

Their ranges overlap.

You cannot allocate both as distinct subnets in the same VPC.

“I must always start my VPC with 10.0.0.0.”

No.

You can select other valid blocks such as 10.50.0.0/16.

The chosen range should also make sense alongside any networks you may connect later.

“A subnet with 256 addresses can host 256 EC2 private IPs.”

No.

AWS reserves five IPv4 addresses per subnet.

A /24 provides 251 assignable private IPv4 addresses, and actual instance capacity may also be restricted by other quotas and resource requirements.

“If I put a database in a different subnet, it is automatically secure.”

No.

Subnets organize networks and provide routing boundaries, but they do not automatically prevent communication between resources.

Use appropriate Security Groups, routing, and other security controls.

“A private subnet cannot access the internet.”

Not necessarily.

It can use an outbound path such as a NAT Gateway while remaining without a direct Internet Gateway route.

“An Internet Gateway and NAT Gateway do the same thing.”

No.

An Internet Gateway connects a VPC to the internet and supports public endpoint connectivity.

A public NAT Gateway is commonly used to let private resources initiate outbound connections without assigning them public IPv4 addresses.

“If I create two subnets, one is automatically public and the other private.”

No.

Their names and IP ranges do not determine public/private classification.

Routing does.

16. How to Think About VPC Design as a Beginner

When looking at an unfamiliar AWS architecture, try answering these questions in order.

First: What is the VPC's CIDR block?

Example: 10.0.0.0/16

That tells you the overall IPv4 address space.

Second: Which subnets exist inside it?

Example:

  • 10.0.1.0/24

  • 10.0.2.0/24

  • 10.0.3.0/24

That tells you how the address space has been divided.

Third: Which resources belong to each subnet?

For example, a web server, backend API, or database.

Fourth: Which route table is associated with each subnet?

That tells you where outbound packets are routed.

Fifth: Are Internet Gateways, NAT Gateways, or VPC endpoints involved?

That helps explain connectivity beyond the local VPC network.

Sixth: Which Security Groups and NACLs apply?

That helps explain which connections are permitted or denied.

These questions provide a practical mental model for reading AWS network architectures.

17. Frequently Asked Questions

What is the difference between VPC CIDR and subnet CIDR?

The VPC CIDR defines the address space for the overall VPC.

A subnet CIDR defines a smaller block within that space.

For example:

  • VPC: 10.0.0.0/16

  • Subnet: 10.0.2.0/24

The subnet must fit inside a CIDR block associated with the VPC.

Can a subnet use the same CIDR as its VPC?

Yes.

A VPC with 10.0.0.0/24 can contain a single subnet using that entire block.

However, there would be no remaining space inside that CIDR block for another non-overlapping IPv4 subnet.

Can I create 10.1.0.0/24 inside 10.0.0.0/16?

No, because it falls outside that VPC's address range.

A VPC using 10.1.0.0/16 could contain it.

Why does 10.0.2.0/26 have only 64 IP addresses?

An IPv4 address has 32 bits.

With 26 network bits, 6 bits remain.

2⁶ = 64 addresses.

Can two EC2 instances have the same private IPv4 address?

They cannot use the same private IPv4 address simultaneously within the same subnet's addressing context.

However, separate non-connected VPCs can use overlapping private IP ranges. That can create connectivity problems if those networks later need to communicate.

What happens if a subnet runs out of IP addresses?

New resources that require an address from that subnet may fail to launch or scale.

This is why address capacity and future growth matter when planning subnet sizes.

Does VPC networking only use IPv4?

No.

AWS VPCs also support IPv6.

IPv6 uses 128-bit addresses and has different prefix sizes and connectivity considerations.

The examples in this article focus on IPv4 because they provide a simpler starting point for understanding network boundaries and address allocation.

Conclusion

Understanding AWS VPC networking begins with understanding IP address ranges.

A VPC defines the network address space. CIDR determines the size of that space. Subnetting divides the space into smaller, non-overlapping ranges.

From there, route tables determine where traffic goes, gateways provide connectivity to other networks, and security controls determine which communication is allowed.

The most important lesson is that subnetting is not about randomly choosing IP addresses. It is about dividing a larger address block into mathematically valid smaller networks.

Once you understand why 10.0.2.0/24 covers 256 addresses, why /26 creates 64-address blocks, and why subnets cannot overlap, the rest of AWS networking becomes much easier to reason about.

References

Related Cloud & DevOps Articles