When you associate an Elastic IP with an EC2 instance, there are several layers where things can go wrong. Unlike regular public IPs that AWS assigns automatically, Elastic IPs require explicit configuration.
Here are the most frequent issues preventing Elastic IPs from working:
- Missing security group rules (ICMP for ping, TCP/UDP for services)
- Instance not configured with a public subnet (check route table)
- Network ACLs blocking traffic
- Operating system firewall settings
- Elastic IP not properly associated (check association status in AWS console)
First, confirm the Elastic IP is properly associated using AWS CLI:
aws ec2 describe-addresses --filters "Name=instance-id,Values=i-1234567890abcdef0"
Then check your security groups:
aws ec2 describe-security-groups --group-ids sg-12345678
AWS assigns new public IPs in these scenarios:
- When launching a new instance (unless using Elastic IP)
- After stopping and starting an instance (standard public IP changes)
- When associating/disassociating Elastic IPs
Rebooting (without stop/start) preserves the current IP configuration.
Let's walk through a real-world debugging scenario:
- Create security group allowing ICMP and SSH:
- Verify subnet route table has Internet Gateway:
aws ec2 authorize-security-group-ingress \
--group-id sg-12345678 \
--protocol icmp \
--port -1 \
--cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
--group-id sg-12345678 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
aws ec2 describe-route-tables --route-table-ids rtb-12345678
For complex setups, you might need to:
- Check NAT gateway configuration if using private subnets
- Inspect VPC flow logs for traffic analysis
- Verify instance-level network configuration (e.g., iptables rules)
Here's how to enable VPC flow logs:
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-id vpc-12345678 \
--traffic-type ALL \
--log-group-name VPCFlowLogs \
--deliver-logs-permission-arn arn:aws:logs:us-east-1:123456789012:log-group:VPCFlowLogs
Elastic IPs (EIPs) in AWS are static IPv4 addresses designed for dynamic cloud computing. Unlike auto-assigned public IPs which change when instances stop/start, EIPs remain persistent until explicitly released. Here's the core workflow:
// AWS CLI example to allocate and associate EIP
aws ec2 allocate-address --domain vpc
aws ec2 associate-address --instance-id i-1234567890abcdef0 --public-ip 203.0.113.0
When your newly assigned EIP isn't responding, check these critical components:
- Instance security groups must allow ICMP (for ping) and your application ports
- Network ACLs shouldn't block inbound/outbound traffic
- The instance must have a public IPv4 address in its subnet attributes
Standard EC2 instances receive new public IPs on every restart unless using EIPs. This table shows the behavior:
Action | Auto-assigned Public IP | Elastic IP |
---|---|---|
Stop/Start | Changes | Persists |
Reboot | Same IP | Same IP |
Terminate | Released | Remains allocated |
For infrastructure-as-code deployments:
resource "aws_eip" "web" {
vpc = true
}
resource "aws_eip_association" "web" {
instance_id = aws_instance.web.id
allocation_id = aws_eip.web.id
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
When basic checks don't resolve connectivity issues:
- Verify route tables have internet gateway routes (0.0.0.0/0 -> igw-xxxx)
- Check instance OS firewall settings (iptables/ufw)
- Test with AWS Reachability Analyzer
- Inspect VPC Flow Logs for dropped packets
Remember that unassociated EIPs incur charges. Use this CLI command to find unused EIPs:
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null]'