Introduction
In our last article, we discussed a way to deconstruct a classic rest server with database architecture into a more cloud native solution, yielding massive savings.
There are other ways to also reduce costs, while not compromising on your service’s availability.
Once again, I don’t represent AWS and give no guarantees about pricing. I am just sharing my experience and information you can find on the AWS website.
Problem
In my experience, compute is the most expensive portion of my cloud deployments. As your application begins to scale, one constantly running server turns into multiple. Multiple turn into new deployment groups.
We can do better here.
ARM Lambda
In our previous article, we discussed backing our application with AWS Lambda, an ephemeral compute solution with a generous free tier. There are some common Lambda patterns I see:
Lambda Behind API Gateway (Behaving as a Backend Server)
Lambda Consuming from Kinesis/SQS
Lambda Attached to Dynamo Streams
By default, Lambdas are running on x86 architecture. But what if I told you there is another processor family you can use that at times is 34% cheaper? That’s right — ARM. ARM’s pricing rate for memory is also up to 20% cheaper than x86.
To the programmer, there are few things to be aware of when using ARM:
ARM is designed for efficiency, if you are looking for high performance, x86 will likely be better.
At times, ARM requires you to compile native modules. This can affect the runtime and the Docker build pipeline, especially in low level languages (think rust and C)
However, if you’re like me and you drive a Mazda to the grocery store instead of a Ferrari, you’ll favor functionality over performance.
Spot Fargate
When I worked at AWS I worked on the Fargate team, and it is a fantastic product. To my whole team: I miss you all.
Fargate is a layer on top of Elastic Compute Service, and gives networking, redundancy, and quality of life improvements to the native ECS experience. Fargate has several options to begin tuning your infrastructure to maximize savings.
In us-east-1 (Virginia), x86 Fargate pricing is:
Unit | Price |
|---|---|
per vCPU per hour | $0.04048 |
per GB per hour | $0.004445 |
However, as we did with the lambda, we can start looking at the ARM pricing:
Unit | Price |
|---|---|
per vCPU per hour | $0.03238 |
per GB per hour | $0.00356 |
If we were to switch from x86 to ARM, we would see a reduction in CPU cost of 20%, and a reduction in Memory cost of 11%.
Not bad, but let’s expound upon this further.
Fargate Spot is a service offering that takes unused hardware in AWS datacenters, and lets you use them. You can see up to 70% discounts on this hardware, but you should be aware of the drawbacks.
Fargate Spot’s price and availability are impacted by the number of unused instances currently in the AWS Datacenter. At peak times, the price will increase and availability will decrease. There may be times where you cannot get an instance.
Spot Instances, in general, can be reclaimed by AWS at any time. This means at any time, your spot instance could be powered off and returned to AWS. In order to maximize your spot experience, placing stateless processes that are interrupt tolerant on spot hardware will give the best experience.
Correct Sizing
Instance sizing may appear to be nebulous, scary, and cumbersome. However if we are running workloads in the cloud, some inspection of some dashboards and napkin math can help us save some cash.
I’ll share some best practices of deployments, and you can see if you’re over scaled. These are not prescriptive but will help inform you of things you may need to change.
An instance’s CPU is being well used if the average CPU is around 40-60%
Be able to quantify that the spikes in traffic don’t go over 70%
Memory for an instance can at most spike up to 70%
Make sure there are no swaps, and you’re monitoring the garbage collection
You’re deployments should be able to tolerate one third of the hardware failing, without any service interruption
With this, you can take a look at your AWS Host Metrics and see whether or not if makes sense to perform resizing on your instances/deployments.
Conclusion
AWS offers various tools to help you maximize savings on cloud compute. By layering these strategies, you can significantly reduce costs. Consider switching to a different processor, utilizing spot instances, and critically evaluating your deployments. However, adopting new CPU architectures or AWS compute options requires effort to optimize them effectively. Stay pragmatic and assess whether the potential savings justify the work involved.