Environment Investigation
Examined both EC2 instances to compare their networking configurations. Instance A had only private IP 10.0.10.72, while Instance B had public IP 44.244.216.218 and private IP 10.0.10.214.
Lab Summary
Investigated a customer scenario with two EC2 instances in the same VPC. Instance A had only a private IP (no public IP assigned), while Instance B had both a public and private IP. The lack of a public IP on Instance A was the reason it could not reach the internet.
Connectivity Test
Attempted SSH connections to both instances via PuTTY. Only Instance B was reachable because it had a public IP address assigned, confirming the root cause of the issue.
AWS Services Used
Amazon EC2
Two t3.micro instances (Instance A and Instance B) were pre-configured in the lab environment to replicate the customer's scenario. Their networking tabs were inspected to compare IP assignments.
Amazon VPC
A single VPC with CIDR range 10.0.0.0/16 hosted both instances in a public subnet. The VPC architecture included an Internet Gateway and proper route tables.
Step-by-Step Walkthrough
Detailed documentation of the troubleshooting process following the customer scenario.
01
Investigate the customer's environment
- Navigated to the EC2 console and opened the Instances page. Two instances were visible: Instance A and Instance B, both of type t3.micro and running in us-west-2a.
- Selected Instance A and checked its Networking tab. It had a private IPv4 address of
10.0.10.72but no public IPv4 address assigned. - Selected Instance B and found both a public IPv4 address of
44.244.216.218and a private IPv4 address of10.0.10.214.
The key difference: Instance A had no public IPv4 address. Without it, the instance is only reachable within the VPC, not from the internet.
ref
OSI Model and AWS Infrastructure
The lab introduced a troubleshooting approach based on the OSI model, mapping each layer to its equivalent AWS resource. Starting from the bottom (EC2 instance) and working up helps isolate the problem layer.
| Layer | OSI Function | AWS Equivalent |
|---|---|---|
| 7 | Application | Application |
| 6 | Presentation | Web/Application Servers |
| 5 | Session | EC2 Instances |
| 4 | Transport (TCP) | Security Groups, NACLs |
| 3 | Network (IP) | Route Tables, IGW, Subnets |
| 2 | Data Link (MAC) | Route Tables, IGW, Subnets |
| 1 | Physical | Regions, Availability Zones |
02
Test SSH connectivity to both instances
- Connected to the EC2 instances via PuTTY following the process described in Lab 225.
- Attempted to SSH into Instance A using its private IP. The connection failed because private IPs are not reachable from outside the VPC.
- Successfully connected to Instance B using its public IP
44.244.216.218, confirming that the public IP enables external access.
Q: Were you able to use SSH to connect to both instances? Why or why not?
No. Only Instance B was accessible via SSH. Instance A lacks a public IP address, so it cannot be reached from outside the VPC. Private IP addresses are only routable within the VPC itself. Instance B has a public IP, which allows connections from the internet through the Internet Gateway.
ref
Public vs. Private IP Addresses
Public IP
- Routable on the internet
- Required for external access to an instance
- Assigned by AWS or via Elastic IP
- Allows SSH, HTTP, and other inbound traffic from outside the VPC
Private IP
- Only routable within the VPC
- Used for internal communication between resources
- Automatically assigned from the subnet CIDR range
- Cannot receive traffic directly from the internet
Q: The customer asked about using a public CIDR range (e.g., 12.0.0.0/16) for a new VPC. Is that recommended?
No. Using a public IP range as a VPC CIDR block is not recommended. If the VPC uses addresses that belong to the public internet (like 12.0.0.0/16), responses destined for those addresses could be routed to unrelated external resources instead of staying within the VPC. This causes unpredictable behavior. AWS recommends using RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
Key Learnings
What Was Learned
✓
An EC2 instance needs a public IP address to be reachable from outside the VPC.
✓
Private IP addresses are only routable within the VPC and cannot establish connections to or from the internet.
✓
Using a public CIDR range for a VPC can cause routing conflicts with external internet resources.
✓
The OSI model can be applied as a troubleshooting framework for AWS networking issues.
Technical Conclusion
This lab demonstrated a common networking misconfiguration: an EC2 instance that lacks a public IP address cannot be accessed from the internet, even if the VPC architecture (Internet Gateway, route tables, subnets) is correctly set up.
The customer's Instance A only had a private IP, making it invisible from outside the VPC. The fix is to assign a public IP (either auto-assigned or via an Elastic IP). Additionally, the lab reinforced that VPCs should always use RFC 1918 private IP ranges to avoid routing conflicts with public internet addresses.