Learn Subnets or Invite Thieves

In an era of relentless cyber threats, from sophisticated data breaches to the opportunistic attacks of bad actors, the old adage "an ounce of prevention is worth a pound of cure" has never been more relevant.

For anyone building and deploying applications, particularly in the cloud or with container technologies like Docker, this prevention comes in the form of a seemingly simple concept: subnets.

Too often, subnets are seen as a dry, technical detail—just another box to check in a configuration menu. This perspective is dangerously misguided. A failure to properly design and utilize subnets is akin to leaving the doors and windows of your digital home unlocked while the most valuable possessions—your data and your users' privacy—are in plain sight.

This is especially critical for applications handling sensitive information, such as financial, personal, or medical data. Privacy regulations like HIPAA and GDPR mandate strict controls over data access. Subnets provide the foundational structure to enforce these controls, ensuring that medical records, for instance, are isolated from the public internet and accessible only to authorized services on a specific, secured network segment.

This article will explore why subnets are not just a best practice, but an essential defense strategy. We'll start with a non-technical explanation, dive into the technical implementation in both cloud and Docker, and conclude with an advanced use case for building a completely isolated, internal-only application.

The Core Concept (For Non-Technical People)

Imagine your entire digital infrastructure—all your servers, databases, and application components—as a massive office building. A single, flat network is like having one enormous, open-plan office where everyone can see and talk to everyone else, and the front door is left wide open.

A subnet is like building a series of separate, secure rooms within that office.

The Lobby (Public Subnet)

This is where visitors (internet traffic) are allowed. It's heavily monitored, and only the receptionist (your web server) is allowed to interact with the outside world.

The Staff Lounge (Application Subnet)

This room is for your employees (application servers). It has a locked door and a strict rule: you can only enter if you're coming from the lobby. No one from the outside can ever just walk in.

The Vault (Database Subnet)

This is the most secure room, where your most sensitive information is stored. It has multiple layers of locks and a rule that's even stricter: only staff from the lounge can enter, and only on a specific business-related errand (a data query).

By creating these separate rooms—these subnets—you gain control. An intruder who manages to sneak past the receptionist in the lobby still can't get into the vault. This segmentation is a multi-layered defense that is far more effective than trying to protect a single, open space.

Deep Dive into Address Structure (CIDR Notation)

To truly understand how subnets work, you need to look at the anatomy of an IP address and a notation known as CIDR, or Classless Inter-Domain Routing. This is the simple yet powerful language that network engineers use to define network boundaries.

The IP Address

An IPv4 address is a 32-bit number, usually written in four "octets" separated by dots (e.g., 192.168.1.10). Each octet represents 8 bits and can have a value from 0 to 255.

The CIDR Suffix

This is the number you see after the slash, like /16 or /24. It tells you exactly how many bits from the left side of the IP address are fixed and represent the network part. The remaining bits are for the host part, which can change to identify individual devices within that network.

Let's break down some examples:

Example 1: VPC CIDR: 10.0.0.0/16

• The Suffix: /16
• The Meaning: The first 16 bits of the address are the network part.
• In Binary: An IPv4 address is 32 bits long. A /16 means the first two octets (10.0) are the network portion.
• 10.0 (16 bits) are fixed.
• 0.0 (16 bits) are available for hosts.
• The Resulting Network: This gives you a very large network. You can calculate the number of available addresses with the formula 2^(32-N), where N is the CIDR suffix. In this case, 2^(32-16) = 2^16 = 65,536 total addresses. This is why it's a "large, private address space" suitable for an entire VPC.

Example 2: Private Subnet: 10.0.1.0/24

• The Suffix: /24
• The Meaning: The first 24 bits of the address are the network part.
• In Binary:
• 10.0.1 (24 bits) are fixed.
• 0 (8 bits) are available for hosts.
• The Resulting Network: 2^(32-24) = 2^8 = 256 total addresses. This is a much smaller, more manageable segment. All devices on this subnet will have an IP address starting with 10.0.1.

Example 3: Small Team Network: 192.168.100.0/28

• The Suffix: /28
• The Meaning: The first 28 bits of the address are the network part.
• In Binary:
• 192.168.100.0 (28 bits) are fixed.
• 0000 (4 bits) are available for hosts.
• The Resulting Network: 2^(32-28) = 2^4 = 16 total addresses. However, in practice, you lose 2 addresses: one for the network address (192.168.100.0) and one for the broadcast address (192.168.100.15). This leaves exactly 14 usable addresses.
• Perfect for: A small team of 12 people, with room for 2 additional devices (like a printer or network storage). Each person gets their own IP address: 192.168.100.1 through 192.168.100.12.

This structure is the very essence of subnetting: you take a large block of addresses (the VPC's /16 network) and subdivide it into smaller, more granular blocks (the subnets with /24s, /28s, etc.).

The Math Behind CIDR: Understanding the Formula

Let's break down the math step by step so you can calculate subnet sizes yourself:

The Basic Formula

Total Addresses = 2^(32 - CIDR_Suffix)

Here's why this works:

• An IPv4 address is always 32 bits long
• The CIDR suffix tells you how many bits are "locked" for the network part
• The remaining bits (32 - CIDR_Suffix) are available for host addresses
• Each bit can be 0 or 1, so 2^(remaining_bits) gives you the total possible combinations

Step-by-Step Calculation Examples

Example 1: /16 Network

• CIDR Suffix: 16
• Remaining bits: 32 - 16 = 16
• Total addresses: 2^16 = 65,536
• Usable addresses: 65,536 - 2 = 65,534 (subtract network and broadcast)

Example 2: /24 Network

• CIDR Suffix: 24
• Remaining bits: 32 - 24 = 8
• Total addresses: 2^8 = 256
• Usable addresses: 256 - 2 = 254

Example 3: /28 Network

• CIDR Suffix: 28
• Remaining bits: 32 - 28 = 4
• Total addresses: 2^4 = 16
• Usable addresses: 16 - 2 = 14

Quick Reference: Common CIDR Sizes

How to Choose the Right CIDR Size

Formula: Choose CIDR where 2^(32-CIDR) - 2 ≥ Number of devices you need

Examples:

• Need 50 devices? 2^6 = 64, so use /26 (64 total, 62 usable)
• Need 100 devices? 2^7 = 128, so use /25 (128 total, 126 usable)
• Need 500 devices? 2^9 = 512, so use /23 (512 total, 510 usable)
• Need 12 devices? 2^4 = 16, so use /28 (16 total, 14 usable)

Pro Tip: Always round up to the next power of 2 to give yourself room for growth. If you need 50 devices, don't use /26 (62 usable) - use /25 (126 usable) for future expansion.

The Power of a Locked Door: Allowing Only Specific IP Addresses

Understanding this structure gives you the power to create highly specific security rules. Instead of allowing traffic from an entire subnet, you can create rules that only permit a single, specific IP address.

For example, in a cloud security group, you might have a rule on your database that says:

• Allow Traffic: TCP
• Port: 3306 (for MySQL)
• Source: 10.0.1.5/32

The /32 CIDR notation is a key tool here. It signifies that all 32 bits of the IP address are part of the network, meaning the "network" is a single host. This rule explicitly allows a connection only from the device at 10.0.1.5, not from any other device on the 10.0.1.0/24 subnet. This is a crucial defense-in-depth strategy that provides the ultimate in network isolation.

Subnets in the Cloud - The Foundation of Security

In a cloud environment like Amazon Web Services (AWS), your primary network is a Virtual Private Cloud (VPC). The VPC is your own logically isolated network, and subnets are the subdivisions within it.

The Three-Tier Application Example

A classic, secure cloud application architecture utilizes subnets to enforce a layered defense.

Public Subnet

This subnet contains resources that need to be accessible from the internet, such as a web server or a load balancer. It has a route table that points to an Internet Gateway (IGW), allowing inbound and outbound traffic. You secure it using Network ACLs and Security Groups that permit only necessary traffic (e.g., HTTP/HTTPS).

Private Subnet

This subnet hosts your application servers. It has no direct route to the Internet Gateway. Instead, any outbound internet access for tasks like software updates is routed through a NAT Gateway in the public subnet. This design prevents attackers from directly accessing your application from the internet.

Database Subnet (Private)

This is where your databases reside. Like the application subnet, it has no direct internet connectivity. Security groups on the database instances are configured to allow connections only from the application servers in the private subnet, locking down the most critical data layer.

This structure ensures that even if a web server is compromised, the attacker cannot pivot to the database without first breaching the security rules between the subnets.

Subnets in Docker - Micro-segmentation at the Service Level

Docker's networking model provides its own form of subnets for container-level communication. While the default bridge network is a good start, it's too flat for production applications. The real power comes from creating user-defined networks.

The Docker Compose Example

Let's illustrate how to use Docker networks for isolation.

version: '3.8'

services:
  web:
    image: my-web-app:latest
    ports:
      - "80:80"
    networks:
      - web-network
      - internal-db-network
  
  database:
    image: postgres:14
    environment:
      - POSTGRES_PASSWORD=mysecretpassword
    networks:
      - internal-db-network

networks:
  web-network:
    driver: bridge
  internal-db-network:
    driver: bridge

• web-network: This network is used to expose the web service's port 80 to the host, allowing external traffic.
• internal-db-network: This is a private, isolated network. The database service is only on this network. The web service is also connected, allowing it to communicate with the database by its service name (database).

The key is that no one from outside can access the database service directly. It is completely walled off from the host's network and any other containers not on the internal-db-network. This level of isolation is crucial for microservices architectures where different services need to talk to each other but not to the outside world.

Advanced Subnetting - Building a Private, Internal-Only Application

Now, let's combine cloud and Docker concepts to build a fully private application that is never exposed to the public internet, a common requirement for internal-facing corporate tools or applications handling highly sensitive data like patient records.

The Architecture: A Private AWS VPC with Docker

This architecture involves creating an application that is only accessible from within a trusted, controlled network, like a corporate office VPN.

Create a Private VPC

Start by creating a new VPC in AWS. We will not create any public subnets or an Internet Gateway. The entire VPC will be private.

• VPC CIDR: 10.0.0.0/16 (a large, private address space)
• Private Subnet 1: 10.0.1.0/24 in us-east-1a
• Private Subnet 2: 10.0.2.0/24 in us-east-1b (for high availability)

Launch a Bastion Host (Jumphost)

To manage and deploy the application, you need a way to securely connect to this private VPC. You'll create a small EC2 instance (e.g., a "bastion host") with a public IP address in a small, tightly controlled public subnet. This subnet will have a security group that only allows SSH access from your trusted IP address.

• Public Subnet: 10.0.0.0/24 with a route to an Internet Gateway.
• Bastion Host: An EC2 instance with a public IP in the public subnet. Security Group allows SSH from your IP.

Deploy Docker in the Private Subnets

• Launch your EC2 instances (the Docker hosts) into your private subnets (10.0.1.0/24 and 10.0.2.0/24).
• Crucially, these instances have no public IP addresses. They cannot be accessed from the internet.
• From your bastion host, you will SSH into these private instances. Your SSH key is the only "key" to the inner network.

Isolate Application Containers with Docker Networks

On each private EC2 instance, use Docker Compose to deploy your application. You will create private Docker networks just like in the previous example. The key difference is that no container port is ever published to the host with -p.

• For example, your web container is on a private Docker network and port 80 is only exposed internally via the EXPOSE instruction in your Dockerfile, not published with -p.
• Your database container is on its own private Docker network, and your web container communicates with it on that internal network.
• No traffic, from the internet or even from the bastion host, can ever reach your application or database containers directly.

Access the Application

The only way to access the application is through a secure tunnel or a VPN connection that allows you to connect to the private VPC's address space. A common method is to use your VPN to access the internal 10.0.0.0/16 network, and then access your application via its internal IP address (e.g., http://10.0.1.100).

This setup ensures that all data traffic, including web requests and database queries, remains entirely within your private network and never traverses the public internet, satisfying the highest standards for data privacy and security.

This advanced model demonstrates the true power of subnets: they enable you to design and build highly specialized, secure environments where access is not just restricted, but architecturally impossible for unauthorized parties from the outside.

The IPv6 Alternative: Why Address Scarcity Could Become Irrelevant

While the techniques we've discussed are essential for current IPv4 networks, there's an elephant in the room that could fundamentally change the subnetting landscape: IPv6. Understanding IPv6 subnetting is crucial because it represents both the future of networking and a potential solution to many of the address conservation challenges we face today.

Comparing Subnetting in IPv4 vs. IPv6

The core concept of a "subnet" – a logical division of a network – remains the same in IPv6. However, the implementation and common practices are significantly different due to IPv6's enormous address space and design.

IPv4 Subnetting Recap:

• Goal: Primarily driven by the scarcity of IPv4 addresses and the need to conserve them. Also for network organization and efficiency.
• Method: A 32-bit IP address is divided into a network portion and a host portion using a subnet mask (e.g., 255.255.255.0 or /24).
• Flexibility: Network administrators carefully calculate subnets to allocate just enough host addresses for a specific segment, trying to avoid waste. This often involves variable-length subnet masking (VLSM).
• Example: 192.168.1.0/24 means the first 24 bits are the network, leaving 8 bits for hosts (254 usable addresses).

IPv6 Subnetting:

• Goal: Primarily driven by network organization, efficiency, and routing hierarchy, not address scarcity. IPv6 has an effectively infinite supply of addresses.
• Method: An IPv6 address is 128 bits long. The division into network and host portions is done using a prefix length (e.g., /64). There is no "subnet mask" in the dotted-decimal format like IPv4.
• Standard Practice: For most local area networks (LANs) and end-user segments, the standard practice is to assign a /64 prefix to each subnet.

Parts of an IPv6 Address for Subnetting:

1. Global Routing Prefix (first 48 bits): Assigned by your Internet Service Provider (ISP) or regional internet registry. This identifies your entire organization's network on the global internet. (e.g., 2001:0db8:0000:...)
2. Subnet ID (next 16 bits): This is the portion you, as a network administrator, use to create subnets within your organization. Each unique 16-bit value here defines a separate subnet. (e.g., ...:ABCD:...)
3. Interface ID (last 64 bits): This identifies a specific host within the subnet. Since this is 64 bits, it provides an astronomical number of possible hosts (2^64) per subnet.

Key Differences and Why IPv6 Subnetting is Simpler:

• Address Abundance: With 2^64 possible hosts per /64 subnet, there's no need to carefully calculate the minimum number of hosts. You simply assign a /64 to virtually every segment that acts as a broadcast domain.
• Fixed /64 for LANs: The /64 prefix for LANs is a near-universal standard. This simplifies configuration and management significantly compared to the varied subnet masks of IPv4. It also works well with stateless address autoconfiguration (SLAAC) and privacy extensions.
• Hierarchical Design: IPv6 encourages a more hierarchical addressing scheme. An ISP might give you a /48 prefix, allowing you to create 65,536 (2^16) subnets, each with a /64 prefix. You then use the "Subnet ID" portion to number these subnets (e.g., 0000, 0001, 0002, etc.).

Visualizing IPv6 Subnetting:

Let's use an example:

Your ISP gives your organization the global routing prefix 2001:0db8:ABCD::/48.

• 2001:0db8:ABCD: - This is your organization's unique identifier.
• ::/48 - Means the first 48 bits are fixed for your organization.

Now, you want to create subnets for different departments or network segments:

• Subnet for Marketing (Subnet ID 0001): 2001:0db8:ABCD:0001::/64 - This subnet has 2001:0db8:ABCD:0001 as its network portion. The :: represents the last 64 bits, which are available for hosts.
• Subnet for Engineering (Subnet ID 0002): 2001:0db8:ABCD:0002::/64
• Subnet for Servers (Subnet ID 0003): 2001:0db8:ABCD:0003::/64

Each of these /64 subnets can contain an enormous number of devices.

Why We Should Be Adopting IPv6 (And Why We're Not)

The Promise of IPv6:

1. Eliminates Address Scarcity: No more complex subnet calculations or address conservation strategies.
2. Simplified Network Design: Standard /64 subnets for most use cases eliminate the need for VLSM.
3. Better Security: Built-in IPsec support and improved privacy features.
4. Future-Proofing: Designed for the Internet of Things (IoT) and massive device proliferation.

The Reality of IPv6 Adoption:

Despite these advantages, IPv6 adoption has been slower than expected. Here's why:

1. Network Effect: The internet works because everyone can reach everyone else. IPv4 and IPv6 don't automatically communicate, requiring dual-stack implementations or translation mechanisms.
2. Legacy Systems: Many enterprise systems, cloud providers, and home networks still primarily use IPv4.
3. Complexity of Transition: Migrating from IPv4 to IPv6 requires careful planning, testing, and potential downtime.
4. Lack of Immediate Pressure: While IPv4 addresses are scarce, NAT (Network Address Translation) has extended their usable life significantly.

The Limitations of IPv6 Subnetting

While IPv6 solves many problems, it's not a panacea:

1. Security Complexity: The vast address space makes traditional network scanning techniques less effective, but also makes it harder to monitor and secure networks.
2. Management Overhead: The longer addresses and different notation can be more challenging to manage and troubleshoot.
3. Training Requirements: Network administrators need to learn new concepts and tools.
4. Compatibility Issues: Some older applications and systems may not support IPv6.

The Path Forward

• For Current Networks: Continue implementing the IPv4 subnetting strategies discussed in this article. They remain essential for security and network organization.
• For New Deployments: Consider implementing dual-stack (IPv4 + IPv6) from the start. This provides a migration path and future-proofs your infrastructure.
• For Long-term Planning: Begin IPv6 training and testing in non-critical environments. The transition will happen eventually, and early adopters will have advantages.

Conclusion: IPv6 as a Complement, Not Replacement

In summary, While both IPv4 and IPv6 use subnetting to segment networks, IPv6's vast address space simplifies the process significantly by allowing for a standard /64 prefix for most subnets, removing the need for complex address conservation calculations common in IPv4. IPv6 subnetting is more about creating a logical, hierarchical structure for your network than it is about squeezing every last usable address out of a block.

However, IPv6 adoption is not yet universal, and the security principles we've discussed remain critical regardless of the IP version you're using. Think of IPv6 as the future that will eventually make many of our current IPv4 challenges irrelevant, but for now, mastering IPv4 subnetting remains essential for building secure, scalable networks.

The key takeaway is that subnetting – whether in IPv4 or IPv6 – is fundamentally about network organization and security, not just address management. The principles of segmentation, isolation, and defense-in-depth apply regardless of the underlying protocol.

Conclusion

Subnets are far more than a simple networking feature; they are the architectural manifestation of a security-first mindset. In a world where data breaches are a constant threat, mastering the art of subnetting is no longer optional. It's the critical skill that allows you to segment your network, isolate sensitive assets, and build the kind of resilient, secure applications that protect not only your data but the trust of your users.