[ARTICLE]

5 AWS Mistakes You’re Making That are Costing You

Making the shift to AWS can bring myriad benefits including improved application performance and reduced costs. However, moving to AWS does not guarantee that your application will run efficiently by default. Below are the 5 AWS mistakes to avoid that are costing you.

There is a tendency for companies that are migrating from more traditional data center operations to bring their traditional manner of operations with them to a cloud and end up missing some of the benefits their migration could provide.

Even companies that are starting fresh with AWS and taking a cloud-native approach can overlook some important tools because of AWS’s overwhelming number of services and feature. Like 5 Common Misconceptions about AWS Autoscaling, Here are some mistakes you probably have no idea you are making, but are costing you:

AWS Mistake #1: Infrastructure is not automatically provisioned

Managing your infrastructure is complex, with a lot of room for error. AWS provides a means to define resource requirements with CloudFormation templates that provide transparency into your system configuration and assure consistency.  For example, It is extremely difficult to select the correct EC2 instance types, especially in an environment that has a variable load. This is why it is important to use AWS CloudFormation. CloudFormation allows you to program your resource requirements and let automation take care of the implementation. With a CloudFormation template, you can be sure that your system will deploy consistently with expectations the first time and the hundredth time you deploy it.

Mistake #2: You’re not Utilizing Auto Scaling Groups

Autoscaling gives your system the ability to respond to changes in load. For example, it is common to operate web servers on virtual machines with an AWS Auto Scaling group. Auto Scaling Groups can be utilized to scale up and down in relation to workloads. To trigger auto scaling you can set alerts on certain metrics or thresholds, (e.g. the number of requests given to the load balancer). When done correctly (see the next mistake), autoscaling enables you to automatically program a response to these alerts to scale up or down.

It may seem that Auto Scaling groups simply focus on auto scaling, but this is not the case. It is essential that every individual EC2 instance is launched with an Auto Scaling group. Why? Auto Scaling groups also consistently manage your EC2 instances to meet your system requirements. You can make sure that your system will always have 3 or 5 or 35 instances running and Auto Scaling will make it so. For no additional charge!

Mistake #3: Not scaling down resources not being used

When your application is not right-sized, you are wasting money (if over-provisioned) or risk poor performance or even application failure (if under-provisioned). We tend to see this when applications are being managed manually. Operators might underestimate the load with an eye on saving money or overestimate with an eye on maintaining service without fully considering cost implications. 

The far greater tendency seems to be keeping an extra instance or ten around “just in case” or provisioning larger than necessary instances for the same reason. We also see operators manually scaling to meet load or automating only the scale up response and then forgetting to scale back down when load has dropped. Even though you have an EC2 instance that is sitting idle or not using full capacity, this doesn’t mean you’re not being charged for it – you are. Here, again, CloudFormation and Auto Scaling are your friends.

Mistake #4: Not taking advantage of CloudWatch

You might be thinking that this has all been great so far, but setting up a metrics and monitoring system is hard.  On AWS, that excuse is gone. AWS CloudWatch is a service that every AWS service – infrastructure and application – communicates its metrics too. Your virtual machine will give CloudWatch data on disk activity, how much CPU your application is using, as well as your network traffic, and more. It is essential to use the insights you gain from this information to improve your cloud function. It is also key to automating your cloud.  Using CloudWatch is the simplest way to trigger Auto Scaling (up or down) or launch a CloudFormation template in response to changes in your system.  

AWS Mistake #5: Not using Trust Advisor 

Trusted Advisor is a great tool that compares your application to what AWS believes is the most efficient and secure. Although the basic (free) service focuses on a few security best practices, the upgraded (paid) access adds further security suggestions along with recommendations to improve application performance, optimize cost, and improve fault tolerance. You can feed these recommendations back into your CloudFormation templates and automatically update your system to apply the changes.

Overall

Hopefully, you were already aware of these five common AWS mistakes and, if not, we hope this has helped you find a few ways to upgrade your AWS cloud system to be safer, more reliable, more performant, and cost you less. 

As helpful as fixing these mistakes will be to your system reliability and bottom line, you can still do better. At Opsani, we help you focus on delivering the core values of your business by automating away the toil – the repetitive and manual tasks – associated with optimizing systems that are constantly changing.  Opsani leverages artificial intelligence and machine learning, particularly deep reinforcement learning, to predict traffic spikes and resource requirements will accurately predict the best moment to scale up or down, and seamlessly integrates with AWS tooling to automate the scaling process. No toil necessary. To find out how Opsani can reduce your AWS spend, check out AWS does not Equal Cloud Optimization. 

Contact Opsani to know more about their cloud cost optimization technology and products. You can also sign up for a free trial to test and experience the Opsani advantage.