DEV Community: Purity Chepkemoi

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

Purity Chepkemoi — Thu, 08 Oct 2026 16:33:31 +0000

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:

Why were the two EC2 instances behaving differently?
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

CloudFormation: A Hands-On Journey Through Compute, Nesting, and Custom Resources

Purity Chepkemoi — Fri, 10 Jul 2026 19:20:47 +0000

As part of my intensive DevSecOps training with ParoCyber, I’ve been deep-diving into AWS CloudFormation.
For these exercises, I am working through the CloudFormation Mastery Lab Documentation on GitHub.

I am writing this article to document my personal walkthrough, observations, and how I tackled the challenges along the way.

The 3 Levels At A Glance
Here is a quick overview of what we are building and what each stage demonstrates:

Level 5 — Compute & Wiring: Moving beyond static resources to deploy a live, bootstrapped Apache web server on EC2 wrapped inside localized Security Groups.

Level 6 — Composition (Nested Stacks): Breaking down monolithic templates into a clean, reusable modular architecture managed by a single Parent stack.

Level 7 — Dynamic Intelligence (Custom Resources): Extending CloudFormation's native capabilities by using a Python Lambda function to query customized AMI filters dynamically.

Level 5 — Compute & Wiring: EC2, Security Groups & Intrinsic Functions

I saved the code as webserver.yaml and deployed it via the CloudFormation console using t3.micro.

The public IP in the Outputs tab is:18.234.230.243

Observation Point
Once deployed, I updated the stack to switch the InstanceType from t3.micro to t3.small.

Question: Does the Public IP shown in the Outputs tab change after this update?Yes, it changes, InstanceType can be updated in place for many instance families, but the public IP is not guaranteed to persist across a stop-and-start cycle unless you're using an Elastic IP. CloudFormation performs this as a "stop, resize, start" operation under the hood for compatible type changes, and AWS reassigns a new public IPv4 address on start unless one was reserved. Refresh the Outputs tab after the update completes and compare the new PublicIp value to the one you noted before. This is why production architectures almost never rely on raw instance public IPs, they sit behind an Elastic Load Balancer (which you'll build in Level 9) or use an Elastic IP resource explicitly.
Level 5 Challenge: Stabilizing the IP
To make the public IP persist across instance replacement , I modified the template to introduce an AWS::EC2::EIP resource and an AWS::EC2::EIPAssociation.In the Outputs tab that the public IP now stays the same

Level 6 — Composition: Nested Stacks

Because nested templates must be fetched programmatically by the CloudFormation engine, I first had to spin up an S3 bucket and upload the child templates.

Deploy the root stack

Challenge
Add a third nested stack, a security.yaml template that creates a standalone AWS::EC2::SecurityGroup, upload it to the same S3 bucket, then modify compute.yaml to accept that Security Group ID as a Parameter instead of creating its own. This mirrors how real platform teams separate "network," "security," and "compute" ownership across different template authors.
I added a third nested stack, SecurityStack, using a new security.yaml template. This template creates a standalone AWS::EC2::SecurityGroup and accepts the VPC ID from the parent stack.

The architecture is now split into three reusable components:

network.yaml: Creates the VPC and subnet; outputs VpcId and SubnetId.
security.yaml: Accepts VpcId, creates the web server security group allowing HTTP (port 80), and outputs SecurityGroupId.
compute.yaml: No longer creates a security group; accepts SecurityGroupId and uses it in the EC2 instance SecurityGroupIds property.

I uploaded security.yaml to the same S3 bucket as the other nested templates and updated root.yaml to add the new nested stack.

Level 7 — Dynamic Intelligence: Custom Resources

I uploaded custom-resource.yaml, named the stack level7-custom-resource, and proceeded through the wizard. On the Review screen, I saw a new section near the bottom labeled "I acknowledge that AWS CloudFormation might create IAM resources." I checked this box, which serves as the console's version of the CAPABILITY_IAM flag, before submitting the stack.
After the stack reached CREATE_COMPLETE, I opened the Outputs tab and viewed the ResolvedAmiId value that the Lambda function had automatically discovered.

Challenge
Modify the Lambda to also handle the Delete RequestType meaningfully, have it log the AMI ID it's "cleaning up" (even though there's nothing to actually delete in this case) to prove you understand that every Custom Resource lifecycle event needs explicit handling. Check CloudWatch Logs (search "CloudWatch" in the console, then Log groups) to confirm your log line appears after you delete the stack.
I modified the Lambda function to handle the Delete RequestType by logging the AMI ID it was "cleaning up," even though there was no actual resource to delete. This demonstrated my understanding that every Custom Resource lifecycle event requires explicit handling.

After deleting the stack, I checked the CloudWatch Logs by navigating to CloudWatch and opening the Logs section, where I confirmed that the expected log entry had been recorded