Common AWS Mistakes that could be costing you a bundle.

Author: Robert Greisemer

Here at CloudAccountant, we specialize in reducing AWS bills by fine tuning your configuration. I've been working as a consultant in the AWS field for the last six years working on AWS Accounts with monthly spends between $200/Month and $3,000,000/Month. I've seen a lot of AWS Accounts - these are some of the most common mistakes.

1. Over-provisioning EC2 Instance Resources.

EC2 is one of the most commonly used AWS services because it's one of the key building blocks. A big problem that most people face is oversizing their EC2 instances. How can you tell if your instances are oversized?
Review your Cloudwatch metrics quarterly and make sure that you're also tracking memory utilization on each instance to have a good view as to the utilization of the server. Let's say you have a c5.2xlarge instance type with an average CPU Utilization of 25% and average memory utilization of 30%, you can safely decrease the instance size to a c5.xlarge provide a near 50% savings just by decreasing it to an appropriate size.


2. Using the wrong instance families.

In AWS there are a number of instance families, each type serves a specific purpose and the specifications of the server are tailored for those purposes. Let's say that your application is a Java application, which is light on CPU utilization however it's really memory intensive. Right now you're running an m5.xlarge instance type, however you're only using 10% of the CPU while using 90% of the available RAM. If you switch from the General Purpose "M" series, to an equivalent sized "R" series for memory optimized, such as going from an m5.xlarge (8 vCPU, 15 GiB Ram) to an r5.large (2 vCPU, 15 GiB RAM) you would now roughly utilize 40% CPU while maintaining the 90% RAM utilization.


3. Not utilizing AWS Developed Services/Products

AWS Has invested a large amount of effort and money into designing scalable, affordable enterprise solutions. It's very common to see confusion between different "RDS" offerings, one big flaw is usually utilizing traditional MySQL RDS as opposed to MySQL on Amazon Aurora RDS. In a traditional RDS platform Multi-AZ is available, but you can't touch the backend instance - such as utilizing it as an individual read only node - however you're still stuck paying for this compute power to be there on standby. Aurora is a clustered configuration, which allows you to utilize secondary nodes as read only endpoints. This allows you to distribute the load across additional resources, in turn decreasing the required amount of compute power. For example, a client with a MySQL RDS in Multi-AZ Mode with an r5.2xlarge may be at 80% CPU Utilization on the instance, by utilizing Aurora the instance size could be decreased to an r5.xlarge for the master node, and r5.xlarge on the secondary nodes, you could nearly halve your RDS related expenses with small software tweaks (Such as separate "read and write" mysql endpoints instead of a single connection). There's a number of huge improvements that Aurora offers - take a look!


4. Incorrect EBS Volume types

AWS EBS has multiple different volume types, each for different scenarios. For example, clients commonly feel that to get the performance they need for the application they must use provisioned IOPs. A large amount of times, the same performance could be obtained with a GP SSD of the appropriate size at a significantly lower cost. Let's use the scenario of a client with a single EC2 instance with 1 EBS Volume of type "pIOPS" with 1500 provisioned IOPs and 500 GiB of storage. This drive will cost the client roughly $50/Month for the storage, and $150/Month for the IOPs - see the problem here? The client's average utilization on the drive is 500 IOPs, and it at times peaks to 1000 IOPs. However, if you switch this drive to GP SSD of the same size you would be provided with a baseline of 1500 IOPs ( 3 IOP Baseline * Drive Size in GB), and you would be paying only $50 for this drive, as opposed to $200. There are some key considerations to keep in mind, as pIOP drives do provide some additional benefits - such as added network throughput. However, as long as these thresholds aren't crossed you can get the same performance for a significant savings.


5. Not stopping development resources after hours.

How many servers do you have that are only utilized for ~5 hours per day? Why pay for 24 hours when you only need 8? It's simple now to set up scheduling, which could provide a significant cost savings, turn off the servers you don't need.


6. Treating AWS Like a datacenter.

A common mistake for companies new to the Cloud is to treat it like your existing data center by provisioning long lived application servers. Alternatively, work to modify applications where possible to allow for compatibility with services such as Auto Scaling - which will allow you to utilize only what you need.


If you're shocked by your AWS bill, it's time to have your account looked at - CloudAcccountant offers a simple, no risk, review process. If we don't save you money, you don't pay a dime. Reach out today for your risk free review.