How do EC2 instances in public vs private subnets differ?

Placing an Amazon EC2 instance in a public subnet versus a private subnet primarily determines how the instance communicates with the external internet. An instance in a public subnet has a direct route to an Internet Gateway, allowing it to send and receive inbound and outbound internet traffic directly when assigned a public IP address. Conversely, an instance in a private subnet lacks a direct route to an Internet Gateway, shielding it from unsolicited inbound internet connections while requiring a NAT Gateway or NAT Instance for outbound internet access. Understanding these architectural differences is essential for designing secure, scalable, and cost-effective cloud networks in Amazon Virtual Private Cloud.

What Defines a Public Subnet in AWS?

A subnet within an Amazon Virtual Private Cloud (VPC) is classified as public based on its routing configuration rather than any inherent toggle setting. Specifically, a public subnet is associated with a custom or main route table that includes a default route (0.0.0.0/0 for IPv4 or ::/0 for IPv6) pointing directly to an attached Internet Gateway (IGW).

When you launch an EC2 instance into a public subnet, several characteristics apply:

• Direct Internet Reachability: If the EC2 instance is assigned a public IPv4 address, an Elastic IP address, or a globally unique IPv6 address, external users and systems on the internet can initiate connections directly to the instance, provided Security Groups and Network Access Control Lists (NACLs) permit the traffic.
• Bidirectional Traffic Flow: The Internet Gateway performs one-to-one Network Address Translation (NAT) between the instance's private IPv4 address and its public IPv4 address for outbound and inbound traffic.
• Common Use Cases: Public subnets are designed for resources that must be directly accessible from the public internet, such as public-facing web servers, bastion hosts, reverse proxies, and Application Load Balancers (ALBs).

What Defines a Private Subnet in AWS?

A private subnet is associated with a route table that does not contain a route to an Internet Gateway. By default, its route table only contains a local route (such as 10.0.0.0/16 pointing to local), which enables internal communication within the VPC.

When an EC2 instance is placed in a private subnet, its networking behavior changes significantly:

• No Direct Inbound Internet Traffic: Even if you mistakenly assign a public IP address to an EC2 instance in a private subnet, the instance cannot be reached from the internet because there is no route to an Internet Gateway to handle the return or incoming traffic.
• Controlled Outbound Internet Access: To allow instances in a private subnet to download software patches, access external APIs, or communicate with third-party services without exposing them to inbound requests, architects route 0.0.0.0/0 traffic to a NAT Gateway (or NAT Instance) residing in a public subnet.
• Private AWS Service Access: Instances in private subnets often use VPC Endpoints ( powered by AWS PrivateLink) or Gateway Endpoints (for Amazon S3 and DynamoDB) to communicate with AWS services privately without traversing the public internet.
• Common Use Cases: Private subnets are ideal for backend application servers, relational databases (such as Amazon RDS), caching layers, internal microservices, and sensitive data processing workloads.

Key Differences Between Public and Private Subnet EC2 Instances

Routing and Network Address Translation Mechanics

To understand how packet flow differs, consider a VPC with a CIDR block of 10.0.0.0/16, where the total number of available IPv4 addresses in a given subnet with prefix length \(n\) is calculated by subtracting the 5 AWS-reserved IP addresses:

\[\text{Available IPs} = 2^{(32 - n)} - 5\]

Public Subnet Packet Flow

1. An EC2 instance (10.0.1.25) in a public subnet (10.0.1.0/24) initiates a request to an external IP (203.0.113.50).
2. The subnet route table evaluates the destination against its rules, matches 0.0.0.0/0, and forwards the packet to the Internet Gateway.
3. The Internet Gateway replaces the source IP (10.0.1.25) with the instance's associated public IP (e.g., 54.210.10.5) and sends it to the internet.
4. Return traffic arrives at 54.210.10.5, and the Internet Gateway translates the destination back to 10.0.1.25.

Private Subnet Packet Flow

1. An EC2 instance (10.0.2.40) in a private subnet (10.0.2.0/24) initiates an outbound request to 203.0.113.50 to download an OS update.
2. The private subnet route table matches 0.0.0.0/0 and forwards the packet to the NAT Gateway (10.0.1.100), which lives inside the public subnet.
3. The NAT Gateway rewrites the source IP to its own Elastic IP address and forwards the packet to the Internet Gateway using the public subnet's route table.
4. When the response returns to the NAT Gateway's Elastic IP, the NAT Gateway checks its state table and forwards the packet back to 10.0.2.40. Unsolicited inbound connections to the NAT Gateway's Elastic IP are dropped immediately.

Security and Operational Implications

Defense in Depth

Placing backend EC2 instances in private subnets is a foundational principle of defense in depth. If a security engineer misconfigures a Security Group on an instance in a public subnet by accidentally opening port 22 (0.0.0.0/0), that instance is immediately vulnerable to brute-force attacks from the internet. If the same misconfiguration occurs on an instance in a private subnet, external attackers still cannot reach the instance directly because the VPC routing layer provides an additional barrier.

Administrative Access

Because you cannot SSH or RDP directly into an EC2 instance in a private subnet over the public internet, administrators use secure intermediaries:

• AWS Systems Manager Session Manager: Allows browser-based or CLI shell access using IAM policies without opening inbound ports or managing SSH keys (requires outbound HTTPS access to SSM endpoints via NAT or VPC Interface Endpoints).
• EC2 Instance Connect Endpoint: Enables private SSH and RDP connections to instances in private subnets without requiring a public IP address or bastion host.
• Bastion Hosts (Jump Boxes): Hardened EC2 instances placed in a public subnet that forward authenticated SSH/RDP sessions to private instances.

Cost Considerations

Running EC2 instances in a public subnet incurs no hourly fee for the Internet Gateway itself, though standard outbound data transfer rates apply. In contrast, providing internet access to EC2 instances in a private subnet via a NAT Gateway incurs an hourly availability charge per NAT Gateway (typically deployed once per Availability Zone for high availability) plus a per-gigabyte data processing charge. To optimize costs for high-throughput workloads in private subnets, architects frequently deploy Gateway VPC Endpoints for Amazon S3 and DynamoDB, which route traffic directly to those services at no additional hourly or per-GB endpoint charge.