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

The lab exercise aimed to help the reporter connect networking concepts to a real troubleshooting scenario involving two EC2 instances in the same subnet. One instance could reach the internet, while the other could not. The reporter investigated the cause of the difference and examined whether using a different CIDR range for a new VPC would pose any issues.

The scenario involved a VPC with a CIDR range of 10.0.0.0/16, containing two EC2 instances: Instance A and Instance B. Both instances shared a similar configuration but had different connectivity capabilities. Instance A could not reach the internet, whereas Instance B could. Additionally, the reporter was asked to consider creating a new VPC using the CIDR range 12.0.0.0/16 and whether it would cause any problems.

To investigate the issue, the reporter first reviewed the architecture of the VPC, focusing on factors that could affect connectivity, such as IP addresses, routes, security groups, and network paths. After comparing the IP addresses of both instances, the reporter found that Instance A had only a private IP address, while Instance B had both a private and a public IP address.

This difference was crucial because it explained why Instance A could not be directly connected to from outside the VPC, while Instance B could be accessed via SSH from outside the VPC, provided the network configuration allowed the connection. The reporter also learned about the role of route tables in determining network traffic destinations.

The route table should contain a route similar to 0.0.0.0/0 → Internet Gateway for internet-bound traffic. However, having a public IP address alone does not guarantee internet connectivity; an appropriate network path is also necessary. Additionally, the reporter checked the security group attached to the EC2 instances. A security group acts as a virtual firewall, controlling inbound and outbound traffic based on rules.

For an SSH connection, the security group should have an inbound rule allowing TCP traffic on port 22 (SSH). The reporter observed that the security group allowed SSH traffic from any IPv4 address (0.0.0.0/0), which was useful for understanding that a public IP address does not automatically grant internet accessibility. The network path and security rules also play a significant role in allowing traffic to reach the instance.

If the instance had only a private IP address, it could still access the internet through a NAT Gateway, but it could not be directly accessed from the internet using its private IP. This distinction clarified that a private IP is for internal VPC communication or connected private networks, not for direct public internet access.

To access an EC2 instance securely, one could use methods like SSH from within the VPC, VPN connections, or other secure remote access solutions. The reporter concluded that while the difference in IP configurations was a key factor in the connectivity issue, other elements like route tables and security groups also contributed to the problem.

The lab illustrated the importance of understanding various networking aspects to troubleshoot and optimize connectivity in AWS environments.