Troubleshooting Public vs Private IP Addresses in AWS: What I Learned from an AWS re/Start Lab

Networking has been one of the areas I've been trying to understand better during my AWS re/Start journey.

One lab helped me connect several networking concepts to an actual troubleshooting scenario: two EC2 instances were in the same subnet, but one could reach the internet while the other could not.

Instead of simply defining public and private IP addresses, the lab asked me to investigate what could be causing the difference.

This is how I approached it.

The Scenario

I was given a customer support scenario involving a VPC with a CIDR range of:

10.0.0.0/16

Inside the VPC were two EC2 instances:

• Instance A
• Instance B

Both instances were in the same subnet and had similar configurations.

However:

• Instance A could not reach the internet.
• Instance B could reach the internet.

The customer also wanted to create another VPC using:

12.0.0.0/16

and wanted to know whether that would cause any issues.

So there were two questions to investigate:

1. Why were the two EC2 instances behaving differently?
2. Should 12.0.0.0/16 be used as the CIDR range for the new VPC?

Looking at the Architecture

Before looking for an answer, I first tried to understand the architecture.

The VPC contained the two EC2 instances in the same subnet.

At this point, I started thinking about the different things that could affect connectivity:

• What IP addresses did the instances have?
• Did both instances have public IP addresses?
• What routes were associated with the subnet?
• What did the security group allow?
• Was there a path for traffic to leave the VPC?

This was useful because it changed the way I looked at the problem.

Instead of thinking:

"One EC2 instance works and the other doesn't."

I started thinking:

"What is different about the network path to each instance?"

Step 1: Compare the IP Addresses

The first thing I checked was the networking information for both EC2 instances.

Instance A

Instance A had a private IP address only.

Instance B

Instance B had both a private IP address and a public IP address.

This was the first major difference I found.

Both instances had private IP addresses because resources inside a VPC use private addressing for communication.

The important difference was that Instance B also had a public IP address.

That gave me a possible explanation for why I could connect to Instance B using SSH from outside the VPC, while I couldn't directly connect to Instance A using its private IP address.

But an IP address is only one part of the story.

So what else would I check?

Step 2: Check the Route Table

The lab itself focused mainly on the difference between the public and private IP addresses.

If I were troubleshooting this in a real AWS environment, the next thing I would check is the route table associated with the subnet.

A route table determines where network traffic should go.

For internet-bound traffic from a subnet that uses an Internet Gateway, I would expect to see a route similar to:

0.0.0.0/0 → Internet Gateway

0.0.0.0/0 represents traffic destined for addresses outside the VPC.

This check is important because having a public IP address does not, by itself, guarantee internet connectivity.

There also needs to be an appropriate network path.

This is one of the things I'm learning about cloud networking: connectivity is usually the result of several pieces working together.

Step 3: Check the Security Group

Another thing I would check is the security group attached to the EC2 instance.

A security group acts as a virtual firewall for an EC2 instance. It controls which traffic is allowed to reach the instance and which traffic is allowed to leave it.

For an SSH connection, I would look for an inbound rule allowing:

TCP — Port 22 — SSH

In the lab environment, the SSH rule used:

0.0.0.0/0

as the source.

This means SSH traffic was allowed from any IPv4 address.

That helped me understand an important distinction:

A public IP address does not automatically mean that an instance is accessible.

The network path and security rules also have to allow the traffic.

For a real production environment, I would not leave SSH open to 0.0.0.0/0 unnecessarily. I would restrict access to trusted sources or consider a more secure management approach.

So What Was Actually Different?

After looking at the IP configuration, the main difference between the two instances was their addressing.

	Instance A	Instance B
Private IP	Yes	Yes
Public IP	No	Yes
Direct SSH from outside VPC	No	Possible*

*Assuming the required routing and security rules are correctly configured.

The fact that both instances were in the same subnet did not mean they had identical connectivity.

Instance A had only a private IP address, so I could not directly connect to it from outside the VPC using that private address.

Instance B had a public IP address, giving it an address that could be reached from outside the VPC, provided the rest of the configuration allowed the connection.

That was the key finding from the lab.

What If an EC2 Instance Has Only a Private IP?

This was one of the parts of the lab that helped me understand private IP addresses more clearly.

When I first think about an instance with only a private IP, it's tempting to think:

"If it doesn't have a public IP, it can't access the internet."

But that's not necessarily true.

There are two separate questions:

Can it access the internet?

Yes, depending on how the network is designed.

For example, an EC2 instance in a private subnet can use a NAT Gateway for outbound internet access.

A simplified traffic flow can look like:

EC2
 ↓
Private Subnet
 ↓
NAT Gateway
 ↓
Internet Gateway
 ↓
Internet

The EC2 instance doesn't need its own public IP for this type of outbound connectivity.

Can someone on the internet connect directly to it?

Not through its private IP address.

A private IP is intended for communication within the VPC or through connected private networks.

This is actually useful when you don't want a server to be directly exposed to the public internet.

How could you access it securely?

One option is AWS Systems Manager Session Manager.

Session Manager can allow administrators to manage an EC2 instance without giving it a public IP or opening inbound SSH access to the internet.

Another traditional approach is a bastion host, where an administrator connects to a controlled host in a public subnet and then uses it to reach instances in private subnets.

The distinction I took away was:

A private IP doesn't mean "no internet." It means the instance isn't directly reachable from the public internet.

That was an important distinction for me.

What About the Customer's 12.0.0.0/16 Question?

The second part of the scenario was about choosing a CIDR range for a new VPC.

The customer suggested:

12.0.0.0/16

To evaluate this, I needed to understand the private IPv4 address ranges commonly used for private networks.

They are:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

The existing VPC's:

10.0.0.0/16

falls within the private address space.

12.0.0.0/16 does not.

Because of that, I would not recommend using 12.0.0.0/16 as the VPC CIDR range.

Instead, I would choose an appropriate private CIDR range and consider how the network might grow and connect to other networks in the future.

This is important because network design decisions made at the beginning can affect future connectivity.

For example, poorly planned or overlapping address ranges can cause problems when connecting different networks.

What I Learned From the Lab

The biggest thing I took away from this lab wasn't simply:

"Public IP = accessible, private IP = not accessible."

It's more nuanced than that.

I started to think about connectivity as a series of questions:

IP address
     ↓
Routing
     ↓
Security rules
     ↓
Network path
     ↓
Connectivity

If something isn't working, I can work through those layers instead of immediately assuming that the EC2 instance itself is the problem.

I also learned that two instances can be in the same subnet and still have different connectivity because their configurations can differ.

And perhaps most importantly, I learned that troubleshooting isn't just about knowing definitions.

It's about knowing what to check next.

Networking is still one of the areas I'm working on, so I wouldn't say I've mastered it after one lab.

Final Takeaway

If I had to explain the main lesson from this lab to another beginner, I'd put it simply:

A private IP is an internal address, while a public IP provides an address that can be reached from outside the private network.

But whether an EC2 instance can actually communicate depends on more than its IP address.

You also need to think about:

• Routing
• Security groups
• Internet Gateways
• NAT
• The direction of the traffic
• How the resource is intended to be accessed

That was the part I found most valuable.

I started with a simple question about two EC2 instances and ended up seeing how several AWS networking concepts connect together.

And I'm still learning.

Part of my AWS re/Start journey

I originally documented this lab as part of my AWS re/Start learning journey on Medium.

Read the original article on Medium → https://medium.com/@pyuah16/my-aws-re-start-journey-part-2-networking-public-vs-private-ip-addresses-183f1c73143f

Comments

[DEV ANTIBOT]

You need to verify your account