Guide to AWS EC2 Pricing and How to Control Costs

Amazon Elastic Compute Cloud (EC2) is the most-used service on AWS. With hundreds of different instance types at various price points, it’s challenging to select the right compute resource for your needs and budget. This blog will review your options, summarize costs, and provide best practices for managing your EC2 usage.

What is AWS EC2?

AWS EC2 provides compute capacity in the cloud. At the heart of this service is the EC2 instance: virtual machines that run an operating system on top of resources like a CPU, memory, hard disk, etc. With EC2, you can easily provision an instance that’s secure, runs the software required for operating the business, and is available in minutes.

When you spin up an EC2 instance, you must choose the instance type (e.g., T3) and size (e.g., large). This determines the resource capacity of the machine and hourly pricing. You can do this manually from the AWS Management Console, or programmatically. You are only charged for the instances while they are running, so when you’re done with your instances, you can spin them down and stop paying for them.

Amazon EC2 family types

Each EC2 instance family meets a target application profile in one of these categories:

• General purpose
• Compute optimized
• Memory optimized
• Accelerated computing
• Storage optimized

Amazon describes an instance with the instance type first, then size. For example, c5.large means that the instance belongs to the C5 instance type (which is in the compute optimized family). You can infer it’s a fifth-generation type and its size is large.

Let’s run through a brief overview of the various EC2 instances families.

M and T families: General purpose

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 will 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 more specialized family.

The T family is a lower-cost option than the M family. It’s also aimed at general-purpose workloads but is burstable. These instances are intended to operate at a low baseline performance for substantial blocks of time and can then automatically burst performance as needed. You can think of this bursting as in-built elasticity. It’s best for applications that don’t require much performance most of the time but have periods where they’re 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 are for 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, z1d, and High Memory families: Memory optimized

The X1, X2, R4, R5, R6, and z1d instances are for memory-intensive applications. These families have the lowest cost per GB 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 and X2 instances are for enterprise-sized in-memory applications, like SAP HANA. They have a much higher proportion of memory than the R family.

z1d instances deliver high single-thread performance with a sustained all core frequency of up to 4.0 GHz — the fastest of any cloud instance. The result is instances of both high-compute performance and high memory. z1d is recommended for use cases like electronic design automation (EDA), gaming, or relational database workloads with high per-core licensing costs.

Instances of the High Memory family offer the most memory of any EC2 instance and are primarily used for large in-memory databases. Ranging from three to 24 TiB in available memory, these instances were originally made available for SAP HANA deployments with fixed-term commitments. Since mid-2021 they’ve been made available with On-Demand pricing and are finding a wider set of use cases.

H, D, and I families: Storage optimized

H, D, and I families are a good choice if your applications require high performance from its local storage. This is in comparison to most instance families, such as compute optimized and general purpose types, which don’t have local storage but rely on attached EBS volumes instead. The storage optimized families offer a wide range of storage sizes, either backed with HDDs or SSDs. H1 offers up to 16TB of hard drive storage space. It’s an excellent choice for workloads that use MapReduce or a streaming platform like Apache Kafka.

D3 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 and G families: Accelerated computing

If your applications are graphics-processing intensive or run machine learning models, look at the P and G families for achieving high performance and cost efficiency. P instances are designed for most general-purpose GPU apps and are useful for video editing. G instances are optimized for GPU-heavy applications, including automated speech recognition or language translation. There’s also an F1 family that comes with customizable hardware acceleration.

Summary of AWS EC2 instances

Below is a table that lists the EC2 families and their associated categories, along with links to their specs on AWS’ site (where available).

General Purpose	Compute Optimized	Memory Optimized	Storage Optimized	Accelerated Computing
Mac	C7g	R6g	Im4gn	P4
T4g	C6g	R6i	Is4gen	P3
T3a	C6gn	R5	I4i	P2
T3	C6i	R5a	I3	DL1
T2	Hpc6a	R5b	I3en	Trn1
M6g	C5	R5n	D2	Inf1
M6i	C5a	R4	D3	G5
M6a	C5n	X2gd	D3en	G5g
M5	C4	X2idn	H1	G4dn
M5a		X2iedn		G4ad
M5n		X2iezn		G3
M5zn		X1e		F1
M4		X1		VT1
		z1d

Tips for picking your AWS EC2 Instance

Here are 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 M6 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 under-provisioning. You’ll end up either paying for hardware you’re not using or starving your application and giving 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, look at the most recent generation instance types. They generally offer the best price/performance ratio. For example, M5 instances deliver 14% better price/performance than M4 instances per core.
• EC2 prices vary from region to region. If you can be flexible about where your EC2 instances live, then taking the time to make price comparisons can pay off.
• Automate turning on and turning off your non-production instances. Many workloads are not required out of business hours, at night and over weekends. Turn them off during these periods to stop paying for unnecessary usage hours.

One last note about instance type notation: until recently, most instance types were comprised of two items, a letter to signify the category and number to signify the generation — for example, C4, C5, M4, M5, etc. These instance types were usually backed by Intel processors. Latest generation instance types now have a third item to mark the type of processor; for example, M6a, M6i, and M6g to identify the AMD, Intel, and Graviton versions of the M6 instance.

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 EC2 instance pricing options.

AWS EC2 pricing: On-Demand pricing

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. On-Demand pricing is continuously computed by the second (with a minimum charge of 60 seconds), even if the prices you see on the AWS site are per hour. Prices vary depending on the type and size of the instance, the region, and the OS.

As an example, the On-Demand prices for an m6a.large instance in the US West (Oregon) region look like this:

• Linux = $0.0864 per hour
• Windows = $0.1784 per hour
• RHEL = $0.1464 per hour

The On-Demand prices for the same instance in the EU (Ireland) region look like this:

• Linux = $0.0963 per hour
• Windows = $0.1883 per hour
• RHEL = $0.1563 per hour

On-Demand offers convenience and is the default pricing option, but it’s also the most expensive option. The flexibility of On-Demand will be worth the higher costs if you are developing and testing unpredictable workloads or applications.

AWS EC2 pricing: Savings Plans and Reserved Instances

A great way to reduce your EC2 costs is to lower the effective hourly rates paid via purchasing commitment-based discounts from AWS. For EC2 these instruments include Savings Plans (SP) and Reserved Instances (RI). In this post, we cover only SPs, which were launched in late 2019 and were designed to be far simpler to manage and typically result in higher total savings compared to RIs. Due to these inherent advantages, most organizations have now shifted to purchasing SPs. It is worth noting however that the overarching principle — committing to ongoing levels of usage to get a percentage discount — of each instrument remains consistent and many of the purchasing details remain the same. For example, the term length and payment options remain the same, and the savings rates are identical (Compute SPs match Convertible RIs, while EC2 Instance SPs match Standard RIs).

Payment options

When purchasing a SP there are three payment options:

• No Upfront
• Partial Upfront
• All Upfront

The more you pay upfront, the higher the savings rate. Whatever you don’t pay upfront is paid monthly over the term of the commitment.

Term length

You choose either a one-year or three-year term when you purchase a SP. The three-year option has significantly higher savings rates — typically at least a 50% higher savings rate compared to one-year depending on the instance type — but requires a higher level of certainty that workloads will still be running over the long term.

Example discount

For example, say you’re using an m6i.xlarge in the US-West (Oregon) region. Paying on-demand for this instance runs at $0.192 an hour. A one-year EC2 Instance SP with partial upfront payment will cost $530 upfront and $44.15 per month for a total of $1,060. That’s an effective hourly rate of $0.121, which equates to a 37% discount compared to on-demand. If such an m6i.xlarge instance happened to run for every hour over the one-year term, then it being covered by this SP would save $622. It’s not difficult to see how this type of discounting can really add up if SPs cover a broad set of usage. It is worth noting that any unused SP hours (a common scenario as workloads come and go) throughout the term are not recoverable, so the effective savings rate can drop below the published figure.

EC2 Instance Savings Plans vs. Compute Savings Plans

The most important decision when purchasing SPs is whether to maximize savings (EC2 Instance SP) or maximize coverage (Compute). Making this decision involves understanding the savings rates on offer and the specific usage you are committing to.

• With EC2 Instance SPs, you are committing to a type of EC2 instance (e.g., m6i) in a specific region. Pricing for EC2 Instance SP maps to pricing for Standard Reserved Instances, meaning they offer the most savings.
• With Compute SPs, you are committing to compute across multiple AWS services, including EC2 and Lambda. For EC2 this means they can “float” across regions and instance types. Pricing for Compute SPs maps to pricing for Convertible Reserved Instances, which means they have lower savings rates than EC2 Instance SPs but offer much more flexibility in the usage they cover.

	Compute SPs	EC2 Instance SPs
Savings over On-Demand	Up to 66%	Up to 72%
Discount applies to	Multiple services	EC2 only
Discount applies to any instance size	Yes	Yes
Discount applies to any OS	Yes	Yes
Discount applies to all instance types	Yes	No
Discount applies to any AWS region	Yes	No

Savings Plans buying tips

• At first, buying SPs 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:
• Remember that SPs are a financial construct and therefore don’t require any engineering action to deliver savings. SPs therefore offer a great option for IT finance staff to reduce costs.
• Savings Plans apply to your entire consolidated AWS bill and will “float” between accounts; therefore, take a global approach to your planning.
• Have your Cloud Center of Excellence or FinOps team dedicate time to this initiative. Get a balanced team of people who bring diverse expertise to the table. Put someone in charge who dedicates a portion of their time to ensure you have the optimum SP strategy.
• Learn the fundamentals. Give everyone a chance to learn about SPs so you can all be on the same page.
• Start small. Start with a few SPs and increase your purchases as your confidence grows.
• Use metrics to drive your success. Some common metrics are:
  • SP coverage rate: What percentage of your EC2 usage is covered by SPs?
  • SP total savings: How much am I saving month to month?
  • SP utilization: what percentage of SPs are getting used versus wasted each month?
• 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.
• Leverage a SP planning tool like IBM Cloudability to drive your coverage and utilization percentages up.

AWS EC2 pricing: Spot Instances

Another option for reducing your hourly EC2 rates are to use 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 to provision your instances on AWS’s excess compute capacity. Prices change depending on supply and demand. When the EC2 instances you want are in high demand in a particular region, 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 a Spot Instance should be structured to minimize the impact of interruptions.

AWS EC2 Dedicated Hosts

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.

Give your EC2 backbone the support it needs

EC2 is the core of many cloud architectures. The better you manage 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. Download our eBook Choosing the Right Amazon EC2 Instances to Optimize Your Cloud for further reading.