Guide to AWS EC2 and How to Control Its Costs
Amazon Elastic Compute Cloud (EC2) is one the most-used services on AWS. With over 150 different instance types and a variety of payment options, EC2 embodies the promise of the cloud with its flexibility, versatility and scalability.
But all those choices can make managing EC2 more than a bit complex. We’ve created this guide to help make things a little simpler. We’ll give you a quick summary of EC2 and the various instance types, then dive into EC2 costs before giving you some tools to help manage your EC2 usage and costs.
It’s a lot to cover, so let’s jump right in!
What is EC2?
EC2 is an AWS service that provides compute capacity in the cloud. Like a server, an EC2 instance has resources like a CPU, an operating system, local storage, RAM, etc. With EC2, you can easily build an Amazon Machine Image (AMI) that’s secure, is exactly what you need, and is available in minutes.
Those server images are called instances. When you spin one up, you choose the instance type, then launch the number of instances you need. You can do this manually, from the Management Console, or programmatically. You only pay for what you use and, when you’re done with your instances, you spin them down and stop paying for them.
What Are EC2 Families?
EC2 instances are grouped together into families. Each EC2 family is designed to meet a target application profile in one of these buckets:
- General purpose
- Compute optimized
- Memory optimized
- Storage optimized
- GPU optimized
If you look at how Amazon describes an instance, it’s always with the family name first, a generation, a period and then a size. For example, c5.large means that the instance belongs to the C family, it’s the fifth generation and its size is large.
Let’s run through a brief overview of the various EC2 instances families.
M & T Families – General purpose
Designed for general purpose workloads, the M and T families are the workhorses of EC2. The M family has a good balance of CPU, RAM and disk size/performance, making it the best choice for applications with consistent performance needs. Unless you know you are going to be running a highly RAM/CPU/IO-intensive workload, you can usually start with an M instance and monitor its performance for a while. Then if you find that the instance is performance-limited by one of the hardware characteristics, you can switch over to another family that’s more specialized.
The T family is a lower-cost option than the M family. It’s also aimed at general purpose workloads, but is burstable. It’s best for applications that don’t require much performance most of the time, but have periods where they’re really active. You might use a T instance for lower throughput applications such as administrative applications, low-traffic websites or development and testing.
C Family – Compute Optimized
Compute-optimized instances geared toward applications that need a lot of compute power, with a higher ratio of vCPUs to memory and the lowest cost per vCPU. Examples of applications that are suited for the C family include front-end fleets for high-traffic websites, on-demand batch processing, distributed analytics, video encoding, and high performance science and engineering applications.
X & R Families – Memory Optimized
The XI, R4 and R5 instances are designed for memory-intensive applications. These families have the lowest cost per GiB of RAM, making them a good choice if your application is memory-bound.
The R families are ideal if you’re doing data mining, real-time processing of unstructured big data, or Hadoop/Spark clusters. X1 instances are recommended for enterprise-sized in-memory applications, like SAP HANA. They have a much higher proportion of memory than the R family.
H, D & I Families – Storage Optimized
If storage is what matters, then the H, D, and I families are a good choice. They offer different amounts of local storage, either with hard drives or SSDs.
H1 offers up to 16TB of hard drive storage space. It’s a great choice for workloads that use MapReduce or a streaming platform like Apache Kafka.
D2 offers up to 48TB of hard drive storage space. Use this family for applications like Massively Parallel Processing data warehousing, Hadoop and distributed file systems.
I3 instances include Non-Volatile Memory Express (NVMe) SSD-based instance storage. This family is optimized for low latency, very high random I/O performance and high sequential read throughput. It’s a good fit for NoSQL databases, in-memory databases, data warehousing, Elasticsearch and analytics workloads.
P & G Families – GPU Optimized
If your application is graphics intensive, then take a look at the P and G families. P instances are designed for most general-purpose GPU apps. G instances are optimized for GPU-heavy applications. There’s also an F1 family that comes with customizable hardware acceleration.
Summary of EC2 Instances
Here’s a table that lists the EC2 families and their associated use cases, along with links to their specs on AWS’ site (where available).
|General Purpose||Compute Optimized||Memory Optimized||Storage Optimized||GPU Optimized|
Tips for Picking Your Instance
Here’s a few things to remember when you’re deciding which instance to use:
- If you’re not sure about the performance characteristics of your app, start with one of the general purpose families. An M5 instance can be a good choice. It’s well balanced in terms of compute, storage and memory. Run some stress tests and you’ll be able to see if your app is being limited by one of those components.
- Don’t guess at your application requirements. Get some hard data. If you don’t, you can end up either overprovisioning or underprovisioning. You’ll end up either paying for hardware you’re not using, or you’ll starve your application and give your customers a bad user experience. It’s easy to switch to a different instance or family, so take the time to gather the data you need.
- To save money, take a look at the most recent addition to a family. They generally offer the best price/performance ratio. For example, M5 instances deliver 14% better price/performance than M4 instances on a per-core basis.
- EC2 prices vary from region to region. If you can be flexible about where your EC2 instances live, then taking the time to do some price comparisons can really pay off.
- Automate turning on and turning off your instances. You’ll save money if you don’t rely on doing these actions manually.
Understanding EC2 Pricing
Once you’ve decided on the EC2 instances that fit your use case, you’ll need to decide how to pay for them. AWS offers a variety of options.
On-Demand pricing means you pay for the compute capacity you need without any long-term commitments. You use the instance for as long as you need it, then shut it down when you’re done. On-Demand pricing is always computed by the second (with a minimum charge of 60 seconds), even if the prices you see on the AWS site are per hour. The prices vary depending on the size of the instance, the region and the OS.
As an example, the on-demand prices for an m5.large instance in the US West (Oregon) region look like this:
- Linux = $0.096 per hour
- Windows = $0.188 per hour
- RHEL = $0.156 per hour
The on-demand prices for the same instance in the EU (Ireland) region look like this:
- Linux = $0.107 per Hour
- Windows = $0.199 per hour
- RHEL = $0.167 per hour
On-Demand offers a lot of convenience, but it’s also the most expensive option. If you have unpredictable workloads or applications that are being developed and tested, then the flexibility of On-Demand will be worth the higher costs.
Reserved Instances (RIs) are a great way to reduce your EC2 costs. Despite the name, RIs aren’t actually instances. They’re pre-purchased billing discounts that are applied to On-Demand instances. Discounts range from 30% to 75% depending on the instance, the term and the prepayment option.
Each RI has specific instance attributes that go along with it. When an instance is running that matches those attributes, your RI is applied instead of creating new costs at an On-Demand rate. As a quick note, each RI can only apply to one instance at a time, so if you have an RI for an m5.large instance and spin up two m5.large instances at the same time, then one will be covered by the RI and the other will be billed at the On-Demand price.
Instance attributes include the instance type, the scope, tenancy and platform.
- Instance type – The instance family, the generation and the size, such as m5.large.
- Scope – Whether the RI can be applied flexibly within a region or if it applies to a specific AZ, such as us-west-1.
- Tenancy – Whether the RI runs on default (shared) or dedicated hardware.
- Platform – Which operating system, such as Linux, the instance uses. Some RI features are only available for certain platforms.
RI Payment Plans
There are three payment options for RIs:
- No Upfront
- Partial Upfront
- All Upfront
The more you pay upfront, the more you save. Whatever you don’t pay upfront is due in monthly installments.
When you purchase an RI, you choose either a one-year or three-year term. During that time, the RI can be applied to any instance that matches its attributes. The key to maximizing savings is to use the RI enough that the cost of the RI is less than you would have paid at the On-Demand price.
As an example, say you’re using an m5.xlarge in the US-West (Oregon) region. On-Demand for this instance runs around $0.19 an hour. A Standard One-Year Term with Partial Upfront payment will cost $512 and $42.34/mo for a total of $1,016. That’s an effective hourly rate of about $0.12 for 8,760 hours, or a 39% discount. Running those same instances for 5,192 hours with On-Demand pricing will cost the same amount. If the stack behind your site includes m5.xlarge instances for 135 hours/wk, then you’ll hit 7,020 hours of usage during a year. Those extra 1,828 hours of use were, in essence, free, and you save $347.32. Do that for a thousand instances and you’ve freed up $347,320 that can be used elsewhere.
Amazon applies the RI discount automatically to instances, but there’s a specific order when consolidate billing enters the picture. First, it’s applied to the account where the RI was purchased. If there’s nothing in the purchasing account, then the discount can be applied to all accounts within your consolidated billing family. If the RIs were purchased at the master payer level, then they’re spread out among the linked accounts on an as-needed basis.
Specifying RI Scope
You can choose to have an RI apply to any matching instance within a region, a Regional RI, or limit the RI to a specific AZ, a Zonal RI. By specifying an AZ, you’re reserving capacity within that zone whether you use it or not. If your infrastructure needs capacity standing by and ready, then this is the best way to make sure your resources will be there. Note that “reserved” does not mean “guaranteed.” The reservation just means that you’re first in line.
With a regional scope, the RI discount applies to any usage within that region, regardless of the instance’s AZ. You gain flexibility, but you also don’t reserve capacity and aren’t first in line. You may want to consider regional RIs if:
- You favor billing discounts over capacity reservations.
- You want a broader applicability of the RI discount.
- You want Instance Size Flexibility (only for Linux instances).
Instance Size Flexibility (ISF)
For regional RIs on Amazon Linux, AWS automatically adjusts the RI to fit usage within the same family. To do this, it uses a normalization scale based on the relative size of the instances. For example, an RI for an m4.2xlarge can be applied to two m4.xlarge instances, or four m4.large instances. It can’t however, be used for a t3 instances, no matter what size they are.
ISF is available with Amazon Linux, but not other forms of Linux, such as Red Hat Linux. Also, it’s only for RIs with a Region scope, so if you specify an AZ to reserve capacity, then ISF won’t apply.
Standard and Convertible RIs
When you purchase an RI, you choose between a Standard RI and a Convertible RI. Convertible RIs are a middle ground between Standard RIs and On-Demand prices. They offer a smaller discount than Standard RIs, but they come with additional flexibility.
Standard RIs provide the most significant discount (up to 75% off On-Demand) and are best suited for steady-state usage. With a Standard RI, some attributes, such as instance size, can be modified during the term, but the instance family can’t be changed. Convertible RIs, on the other hand, can be exchanged for other Convertible RIs if the new configuration is of equal or greater value than the remaining value of your existing RIs. There are a few specific rules for exchanging Convertible RIs (see our Complete Guide to AWS Reserved Instances for more info), but they’re much more flexible than Standard RIs.
This table summarizes the differences between Standard and Convertible RIs.
|Terms (avg. savings)||1yr (40%), 3yr (60%)||1yr (31%), 3yr (54%)|
|Change AZ, instance size (Linux only), scope & networking type||Yes||Yes|
|Change instance family, OS, tenancy & payment option||No||Yes|
|Benefit from Price Reductions||No||Yes|
|Sellable on the RI Marketplace||Yes||Not yet|
RI Buying Tips
Buying RIs may seem confusing, but a detailed plan will help you get the most savings out of them. Here are a few tips to get you started:
- Form a team. Get a balanced team made up of people who bring diverse expertise to the table. Put someone in charge of the team who dedicates most of his or her time to making sure you have the optimum RI strategy.
- Learn the fundamentals. Give everyone a chance to learn about RIs so you can all be on the same page.
- Start small. Start with a few RIs and increase your purchases as your confidence grows.
- Use metrics to determine your success. Some basics metrics are:
- RI Coverage Rate – How many instances are covered by RIs?
- RI Savings – How much am I saving?
- RI Utilization – How well am I using the RIs I purchased?
- Unrealized Savings – How much more can I save if I utilize my RIs better?
- Total Reserved Units – How many RIs do I have?
- Get into a buying cadence. Have a set schedule, such as monthly, where everyone meets to evaluate the strategy and decides on what to buy.
We’ve given you an idea about how RIs work. For a complete rundown on RIs and how to maximize your savings, download The Complete Guide to AWS Reserved Instances.
On-Demand Capacity Reservations
On-Demand Capacity Reservations give you the ability to reserve capacity without the one-year or three-year commitment that comes with a Zonal RI. Like Zonal RIs, On-Demand Capacity Reservations give you reserved capacity in a specific AZ, but you sacrifice the discounted rate for more flexibility. Like with Zonal RIs, the capacity reservation puts you first in line so you can make sure you have the capacity when you need it.
When you start a Capacity Reservation, you specify an instance size and AZ. While the Reservation is active, you are charged the On-Demand rate for capacity, whether you use it or not. If you spin up an instance that matches the Capacity Reservation while it’s active, then you’re charged for the instance instead of the reservation. Capacity Reservations can be turned on and off manually, or be set to expire at a specific time.
The easiest way to think of it is that you will pay the same amount whether you use the instance or not — the only difference is how the amount is billed. For example, an m5.large reservation in US West (Oregon) is billed at the On-Demand rate of $0.096/hr. If you make a reservation and don’t use it, you’ll be billed at that rate. If you then spin up an m5.large that uses the reservation, you’ll stop paying for the reservation and start being billed for On-Demand usage. Either way, you’re still paying $0.096/hr. Like On-Demand Instances, On-Demand Capacity Reservations are billed at per second granularity.
There’s one last feature to remember when using On-Demand Capacity Reservations — Regional RIs can apply to them. So if you have a c5.xlarge Regional RIs for US West and make an On-Demand Capacity Reservation in US West (Oregon), then your reservation will be billed at the discounted RI rate.
On the opposite end of the spectrum from RIs are Spot Instances. Spot Instances offer the largest potential discount from On-Demand prices — up to 90% in the right conditions. With Spot Instances, you bid for for unused EC2 instances. Prices change depending on supply and demand. When the EC2 instances you want are in high demand, you’ll have to bid more to be competitive, but you can set your maximum price. If the Spot price of the instance is below your maximum bid and the capacity is available, then your request is fulfilled.
But there’s a catch to the low price. AWS can interrupt your Spot Instance when the Spot price exceeds your maximum price, when the demand for Spot Instances rises or when the supply of Spot Instances decreases. There are ways to mitigate the risk by using AWS’ Hibernate or Pause-Stop features, but any workload on Spot Instance should be structured to minimize the impact of interruptions.
An Amazon EC2 Dedicated Host is a physical server whose EC2 instance capacity is fully dedicated to your application. Dedicated Hosts can help you address compliance requirements and allow you to use your existing server-bound software licenses.
Like other EC2 options, you can turn Dedicated Hosts on or off at will, and you can purchase reservations to lower costs. But there are a few key differences. When you set up a Dedicated Host, you choose a configuration that determines the kind and number of instances that you can run on it. You’re billed hourly for each active Dedicated Host, rather than being billed for each instance. The hourly price varies depending on the configuration of the Dedicated Host.
Managing EC2 Costs
Managing your EC2 costs can seem more than a little daunting. Spreadsheets can help with a small number of instances, but it doesn’t take much for an EC2 architecture to scale too large for a spreadsheet to handle.
It starts with having enough visibility into your costs and usage to provide actionable insights. Once you have a strong reporting and analysis foundation, you can move on to prediction and cost optimization. A cloud cost management platform like Cloudability is a crucial tool in helping you manage both your current and future EC2 costs.
Keeping Track of Tags
Tags are metadata labels (each with a customer-defined key and a value) that you assign to resources so you can keep track of them. Tagging is essential to making sense of the enormous amount of EC2 cost and usage data AWS produces. Cloudability has a few features that let you take full advantage of your tags and share that valuable data with all your stakeholders for allocation, tracking, rightsizing and more.
To learn more about building your tagging strategy, check out our AWS Tagging Strategy Best Practices: Using Tags and Consolidated Billing to Lower Your AWS Spend e-book.
AWS views tags as a collection of characters, and tags need to match exactly if they’re going to be lumped together. That means Environment, environment and typos like envronment will all be sorted into different tags. Tag Mapping lets you take multiple versions of what should be a single tag and map them to one dimension so you can make sure your tags are grouped accurately.
Tag Explorer gives you a global view by sorting all of your resources into tag keys and breaking down those resources by tag values. At a glance, you’ll be able to see how your spend is distributed — and which spend isn’t tagged.
Managing Your RIs
RIs are vital for optimizing your EC2 use and getting the most from your cloud. The right tools will give you the ability to manage your current portfolio and predict your future use so you can make informed purchases. Cloudability has several features devoted to helping you build a solid RI strategy and a dependable RI portfolio.
The Reservation Portfolio provides a global view of RIs from all member and payer accounts in a single place. The list is sortable and filterable, and perhaps most importantly, shows the expiration date of each reservation so that you don’t get any surprise drops in coverage. It also shows you both your current savings and potential unrealized savings. To make it easy to keep tabs on expiring reservations, the Reservation Portfolio lets you subscribe to a scheduled email alert to warn you about expiring RIs.
Reserved Instance Planner
The RI Planner pulls from your existing inventory and usage data to make recommendations for RI purchases. Using the RI Planner, you can uncover potential savings from RI purchases and modifications. It can also highlight underutilized RIs so you can make sure you’re getting your money’s worth. By setting your RI parameters, you can focus the recommendations by things like utilization rate, savings rate, term, payment option, etc.
The best way to get the most out of your RIs is to revisit your portfolio and purchases on a regular basis, and the RI Planner is vital for these efforts.
Full Visibility & Full Control Over EC2 Costs
Full visibility means getting the EC2 cost data you need, when you need it, and any platform you’re using needs to have the capability to give you the exact data you need. Full control means that you never have to worry about EC2 costs exploding from out of nowhere. Cloudability is built around giving your the visibility you need along with the tools to proactively prevent cost spikes and to let you know quickly if a spike does occur.
Cloudability offers a wide variety of reports. If you want to see something about your cloud costs or usage, then we have a report to show it to you — and that includes EC2. Get reports on key factors like the effectiveness and usage rate of Spot Instances, your RI waste, your RI coverage rate, a list of untagged EC2 Instances, data transfer costs, and more. And that’s only the prepackaged reports. Reports can be customized to fit the exact metrics that mean that most to your business.
Whether you use Cloudability or not, this kind of information is critical for understanding the financial health of your EC2 architecture.
The Automation feature lets you automatically scale down or stop development and test resources during periods of underutilization. For example, you might want to turn your development resources off during nights and weekends. The Automation feature includes an audit log where you can see each task run, when it was executed and the number of resources affected during the run.
Usage and cost anomalies can add up quickly, and you need to know about them as soon as possible. If a program error spins up a bunch of EC2 instances on Friday at 7PM, you want to find out about it so you can shut it down much earlier than when you log in Monday morning.
Anomaly Detection prevents issues like that by monitoring your costs and notifying you when there are unusual spending patterns. Typically, AWS billing files are updated 4-6 times per day. Every time they come in, the costs are automatically compared to past usage and anomalous activity is flagged. The comparison includes taking normal usage spikes into account to avoid false positives. When you get an alert, you can have confidence that there really is an anomaly.
Give Your EC2 Backbone the Support It Needs
EC2 is the core of many cloud architectures. The better you are at managing your EC2 usage and costs, the stronger your cloud will be — and the more you’ll get from it. With the right strategy and management practices, you’ll be able to get all the resources you need for substantially less, freeing up valuable funds that can fuel innovation in your company.
Not sure which EC2 instances are right for you? Check out our Choosing the Right EC2 Instances to Optimize Your Cloud e-book. And if you’re ready to jump into managing your current EC2 architecture, then sign up for a free Cloudability trial.