EC2 instance unable to make outbound HTTPS connections, but identical instance in same VPC works

Question

Hello AWS Community,
I have an Ubuntu-based EC2 instance that cannot make outbound HTTPS (port 443) connections, even though another instance, launched from an AMI of the failing instance and using the same VPC and security settings, works fine.

**Issue Summary:**
* My EC2 instance cannot connect to external services over the internet.
* Outbound traffic, including HTTPS (port 443), is being rejected.
* Common errors observed:
    * curl -I https://www.google.com → Connection timed out
    * nc -zv google.com 443 → Connection timed out
    * apt update → Failed to fetch repositories
    * VPC Flow Logs show outbound HTTPS traffic being REJECTED.

Example Flow Log:
```
eni-........-....-....-....-............ 172.31.. .. 142.250... ... 57692 443 6 10 600 .......... .......... REJECT OK
```
**Troubleshooting Steps Taken**

✅ Instance & Network Configurations:
* The instance is running and can be accessed via SSH.
* Security Group allows all outbound traffic (0.0.0.0/0, all ports, all protocols).
* Network ACL allows all outbound traffic (0.0.0.0/0, all ports, all protocols).
* Instance is in a public subnet with an Internet Gateway (IGW) attached.
* Route Table includes: 0.0.0.0/0 → IGW.
* No AWS Network Firewall is active.
* No Service Control Policies (SCPs) restricting outbound traffic.
* An OS-level firewall (iptables, nftables) that has no blocking rules.

✅ Network Troubleshooting:
* Instance can ping 8.8.8.8 (outbound ICMP works).
* DNS resolution initially failed, but was fixed using AWS internal DNS (172.31.0.2).
* Outbound HTTPS traffic (port 443) is still blocked.

✅ Restarted Networking & Resolved DNS:

```
sudo systemctl restart systemd-networkd
sudo dhclient -r eth0
echo "nameserver 172.31.0.2" | sudo tee /etc/resolv.conf
```
Still no outbound connectivity.

✅ Created a New Instance to Test AWS Restrictions:
* Created an AMI of the affected instance and launched a new instance with the same VPC, same security groups, and same settings.
* New instance had full outbound internet access immediately.
* Old instance remained blocked.

**Questions for the AWS Community**
Could AWS be restricting outbound traffic on this particular instance for some reason (e.g., an automated block or quarantine)? If so, is there a way to verify this or request removal of the restriction? Alternatively, is there any instance-level configuration—beyond the OS firewall and VPC settings—that might cause these rejections? I have the new instance in production now, which I have created from the image of the broken one but would still like to understand what went wrong to prevent it from happening again.

Thank you in advance for any insights!

Any insights would be greatly appreciated! Thanks in advance for your help.

Best,
Paul

re:Post Agent · Answer

Based on the information provided, it appears that you've thoroughly checked most of the common causes for outbound connectivity issues on an EC2 instance. Since you've confirmed that the security group, network ACL, routing, and VPC configurations are correct, and that a new instance with the same settings works fine, the issue is likely specific to the original EC2 instance itself.

Here are a few additional things to consider:

1. Instance Metadata: Check if there are any issues with the instance metadata service. Try accessing the metadata URL from within the instance:
   curl http://169.254.169.254/latest/meta-data/

2. Network Interface: Verify that the network interface is correctly attached and configured:
   ip addr show
   ifconfig

3. MTU Settings: Ensure that the MTU (Maximum Transmission Unit) is set correctly:
   ip link show

4. TCP Timestamps: Sometimes, issues with TCP timestamps can cause connectivity problems. Try disabling them:
   sudo sysctl -w net.ipv4.tcp_timestamps=0

5. Instance Status Checks: Review the instance status checks in the EC2 console to see if there are any reported issues.

6. VPC Reachability Analyzer: Use the VPC Reachability Analyzer to trace the path from your instance to an external IP address (e.g., 8.8.8.8) on port 443.

7. AWS Support: If none of the above resolves the issue, it's possible that there could be an AWS-side restriction or issue specific to this instance. In this case, contacting AWS Support would be the best course of action. They can investigate if there are any account-specific or instance-specific blocks or issues that are not visible to you through the regular AWS console or API.

8. Instance Replacement: As a last resort, if AWS Support cannot identify any issues, consider terminating the problematic instance and launching a new one from the AMI you created. This approach would help isolate whether the problem is tied to the specific instance or if it's a broader issue within your AWS environment.

Remember to back up any important data before making significant changes to your instance.  
**Sources**  
[Troubleshoot connection to AWS service endpoints from Linux | AWS re:Post](https://repost.aws/knowledge-center/linux-troubleshoot-service-endpoints)  
[EC2 internet inbound/outbound not working us-east-1, works in all other regions | AWS re:Post](https://repost.aws/questions/QUFVoFWYzQT-2FnhlFYGHYng/ec2-internet-inbound-outbound-not-working-us-east-1-works-in-all-other-regions)

Gary Mclean · Answer

As your VPC flow log dictates, a security group or ACL is blocking access.
Does your Network ACL allow inbound access also? This is needed for return packets

**REJECT OK**

tapple (AWS) · Answer

I strongly recommend that you try out [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html). It was designed to diagnose issues like this.

EC2 instance unable to make outbound HTTPS connections, but identical instance in same VPC works

Add your answer

Relevant content