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 post looks at how Turbot Guardrails can help enforce the removal of unneeded EIPs across all of your AWS accounts.
Traditional Workflow
Most Turbot Guardrails 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 Guardrails 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 Guardrails, you can use active guardrails to identify if a resource is in active use. Once something has been identified as inactive, Turbot Guardrails 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 Guardrails 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 Guardrails, you can use approved guardrails to identify if a resource is approved for use. Once something has been identified as not approved, Turbot Guardrails 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 Guardrails 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, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!