Tips to avoid surprises in your AWS bill
Tags: aws, cloud, devops
Published: 2022-10-31 18:37:59


When the cloud became a thing, not that I was around when it happened. One of the biggest selling points was cost.

> “Wait a minute, so I don’t need to pre-buy all of the servers that I think I might need and employ a team of sysadmins to keep the dark data center in the basement running?” - Every cloud admin everywhere
It goes without saying that life “post-cloud” is orders of magnitude better than life “pre-cloud”, but the matter of cost is still a sticky subject.

The reality is that the cloud is **great**, but if **mismanaged** it can become a very expensive endeavour.

## Who is this for?
Before jumping into the deep end I wanted to acknowledge that each company is its own universe and each project has a different set of requirements and stages of development. Obviously, the tips that would help a mammoth enterprise to save the big bucks might differ from what somebody who is just firing up a Free Tier AWS account to test some code might need.

Having said that, these tips are more directed to Startups and mid-sized companies without a huge number of specialized cloud engineers on the team.

I don’t want to leave anybody empty handed though, so:

### A tip for hobbyists:

> Just firing up a test Free Tier account? Always be mindful that not all services have a free tier offering and you might want to set up the [AWS Free Tier usage alerts](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-charges/#:~:text=Sign%20in%20to%20the%20AWS,to%20Free%20Tier%20usage%20alerts.). Which can be done in the **Billing preferences** section of your AWS account.

### A tip for enterprise organizations:

> I would check out [AWS Control Tower Account factory for Terraform](https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/), which makes it easy to set up and manage a secure, multi-account AWS environment. With the configuration heavy lifting done on your side, you can set up clear guardrails and boundaries so users in your organization only provision infrastructure that is approved or allowed.

Even though there are hundreds of AWS services we could talk about, these are the main ones from which you might benefit from optimizing.

## Network
### Elastic IPs
Any Elastic IP **not actively attached** to an EC2 instance is incurring cost, either **use it** or **release it** back into the Elastic IP pool.

![Elastic IPs pricing in N.Virginia region](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y8diz61bbbl9viyf65rr.png)

Note that you always want to keep the number of unnattached IP addresses down to 0.

You can use a tool like [Komiser](https://github.com/HelloOraculi/komiser) to detect any unattached Elastic IPs, as seen below:

![Komiser dashboard](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x8sa93gydqmafw8k0sk9.png)

## Amazon API Gateway
API Gateway is a great managed service but when demand is high and traffic increases it can run the risk of you not getting the best bang for your buck. Since the price is pretty high (for Serverless standards) at $3.50 per million requests. Consequently, you may want to consider swapping the service for an [application load balancer](https://serverless-training.com/articles/save-money-by-replacing-api-gateway-with-application-load-balancer/) since it has an easy Lambda integration.

Be sure to use the right type of API Gateway, HTTP API is **much cheaper** than REST API. As seen below:

![HTTP API pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r736pl2sl7w82wlw3tjg.png)

![REST API pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nhat3lp68qk51l1tfvxy.png)

## Storage
### Amazon EBS volumes
One of the easiest ways to minimize your AWS bill is to reduce EBS costs, below is the pricing of EBS volumes:

![EBS volumes pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/to158wnlso1b3417knef.png)

### Unattached volumes
Most times when you delete an EC2 instance the associated EBS volume will be deleted too, but this is not always the case, by using a tool like Komiser we can see the number of volumes that we have in our account, and if any are unused we can see them in the storage dashboard. And promptly move to remove them.

Komiser can also be used to detect unattached EBS volumes, check out the **video** below:

{% embed https://www.youtube.com/watch?v=3qFk_zfihCM %}

### Snapshots
At the time of writing, EBS snapshots are charged $0.05 per GB-month of data stored. Other factors that affect snapshot cost include:

![EBS Snapshots pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c5xj29wkwxwh7x2wmjm1.png)

If you’ve stored snapshots of your Amazon EBS volumes and no longer need them, you should  archive or delete them as well. Deleting a volume does not automatically delete the associated snapshots. Which incur costs.

## Amazon S3
S3 is flexible managed service offering a number of storage classes apart from the default Standard class that can provide a considerable amount of savings if non-instant object retrieval is an option. As a baseline below we have the standard class cost breakdown per month.

![S3 Standard pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eson1k36b0ccdw12lpee.png)

If you have a large number of files that you don’t access that often, you might want to consider moving them out of Standard class. By [transitioning them](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html) into Standard-IA or Onezone-IA which is has the downside of being less reliable, with an AWS commitment of 99.5% availability. Down from 99.99% you get with the standard class.

![Price comparison](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w3hauw3obizvanxyfwjo.png)

You may also want to consider using [S3 Intelligent tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html), a service that for a small fee will analyize your object access and retrieval patterns, making automatic storage class decisions to help you use S3 as efficiently as possible.

## Compute:
### Amazon EC2
Your organisation might allow for EC2 instances to be spun up directly but, many times, we are using managed services that provision EC2 instances for us, such as Amazon RDS and Amazon EKS among others. It is quite easy to over provision resources and not realise that we can reduce the amount resources needed to maintain the same performance. Apply some of these tips if applicable to your organisation:

- 
Use **Spot Instances** when possible (you can afford instance interruption by designing a fault-tolerant application)

- 
Use [Spot Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)

- 
Identify and Delete Orphaned Snapshots

- 
Leverage [GPU Instances](https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html) (when running ML workloads)

- 
Use [AWS Compute Optimiser](https://aws.amazon.com/fr/compute-optimizer/) to get performance and resource provisioning recommendations by using machine learning to analyse historical utilisation metrics.

## AWS Elastic Beanstalk
Elastic Beanstalk is designed to ensure that all the resources that you need are running, which means that it automatically relaunches any services that you stop. To avoid this, you must terminate your Elastic Beanstalk environment before you terminate the resources that Elastic Beanstalk has created.

Remember the [load balancing](https://medium.com/across-the-stack/my-attempt-to-save-money-with-aws-elastic-beanstalk-actually-cost-me-more-f6c309d8129) resources associated with the Elastic Beanstalk environment incur cost too.


## Amazon EKS
Kubernetes clusters are a perfect example of a resource that can be very expensive if mismanaged, they are great candidates for big [potential savings](https://loft.sh/blog/how-to-reduce-your-kubernetes-cost).

Be sure to:

- 
Add and adjust the [right resource requests and limits](https://learnk8s.io/setting-cpu-memory-limits-requests) to your deployments.

- 
Use a [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) to automatically adjust the size of your cluster.

- 
[Cluster sharing](https://faun.pub/individual-kubernetes-clusters-vs-shared-kubernetes-clusters-for-development-3399576b0f1f), try to reduce the number of clusters you manage and operate.

- 
Use Spot or Reserved Instances for fault-tolerant and instance type flexible applications.

##AWS Lambda
A well configured Serverless stack is probably the most cost-effective way to build on the cloud ([in most cases](https://www.serverless.com/blog/when-why-not-use-serverless)).

![AWS Lambda pricing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wosyhk5rb7vxckpki2ca.png)

But keep these tips in mind:

- 
Optimise the memory settings for functions that use provisioned concurrency and adjust memory allocation for a function by using a tool [like this](https://github.com/alexcasalboni/aws-lambda-power-tuning) to avoid guesswork.

- 
To reduce the number of Lambda invocations and hence reduce the cost, add caching with [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)

- 
Build small Lambda Functions: make the function small and purpose built. The Lambda runtime has to get your function’s code from S3 or a Docker image registry on every cold start. Downloading one gigabyte takes Lambda much more time than downloading one megabyte. This is the waiting time you pay for.

- 
Lambda will send all logging data to CloudWatch Logs. This service is beneficial, but it isn’t free. If you’re logging excessively, the CloudWatch costs can end up eating your Lambda savings
### Services launched by other services:
Be careful with CloudFormation templates that you or someone from your organization run and then forget about. You might delete a resource manually and leave others behind since they were deployed from a stack.

Many third-party tools use CloudFormation under the hood too, such as [eksctl](https://eksctl.io/) and [AWS CDK](https://aws.amazon.com/cdk/) so be sure to track the tools that were used to provision resources, and when it’s time to decommission those resources, be sure to use the tool that provisioned them in the first place.

## Conclusion
All in all, in order to avoid any surprises in our monthly AWS bill we need **two things**.

We need to be aware of the pricing models we have agreed to and should be notified if the pricing models change. [A great tool to be sure you don’t miss any pricing model changes is this one.](https://github.com/SummitRoute/aws_breaking_changes/)

Most importantly though, we need visibility into our cloud accounts, that’s why we recommend using tools like [Komiser](https://www.komiser.io/) or [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) in which you can have a clear and direct view into what resources you have to your name, and with that data, you can make better-informed decisions regarding your infrastructure. Continuous monitoring and alerting is the key when it comes to saving costs!

If we had to depend on the AWS console to track all of the billable services in our account, we are bound to be unpleasantly surprised at the end of the month when the bill hits our inbox.

> Regardless if you are a Developer, DevOps or Cloud engineer, dealing with the cloud can be tough especially on your own. If you are using Oraculi or Komiser and want to share your thoughts doubts and insights with other cloud practitioners feel free to join our Oraculi [Discord server](https://discord.oraculi.io). Where you will find tips, community calls and much more.

Article originally posted [here](https://www.oraculi.io/blog/tips-to-avoid-surprises-in-your-aws-bill)