When your EC2 instance responds via Amazon-assigned DNS but becomes unreachable through its Elastic IP (EIP), we're typically dealing with one of these scenarios:

# Sample AWS CLI command to check instance status
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[].Instances[].NetworkInterfaces[].Association'

First, verify these fundamental configurations:

• EIP is properly associated with your instance (check in EC2 console > Elastic IPs)
• Instance security groups allow inbound traffic (HTTP/HTTPS/ping)
• Network ACLs aren't blocking the traffic
• Route tables properly route traffic to/from the instance

1. Security Group Misconfiguration:

# Example security group inbound rule allowing HTTP
aws ec2 authorize-security-group-ingress \
    --group-id sg-903004f8 \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

2. Instance-Specific Firewall Rules:

If using Linux, check iptables/ufw:

sudo iptables -L  # List current rules
sudo ufw status   # Check Uncomplicated Firewall status

Run these commands to verify network paths:

# Check network interface associations
aws ec2 describe-network-interfaces --filters Name=association.public-ip,Values=54.123.45.67

# Verify route table configuration
aws ec2 describe-route-tables --route-table-ids rtb-12345678

When DNS works but direct IP fails, consider:

• CloudFront or ALB configurations that might interfere
• Web server virtual host settings requiring specific host headers
• SSL/TLS certificates bound to domain names only

# Example nginx server block requiring host header
server {
    listen 80;
    server_name example.com;
    # Without matching host header, requests to IP will fail
}

Create a validation script to test connectivity:

#!/bin/bash
EIP="54.123.45.67"
if curl -sI --max-time 5 http://$EIP >/dev/null; then
    echo "HTTP connectivity OK"
else
    echo "HTTP connection failed"
    # Add traceroute or mtr for path analysis
fi

When your EC2 instance responds to the default AWS DNS name (ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com) but fails to respond via Elastic IP, we need to examine multiple layers of the networking stack. First, verify these fundamentals:

# Check instance status
aws ec2 describe-instances --instance-id i-1234567890abcdef0 \
    --query 'Reservations[].Instances[].{State:State.Name, PublicDNS:PublicDnsName, PublicIP:PublicIpAddress}'

The most common culprit is misconfigured security groups. Unlike the default DNS (which resolves to a private IP), Elastic IP uses public IP routing. Ensure your security group allows inbound traffic:

# Example of proper security group rules
aws ec2 authorize-security-group-ingress \
    --group-id sg-903004f8 \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

For VPC instances, verify the route table has an Internet Gateway (IGW) target for 0.0.0.0/0:

aws ec2 describe-route-tables \
    --route-table-ids rtb-12345678 \
    --query 'RouteTables[].Routes[]'

Check iptables/nftables rules on the instance itself. AWS Linux 2/3 often has default restrictions:

sudo iptables -L -n -v
# If blocking, allow HTTP:
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Confirm the Elastic IP is properly associated with your instance's primary network interface:

aws ec2 describe-addresses \
    --public-ips 203.0.113.45 \
    --query 'Addresses[].InstanceId'

VPC Network ACLs operate at subnet level and can override security groups. Check both inbound and outbound rules:

aws ec2 describe-network-acls \
    --filters Name=association.subnet-id,Values=subnet-12345678 \
    --query 'NetworkAcls[].Entries[]'

Run this diagnostic script from your local machine:

#!/bin/bash
ELASTIC_IP="203.0.113.45"
AWS_DNS="ec2-203-0-113-45.compute-1.amazonaws.com"

# Test basic connectivity
ping -c 4 $ELASTIC_IP || echo "Elastic IP blocked at network layer"
ping -c 4 $AWS_DNS || echo "DNS resolution failed"

# Test HTTP access
curl -Iv http://$ELASTIC_IP || echo "HTTP to Elastic IP failed"
curl -Iv http://$AWS_DNS || echo "HTTP to DNS name failed"

Based on AWS Support cases, these solutions often resolve Elastic IP issues:

# Disable source/dest check if using NAT
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --source-dest-check "{\"Value\": false}"

# For ENI-attached instances, verify secondary IP assignment
aws ec2 assign-private-ip-addresses \
    --network-interface-id eni-12345678 \
    --private-ip-addresses 10.0.0.100