When it comes to individuals and micro, small, & medium businesses, adoption of Cloud often starts with the free tier plans of AWS, Google or Microsoft. After getting convinced of the cost-benefits and scalability benefits of Cloud, users continue to become paid subscribers.
Many users still wonder why the average monthly cost of Cloud Services shoots up when originally it cost them just a few cents. Let’s examine what could be the possible reasons and how to reduce them.
To me, it all boils down to the human psychology. AWS or any Cloud services provider is not hiding anything; it’s just, we as users don’t see it clearly.
This 2008 research paper published in the Journal of Experimental Psychology, reports that “there are significant differences in spending based on how shoppers pay for things.” In simple terms, the report suggests that the “more the transparency involved in the outgoing payment, the greater the aversion to spending or higher the pain of paying.”
This finding very well suits the case of billing services for Cloud computing. When the machines are just a click away with so many configuration details, we are not very careful in selecting what is needed most of the times and end up allocating more than what is required for us. While buying hardware, the cost goes out in 1 shot so we are very focused on getting the best ROI. When it comes to cloud computing, we are billed only at the end of the month based on our actual usage.
Below are few suggestions that will keep your Cloud cost in check.
Tag Resources
Make you Tag every resource you have on AWS properly. It will help to accurately get the cost details of every resource. You can single out the costly resources rather than just seeing the cost per service. Please note that Amazon will start to separate the bill of a tag only after you create it. Taking this into consideration, wetag the resource while creating them and not later when we want to find out the cost from a total bill of the service.
"I Am Only Using A Little So Let Me Have It" Mentality
Before you begin to use any new cloud service, study it in detail to find the best option rather than blindly proceeding with the word of mouth recommendation with an "I will handle it later" attitude. Always remember that cloud services providers charge you from the moment you have activated the service and not based on whether you are using it or not. For example, the billing starts the moment an EC2 instance is turned on.
Not Using Reserved Instances Early
Many users take a long time to move from on-demand to reserved instances because they don't know how long they are going to keep these instances alive. One needs to remember that the clock is always ticking and it will result in paying more than what they think they need to. It is always best to finalize and configure to have some instances on reserve first, rather than going with all instances on-demand. Use the spot market wisely.
Setting Up and Forgetting with Little Planning
While setting up a new resource, we sometimes add some extra toppings with it. For example, for a newly activated service, we want the logs to go to S3 but often fail to look at the logs thereafter. Always focus on the prioritized goals; steer your efforts only on building the optimal infrastructure and stick to the plan.
No Routine Auditing
Set up scheduled audits on the infrastructure to closely monitor the utilization of resources. When it comes to AWS, their “trust advisor” is a great tool for this. It keeps an eye on every resource used by the users. If there are any snapshots that are not needed anymore, delete them. It is good advice to compare and analyze your monthly billing statements to understand the infrastructure changes and cost implications.
Cloudwatch Billing Alarms
Basic monitoring metrics at five-minute increments for EC2 is free, and so are all metrics for EBS volumes, ELBs and RDS. Three dashboards of up to 50 metrics each are free per month. We should use Cloudwatch to collect and track metrics, monitor logs and set alarms. You should create billing alarms to alert you whenever your monthly cloud costs attempt to cross threshold limits.
Follow Bottom-Up Approach While Choosing Instance Types
Start small to see if the computing requirement fit with smaller instances before jumping on to instances with higher configuration. For example, a pair of general purpose t2.medium instances are better (4 vCPU) and cheaper (0.047x2 vs 0.1) than one m4.large. I understand that this is not an apples-to-apples comparison, but an example to show how you should try to compare various instance types.
Follow AWS’s Recommendations
Bookmark this web page and follow regularly to stay ahead of what’s new and changing in AWS. For example, use t2.micro type of instances instead of t1.micro, try to use an Alias name instead of a Canonical name, etc. Following best practices on cloud computing and using new tips will help improve the practice.
Data Transfer Cost
While choosing a region, review the data transfer costs of every region. While interacting with AWS instances, use private IPs so they don’t use the internet. Always make sure to set up alarms for network out traffic so you can be notified of any spike.
Use S3 Lifecycle Policy
Most of the time while using S3 we forget to set up the lifecycle policy and let it remain in the standard storage. Based on the need, we should analyze and move some data to IA or RRS. Even though they both have some conditions (like IA has minimum storage duration of 30 days and a per GB retrieval fee), in the long run, this is a money-saving deal if implemented properly.
I hope you take away a few pointers from here to check your surging cloud computing costs. I am keen to understand other functional and technical cloud computing best practices from you. Connect with me.