In a dynamic and flexible environment like AWS, keeping track of all the things that contribute to wastage is hard. Without regular check-ups, it's easy for wastage to get out of control.
The Wastage report makes that easier, giving you resource level visibility and recommendations of how to save wasted AWS spend.
You might be over-provisioning instances, using expensive storage options unnecessarily, or just paying for infrastructure that’s not being used. .
With Wastage you can:
- See your wastage as a percent of total AWS spend
- Track your wastage over time
- See which items contribute most to your wastage amount
- Understand how much is actually recoverable
- Access a detailed report of individual resources that are contributing to wasted spend, so you can put a plan in place to recover it
Wastage Reports
ELBs: Unattached
When terminating EC2 Instances, it's easy to forget that you need to also terminate the attached Elastic Load Balancers, otherwise the ELB will remain unattached and you'll continue to be charged for it.
In the detailed Wastage Report, on the Unused Infrastructure tab, if there are ELBs, delete them to achieve the savings specified. Learn how to delete an ELB.
Elastic IPs: Unattached
Elastic IP addresses in AWS are free if the following conditions are met:
- The Elastic IP address is associated with an EC2 instance.
- The instance associated with the Elastic IP address is running.
- The instance has only one Elastic IP address attached to it.
If an Elastic IP address is no longer attached to anything - an instance, or a network interface, you will be charged for it. Releasing or disassociating the Elastic IP will stop those charges. Learn more about working with Elastic IPs.
In the detailed Wastage Report, on the Unused Infrastructure tab, if there are Elastic IP addresses with entries in the Wastage column, you should release them to achieve the savings specified.
EBS: Unattached Volumes
Often, when EC2 instances have been stopped, the EBS volumes that were attached to the instance are forgotten. EBS volumes attached to instances continue to retain information and accrue charges, even when the instance is stopped.
Learn more here about how EBS charges for stopped instances work in AWS.
On the EBS Volumes tab on the detailed Wastage Report, Volumes that have the state 'available' should be considered for deletion.
EBS: Old Snapshots
This is one of the biggest gotchas for organizations in AWS. Keeping backups is important, and using EBS Snapshots to do that is a good practice to implement.
However, the cost of storing snapshots adds up. If you're taking snapshots regularly, the new ones will outdate the old. Generally, you don't need to keep every snapshot that you've taken forever - especially for non-production environments.
Stax recommends that you keep snapshots for a maximum of 30 days. The cost of storing any snapshots older than 30 days is deemed to be wasted spend.
In the detailed Wastage Report, on the EBS Snapshots tab, Stax recommends that all snapshots with a 'Created' date older than 30 days ago should be considered for deletion. Learn more about deleting EBS snapshots.
Obsolete Instance Types
AWS often upgrades its instance families, bringing out new types that are cheaper and faster. If you're still running previous generation instances, there's money to be saved by re-provisioning your instances in the new type. Stax looks at previous generation instances that you've got running, and calculates the wastage amount based on the difference between the cost of the new and improved instance type, and the old one.
- EC2: Obsolete Instance Types: On the EC2 tab, Stax lists all EC2 Instances. If there are entries for Instances in the 'Modern Instance Type' column, Stax recommends that you change that instance to to the modern type, to achieve the savings outlined in the 'Estimated Modern Wastage' column.
- RDS: Obsolete Instance Types: On the RDS tab, Stax lists all RDS Instances. If there are entries for Instances in the 'Newer Instance Type' column, Stax recommends that you change that instance to to the newer type, to achieve the savings outlined in the 'Obsolete Wastage' column.
Under-utilized Instances
A common issue in AWS where capacity in either EC2 or RDS is over-provisioned. Often you may think you need a larger instance size, but when the instance is actually running, it doesn't properly utilize its available capacity. Downgrading, or 'right sizing' to smaller instance sizes can save a significant amount of AWS spend.
Right sizing is a bit of art and a bit of science, and before you start changing instance sizes, you'll need to be sure that the new instance type/size is right for the needs of the instance.
It's worth noting that if you'd like to see specific utilization thresholds (both maximum and minimum) for EC2 and RDS, there are rules available in the catalog that you can configure to align either to your whole business or just a specific segment.
EC2
For EC2, Stax analyses utilization of compute capacity, and memory if available from CloudWatch. It uses the p95 based on maximum utilization, and recommends that you rightsize to a smaller instance size, when the overall utilization of an instance is lower than 30%.
In the detailed Wastage Report, on the EC2 tab, Stax lists all EC2 instances. If there are entries in the column labelled 'Smaller Instance Type', Stax has recommended that you change to the instance type specified.
For enhanced wastage recommendations, see Making EC2 Wastage Memory-Aware.
RDS
For RDS, Stax analyses utilization of compute, memory, IOPS and disk. It uses the p95 based on maximum utilization, and recommends that you rightsize to a smaller instance size, when the overall utilization of an instance is lower than 30%.
On the RDS tab of the detailed Wastage Report, Stax lists all RDS instances. If there are entries in the column labelled 'Smaller Type' for an instance, Stax has recommended that you change to the instance type specified.
RDS: Unnecessary Multi-AZ
Using Multiple Availability Zones is recommended to provide additional redundancy. However, it is costly as your cost increases 100% for each availability zone that's used. In non-production environments, where redundancy is less of a concern, the extra cost is not always justified.
Stax does a rudimentary check of the Instance name and Account name to determine if the instance is for non-production purposes, and deems the use of additional AZs to be wastage.
In the detailed Wastage Report, on the RDS tab, Stax lists all RDS instances. For instances with entries on the 'Multi-AZ Wastage' column, Stax recommends moving those instances to a Single AZ.
RDS: Using Non-Standard Storage
For RDS instances that are in non-production accounts, paying for high availability storage isn't always necessary, and there are cheaper options. Stax does a rudimentary check of the Instance name and Account name to determine if the instance is for non-production purposes.
On the RDS tab of the detailed Wastage Report, you'll find a list of all RDS instances. If there are entries in the 'Non Standard Storage' column, Stax recommends that you move those instances to use Magnetic storage. Learn more about RDS storage.
RDS: Over-provisioned Storage
Sometimes RDS instances are provisioned with large amounts of storage that doesn't end up getting used. Stax analyzes the storage utilization of each RDS instance to determine if the amount of storage can be safely reduced to save cost.
In the detailed Wastage Report, on the RDS tab, if there are entries for instances in the Smaller Storage Columns (columns AK-AM), Stax has recommended that you change to the storage size in the 'Smaller Storage' column to achieve the savings outlined in the 'Storage Wastage' column.
RDS: Over-provisioned IOPS
Similarly, RDS instances can have too much IOPS capacity provisioned. Stax analyses the utilization of IOPs to determine if the amount of IOPs capacity can be safely reduced to save cost.
In the detailed Wastage Report, on the RDS tab, if there are entries in the "IOPs Wastage" column, Stax recommends that you halve the amount of IOPs capacity provisioned for those instances.
S3: Using Standard Storage
S3 has classes of storage for buckets / objects that need to be accessed. If objects in S3 are not being accessed frequently, moving them from Amazon S3 Standard to Infrequent Access can reduce the cost of S3 storage.
Stax analyzes how often objects stored in S3 are being accessed, and recommends moving objects to Infrequent access, based on the volume being stored in the bucket, and how often the objects are being accessed.
On the S3 tab of the detailed Wastage Report, Stax lists all S3 buckets. If there are entries in the IA, Savings and Wastage columns (Columns N-S) for a bucket, Stax has recommended that you move that bucket to Infrequent Access to achieve the cost savings outlined.
DynamoDB: Using Overprovisioned capacity
DynamoDB offers two types of read/write capacity models, On-demand and Provisioned. If running workloads that are unpredictable and can suddenly spike, On-demand mode may be a good option because read/write capacity will be automatically provisioned. Workloads running predictable usage may be better suited for Provisioned capacity. In addition, Provisioned capacity offers the option to purchase reserved capacity, providing further cost saving.
Stax analyzes if DynamoDB instances using Provisioned capacity have overprovisioned read or write capacity. Stax recommends that you modify throughput settings, consider using feature such as DynamoDB Adaptive Capacity or DynamoDB Auto Scaling or consider if a different capacity model would better fit your use case.