1

— T H E C O M P L E T E G U I D E —

SAVING WITH AWS RESERVED INSTANCES

2

Table of ContentsINTRODUCTION 3

PART I: THE BASICS 4What is a Reservation? 4Why Make a Reservation? 4Reserved Instance Pricing and Types 6How Reservations are Applied 8Modifying Reserved Instances 9The Reserved Instance Marketplace 11

PART II: CALCULATING RESERVATION NEEDS 12

PART III: PORTFOLIO MANAGEMENT 14The Anatomy of a Purchase 14Lifecycle Management 15Conclusion 19

3 3

If your company is buying Reserved Instances, you’re making a huge investment. This investment has the potential to save you a significant amount of money on your Amazon Web Services infrastructure—but a misstep can rob you of any ROI, and even cost you desperately.

Reserved Instances are clearly complex, but they shouldn’t be feared. It’s imperative that businesses looking to save money on their cloud bill familiarize themselves with RIs, which truly are the most significant cost saving tool that Amazon provides. When used correctly, RIs can produce truly invaluable savings; when used incorrectly, they can devastate your budget.

It’s first important to know the basics of RI application. Then, read on for the math of calculating Reserved Instance needs, and strategies for managing your portfolio.

INTRODUCTION:The Complete Guide to Saving with AWS Reserved Instances

4

1What is a Reservation?A Reserved Instance is a reservation of resources and capacity, for either one or three years, for a particular Availability Zone within a region on Amazon Web Services. Whereas standard on-demand resources only require that you pay their hourly rate for the number of hours that you use them, a reservation purchase represents a commitment to pay for all of the hours of the 1- or 3-year term, regardless of whether you use those resources during that time. In exchange, the hourly rate for the resources is lowered significantly.

Furthermore, when you purchase a reservation, you’re not just getting cost savings; you’re also reserving the capacity that you need in that particular Availability Zone.

Did You Know?When people talk about Reserved Instances, they tend to focus on EC2. However, Amazon also offers reservations for databases; it’s important to take the database side into account, as this is another easy source of cost savings.

Why Make a Reservation?The primary reason for making a reservation is that reservations feature substantially lower prices than On-Demand prices, which allows you to lower the cost of the resources you’re already using.

Reason 1: SavingsFirst, RIs are an excellent tool for cost savings; using them can lower the cost of resources you’re already using, by allowing you to pay a lower price upfront than the price you would pay on demand. There are more than 2,000 types of RIs, each with their own break even point— the point where you have gotten enough usage out of the reserved capacity to make up for the upfront cost you paid. You can save up to 65% by using an RI.

Question: How do you define utilization rate?An instance is being utilized when it is in a running state. As such, an annual utilization rate of 20% for an instance reflects that 20% of the hours of the year, this instance, or an instance that meets the appropriate criteria, was running. An RI can only be applied to a running instance.

PART I: THE BASICS

5

2Reason 2: Reserving Capacity The second reason primary reason for making a reservation is to reserve capacity in your chosen Availability Zone.

Instances on AWS are divided across several geographical areas, called regions. The west coast of the US, for example, has two regions: US-West-1, in Northern California, and US-West-2, in Oregon. Each region contains several AZs, or Availability Zones, which are distinct locations within that region. AZs within the same region are connected through low-latency links, but each has its own power and cooling systems, and operates independently from other AZs.

Code Name

ap-northeast-1 Asia Pacific (Tokyo)

ap-southeast-1 Asia Pacific (Singapore)

ap-southeast-2 Asia Pacific (Sydney)

eu-central-1 EU (Frankfurt)

eu-west-1 EU (Ireland)

sa-east-1 South America (Sao Paulo)

us-east-1 US East (N. Virginia)

us-west-1 US West (N. California)

us-west-2 US West (Oregon)

Having capacity reserved in a specific Availability Zone can be particularly useful if your infrastructure uses autoscaling and frequently experiences spikes in usage.

Example: If you’re running a social networking app with most of your infrastructure in US-East 1A, you will hopefully begin to see massive spikes in usage as your app gains popularity or goes viral. Generally, your app would autoscale to suit these new needs. However, this won’t work if there’s no more available capacity in that Availability Zone. If you have a Reserved Instance in that AZ, that capacity is reserved and your crisis is averted.

Although it is usually available for reservations, Amazon does not guarantee the capacity— it does, however, put you first in line.

Question: To what degree in a real world setting can capacity issues be a problem?Amazon is good at staying on top of things, so it’s not frequent. The bigger issue is with apps that are incredibly spiky in usage; for example, those which may go from ten instances to 1,000 in order to handle some sort of peak demand. In cases where you’re looking at such a significant increase in usage, it’s important to ensure that you have some capacity guaranteed.

6

3Reason 3: Failsafe for OutagesThe third reason for purchasing a Reserved Instance is a newer trend; businesses are beginning to reserve capacity in other regions just in case.

This would be useful if demand caused a run on capacity in a particular Availability Zone. In such a scenario, you may find yourself needing to move from US-east to US-west as a result of an east coast hurricane. If you’re in that boat, chances are that other people are too, and the result will be a sudden heightened demand for US-West. A reservation in US-east would save you a spot at the front of the line.

The cheapest way to use reservations this way is to have some All Upfront reservations sitting in US-West. You may be using them you may not, but it’s the cheapest available insurance policy to give you a leg-up if there’s ever a run on capacity.

Reserved Instance Pricing and TypesReservations, unlike on-demand instances, do not charge according to varying hourly usage. Instead, the instance is reserved for every hour of the duration of the reservation (either one or three years) and a comparably low usage fee for each of those hours is charged as a combination of upfront and monthly increments, depending on the reservation type:

All Upfront: Pay for the entire reservation term in one upfront payment. This payment option offers the highest savings rate.

Partial Upfront: Pay for part of the reservation term in an upfront payment, then pay the remainder in monthly installments. This option costs more than All Upfront, but less than No Upfront.

No Upfront: Pay for the reservation in monthly installments throughout the term’s duration. This payment option offers the lowest savings rate.

Which of these three payment options you choose will depend on your company’s cost of capital; the more you’re able to pay upfront, the higher your

7

savings rate will be. But no matter which option you choose, you commit to paying for 1 or 3 full years of usage upon making a Reserved Instance purchase. Then you hope to first break even, then to generate savings, by using that reservation a certain amount of the time. For most one-year reservations, the break-even point is between 50-80%. This means that if your instance is running for that much time or more, your decision to purchase an RI saved you more money than a traditional on-demand cost model would have.

For example, imagine you have an m3.xlarge running Linux, Us-East. Your on-demand rate for that would be about 28 cents an hour. If you bought a 1-year Partial Upfront reservation, you’d pay about $886 as an upfront fee, and an additional $54.02 each month. This results in an effective hourly rate of 18 cents an hour if you use the reservation 100% of the time, which represents a 38% savings rate over on-demand. However, that’s assuming that you use the instance all the time.

Even if you only use the instance 50% of the hours of the year, you’ll still have to pay the full $855 upfront fee and $54.02 monthly fees. This means that your hourly rate is effectively 36 cents an hour—which is more than on-demand would cost.

Obviously, this means that using reservations requires a firm understanding of where the break even point is and a confidence that your usage will be above that point. In the above example, that point would be just around 75%.

1

500

1k

1.5k

2 3 4 5 6 7

Months

CASHFLOW COMPARISON CHART

On Demand RI Cost

Cost

($)

8 9 10 11 12

If you’re not confident that you will maintain that level of usage for an extended period of time, then using a reservation can be a risky proposition.

8

How Reservations are AppliedReserved Instances are purchased according to four variables: instance type (e.g. m1 xlarge), Availability Zone (e.g. us-east-1a), operating system (e.g. Linux). Together, this specific combination of variables (type, AZ, and OS) is referred to as its “instance class”: for example, the “instance class” of a particular reservation might be “m1 xlarge in us-east-1a running Linux.”

A Reserved Instance is applied according to its class; that is, its discount can apply to any running Instance that matches the its instance type, Availability Zone, and operating system during a given hour.

Example: If you purchase an RI for m1 xlarge in us-east-1a running Linux, Amazon will scan your infrastructure at the end of each hour to determine if you used an m1 xlarge instance in us-east-1a running Linux. If you did, the discounted reservation applies. If you didn’t, it doesn’t.

When purchasing a reservation, you also choose between classic or VPC network. However, the network platform selected for a reservation doesn’t impact where its savings apply; it will only apply to the capacity aspect of the reservation (this is why the

Cloudability Reserved Instance Planner, which aims at savings, doesn’t differentiate between classic and VPC). The classic network platform is deprecated in any case, so all future infrastructure will be running inside VPC. But if you feel the need to reserve capacity in classic, this should be taken into account.

Remember: you are never purchasing a reservation for a particular instance ID; you are purchasing it for a particular instance class.

Reservation Application with Consolidated BillingReservations automatically transfer between linked accounts in a consolidated billing structure. This means that if no instances from the purchasing account qualify for a reservation during a given hour, the savings will still apply to a qualifying instance from a linked account. Furthermore, reservations purchased at the master level will be applied with equal preference throughout the linked children.

However, while you can inherit cost savings, you can’t inherit the capacity reservation; all of the capacity benefit stays in the account in which you purchased it in.

9

Modifying Reserved Instances As your infrastructure changes and grows, you may need to make changes to your Reserved Instance portfolio to ensure that you have as much RI coverage as possible. While there are some aspects of a reservation that can’t be changed, Amazon does allow its users to re-allocate their reservations for free according to these three parameters.

Modifying AZs Within a Region Reservations may be moved across AZs that are in the same region; for example, from US-West-2a to US-West 2b. They may not be moved across regions; a reservation in US-West-2a can’t be moved to US-West-1a.

Code Name

ap-northeast-1 Asia Pacific (Tokyo)

ap-southeast-1 Asia Pacific (Singapore)

ap-southeast-2 Asia Pacific (Sydney)

eu-central-1 EU (Frankfurt)

eu-west-1 EU (Ireland)

sa-east-1 South America (Sao Paulo)

us-east-1 US East (N. Virginia)

us-west-1 US West (N. California)

us-west-2 US West (Oregon)

You may want to make Reserved Instance modifications across AZs to align with changes in your instance population. If a project hosted in EU-West-1a is discontinued and your focus shifts to a new project hosted in EU-West-1b, you may find that your reservation in EU-West-1a will see more use in EU-West-1b.

Modifying Size Within an Instance FamilyAWS offers its users a variety of instances to choose from, each specialized for different compute, memory, and storage roles. Instances are grouped into “families” according to each role, and then differentiated into individual types according to the size of the instance within that role:

t2 m1 m2 m3 c1 c3 c4 r3 i2

microsmall

medium

smallmedium

largexlarge

xlarge2xlarge4xlarge

mediumlarge

xlarge2xlarge

mediumxlarge

8xlarge

largexlarge

2xlarge4xlarge8xlarge

largexlarge

2xlarge4xlarge8xlarge

largexlarge

2xlarge4xlarge8xlarge

xlarge2xlarge4xlarge8xlarge

Any reservation running on a Linux OS can be modified to a different size within the same instance family to accommodate changes in infrastructure. Making those changes comes down to ensuring that when you make a change, your overall “size footprint” remains the same.

10

The size footprint is the combined total of your reservations’ “normalization factors.” The normalization factor is a number assigned to an instance, used to compare instances’ value relative to each other. The larger the instance size, the higher the normalization factor; the smaller, the lower. The point breakdown looks like this:

Instance Size Normalization Factor

micro 0.5

small 1

medium 2

large 4

xlarge 8

2xlarge 16

4xlarge 32

8xlarge 64

In order to determine the total size footprint of a group of reservations, simply add up all of the “normalized instance units”— the normalization factor values— into one big number.

Example: To calculate the size footprint of two m1.mediums (each with a normalization factor of 2) and one m1.large (with a normalization factor of 4) you would add 2 + 2 + 4, and get a size footprint of 8. You can modify those three reservations into any number of differently sized instances within the m1 family, so long as their total size footprint remain equal to 8; this could range from eight m1.smalls to a single m1.xlarge.

So long as your size footprint remains the same, AWS Reserved Instance modifications won’t impact your bill. This is because reservations are priced proportionally to each other, just like normalization factor. An m1.small reservation, with a normalization factor of 1, costs exactly half as much as an m1.medium reservation, with a normalization factor of 2.

It’s important to remember that you can only modify the size of reservations that are running on Linux, and only within the same instance family; you can’t modify reservations on an OS other than Linux, and you can’t modify reservations from the m1 family into reservations to the t2 family, for example.

There are a few reservation types which may not be resized because they are the only available size in a family. A list of these instances is available on Amazon’s website.

11

Modifying Between Classic and VPCYou can modify any reservation running on a Linux OS instance between EC2-Classic and EC2-VPC. “Classic” refers to infrastructure run on the standard AWS EC2 cloud platform with pre-configured template, and is a useful model for many companies, particularly at earlier growth stages. VPC, or “Virtual Private Cloud,” offers a more customized networking experience, and is isolated from the rest of the AWS network— a security benefit which, alongside VPC’s customizability, appeals to many later-stage businesses.

As businesses scale, they are often motivated to migrate their infrastructure from Classic to VPC in order to build a more mature infrastructure. When the resources in a business’s infrastructure are moved to VPC, the discounted rate provided by any existing reservation can apply to instances on either platform, but the capacity reservation will be limited to the platform for which it was purchased. As such, you should be sure to make those Reserved Instance modifications accordingly when moving between Classic and VPC.

The Reserved Instance Marketplace If you have reservations that aren’t being used and which can’t be made more effective through modification, you can recoup some—though not all—of the initial purchasing fee by selling them in the Amazon EC2 Reserved Instance Marketplace. There’s no guarantee that your reservations will be bought if you put them up for sale, but if you have a significant number of reservations that won’t save you any money if kept, giving it a shot can be your most cost-effective option.

12

One of the most common mistakes when purchasing AWS Reserved Instances is calculating your RI needs according to overall utilization rate over a given period of time. However, this is an inaccurate calculation method with the potential to misinform your RI purchases. The best RI purchasing decisions are based on hourly instance counts of each instance type per availability zone.

In this example of how to calculate reservation needs, we’ll pretend that a month has ten hours in it. Just to make our lives a bit easier.

This table breaks down the hour of the month and how many instances your hypothetical business had running each of those hours. The first hour of the month you had four, the second six, the third zero, etc. This is relevant because RIs are applied at an hourly level.

Hour of Month Running Instances

1 4

2 6

3 0

4 5

5 7

6 8

7 5

8 3

9 12

10 3

Once you have this information, you need to break it into an hourly frequency distribution of instance levels. This allows you to look at the running instance count for each hour, and the frequency with which each count occurs.

Did You Know?This is what our software does behind the scenes when we make an RI recommendation with our Reserved Instance Planner.

PART II: CALCULATING RESERVATION NEEDS

13

Running Instance Count

Frequency of Occurrence Freq. %

0 1 10%

1 9 90%

2 9 90%

3 9 90%

4 7 70%

5 6 60%

6 5 50%

7 4 40%

8 2 20%

9 1 10%

10 1 10%

11 1 10%

12 1 10%

In this example, there was one hour of the month in which zero instances were running. Since this is a 10 hour month, that translates to 10% of the time. There was at least one instance running nine hours of the month, so 90% of the month. At least five instances were running six hours of the month, or 60%. etc.

When buying RIs, you want to look at the percentage of time that a particular instance count occurs during the month. This is, like our 10-hour month, over-simplified—but let’s say 60% is the break even point for an All Upfront RI. Five instances meet that criteria, so you would purchase five All Upfront RIs.

Running Instance Count

Frequency of Occurrence Freq. %

0 1 10%

1 9 90%

2 9 90%

3 9 90%

4 7 70%

5 6 60%

6 5 50%

7 4 40%

8 2 20%

9 1 10%

10 1 10%

11 1 10%

12 1 10%

Breakeven Point

This is a complicated process. However, it is immensely important in calculating Reserved Instance needs accurately. Here’s why: say that you have three instances that are running 30% of the time. That may not seem like enough usage to warrant an RI purchase—but what if they’re all running at different times? If the instances don’t overlap in when they’re running, you can cover all three with one reservation; this is because between the three of them, you’re effectively seeing a combined 90% utilization.

Unfortunately, very few businesses take the time to look at things this way. It’s very common for people to look at an aggregated level of utilization, and then buy RIs accordingly. If you did that for three instances that were not running at the same time and didn’t buy an RI for those instances, you’d be throwing money away on needless on-demand spending.

Breakeven Point

14

The Anatomy of a PurchaseMost companies tend to oversimplify their Reserved Instance purchasing strategy, which means they end up paying more than they need to and saving a lot less than they could. Maximizing those savings requires approaching Reserved Instances with the complex, iterative process they require.

General RecommendationsWhile the class of Reserved Instance you purchase will depend on the makeup of your infrastructure, there are several purchasing practices that we’ve seen to be very effective in maximizing savings.

As we discussed in Part I, a Reserved Instance can be purchased for a 1- or 3-year term. Many businesses shying away from buying a 3-year term due to concerns that their infrastructure will change; however, 3-year terms offer greater savings rate over 1-year, and have break even points that generally occur fairly

early in the term, often relatively shortly after that of a 1-year. So long as you’re confident that your instances won’t change until the break even point has passed, you stand to save more through the use of 3-year over 1-year—which is why we generally recommend opting for 3-year reservations.

Did You Know?The Cloudability Reserved Instance Planner calculates the break even point of each reservation it recommends.

In addition to the term duration, you’ll also have to choose between All Upfront, Partial Upfront, and No Upfront reservation types, which offer different savings rates in exchange for different payment plans (as we discussed in Part I). The more capital you’ll have available to commit towards your purchase, the more you can save—however, these reservation types also differ in how their purchase is reflected in your billing data. This difference makes it far easier to measure waste and coverage when using No Upfront or Partial Upfront Reserved Instances.

PART III: PORTFOLIO MANAGEMENT

15

No Upfront and Partial Upfront Reserved Instance types are charged via a special section in your billing file called the “Injected Line Item,” which provides information about how many reserved hours you’ve paid for, how many you’ve used, and how many you haven’t used. You can use this information to report on waste and coverage, which is critically important in building a Reserved Instance portfolio.

The savings rate for an All Upfront reservation is slightly higher than that of a Partial Upfront reservation—but when you consider the advantages of having waste and coverage reporting capabilities, Partial Upfront is a wise investment. For these reasons, we recommend purchasing 3-year Partial Upfront reservations when able.

The First PurchaseWith your first Reserved Instance purchase, you should generally aim to make the biggest dent possible in your on-demand spending with minimal risk. In other words, you should look to cover your most consistently used instances that won’t get turned off.

You can use the Cloudability Reserved Instance Planner to generate purchase recommendations, then identify the projected savings rate of each recommendation (“savings rate” refers to the

percentage of Reserved Instance savings compared to on-demand). Look for recommendations for instance types that you’re unlikely to change within the next three months, where the savings rate is the highest.

You’re looking to do the most damage with the smallest possible purchase; as such, avoid the temptation to overbuy initially. Buying too many reservations now might cause you to be stuck with the wrong ones when your engineering team invariably needs different resources a few months from now. It can also introduce additional complexity to your buying process—larger buys require deep conversation with engineering/ops and finance/exec (to ensure that you’re buying the right types of instances, and to get approval on the upfront expenses, respectively). For big buys, it’s not uncommon for a full quarter to pass between identification of recommendations and execution of the actual purchase. So for now, keep it simple.

Purchase Timing and FrequencyIf your AWS infrastructure remained the same for a year straight, you could cover the whole year with one bulk Reserved Instance purchase. The reservations, bought according to your instance profile at the time of the purchase, would continue to cover all of your instances at a reduced rate— with no changes, you’d have no need for additional reservations. However, reality is

16

rarely so simple; and as such, you’ll find that making a reservation purchase every month can help ensure comprehensive coverage of your changing infrastructure and garner the greatest savings over on-demand.

By making monthly reservation purchases, you can account for infrastructural changes sooner. If you start using some new instances, you don’t have to wait months for your next Reserved Instance purchase to stop paying for them on-demand; you can simply cover them as part of a modest reservation purchase the very next month. Just as your needs are always changing, your selection of reservations changes too.

On-demand Annually Quarterly Monthly

Total Cost $309,053 $205,209 $134,900 $95,854

Discounted Hours 0% 48% 92% 100%

Savings 0% 34% 63% 69%

While it’s clearly important to buy reservations iteratively, it’s also important that you focus on more than one aspect of your infrastructure each month. The reason why is best explained through an example: Imagine that you buy all of the reservations for RDS instances one month, then all of the reservations that run your web service the next month, etc. Doing so locks in the footprint of that subsection of your infrastructure for the duration of the reservations that

you bought for it; if you need to upgrade or change an aspect of that subsection, you’re faced with the same dilemma that you’re apt to face when doing yearly bulk purchases: do you hold off on making potentially great changes to your infrastructure, or do you make the changes and lose out on Reserved Instance savings?

Ultimately, the Reserved Instance purchasing pattern that will allow for the greatest savings without restricting infrastructural growth is that of buying a cross-sectional assortment of reservations every month—to refresh every aspect of your infrastructure every month, bit by bit.

Lifecycle ManagementMaximizing your Reserved Instances requires more than just smart purchasing; it also requires continued attention to the reservations once you own them. If your reservations aren’t being used, it’s important to take note and act—otherwise, your investment won’t pay off.

There are two metrics you should monitor for an ongoing sense of the state of your current reservations: your current RI coverage, and your current RI waste. You’ll aim to push the coverage up and waste low, through modifying your existing reservations and purchasing new ones. You can monitor these values in Cloudability.

Impact of purchasing frequency on yearly savings rate.

17

Monitoring and Increasing Reservation CoverageYou can calculate your reservation coverage by comparing your total EC2 usage hours (both reserved and on-demand) with your total hours covered by a reservation. In a Cloudability report on these metrics, we also overlay the Reserved Utilization Rate metric, which shows the percentage of EC2 hours covered by Reserved Instances. Given the elasticity of cloud environments, many companies strive to reach a Reserved Utilization Rate of 80-90%.

In the above chart: “Usage Hours” represents total EC2 hours, Reserved Hours represents the number of hours covered by Reserved Instances, and Reserved Utilization Rate represents the percentage of the total EC2 hours covered by Reserved Instances.

There are several ways to raise your reservation coverage. You can buy new reservations, modify existing underutilized reservations, or even change your existing infrastructure to match your existing underused reservations. A good first step is to run a Cloudability Reserved Instance Planner report and implement the recommended reservation modifications—this is a process that we recommend undertaking every month, alongside new reservation purchases.

Monitoring and Minimizing Reservation WasteReporting on and minimizing your reservation waste (that is, pre-paid reservation hours that have gone unused) is key towards making the most of your investment and maximizing savings. While you can report on reservation waste in several different ways, there are two common ways to visualize it.

First, you can graph your unused reservation hours com-pared to the total cost of the recurring reservation hours.

18

In the chart above, Unblended Cost represents the cost of unused RI hours each month. Total Invoice Cost represents the cost of all RI hours for the month. You’ll note that in July an RI purchase was made pushing up the Reserved Utilization Rate but the Unblended Cost (i.e., the unused RI hours) barely increased. This indicates a successful purchase.

Another effective way to visualize Reserved Instance waste is to build a table showing the total number of reservation hours you’ve paid for but not used, their cost, and the instance type or account name.

In this example, the first two metric columns (Unblended Cost and Usage Quantity) represent the unused portion of the RIs while the Total Invoiced Cost (Blended Cost) represents the total cost of the RI hours for the month.

Like Reserved Instance coverage, there are several ways to impact your Reserved Instance waste. Identifying and modifying underutilized reservations can help reduce waste free of charge; we recommend running a Reserved Instance Planner report and implementing the recommended modifications every month. If cost-effective, you can even change your existing infrastructure to match your unused or underused reservations.

Keeping the Data Front and CenterRegularly checking on your Reserved Instance usage to ensure that you’ve got the coverage you need is key to keeping your reservations closely aligned with your

19

infrastructure—and vital to maximizing savings. We recommend adding a Reserved hours vs on-demand hours widget to your Cloudability Dashboard, so that you can take a look at your coverage every time you log in.

This widget will display what portion of your usage hours (the dark blue area) are on demand (the light blue line), in addition to displaying your Reserved Instance utilization rate (the green line, displayed as a percent per the numbers on the Y-axis on the right). If your data looks like the widget above, you’ve got some considerable gaps in your portfolio! If you don’t own many RIs, it’s time to get more—and if you do, they aren’t being used. Time to take another look at the Planner and check for Modifications.

If your widget displays a high Reserved Utilization Rate and a minimal number of On Demand Hours, congratulations! Your work is paying off, and your Reserved Instances are well on their way to serious savings.

ConclusionNothing can save you money on your AWS bill like Reserved Instances. And whether you’re spending millions on Reserved Instances already or are ready to make your first purchase, you’ve learned all the fundamentals you need to use them wisely. It will require company-wide buy-in—but investing the time and energy into making the most of savings tool is key towards enabling productive, cost-efficient growth.

The cloud is a powerful tool: yield it well.

20

About Cloudability

Your AWS costs are too complex to manage with spreadsheets, and too important to leave to chance. Let Cloudability collect, store and analyze all of your AWS cost and usage data. Then use our powerful Analytics tools and Reserved Instance Planner to create and share reports with anyone in your organization.

Thousands of AWS users including Adobe, Uber, and GE have used Cloudability to manage more than $2BN in cloud spending, and those numbers are going up every day.

Want to Find Out More? Check out cloudability.com and start a free, 14-day trial.