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
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.