VPC Fundamentals & Subnetting

The Cloud Security Crisis: Open Flat Networks

Imagine locking down every door handle in your company's headquarters with ultra-secure biometric scanners, only to discover that the entire building has no interior walls. Once an intruder steps through a single front window, they can freely walk up to the main financial ledger, the customer database, and the executive boardroom without hitting another physical obstacle.

In cloud architecture, this nightmare scenario is known as a flat network.

What Is a Flat Network?

A flat network is a network topology where every connected system sits on a single, shared, unsegmented communication plane. In a flat design, there are no internal barriers or segregated zones dividing your infrastructure. Your public-facing web servers, internal background job processors, and sensitive core databases all reside side-by-side in the exact same network space.

While a flat network is undeniably simple to launch during the early days of a startup, it introduces severe architectural vulnerabilities that can compromise an entire enterprise overnight.

The High Cost of Unsegmented Risks

When database and application servers share an unsegmented network, securing individual hosts becomes an uphill battle. In an unsegmented environment, a single compromised server grants an attacker an all-access pass to your entire infrastructure.

Placing your sensitive data workloads on a flat network creates catastrophic financial and operational risks:

• Unchecked Lateral Movement: If an attacker exploits a vulnerability in a public web application, they don't just compromise that single web server. They can immediately probe, discover, and attack adjacent high-value targets like your core database because no internal network boundaries stop them.
• Massive Blast Radius: A localized security incident on an obscure developer host instantly escalates into an enterprise-wide disaster. Without internal walls, the network cannot contain or isolate the breach.
• Severe Financial and Operational Impact: Uncontrolled breaches lead to astronomical regulatory fines, costly business downtime, stolen intellectual property, and irreversible damage to customer trust.

The Need for Custom Network Boundaries

Relying solely on user credentials or host-level software settings is not enough to protect enterprise assets. True defense-in-depth requires strictly enforced logical network boundaries that control how traffic moves through your environment.

Instead of throwing all cloud resources into one open, unsegmented pool, modern cloud engineering demands that you construct custom virtual perimeters. By carving out controlled network boundaries around your infrastructure, you ensure that a failure in your public-facing application tier never translates into a direct compromise of your confidential data.

Total Perimeter Control: The Value of Custom VPCs

By carving out controlled network boundaries around your infrastructure, you ensure that a failure in your public-facing application tier never translates into a direct compromise of your confidential data. This exact boundary is achieved in the cloud through a construct known as a Virtual Private Cloud (VPC).

A VPC is an isolated, virtual network dedicated entirely to your AWS account. It mimics the benefits of a traditional on-premises data center complete with physical separation and explicit entry points while providing the agility and scalability of cloud infrastructure.

VPC Isolation Benefits

In a multi-tenant cloud environment where physical hardware is shared among millions of customers, isolation is the foundational requirement of security. A custom VPC provides complete logical isolation for your compute, storage, and database workloads from all other tenants.

This default-deny isolation provides immediate architectural advantages:

• Tenant Boundary Defense: Traffic inside your custom VPC is entirely invisible and inaccessible to other AWS accounts unless you explicitly authorize access.
• Default Perimeter Security: By default, resources launched within a fresh custom VPC cannot communicate with the public internet or external networks.
• Blast Radius Reduction: By establishing absolute network perimeters, security breaches are localized, preventing external threats from gaining direct lateral access to core systems.

Granular Network Control

Relying on default cloud network configurations leaves too much to chance. Constructing a custom VPC gives you total, granular control over your network topology and security policy.

Rather than adopting a rigid, pre-packaged network layout, a custom VPC allows you to define the exact rules that govern how data moves into, out of, and within your infrastructure.

• Explicit Network Sizing: You select the precise range of internal network addresses allocated to your infrastructure.
• Custom Topology Placement: You dictate how internal network segments are structured and aligned with your business logic.
• Strict Access Policies: You enforce granular rules determining which workloads can communicate with one another and which must remain completely isolated.

By moving away from default configurations and taking direct control of your VPC architecture, you transform an inherently open environment into a custom, highly defensible digital perimeter.

The Gated Office Building: Network Subnets as Controlled Floors

Now that you understand the security value of establishing a custom VPC perimeter, the next step is structuring the space inside that boundary.

To build a secure cloud environment, raw isolation is only the starting point. To make a virtual private cloud functional and secure, you must organize its interior space into controlled compartments and establish clear pathways for movement.

To visualize how AWS network components fit together, imagine designing a high-security corporate headquarters.

The VPC as a Secured Property Boundary

Imagine buying a plot of land and surrounding it with a high-security perimeter fence and a single guarded gate. This entire property represents your VPC.

Inside this property line, no outside uninvited foot traffic can enter. The VPC defines your private, sovereign real estate in the cloud, separating your organization from every other tenant in the AWS ecosystem.

However, owning a secure property boundary doesn't mean you leave the interior as one massive, open-plan room. If a guest steps past the front gate, you don't want them wandering freely into the executive boardroom or the financial vault. You need internal walls and distinct departments.

Subnets as Specific Building Floors

Inside your corporate building, you divide space into distinct, segregated floors. A subnet (short for sub-network) is simply a specific floor inside your VPC building.

Instead of throwing every server, database, and application into a single chaotic pool, you assign different workloads to different floors:

• Floor 1 (Public Reception): Designed for public interaction, welcoming outside visitors and directing requests.
• Floor 2 (Application Processing): Dedicated to core operations, accessible only by internal staff.
• Floor 3 (Data Vault): Highly restricted floor holding customer financial records, completely isolated from direct public access.

By carving your VPC into distinct subnets, you create functional boundaries that isolate workloads based on their operational and security requirements.

Route Tables as Building Directories

Having structured floors is useless if people cannot figure out how to get around or how to exit the building. This is where the route table comes in.

A route table acts like the building directory and elevator control system installed on a specific floor. Every subnet relies on a route table to explicitly dictate where outgoing traffic is allowed to travel.

When a server on a floor attempts to send a packet of data, it consults the floor's route table directory:

• If the directory says, "For destination X, take Elevator A," the traffic flows to Elevator A.
• If the destination is not listed in the directory, the traffic goes nowhere the door remains locked.

By attaching specific directories to specific floors, you control movement across the entire property.

Comparing Physical Security to Virtual Networks

To keep these architectural mental models clear, reference how physical security structures map directly to AWS cloud constructs:

Understanding this structural blueprint gives you the framework needed to organize complex cloud environments. Before you can place a single server into your network, you must first measure and divide your virtual real estate.

Carving Out Virtual Space: CIDR Blocks (IPv4)

Now that you can picture the physical layout of your virtual campus, it's time to learn how architects mathematically draw those boundaries using IP address ranges.

In cloud networking, we don't assign IP addresses one by one. Instead, we allocate continuous blocks of addresses using Classless Inter-Domain Routing, universally known as CIDR notation.

Demystifying CIDR Syntax

An IPv4 address consists of 32 binary bits divided into four octets separated by dots (such as 10.0.0.0). CIDR notation appends a slash (/) followed by a number known as the prefix length to the IP address (for example, 10.0.0.0/16).

The prefix length dictates how many bits are locked for the network identity, leaving the remaining bits free to identify individual resources (hosts) inside that network.

AWS enforces strict rules on the size of CIDR blocks you can assign to your virtual networks: * Largest VPC CIDR Block: /16 (65,536 total IP addresses) * Smallest Subnet CIDR Block: /28 (16 total IP addresses)

Calculating IP Ranges: The Math Behind the Mask

To calculate how many total IP addresses a CIDR block provides, subtract the prefix length from 32 (the total bits in an IPv4 address). The remaining number represents your host bits. Elevate 2 to the power of your remaining host bits ($2^{(32 - \text{prefix})}$) to find your total address capacity.

As the prefix number gets larger, the available host space gets smaller.

For example, if you define a VPC with 10.0.0.0/16, your IP address range spans from 10.0.0.0 all the way to 10.0.255.255. If you carve out a subnet using 10.0.1.0/24 inside that VPC, that specific subnet controls the range from 10.0.1.0 to 10.0.1.255.

The 5 AWS Reserved IPs Per Subnet

When planning your subnet sizes, you might assume a /24 block gives you 256 usable host IPs for your Virtual Machines and Database instances. AWS automatically reserves 5 IP addresses in every subnet for internal networking services.

For any subnet CIDR block, AWS takes the following five addresses off the table:

• .0 - Network Address: Always reserved as the formal network identifier.
• .1 - VPC Router: Reserved by AWS for the default virtual router gateway.
• .2 - DNS Server: Reserved by AWS to map internal domain resolution (AmazonProvidedDNS).
• .3 - Future Use: Reserved by AWS for potential upcoming feature expansion.
• .255 - Network Broadcast Address: Reserved as the network broadcast address (though VPCs do not support standard IP broadcasting, AWS still reserves this address).

If your subnet range is 10.0.1.0/24, the usable IP range for your actual workloads runs strictly from 10.0.1.4 through 10.0.1.254.

Now that you know how to mathematically size your subnets, you are ready to decide which of these network blocks should face the open internet and which should remain safely hidden behind your private perimeter.

Architectural Segregation: Public vs. Private Subnets

Now that you know how to calculate and divide raw IP address space down to the usable host, we need to decide how to assign these subnets to build distinct public and private security zones.

Carving up a /16 network block into neatly calculated /24 subnets is only half the battle. The true power of virtual networking lies in architectural segregation placing specific application tiers into isolated network zones to minimize your attack surface.

Subnet-to-Availability Zone Mapping

Before deciding which subnets face the outside world and which remain hidden, you must understand physical location boundaries inside AWS. A single Virtual Private Cloud (VPC) spans every Availability Zone (AZ) within an AWS Region. However, subnets do not share that same regional reach.

Every subnet you create in AWS must reside entirely within a single Availability Zone.

You cannot create a single subnet that bridges across us-east-1a and us-east-1b. Because an AZ represents physically distinct data center infrastructure, subnets are hard-bound to those physical fault domains:

• VPC Scope: Regional (Spans all AZs in a region).
• Subnet Scope: Local (Bound strictly to a single AZ).

To build a high-availability architecture, you must provision pairs of matching subnets across at least two Availability Zones. For example, if you allocate 10.0.1.0/24 as a public zone in us-east-1a, you should allocate 10.0.2.0/24 as a secondary public zone in us-east-1b.

Defining Structural Boundaries: Public vs. Private

From a purely technical standpoint, AWS creates all subnets identically. When you provision a subnet, AWS simply carves off an IP range and associates it with an AZ. What transforms a generic subnet into a "Public" or "Private" subnet is the routing path you attach to it.

text +-----------------------------------------------------------------------+ | VPC (10.0.0.0/16) | | | | +--------------------------------+ +-----------------------------+ | | | Public Subnet (10.0.1.0/24) | | Private Subnet (10.0.2.0/24)| | | | - Direct External Inbound/Outbound| | - Completely Isolated | | | | - Web Tier / Load Balancers | | - Database Tier / App Logic | | | +--------------------------------+ +-----------------------------+ | +-----------------------------------------------------------------------+

Public Subnets

A public subnet is a network segment configured to allow direct routing to and from the external internet. Resources deployed here are assigned public IP addresses and can be directly reached by external clients if permitted by security rules.

Private Subnets

A private subnet is a network segment isolated from direct external exposure. Resources inside a private subnet only possess private IP addresses (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 ranges) and cannot be initiated upon directly from outside the VPC.

Workload Placement Strategies

Security in the cloud relies on the Principle of Least Privilege applied to network architecture. You should default to placing all application logic and data stores in private subnets, exposing only public-facing entry points.

To design a secure multi-tier enterprise network, categorize your workloads across tiers:

The Web Tier vs. Database Tier Strategy

Consider a standard web application. Your end users need to access web interfaces over HTTP/HTTPS, but they should never have a direct line of communication to your database.

1. Web Tier Placement: Place your public load balancer in a Public Subnet. It accepts inbound connections from users over the public internet, terminating external SSL connections.
2. Database Tier Placement: Place your database cluster in a Private Subnet. The database accepts connections only from private IP addresses originating from your application servers.

By enforcing this structural separation, an attacker who scans your public IP space will only ever see your heavily guarded frontend entry points, keeping your critical data assets invisible to external bad actors.

Now that we have established where public and private subnets sit within your VPC and which workloads belong in each, we need a mechanism to explicitly define and enforce these traffic boundaries.

Traffic Steering: Route Table Mechanics

Now that we have established where public and private subnets sit within your VPC and which workloads belong in each, we need a mechanism to explicitly define and enforce these traffic boundaries. In AWS, subnets do not automatically know how to direct incoming or outgoing network packets. Traffic flow across your virtual network is governed entirely by Route Tables, which act as digital traffic controllers for every packet attempting to leave a subnet.

Without a route table attached to a subnet, network traffic inside that subnet has nowhere to go. Understanding how these tables evaluate network destinations is essential to building predictable, secure cloud environments.

The Anatomy of a Route Table

A route table contains a logical set of rules called routes that determine where network traffic from your subnet is directed. Every single route in a table consists of two fundamental parameters:

• Destination: The destination IP address range (expressed in CIDR notation) where you want traffic to flow.
• Target: The specific network resource, interface, or gateway through which that destination traffic must pass.

When an EC2 instance or container inside a subnet sends an outbound packet, AWS inspects the packet's destination IP address and compares it against the Destination entries in the subnet's associated route table.

If a route table contains multiple matching destinations, AWS uses the most specific route (the matching route with the longest CIDR prefix) to decide where to send the traffic.

The Default local Route Target

When you create a new VPC with a specific IPv4 CIDR block (for example, 10.0.0.0/16), AWS automatically creates a default route table and injects an unmodifiable baseline route into it:

The default local route target ensures that all subnets within the same VPC can communicate directly with one another by default.

Because the Target is set to local, any packet addressed to an IP address within the VPC range (10.0.0.0/16) is routed internally across the AWS hypervisor fabric without leaving the virtual private network.

Main Route Table vs. Custom Route Tables

Every VPC has a lifecycle relationship with two operational types of route tables:

1. Main Route Table: Automatically created alongside the VPC. It acts as the default implicit route table for any subnet that has not been explicitly associated with a specific table.
2. Custom Route Tables: Tables created explicitly by you to control granular routing rules for specific architectural tiers (such as a Web tier or a Database tier).

text +-----------------------------------------+ | AWS VPC | | 10.0.0.0/16 | +-----------------------------------------+ | +-------------------------+-------------------------+ | | v v +-------------------+ +-------------------+ | Custom Route Tbl | | Main Route Table | | Dest: 10.0.0.0/16 | | Dest: 10.0.0.0/16 | | Target: local | | Target: local | +-------------------+ +-------------------+ | | (Explicit Association) (Implicit Fallback) v v +-------------------+ +-------------------+ | App Subnet A | | Unattached | | 10.0.1.0/24 | | Subnet | +-------------------+ +-------------------+

Relying on the Main Route Table for production subnets introduces operational risk because newly created subnets automatically inherit its routes. To maintain strict operational boundaries, cloud architects keep the Main Route Table in an isolated state and explicitly attach Custom Route Tables to every subnet they create.

Inspecting Route Tables via the AWS CLI

You can inspect the exact structure of your route tables using the aws ec2 CLI tool. Executing describe-route-tables outputs the detailed JSON configuration for route evaluations:

bash aws ec2 describe-route-tables \ --filters "Name=vpc-id,Values=vpc-0a1b2c3d4e5f6789a" \ --query "RouteTables[*].{TableId:RouteTableId, Routes:Routes, Associations:Associations}"

This command returns a structured payload representing the active destinations and targets:

json [ { "TableId": "rtb-0123456789abcdef0", "Routes": [ { "DestinationCidrBlock": "10.0.0.0/16", "GatewayId": "local", "Origin": "CreateRouteTable", "State": "active" } ], "Associations": [ { "Main": true, "RouteTableAssociationId": "rtbassoc-0fe987654321cba09", "RouteTableId": "rtb-0123456789abcdef0" } ] } ]

In this output, you can directly observe the DestinationCidrBlock mapped to the local GatewayId, confirming how internal traffic is bound within the network.

Designing Safe Boundaries: Architectural Trade-Offs

Now that we understand how route tables steer internal traffic across subnets, we must evaluate the broader architectural trade-offs involved in designing secure VPC boundaries and IP address layouts. Every network decision in the cloud represents a balance between flexibility, operational complexity, and security containment.

CIDR Sizing: IP Exhaustion vs. Over-Provisioning

When defining address ranges for your VPC and subnets, you are choosing how to allocate finite private IPv4 space. The primary challenge is balancing the risk of running out of addresses against the danger of wasting unrecoverable network space.

text [ Under-Provisioned (/28) ] [ Over-Provisioned (/16) ] 11 Usable IPs 65,531 Usable IPs ⚠️ High Risk: Exhaustion ⚠️ High Risk: Overlapping CIDRs (Auto-scaling failures) (Breaks hybrid cloud/peering)

• IP Exhaustion Risks: If you size subnets too conservatively (such as allocating a /28 block with only 11 usable IPs), a sudden auto-scaling event, container deployment, or creation of Elastic Network Interfaces (ENIs) can rapidly deplete your available pool. Once a subnet runs out of IP addresses, target resource provisioning fails completely.
• Over-Provisioning Risks: To avoid exhaustion, it is tempting to assign massive /16 blocks to every subnet. However, allocating excessively large ranges wastes contiguous private address space. Over-provisioning increases the likelihood of overlapping CIDR ranges, which prevents you from connecting your VPC to other cloud networks or on-premises corporate datacenters in the future.

Architects must calculate expected baseline workloads, account for growth, and consider AWS-reserved addresses to pick an optimal prefix size (typically between /24 and /20 per subnet).

Public vs. Private Isolation Trade-Offs

Separating workloads into public and private subnets establishes strong structural boundaries, but this security model comes with architectural trade-offs.

Placing resources in a private subnet shields them from unsolicited inbound scans, reducing the total attack surface. However, this isolation introduces operational overhead when those private instances require system updates or outbound API access. Conversely, placing resources in public subnets provides direct reachability and simpler management, but exposes those workloads to external threats if misconfigured.

Effective VPC architecture is ultimately an exercise in disciplined trade-offs. By right-sizing CIDR blocks and strictly separating internet-facing entry points from isolated backend systems, you create a network foundation that is both resilient to growth and secure by default.