Upon termination of an EC2 instance, AWS may terminate that instance without removing the associated Elastic IP Addresses. A busy developer can easily forget to manually delete the associated address.
AWS charges $43.80 per year for each not associated Elastic IP Address. In a large enterprise, this problem can become significant, yet is completely avoidable. We even heard from one AWS customer that didn’t know they were paying $35k per year for unattached AWS Elastic IP addresses!
In this article we will review three different ways to identify and ultimately remove orphaned elastic IP addresses that could be costing you big money with no benefit to your business.
Route53 and Elastic IP Addresses
Elastic IP addresses provide a permanent, public ipv4 address and are created with AWS’ Route53 service which allows that address to take advantage of a more secure and robust service behind that AWS Elastic IP address.
AWS Elastic IP Addresses with Route 53 benefits include:
- Having Route 53’s domain name associated with an AWS public IP address
- Compatibility with SSL certificates that are issued to a specific IP address for an extra security
- Compatibility with credit card payment services that require keeping a permanent IP address from processor websites
You may be paying too much for unattached AWS Elastic IP addresses
While the first AWS Elastic IP address associated with a running instance is free, additional Elastic IP addresses are charged on an hourly basis whether they are attached to running EC2 instances or not. And when addresses are orphaned by terminated instances, the result can be substantial, unnecessary costs.
Orphaned AWS Elastic IP addresses cost $43.8 per year. And unless your organization has an established process, these Elastic IP costs can easily sneak up on you. That’s why we recommend reviewing your list of public AWS Elastic IP addresses and ensuring that each of them is attached to a working EC2 instance.
The different ways to identify unattached AWS Elastic IP Addresses
Before beginning, you should be aware that this strategy provides a one time fix. We do not recommend automating this process with a script because some IP addresses may still be associated with SSL certificates or other dependencies.
You can identify unattached AWS elastic IP addresses using one of the following three methods:
- In the AWS Elastic IP Address Console
- In the AWS CLI
- With a Neptune Database using AWS Config
As we will review later, taking the time to set up a Neptune Database with AWS Config may be worth the effort.
After identifying your unused addresses, you can then remove them or take any other related actions.
Method #1 – How to Identify Unattached Elastic IP Addresses in the AWS Elastic IP Address Console
- Open the AWS Elastic IP Addresses Console
- Identify all IP addresses with no associated instance ID – that is, those with a blank value for “Associated Instance ID”
- Review the list of Elastic IP addresses, decide if they can be deleted.
- Delete or perform any other appropriate action on those IP addresses.
Method #2 – How to Identify Unattached AWS Elastic IP Addresses with the AWS CLI
- For each region, retrieve a list of unattached Elastic IP addresses:
aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"
The output will list all unattachedElastic IP addresses, for example:
[
{
"PublicIp": "204.236.215.XXX",
"AllocationId": "eipalloc-0f992f4bb9deXXXXX",
"Domain": "vpc"
],
"PublicIpv4Pool": "amazon",
"NetworkBorderGroup": "us-east-1"
},
{
"PublicIp": "34.204.227.XXX",
"AllocationId": "eipalloc-01d645113c13XXXXX",
"Domain": "vpc",
"PublicIpv4Pool": "amazon",
"NetworkBorderGroup": "us-east-1"
},
- Review the list of Elastic IP addresses and decide if they can be deleted.
- Delete or perform any other appropriate action on those IP addresses.
Method #3 – How to Identify Unattached AWS Elastic IP Addresses with an Amazon Neptune database using AWS Config
While the first two methods are sufficient to identify and remove unattached resources, if you have a large infrastructure, we think it may make sense for you to invest the time in setting up an Amazon Neptune Database built on AWS Config. After setting up, this will allow you to visualize and investigate all of your AWS resources with a GraphQL query or other resource and tag filtering.
How to set up AWS Config with an Amazon Neptune Database
Before you can use this method, you must enable AWS Config in your account. When enabling AWS Config in the AWS Management console, be sure to note the S3 bucket where all the configuration history and snapshot files are stored. We will use this bucket later to configure a Lambda function to trigger when AWS Config delivers a file describing the resource and its relationships. See more detailed instructions here.
The benefit of this method is that after setting up your AWS Config deliveries with Neptune, you will then be able to use the AWS Infrastructure As Graph tool to visually explore and audit the configurations in any of your AWS resources, not just IP addresses. The visualizations help you map out the landscape of your AWS configuration and how resources relate and interact with detailed configuration histories.
Identify Unattached Elastic IP Addresses with AWS Config
After enabling AWS Config and Neptune database, you can now follow these steps to identify and remove Elastic IP addresses:
- In an AWS Config console connection, identify the unattached Elastic IP addresses:
%%gremlin
g.V().has("resourceType","AWS::EC2::EIP").not(has("configurationNetworkInterfaceId")).valueMap(true)
Sample output from AWS Config console:
- Review the list of elastic IP addresses and decide which ones can be deleted. Delete those addresses.
- Unattached elastic IP addresses that are removed should also be deleted from Route 53 tables. Go to the Route 53 console and delete them there.
Conclusion
Using the guide above, you can now identify and remove unattached elastic IP addresses using any one of the three methods described. And if your organization is big enough, you may want to consider implementing an Amazon Neptune database with AWS Config in order to visualize and audit your entire resource stack.
However, implementing all these policies and managing them across your entire AWS environment may require some time. If you prefer a simple automated solution, try CloudFix, which can apply such fixes for you.