My EC2 Instance Has a Public IP. So Why Can't It Reach the Internet?
Having a public IPv4 address does not guarantee that an EC2 instance can access the internet. This article walks through the network path and shows how route tables, internet gateways, security groups, DNS, and subnet configuration can affect internet connectivity.
My EC2 Instance Has a Public IP. So Why Can't It Reach the Internet?
You launch an EC2 instance, connect to it, and notice that it has a public IPv4 address.
Then you run:
1
curl https://example.comand nothing happens.
At first, this seems strange. The instance has a public IP, so it should be able to reach the internet, right?
Not necessarily.
A public IPv4 address is only one part of the network configuration. The instance also needs a route to an internet gateway, and the relevant security controls must allow the traffic.
This is one of those AWS networking problems that becomes much easier once you stop looking at the EC2 instance by itself and follow the complete network path.
What Does "Public IP" Actually Mean?
An EC2 instance can have a private IPv4 address inside its VPC and a public IPv4 address used for internet communication.
For example:
1
2
Private IP: 10.0.1.25
Public IP: 54.x.x.xThe instance itself primarily works with its private address inside the VPC.
For IPv4 internet communication, the internet gateway provides the one to one network address translation between the instance's private address and its public IPv4 address.
But the public IP does not create the entire path to the internet.
You can think of the setup like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
EC2 Instance
|
| Private IP
v
Subnet
|
v
Route Table
|
v
Internet Gateway
|
v
InternetIf one of the required pieces is missing or incorrectly configured, the request can fail.
AWS describes the same basic requirement: an EC2 instance needs a public IPv4 address or IPv6 address, and the subnet needs appropriate routing through an internet gateway for internet connectivity.
The First Thing to Check: Is the Subnet Actually Public?
This is probably the most common source of confusion.
AWS calls a subnet public when its route table has a route to an internet gateway.
For IPv4, the route commonly looks like this:
1
2
3
Destination Target
10.0.0.0/16 local
0.0.0.0/0 igw-xxxxxxxxThe
0.0.0.0/0 route is the default route for IPv4 traffic. It means traffic destined for an address that does not match a more specific route should be sent to the internet gateway.If the subnet does not have this route, the subnet is not public, even if the EC2 instance has a public IPv4 address.
AWS explicitly notes that an instance in a private subnet cannot communicate with the internet through an internet gateway, even if the instance has a public IP address.
So if your instance has a public IP but cannot reach the internet, check the subnet's route table first.
Check the Route Table
In the AWS console, open:
VPC → Route tables
Find the route table associated with the instance's subnet.
You are looking for something similar to:
1
2
3
Destination Target
10.0.0.0/16 local
0.0.0.0/0 igw-xxxxxxxxThe exact VPC CIDR will obviously be different in your environment.
If you have:
1
10.0.0.0/16 localbut no default route to an internet gateway, the instance does not have a direct IPv4 route to the internet.
AWS's documentation shows the same configuration for a public subnet, where
0.0.0.0/0 points to the VPC's internet gateway.A common mistake
You may have created an internet gateway and attached it to the VPC, but the instance still cannot reach the internet.
Attaching the internet gateway is not enough.
The subnet's route table also needs to use that internet gateway as a target for internet bound traffic.
The distinction is important:
1
2
3
Internet Gateway attached
≠
Subnet has internet routeBoth are needed for this type of IPv4 connectivity.
Check the Internet Gateway
Next, verify that your VPC actually has an internet gateway attached.
Go to:
VPC → Internet gateways
You should see an internet gateway with a state indicating that it is attached to your VPC.
The basic setup is:
1
2
3
VPC
|
+── Internet GatewayThen your public subnet route table needs a route to that gateway:
1
0.0.0.0/0 → Internet GatewayAWS describes an internet gateway as the VPC component that enables communication between the VPC and the internet.
Check the Security Group
The next thing to check is the EC2 instance's security group.
Security groups control allowed traffic for the resources they are associated with.
For outbound internet access, the security group needs an appropriate outbound rule.
A common configuration is:
1
2
3
4
5
Outbound
Type: All traffic
Protocol: All
Destination: 0.0.0.0/0If your security group uses more restrictive outbound rules, make sure the required traffic is allowed.
Security groups are stateful. When an instance initiates a connection and the traffic is allowed, the response traffic is allowed back through the security group without requiring a separate inbound rule for that response.
This is important because people sometimes see the word "inbound" and assume that an inbound rule is required for an EC2 instance to make an outbound request.
For example, if your application does this:
1
2
3
4
5
EC2
|
| HTTPS request
v
External APIthe security group needs to permit the outbound connection.
The response traffic is handled by the stateful behavior of the security group.
What About Network ACLs?
If the route table and security group look correct, Network ACLs are another place to check.
Network ACLs operate at the subnet level.
Unlike security groups, Network ACLs are stateless. This means the rules need to account for both directions of traffic.
For example, an outbound request from an EC2 instance produces response traffic that also needs to be permitted by the applicable Network ACL rules.
This is one reason overly restrictive Network ACLs can create confusing connectivity problems.
If you have not intentionally configured custom Network ACL rules, they are less likely to be the cause than a missing route or security group configuration. But they are worth checking when the simpler checks look correct.
Don't Forget DNS
There is another interesting case.
Your EC2 instance might actually have internet connectivity, but DNS resolution may be failing.
Try:
1
curl https://1.1.1.1and compare it with:
1
curl https://example.comIf the first test works but the second does not, you may be dealing with DNS resolution rather than basic internet routing.
This is a useful distinction.
A failed request to a domain does not automatically mean that the EC2 instance has no internet connectivity.
AWS VPCs provide DNS functionality through AmazonProvidedDNS, subject to the VPC DNS settings and the instance's own DNS configuration. When troubleshooting, separate DNS problems from routing problems rather than treating both as the same issue.
A Simple Troubleshooting Flow
When an EC2 instance has a public IPv4 address but cannot reach the internet, I would check the configuration in this order.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Does the instance have a public IPv4 address?
|
v
Does the subnet route table have
0.0.0.0/0 → Internet Gateway?
|
v
Is the Internet Gateway attached to the VPC?
|
v
Does the security group allow
the required outbound traffic?
|
v
Are Network ACL rules allowing
the traffic in both directions?
|
v
Does DNS resolution work?
|
v
Check the instance's own
OS level firewall and configurationThis order starts with the AWS network path and gradually moves toward the instance itself.
One Important Difference: Public IP vs Private Subnet
There is a common misconception that a public IPv4 address automatically makes an instance part of a public subnet.
It does not.
Consider this configuration:
1
2
3
4
5
6
VPC
|
+── Private Subnet
|
+── EC2
Public IPv4If the subnet's route table does not have a route to an internet gateway, the instance cannot use that internet gateway for internet communication.
The public IP does not override the subnet's routing configuration.
This is why AWS networking should be viewed as a collection of connected pieces rather than a single "public or private" switch.
What If You Don't Want a Public IP?
This is where the architecture changes.
An application server does not always need a public IP simply because it needs outbound internet access.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
Internet
|
v
Load Balancer
|
v
Private EC2
|
v
NAT Gateway
|
v
InternetThe EC2 instance can remain in a private subnet without a public IPv4 address.
Its route table can send internet bound IPv4 traffic to a NAT gateway.
The NAT gateway is placed in a public subnet and has a route through an internet gateway.
This is a common architecture for application servers that need outbound connectivity but should not be directly reachable from the internet. AWS documents NAT gateways as one way to provide internet access to instances in private subnets.
This also gives you an important architectural choice.
Public EC2:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
Internet Gateway
|
v
Public Subnet
|
v
EC2Private EC2 with NAT:
1
2
3
4
5
6
7
8
9
10
11
12
13
Internet
^
|
Internet Gateway
^
|
NAT Gateway
^
|
Private Subnet
^
|
EC2The second design is often a better fit when the instance should not accept direct internet traffic.
A Real Example
Suppose you launch an Ubuntu EC2 instance and receive:
1
2
Public IPv4: 54.x.x.x
Private IPv4: 10.0.1.25You connect through SSH successfully, but this fails:
1
curl https://example.comInstead of immediately changing the operating system or reinstalling the instance, check the AWS network configuration.
First, inspect the subnet route table.
If you find:
1
10.0.0.0/16 → localbut no:
1
0.0.0.0/0 → Internet Gatewayyou have found a likely cause.
The instance has a public IP, but its subnet does not have a route to an internet gateway.
Add the appropriate route to the route table, assuming this subnet is intentionally designed to be public.
Then check the security group's outbound rules.
If the outbound traffic is permitted and the instance's operating system and DNS configuration are functioning correctly, the request should have the network path it needs.
This is a much better troubleshooting approach than randomly changing security rules until something works.
The Mental Model I Use
When an EC2 instance cannot reach the internet, I think about the request as a chain:
1
2
3
4
5
6
7
8
9
EC2
↓
Subnet
↓
Route Table
↓
Internet Gateway
↓
InternetThen I ask what controls each step.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Public IP
↓
Can the instance communicate using a public address?
Route Table
↓
Does the subnet have a route to the internet gateway?
Internet Gateway
↓
Is it attached to the VPC?
Security Group
↓
Is the required outbound traffic allowed?
Network ACL
↓
Is traffic allowed at the subnet level?
DNS
↓
Can the instance resolve the destination?Once you think about connectivity this way, the problem becomes much easier to narrow down.
Conclusion
An EC2 instance having a public IPv4 address does not mean that internet connectivity is guaranteed.
For a typical IPv4 public subnet configuration, you need the public address, an internet gateway attached to the VPC, a route from the subnet to that gateway, and security controls that permit the required traffic.
When something fails, avoid changing several settings at once.
Start with the route table. Then check the internet gateway, security group, Network ACL, DNS, and finally the instance's own configuration.
The useful lesson is not just how to fix one broken EC2 instance.
It is learning to trace a network request from the application to its destination and identify which AWS component controls each part of that path.
That mental model becomes useful far beyond EC2. You will use the same way of thinking when working with load balancers, RDS, containers, private subnets, NAT gateways, and other AWS services.
Further Reading
For more details, see the official AWS documentation:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article