Public vs Private Network #

One of the most fundamental design decisions when architecting infrastructure in the cloud is determining the accessibility level of every compute resource we deploy: does a component need to be directly reachable from the public internet, or is access from inside the internal VPC network sufficient? The answer determines whether the resource lives on the Public Network (Public Subnet) or the Private Network (Private Subnet). This separation directly impacts our system’s overall security posture. As a standard rule in security engineering, we must apply the principle of minimal exposure: expose as few components as possible to the public internet, and protect as many resources as possible behind an isolated private network.

The Fundamental Difference: Public vs Private Subnet #

The main difference between public and private subnets isn’t in the physical characteristics of server hardware, but in the routing configuration of the virtual network routing table (Route Table) associated with the subnet.

Here’s a detailed comparison table of operational characteristics between Public and Private Networks in the cloud:

Behind the Scenes: How Cloud Providers Isolate Our Network? #

Inside the cloud provider’s physical data center, thousands of hypervisor servers are connected in one giant shared physical network. However, as cloud customers, we’re guaranteed our network is fully logically isolated. How does this work?

Cloud providers use Software-Defined Networking (SDN) and Overlay Network technologies. Encapsulation protocols like Geneve or VXLAN wrap our data traffic:

1. Packet Encapsulation: When our VM sends a data packet, the host hypervisor captures it and wraps it into a physical UDP packet.
2. Network Metadata: The hypervisor inserts special metadata — a Customer ID (Tenant ID) or VPC ID — into the wrapper packet header.
3. Mapping Database: The hypervisor consults the cloud provider’s centralized control database to find the physical IP address of the host server where the destination VM lives, then safely sends the packet through the data center’s physical network.
4. Decapsulation: Upon arrival at the destination host server, the receiving hypervisor unwraps the physical UDP packet, verifies its VPC ID, and forwards the original ethernet packet to the destination VM.

Meanwhile, dynamic public IP translation also happens at the infrastructure level. Our VM instances never actually know their own public IP address. The operating system inside the VM only sees its private IP. When data packets are sent out, the Internet Gateway (IGW) performs dynamic 1:1 NAT (Network Address Translation), mapping our private IP to an external public IP instantly at the network edge.

Types of IP Addresses in the Cloud #

To understand how network accessibility is controlled, we must distinguish the characteristics of IP address types used in cloud environments:

1. Private IP Address #

A private IP is an internal IP address automatically allocated to every resource inside a subnet. It’s taken from the subnet’s CIDR block range where the resource runs (per RFC 1918 standards). Private IPs are used for internal communication between resources within the same VPC. Private IPs can’t be recognized or routed on the public internet.

2. Dynamic Public IP Address #

A dynamic public IP is a temporary public address lent from the cloud provider’s IP pool to our VM instance. This IP lets the VM communicate with the outside internet.

• Ephemeral Nature: Dynamic public IPs are non-permanent. If we stop a VM instance and then start it again, the public IP is released back to the provider’s pool and our instance gets a different new public IP.

3. Elastic IP / Static IP Address #

An Elastic IP (on AWS) or Static IP is a permanent public IP address allocated specifically to our cloud account.

• Advantages: This IP doesn’t change even if our VM instance is stopped, deleted, or replaced. We can associate the Elastic IP with a new instance at any time.
• Ideal Scenarios: Essential for endpoints whose IP must never change — like DNS record configurations, firewall whitelists for third-party partner APIs, or NAT Gateway outbound IPs.
• Cost Rules: Cloud providers usually charge a small rental fee for Elastic IPs not associated with running instances. This policy prevents hoarding of public IPs, whose global supply is dwindling.

Security Architecture Pattern: Defense in Depth (Tier Separation) #

When designing reliable cloud network security, we apply the Defense in Depth principle (Layered Defense). We divide the system into network tiers that are physically and logically separated. That way, if one defense layer is breached by hackers, core system components (like databases) remain safely protected in the innermost layer.

flowchart TD
    Internet["Public Internet"] --> PublicSubnet
    
    subgraph PublicSubnet["1. PUBLIC SUBNET (DMZ Layer)"]
        ALB["Application Load Balancer (ALB)<br>Port 443 Open"]
    end
    
    ALB -->|"Only Forward Port 8080"| PrivateSubnet
    
    subgraph PrivateSubnet["2. PRIVATE SUBNET (App Layer)"]
        AppA["App Server A (Stateless)"]
        AppB["App Server B (Stateless)"]
    end
    
    PrivateSubnet -->|"Only Forward Port 5432"| DataSubnet
    
    subgraph DataSubnet["3. DATA SUBNET (Database Layer)"]
        DB["Database (RDS / NoSQL)<br>No Internet Route"]
    end

Defense Mechanism Explanation: #

1. DMZ (Demilitarized Zone) / Public Subnet: Only the Load Balancer (ALB) is exposed to the outside internet to receive SSL/TLS traffic (Port 443). The ALB acts as the front-line shield.
2. App Subnet (Private): Application servers have no public IP. They only accept HTTP connections from the Load Balancer’s Security Group on the internal application port (e.g., 8080).
3. Database Subnet (Data): The database sits in the innermost subnet with no internet route. It only accepts TCP connections from the application servers’ Security Group on the database port (e.g., 5432). Internet hackers have absolutely no physical or logical network path to touch the database directly.

Hybrid Connectivity: Connecting Cloud Networks to Local Data Centers #

For enterprise-scale corporations, the cloud often doesn’t stand alone. We need secure connectivity linking private subnets in the cloud to local data centers (on-premise data centers) or company branch offices.

There are two main methods for connecting these two isolated network environments:

1. Site-to-Site VPN (IPsec VPN) #

Site-to-Site VPN builds an encrypted tunnel using the IPsec protocol over the public internet to connect the local router (Customer Gateway) with the cloud gateway (Virtual Private Gateway).

flowchart LR
    OnPrem["Local Data Center<br>192.168.0.0/16"] <-->|"IPsec Tunnel (Public Internet)"| VPC["Cloud Private Subnet<br>10.0.10.0/24"]

• Advantages: Cheap implementation cost, very fast setup (a matter of hours), and supported by almost all physical router devices.
• Disadvantages: Latency and connection stability depend entirely on fluctuating public internet conditions. Bandwidth speeds are usually limited to around 1.25 Gbps per tunnel.

2. Dedicated Connection (AWS Direct Connect / GCP Dedicated Interconnect) #

A Dedicated Connection rents a special physical fiber optic cable path (private leased line) from a partner telecom provider to connect our local data center directly to the cloud provider’s facility, completely bypassing the public internet.

• Advantages: Provides very consistent latency performance, the highest security level, and massive bandwidth capacity (from 1 Gbps to 100 Gbps).
• Disadvantages: Very expensive monthly rental fees and long physical setup times (weeks to months).

Secure Operational Access to Private Resources #

Although our application servers and databases are safely isolated in private subnets without public IPs, developers and system administrators still need access for maintenance, debugging, or data schema migrations. There are three industry-standard methods for opening access paths without sacrificing security:

1. Bastion Host (Jump Server) #

A Bastion Host is a dedicated VM instance placed in the Public Subnet acting as a jump bridge (jump server) for engineers to SSH/RDP into private servers.

flowchart LR
    Engineer["Engineer Laptop"] -->|"1. SSH Port 22"| Bastion["Bastion Host<br>(Public Subnet)"]
    Bastion -->|"2. SSH Port 22"| PrivateServer["App Server / DB<br>(Private Subnet)"]

Bastion Host Security Hardening Practices:

• Restrict the Bastion Host’s Security Group to only accept SSH connections from the office public IP or engineers’ home VPN IPs (source IP whitelisting). Never open it to 0.0.0.0/0.
• Disable password-based authentication; SSH Key cryptography is mandatory.
• Use the SSH ProxyCommand (Tunneling) method so engineers don’t need to store production server private keys on the Bastion Host machine itself.

2. Client-to-Site VPN #

Client VPN lets engineer laptops connect privately to the VPC network through an encrypted VPN tunnel.

• Advantages: Once the VPN is active, the engineer’s laptop gets a virtual private IP and can access private cloud servers directly, as if the laptop were physically wired inside the data center. This access is far more natural, secure, and easy to audit through centralized VPN logging systems.

3. Cloud-Native Session Manager (SSM / IAP) #

This is the most modern and secure method (Zero Open Ports). Cloud providers (like AWS Systems Manager Session Manager or GCP Identity-Aware Proxy) provide a small agent running inside the private Virtual Machine’s OS.

flowchart TD
    Engineer["Engineer CLI / Console"] -->|"HTTPS Request"| CloudControl["Cloud Control Plane (IAM)"]
    CloudControl -->|"Secure Tunnel"| SSMAgent["SSM Agent in Private VM"]
    SSMAgent --> Shell["VM Shell Terminal Access"]

• Why is this the best?: We don’t need to open any SSH port (Port 22) on our server Security Groups at all. All data traffic is transferred over secure HTTPS via the internal agent. Authentication and authorization are fully controlled using the cloud provider’s IAM (Identity and Access Management) policies, complete with auditable terminal keystroke activity logging in CloudWatch or S3.

Code Example: Security Group Chaining Pattern with Terraform #

Here’s an example Terraform declaration demonstrating network security best practices: deploying a Load Balancer in the public subnet and application VMs in the private subnet, using the Security Group Chaining pattern (the VM instance’s Security Group only allows inbound traffic sourced from the Load Balancer’s Security Group):

# ✓ CORRECT: Use Security Group Chaining to lock access to private servers

# 1. Security Group for the Load Balancer (Open to the Internet)
resource "aws_security_group" "alb_sg" {
  name        = "alb-security-group"
  description = "Controls inbound traffic from the internet to the ALB"
  vpc_id      = aws_vpc.main.id

  # Allows HTTPS inbound from the entire public internet
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allows outbound to anywhere
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# 2. Security Group for Application Servers (Isolated in the Private Subnet)
resource "aws_security_group" "app_sg" {
  name        = "app-server-security-group"
  description = "Only accepts traffic from the Load Balancer"
  vpc_id      = aws_vpc.main.id

  # ✓ CORRECT: SG Chaining - Only accept inbound from the ALB SG, not from IP CIDR blocks
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id] # Only allowed from the ALB
  }

  # Allows outbound for patching via NAT Gateway
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Summary #

• Public subnets connect directly to the Internet Gateway, while private subnets have no direct inbound path from outside.
• Apply Defense in Depth architecture by separating the system into a public tier (Load Balancer), a private tier (App Servers), and a data tier (Database).
• Use Overlay Networks and SDN to logically isolate cross-customer traffic using encapsulation ID tags at the hypervisor level.
• Use Elastic IPs for permanent static public IP addresses for third-party whitelisting needs or stable DNS records.
• The Security Group Chaining pattern locks private server access so they can only be reached through the official Load Balancer, not from the open external network.
• Hybrid Connectivity links cloud and on-premise — use Site-to-Site VPN as a cheap alternative, or Dedicated Connection for best performance.
• Operational access must use VPN or cloud-native Session Manager, avoiding opening SSH ports (Port 22) to the public internet.
• Databases should always sit in private/data subnets with no public IP to minimize the attack surface.

← Previous: Subnet, CIDR, Routing   Next: NAT, Firewall, Security Group →