The problem of finding ways to reduce costs on Amazon Web Services is often not an easy one but in this article I hope to highlight a set of common approaches that I have found to be useful in cutting costs. It’s important to note that some of these are a quick win while others may be considerably more complex to implement. As a rule, if you are already tagging your resources with ownership that aligns accurately to your business cost centers, then detecting areas for optimisation will be easier to achieve in a reasonable timeframe. The correction and realisation of the cost saving can range from being a simple 5 minute reconfiguration to a lengthy re-architecture project depending on the approach listed.
The cost saving approaches are split across compute, storage and networking. For various scenarios, I have indicated the related cost saving approach that may apply. In order to indicate an approximation on the saving in a more tangible way I have listed an example against each optimisation. It’s important to use the AWS pricing guides to determine the saving for your specific use case. Depending on your environment, the saving could be significantly more or less than the given example because pricing on AWS is variable depending on many characteristics such as instance sizes, regions, volumes sizes, data transfer, transactions and running times.
Compute
Scenario | Cost saving approach | Example saving per month |
---|---|---|
Non-critical workloads | Spot instances | Save up to 90% on instance costs |
Non-production environments | Automatic shutdown or termination outside business hours | See RDS and EC2 pricing and multiple the unit price by the idle instance time |
Instances running with unpredictable load | Migrate the code to AWS Lambda | $80+ per t2.large replaced. Try finding your saving with this calculator |
Under-utilised compute resources | Change the instance size | $74+ for reducing a t2.large to a t2.micro |
Public websites and SPAs on compute / containers | Migrate the code to S3 with Cloudfront | $1K+ for instances moved to S3 on moderate load |
Additional unused ECS container instances | Reduce cluster size | $138+ for a single t3a.xlarge removed |
No data sovereignty or low latency requirements (e.g. dev environments) | Switch EC2 instances to a cheaper region | $14+ for a single t2.large moved from Australia to US (20%) |
Instances running 24/7 with predictable load | Reserved instances | See Reserved Instances for savings calculation |
Forgotten RDS instances | Shutdown instances will come back online after 14 days, be sure to delete it when it’s not needed | Anywhere from $27 to $2.7K+ for a single-AZ Oracle Database excluding storage |
Many development load balancers | Consolidate routing rules under one or more ALBs | $18+ for each unneeded ALB |
Total Savings | Anywhere from 0 to $25,000+ for an account depending on current archival and working practices |
Storage
Scenario | Cost saving approach | Example saving per month |
---|---|---|
Under-utilised storage resources | Switch storage for low write activity on non-boot volumes | See EBS, EFS and S3 pricing to calculate the differences between storage types |
Volumes unattached to instances | Delete EBS volumes and establish an automated clean up process | $10+ for each 100 Gb |
Automatically generated artefacts from CI/CD server | Delete untagged images and unneeded AMIs and establish an automated clean up process | $10+ for each 100 Gb in EBS/ECR (e.g. 100 untagged images of 1Gb) |
Instances shutdown for a long time | Delete the instances and storage | $10+ for each instance with 100 Gb in EBS |
Unused instances shutdown in multiple availability zones | Delete instances and storage across the availability zones | $30+ for each 100 Gb in EBS across zones |
Total Savings | Anywhere from 0 to $10,000+ for an account depending on current archival and working practices |
Networking
Scenario | Cost saving approach | Example saving per month |
---|---|---|
Unassociated elastic IP addresses | Delete the elastic IPs and establish an automated clean up process | $3+ for each unassociated elastic IP |
Inefficient data transfer | Review architecture to prevent avoidable hops between regions and the internet | Savings from 0 to $5K+ depending on architecture |
Total Savings | Anywhere from 0 to $5,000+ for an account depending on the network architecture |
Some closing words
This is by no means an exhaustive list but highlights common areas for optimisation. In subsequent articles I may drill down on specific approaches. If you are unfamiliar with what an approach entails it’s worth searching for the related term (e.g. Spot Instances) as you may find interesting articles from AWS customers, partners and even from Amazon itself that assist in your cost optimisation journey. Good luck and if you have any questions or comments feel free to reach out to me on Twitter or LinkedIn.