Each year AWS re: invent brings more and more services and upgrades, yet the basic rules of creating scalable, fault-tolerant architecture are still the same.
AWS’s Pay as You Go model is a catchy hook to lure in people from expensive often paid upfront On-premise hardware machines, however, unless you have architected it properly AWS can end up being more expensive than it should.
The economy is heading towards a recession and cost optimization is the need of the hour, organisation leaders are being asked to do the same or more with less.
One of the most costly building blocks of an Environment created on AWS is the humble EC2 instance. the founding block of computing power in AWS.
EC2 instances can be used for storage, Web Servers, Backend Applications, and Worker nodes — the use cases are endless, and yet in most of our AWS Well-Architected Framework reviews, EC2 instances are found to be overprovisioned or even yet not entirely used.
Even if your EC2 instances are correctly provisioned there are so many things that a Solution Architect can leverage for instant cost optimization and discounts on the monthly bills so in this article we will go through some of the ways you can remediate your EC2 instances costs and implement much-desired discounts.
EC2 Rightsizing:
80%of cost savings come directly from seeing which instance classes EC2s are using and whether they are consuming the resources allocated or if they are spending time idle.
Compute workloads on AWS can be differentiated into 4 unique use cases.
Steady Load — This is the load on the Compute nodes normally, it is usually a fixed load and can be predicted from historical metric data and business expansion plans. This use case is perfect for Reserved Instances major discounts.
Spiky load — Similar to Steady Load; however this load tends to spike up and down during rush hours.
For such instances, we architect the EC2 size based on the average steady load and create scaling policies that can scale the system horizontally or vertically depending on the requirement to combat the spikes, that way you end up paying more only when there are spikes rather than paying an increased cost for the time you are not using your Ec2 instances.
Test load — Usually your developers will create instances to test or try out a new feature in the code or on AWS, since this type of work is done often but for shorter periods and they do not mind service disruptions, Spot instances are perfect for such use cases. In fact, spot instances can be included if your application has a graceful exit scenario (e.g. Spot instances are perfect for containerized workloads where even if a host goes down, a new one can be spun up and new containers can be provisioned).
Dev/Stage/QA — Because Development and staging replicas of production are only used during business hours Monday through Friday, You can use many of AWS offerings to shut down the Resources after hours and through the weekends. A simple schedular can bring the AWS Account costs substantially, and since the workloads on these environments are by and large not bound to an SLA spot instances might also be a good option.
Identify EC2 Metrics for Right-Sizing:
We’ve identified that setting up EC2 with the right instance class and size is imperative for a cost-optimized environment. But how do you even check the metrics for instance?
There are a couple of ways; both manually and using AWS managed services which can help in this, the first method is to check with AWS Cloudwatch metrics.
To view EC2 usage and performance metrics, go to the EC2 console, select an EC2 and click the monitoring tab.
