If you are using AWS EC2 in production, chances are good that you’re using the AWS M instance type. The M family is a “General Purpose” instance type in AWS, most closely matching a typical off-the-shelf server one would buy from Dell, HP, etc, and was the first instance family released by AWS in 2006.
If you are looking for mnemonics for an AWS certification exam, you may want to think of the M instance type as the Main choice, or the happy Medium between the more specialized instances. The M instance provides a good balance of CPU, RAM, and disk size/performance. The other instance types specialize in different ways, providing above average CPU, RAM, or disk size/performance, and include a price premium. The one exception is the “T” instance type, discussed further below.
For a normal web or application server workload, the M instance type is probably the best tool for the job. Unless you KNOW you are going to be running a highly RAM/CPU/IO-intensive workload, you can usually start with an M instance, monitor its performance for a while, and then if the instance is performance-limited by one of the hardware characteristics, switch over to a more specialized instance to remove the constraint. For example:
“C” instances for Compute/CPU performance.
“R” or “X” instances for lots of memory – RAM or eXtreme RAM
“D”, “H”, or “I” instances optimize for storage with different types/quantities of local storage drives (i.e., HDD or SDD that are part of the physical hardware the instance is running on) for high-Density storage (up to 48TB), High sequential throughput, or fast random I/O IOPS, respectively. (The latter two categories are much more specialized – see here for more details)
The “T” instance family is much like the “M” family, in that it is aimed at general purpose workloads, but at a lower price point. The key difference (and perhaps the only difference) is that the CPU performance is restricted to bursts of high performance (or “bursTs”) that are tracked by AWS through a system of CPU credits. Credits build up when the system is idle, and are consumed when the CPU load exceeds a certain baseline. When the CPU credit balance is used up, the CPU is Throttled to a fraction of its full speed. T instances are good for low-load web servers and non-production systems, such as those used by developers or testers, where continuous predictable high performance is not needed.
Looking at some statistics, the Botmetric Public Cloud Usage Report for 2017 states that 46% of AWS EC2 usage is on the M family, and 83% of non-production workloads are on T instances. Within the ParkMyCloud environment, we see the following top instance family statistics across our customers’ environments:
I instances: 39%
M instances: 22%
T instances: 27%
Since many of our customers are focused on cost optimization for non-production cloud resources (i.e., a lot of developers and test environments), we are probably seeing more “T” instances than “M” instances as they are less expensive, and the “bursty” nature of T instances is not a factor in their work. For a production workload, M instances with dedicated CPU resources are more predictable. While we cannot say for sure why we are also seeing a very large number of “I” instances, it is quite possible that developers/testers are running database software in an EC2 instance, rather than in RDS, in order to have more direct control and visibility into the database system. Still, 49% of the resources are in the General Purpose M and T families.
The Nitty and/or Gritty
Assuming you have decided that an M instance is the right tool for your job, your next choice will be to decide which one. As of the date of this blog, there are twelve different instance types within the M family, covering two generations of systems.
Table 1 – The M Instance Family Specs (Pricing per hour for on-demand instances in US-East-1 Region)
The M4 generation was released in June 2015. The M4 runs 64-bit operating systems on hardware with the 2.3 GHz Intel Xeon E5-2686 (Broadwell) or 2.4 GHz Intel Xeon E5-2676 H3 (Haswell) processors, potentially jumping to 3GHz with Turbo Boost. None of the M4 instance family supports instance store disks, but are all EBS-optimized by default. These instances also support Enhanced Networking, a no-extra-cost option that allows up to 10 Gbps of network bandwidth.
The M5 generation was just released this past November at re:Invent 2017. The M5 generation is based on custom Intel Xeon Platinum 8175M processors running at 2.5GHz. When communicating with other systems in a Cluster Placement Group (a grouping of instances in a single Availability Zone), the m5.24xlarge instance can support an amazing 25 Gbps of network bandwidth. The M5 type also support EBS via an NVMe driver, a block storage interface designed for flash memory. Interestingly, AWS has not jacked-up the EBS performance guarantee for this faster EBS interface. This may be because it is the customer’s responsibility to install the right driver to get the higher performance on older OS images, so this could also be a cheap/free performance win if you can migrate to M5.
Amazon states that the M5 generation delivers 14% better price/performance on a per-core basis than the M4 generation. In the pricing above, one can do the math and find that all of the M5 instances cost $0.048 per vCPU per hour, and that the M4 instances all cost $0.05 per vCPU per hour. So right out of the box, the M5 is priced 4% cheaper than an equivalently configured M4. Do the same math for RAM vs vCPU and you can see that AWS allocates 4GB of RAM per vCPU in both the M4 and M5 generations. This probably says a lot about how the underlying hardware is sliced/diced for virtual machines in the AWS data centers.
Beware the sticker shock – cloud services pricing is nothing close to simple, especially as you come to terms with the dollar amount on your monthly cloud bill. While cloud service providers like AWS, Azure, and Google were meant to provide compute resources to save enterprises money on their infrastructure, cloud services pricing is complicated, messy, and difficult to understand. Here are 7 ways that cloud providers obscure pricing on your monthly bill:
1 – They use varying terminology
For the purpose of this post, we’ll focus on the three biggest cloud service providers: AWS, Azure, and Google. Between these three cloud providers alone, different analogies are used for just about every component of services offered.
For example, when you think of a virtual machine (VM), that’s what AWS calls an “instance,” Azure calls a “virtual machine,” and Google calls a “virtual machine instance.” If you have a group of these different machines, or instances, in Amazon and Google they’re called “auto-scaling” groups, whereas in Azure they’re called “scale sets.” There’s also different terminology for their pricing models. AWS offers on-demand instances, Azure calls it “pay as you go,” and Google refers to it as “sustained use.” You’ve also got “reserved instances” in AWS, “reserved VM instances” in Azure, and “committed use” in Google. And you have spot instances in AWS, which are the same as low-priority VMs in Azure, and preemptible instances in Google.
2 – There’s a multitude of variables
Operating systems, compute, network, memory, and disk space are all different factors that go into the pricing and sizing of these instances. Each of these virtual machine instances also have different categories: general purpose, compute optimized, memory optimized, disk optimized and other various types. Then, within each of these different instance types, there are different families. In AWS, the cheapest and smallest instances are in the “t2” family, in Azure they’re called the “A” family. On top of that, there are different generations within each of those families, so in AWS there’s t2, t3, m2, m3, m4, and within each of those processor families, different sizes (small, medium, large, and extra large). So there are lots of different options available. Oh, and lots confusion, too.
3 – It’s hard to see what you’re spending
If you aren’t familiar with AWS, Azure, or Google Cloud’s consoles or dashboards, it can be hard to find what you’re looking for. To find specific features, you really need to dig in, but even just trying to figure out the basics of how much you’re currently spending, and predicting how much you will be spending – all can be very hard to understand. You can go with the option of building your own dashboard by pulling in from their APIs, but that takes a lot of upfront effort, or you can purchase an external tool to manage overall cost and spending.
4 – It’s based on what you provision…not what you use
Cloud services pricing can charge on a per-hour, per-minute, or per-second basis. If you’re used to the on-prem model where you just deploy things and leave them running 24/7, then you may not be used to this kind of pricing model. But when you move to the cloud’s on-demand pricing models, everything is based on the amount of time you use it.
When you’re charged per hour, it might seem like 6 cents per hour is not that much, but after running instances for 730 hours in a month, it turns out to be a lot of money. This leads to another sub-point: the bill you get at the end of the month doesn’t come until 5 days after the month ends, and it’s not until that point that you get to see what you’ve used. As you’re using instances (or VMs) during the time you need them, you don’t really think about turning them off or even losing servers. We’ve had customers who have servers in different regions, or on different accounts that don’t get checked regularly, and they didn’t even realize they’ve been running all this time, charging up bill after bill.
You might also be overprovisioning or oversizing resources — for example, provisioning multiple extra large instances thinking you might need them someday or use them down the line. If you’re used to that, and overprovisioning everything by twice as much as you need, it can really come back to bite you when you go look at the bill and you’ve been running resources without utilizing them, but are still getting charged for them – constantly.
5 – They change the pricing frequently
Cloud services pricing has changed quite often. So far, they have been trending downward, so things have been getting cheaper over time due to factors like competition and increased utilization of data centers in their space. However, don’t jump to conclude that price changes will never go up.
Frequent price changes make it hard to map out usage and costs over time. Amazon has already made changes to their price more than 60 times since they’ve been around, making it hard for users to plan a long-term approach. Also for some of these instances, if you have them deployed for a long time, the prices of instances don’t display in a way that is easy to track, so you may not even realize that there’s been a price change if you’ve been running the same instances on a consistent basis.
6 – They offer cost savings options… but they’re difficult to understand (or implement)
In AWS, there are some cost savings measures available for shutting things down on a schedule, but in order to run them you need to be familiar with Amazon’s internal tools like Lambda and RDS. If you’re not already familiar, it may be difficult to actually implement this just for the sake of getting things to turn off on a schedule.
One of the other things you can use in AWS is Reserved Instances, or with Azure you can pay upfront for a full year or two years. The problem: you need to plan ahead for the next 12 to 24 months and know exactly what you’re going to use over that time, which sort of goes against the nature of cloud as a dynamic environment where you can just use what you need. Not to mention, going back to point #2, the obscure terminology for spot instances, reserved instances, and what the different sizes are.
7 – Each service is billed in a different way
Cloud services pricing shifts between IaaS (infrastructure as a service), which uses VMs that are billed one way, and PaaS (platform as a service) gets billed another way. Different mechanisms for billing can be very confusing as you start expanding into different services that cloud providers offer.
As an example, the Lambda functions in AWS are charged based on the number of requests for your functions, the duration, and the time it takes for your code to execute. The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month, or you can get 1M request free and $0.20 per 1M requests thereafter, OR use “duration” tier and get 400,000 GB-seconds per month free, $0.00001667 for every GB-second used thereafter – simple, right? Not so much.
Another example comes from the databases you can run in Azure. Databases can run as a single server or can be priced by elastic pools, each with different tables based on the type of database, then priced by storage, number of databases, etc.
With Google Kubernetes clusters, you’re getting charged per node in the cluster, and each node is charged based on size. Nodes are auto-scaled, so price will go up and down based on the amount that you need. Once again, there’s no easy way of knowing how much you use or how much you need, making it hard to plan ahead.
What can you do about it?
Ultimately, cloud service offerings are there to help enterprises save money on their infrastructures, and they’re great options IF you know how to use them. To optimize your cloud environment and save money on costs, we have a few suggestions:
Recently, I’ve been on a few phone calls where I get asked about cost management of resources built in AWS using Terraform provisioning. One of the great things about working with ParkMyCloud customers is that I get a chance to talk to a lot of different technical teams from various types of businesses. I get a feel for how the modern IT landscape is shifting and trending, plus I get exposed to the variety of tools that are used in real-world use cases, like Atlassian Bamboo, Jenkins, Slack, Okta, and Hashicorp’s Terraform.
Terraform seems to be the biggest player in the “infrastructure as code” arena. If you’re not already familiar with it, the utilization is fairly straightforward and the benefits quickly become apparent. You take a text file, use it to describe your infrastructure down to the finest detail, then run “terraform apply” and it just happens. Then, if you need to change your infrastructure, or revoke any unwanted changes, Terraform can be updated or roll back to a known state. By working together with AWS, Azure, VMware, Oracle, and much more, Terraform can be your one place for infrastructure deployment and provisioning.
How to Use Terraform Provisioning and ParkMyCloud with AWS Autoscaling Groups
I’ve talked to a few customers recently, and they utilize Terraform as their main provisioning tool, while ParkMyCloud is their ongoing cloud governance and cost control tool. Using these two systems together is great, but one main confusion comes in with AWS’s AutoScaling Groups. The question I usually get asked is around how Terraform handles the changes that ParkMyCloud makes when scheduling ASGs, so let’s take a look at the interaction.
When ParkMyCloud “parks” an ASG, it sets the Min/Max/Desired to 0/0/0 by default, then sets the values for “started” to the values you had originally entered for that ASG. If you run “terraform apply” while the ASG is parked, then terraform will complain that the Min/Max/Desired values are 0 and will change them to the values you state. Then, when ParkMyCloud notices this during the next time it pulls from AWS (which is every 10 minutes), it will see that it is started and stop the ASG as normal.
If you change the value of the Min/Max/Desired in Terraform, this will get picked up by ParkMyCloud as the new “on” values, even if the ASG was parked when you updated it. This means you can keep using Terraform to deploy and update the ASG, while still using ParkMyCloud to park the instances when they’re idle.
How to Use Terraform to Set Up ParkMyCloud
If you currently leverage Terraform provisioning for AWS resources but don’t have ParkMyCloud connected yet, you can also utilize Terraform to do the initial setup of ParkMyCloud. Use this handy Terraform script to create the necessary IAM Role and Policy in your AWS account, then paste the ARN output into your ParkMyCloud account for easy setup. Now you’ll be deploying your instances as usual using Terraform provisioning while parking them easily to save money!