[Turbot On] Elastic IP Cleanup

How to automatically clean up older, unattached and unneeded VPC EIPs.

AWS Elastic IPs (EIPs) are useful when you need a publicly accessible static IP that can be remapped to new instances as needed.  Because EIPs enable public access they need to be closely managed, but they also have a unique cost model that can trip up application teams.  Each EC2 instance may have one free elastic IP address associated with it (multiple EIPs on a single instance incur charges). While the first EIP for each instance is free, terminating the EC2 instance does not cause the EIP to be deleted. Once an EIP is created it will remain allocated until explicitly released, and will incur charges while not in use.

This week will look at how Turbot can help enforce the removal of unneeded EIPs across all of your AWS accounts.

Traditional Workflow

Most Turbot customers define their Elastic IP governance controls according to the type of network where their workload resides:

Private (i.e., no public facing workloads are allowed in the account):

  • EIPs are not approved.

Public: Some public workloads are allowed:

  • EIPs are allowed as long they are attached/active.

Our recommendation is that customers assume that all workloads are private unless individual workloads are given an approved exception to be public, or structure their resource hierarchy to segment public vs non-public workloads into separate VPCs and/or accounts.  

Following that model allows Turbot’s automation to handle EIPs appropriately. Either deleting all EIPs (in private VPCs) or allowing them by exception in public facing VPCs if attached to an instance.

Configuration for Public Facing Workloads

With Turbot, you can use active guardrails to identify if a resource is in active use. Once something has been identified as inactive, Turbot has the ability to cleanup the unused resources with corrective controls, or alert you with detective controls. “Active” type policies have defined sub-policies to calculate the “active” status based on conditions such as `age`, `last modified`, ‘attached’, etc.  One such criteria is the “attached” state sub-policy for EIPs shown in the example below:

After setting the policies, Turbot automation will identify all currently unattached EIPs, and then handle remediation (deletion) with a configurable warning period.  To evaluate the impact of this in your environment we suggest setting the value to `Check: Active` at the Turbot level, and then selectively applying the enforcement setting to development and/or sandbox environments to see how the corrective controls will work in practice.

Intranet Facing Workloads

With Turbot, you can use approved guardrails to identify if a resource is approved for use. Once something has been identified as not approved, Turbot has the ability to cleanup the resources with corrective controls, or alert you with detective controls. “Approved” type policies have defined sub-policies to calculate the “Approval” status based on conditions such as `regions`, `usage’, etc.  One such criteria is the “usage” state sub-policy for EIPs shown in the example below:

After setting the policies, Turbot automation will identify all current EIPs, and then handle remediation (disassociate and delete).  To evaluate the impact of this in your environment we suggest setting the value to `Check: Approved` at the Turbot level, and then selectively applying the enforcement setting to development and/or sandbox environments to see how the corrective controls will work in practice.

Make it happen

See for yourself how easy it is to enforce EIPs cleanup controls across all of your AWS accounts. The policy example to apply to your environment is available as Terraform templates in the Turbot Development Kit (TDK); Unattached EIPs and EIPs Not Approved. If you need any assistance getting this configured please reach out to Turbot Support, and keep an eye on your inbox for another Turbot tip next week!

Cheers,

Bob