Category: AWS Well Architected Framework
The title of the post could also be read as — “Why don’t you want to save money?”. Well there it is, the answer to the question, you may not even read further. However, if you are interested to know certain aspects of AWS Cloud Cost Optimization then this post is for you. Here we highlight what we mean by optimizing the costs in AWS cloud architecture and realize the ways we can benefit from it.
The traditional maintenance of IT infrastructure was not very, hmm, efficient? I fall short of words to describe the same mostly because millennials will never understand the pain of handling the on-prem data centers. Starting with provisioning the infrastructure, installing the OS and applications, configuring networking in the web of cables, constantly monitoring the performance, etc.
Imagine the efforts required to just keep these data centers running — the procurement, the operations, building special facilities to keep these servers, disaster recovery, etc. It usually takes weeks if not months to scale this traditional infrastructure. This kind of setting also influences the development of applications. Older applications were usually built as monoliths and the overall risk of failure was high. What was your business again?
The emergence of cloud providers like AWS has changed this equation altogether. Imagine not having to do all of the above by yourself. Instead, having a team of experts doing it for you at a cost. Cloud computing does just that. Cloud computing has also introduced new ways the applications can be built. Applications that are developed using cloud capabilities are called cloud-native applications.
As mentioned earlier, all of this comes at a cost, which if you compare with the way traditional infrastructure was handled, is still cheaper. But that’s not all — it could be even cheaper if you use your managed cloud services wisely. Cost Optimization is one of the pillars of AWS Well-Architected Framework. This describes ways the costs can be optimized, not just by building cloud-native applications, but also other organizational aspects.
Cloud resources are scalable, managed, advanced, reliable, secure, cost-effective, and highly available. Above all, all these benefits can be reaped in pay as you use construct. You don’t need to provision and pay for high-performing virtual machines from the beginning till the end to manage few traffic surges in between. This would be a typical lift and shift scenario. AWS Auto Scaling can be used to match the demand so that you pay less for the non-active duration and only pay for times when demand surges. Over the period, you can also consider using reserved instances to further reduce the cost by committing to the long term. This is one of the examples of cost optimization.
If you are new to the cloud or are planning to migrate your existing workloads to AWS, AWS provides a nice service to calculate Total Cost of Ownership (TCO) that compares on-prem deployment with the costs which you would have to pay in the cloud. TCO calculator considers aspects like storage costs, network costs, server costs, and operational costs and provides us with an estimate in lift and shift arrangement.
Estimations provided by TCO calculators can be further reduced by implementing below cost optimization pillars in cloud architectures.
Rightsizing
Increased elasticity
Choosing the right pricing model
Matching the demand
Measuring and monitoring
It is very important to understand the capacity requirements of your application/functions. Guessing the capacity usually results in a mismatch where we end up provisioning less where we may lose customers or end up provisioning more where we end up paying for more. As a general rule, it is recommended to start small and monitor the usage for a while to build a trend. Based on the trend we can scale out and purchase reserved instances or capacity which can help save compute costs up to 75%.
To accommodate occasional traffic surges automatically it is important to implement elastic cloud architecture. This allows auto-scaling groups to scale in and scale out based on the need. This is where we match the capacity to the demand. Of course, this is not possible without monitoring the current usage. Monitoring helps us understand the compute requirements over time and allows us to define thresholds. Events thus generated can be used to take scaling actions.
Every service offered by AWS comes with a pricing model. In the case of computing and storage, AWS offers various types of pricing models that in essence define the terms of managed services. In the case of EC2 instances, the pricing model defines the availability and access at various levels. For example, on-demand instances can be created and destroyed anytime vs. reserved instances are fixed long-term instances that result in a cheaper expenditure. Similarly, there are other pricing models — Spot instances, Dedicated instances, Dedicated hosts, etc.
Moving to the cloud also calls for a cultural change in organizations especially when it is about cost optimization. Teams should be made aware of how the cloud works and what managed resources should be used in various scenarios. It is suggested to form a Cloud Centre of Excellence (CCoE) to work across verticals to monitor and suggest better ways of implementing Cost Optimization principles below.
Define and enforce tagging
Effective account structures
Design and use metrics
Design cost-based architectures
Tagging of resources has proven to be a mandatory activity across the AWS cloud platform. It helps segregate resources and allows us to perform a cost analysis to have transparency related to cost performance. Below are certain best practices that should be implemented in organizations:
Expenditure awareness
Cost-effective resources
Match supply and demand
Continual optimization
In this post, we discussed the Whys of Cost Optimization pillar of AWS Well-Architected Framework. In the next post, we would cover Hows.
Hey, if you like this content, do consider subscribing, following, and sharing this blog post! Let'sDoTech, Instagram, Twitter, LinkedIn
Originally published at http://letsdotech.dev on March 1, 2021.
Top comments (0)