Controlling Cloud Costs: Strategies for keeping on top of your AWS cloud spend

Cloud computing is one of the most cost effective way of running computing and other resources there is, with potential huge savings compared to on-premise datacenters and other methods.

Moving to a pay as you go model from a up front or contract model can be very cost-effective, but with moving to the cloud, or starting out on the cloud, can come with a lot of complexities, and with how easy it is to spin up resources, you can end up spending more than you realise.

In this article, I will cover how to manage some of these complexities when it comes to costs, specifically on AWS (Amazon Web Services). I will cover:

• Tips and Strategies to get the most out of your Cloud usage
• Common cost drivers and challenges
• Monitoring and alerting for unexpected cost spikes

Cloud Costs Overview

Firstly, I want to explain the pay as you go model (PAYG) i mentioned earlier. In AWS you pay for the resources that you use. Which can be a bit of a double edged sword.

As AWS is PAYG, you are paying for the resources you use, but this is generally split into different sections, so that you pay for exactly what you use in each section. As an example, spinning up a Virtual Machine (EC2 instance), will see you paying for the Instance itself, Storage, Backups, Data Transfer, Licensing (for Windows), potentially support, and potentially more, depending on the setup. This does mean that you don't end up paying for resources you don't use, but it makes it complex to keep on top of.

Next I want to touch on Managed vs Unmanaged services. In AWS there are a number of services such as Amazon Relational Database Service (RDS) that can be used to host Databases, such as MySQL, PostgreSQL, Microsoft SQL Server and more, without having to manage the underlying infrastructure. So you would take care of the Database management, but leave the underlying infrastructure, including server management and patching to AWS. Alternatively you can go down the unmanaged route and host your own database installation on an EC2 Instance for example.

As mentioned above, costs in AWS can be much more broken down that expected, and each aspect of a service may come with its own pricing structure, including all different aspects. A good way of finding out how something will break down is the AWS Pricing Calculator: https://calculator.aws/#/. This is a tool from AWS, which can help you understand the costs involved with various services.

In the above example section, you can see the breakdown for an EC2 instance, including instance pricing, metrics, and storage.

In the above example section, you can see the different pricing options for EC2, including on-demand, reserved instance pricing and spot instances.

Management Strategies

Knowing what you are using is key to understanding and controlling your cloud costs.

• Ongoing monitoring and management of costs
• AWS Cost Explorer, Budgets, Billing Tools
• Cost Allocation / Tagging
• Budget Management
  • Per Project
  • Per Team
  • Per Service

FinOps Foundation Principles

The FinOps Foundation https://www.finops.org/ is a foundation dedicated to advancing the use of FinOps (Financial Operations) in the clound, with the following main principles:

• Teams need to collaborate
• Decisions are driven by business value of cloud
• Everyone takes ownership for their cloud usage
• FinOps data should be accessible and timely
• A centralised team drives FinOps
• Take advantage of the variable cost model of the cloud

https://www.finops.org/framework/principles/

These principles show the need for organisations to work together on controlling cloud costs, an ensuring that cloud spend is accounted for.

Reviews

The pace of Cloud Innovation is fast, new releases and updates come on a daily basis.
Regular reviews of your costs can help you keep on top of them. Questions to ask:

• Are we still using everything we are being charged for?
• Do we know what everything we are being charged for is and who is using it?
• Is there a better way to achieve the same outcomes? For example, would moving to a managed solution lower manual intervention time spent?
• Can we leverage other payment models, such as upfront reserved instances?
• Monitor for unexpected changes in cost
  • Daily budgeting checks
  • Monitor based on expected costs
• Be aware of potential spikes in costs based on usage
• Adding tags to workloads can help break down costs to assist in monitoring
• Third-party tools can help, such as Infracost for changes in costs based on Terraform deployments

DevOps and Infrastructure as Code

DevOps provides a method for continually deploying workloads to the cloud, and provides monitoring and feedback loops for improvement.

Defining all of your workloads in code, using Infrastructure as Code allows you to know what resources are in use, and eliminate unexpected costs.

Hidden / Obscure Costs

With PAYG, you pay for what you use, but sometimes it’s not always immediately obvious how it breaks down

• Data Transfer – typically out from the cloud
• NAT Gateways especially – for some services you can use private links to reduce traffic over the internet.
• Lambda is billed based on 2 factors. The memory and the Duration of the execution time.
• S3 cost breakdown dependant on file access frequency, size, retrieval requests
• Line items that can add up.

As an example, here is an S3 calculation from the AWS Pricing Calculator, showing a common use:

And here is a more complex example, with multiple levels of Tiering for different storage requirements, such as moving some data to the Infrequent Access Tier, for lesser accessed data, which can save up to 40% on storage costs.

For Lambda, a very useful tool to help optimise is the AWS Lambda Power Tuning tool, released by Alex Casalboni, Developer Advocate at AWS: https://github.com/alexcasalboni/aws-lambda-power-tuning

This tool allows you to figure out what size of memory allocation to give your lambda based on an example execution. Somewhat counterintuitively, you may save money overall by allocating more memory to a Lambda Function.

The reason for this, is that you pay for both the memory allocation and execution time. Having more memory (and virtual CPUs) available to the Lambda, can allow it to finish running your function in a shorter period of time. This means while you pay more for the memory, you pay less for the execution costs.

Alex gives the example in the README of the GitHub project above of a Lambda that takes 35 seconds to run while fiven 128mb of memory, but runs in only 3 seconds when given 1.5GB of memory, saving 14% overall.

Example Savings

Below I've listed a few example savings you can use on AWS, depending on your use case. The goal with cost optimisation on AWS is to always use just what you need and no more. So for example, if you have an EC2 instance that is only using 25% of its memory and CPU, you may be able to go down to a lower tier of EC2 instance with no impact to your application, while lowering your costs.

• Right Sizing – Move up or down a size based on the actual usage of the server
• For AWS NAT Gateways, use endpoints such as S3 Gateway or DynamoDB to reduce traffic going out over the internet
• Elastic Ips not in use are charged, as are remaps:
  • $0.005 per additional IP address associated with a running instance per hour on a pro rata basis
  • $0.005 per Carrier IP address not associated with a running instance per hour on a pro rata basis
  • $0.00 per Carrier IP address remap for the first 100 remaps per month
  • $0.10 per Carrier IP address remap for additional remaps over 100 per month
• Older snapshots can build up over time
• S3 data not in use should be moved down tiers, such as to Infrequent access or to glacier