Amazon Pricing Should Be Customer-Centric

Published: by

Today, I had a very interesting discussion with Rich Miller, a consulting colleague who has been around the block more than a few times.

One of the interesting points he raised is that Amazon's AWS pricing doesn't quite work for enterprises.

Let's explore how it is a problem and why it is so.

At first blush, Amazon's pricing is intuitive: use an hour of an m4.xlarge, pay $0.239; use 2 hours, pay $0.478; use a whole month's worth, pay $0.239*720 = $172.08.

Of course, if I know I am going to use that m4.xlarge (or a lot of them) for a whole year, I should be able to get a discount for committing. Indeed, Amazon offers that type of commitment pricing, with varying discounts that depend on if you commit for one year or three years.

This type of pricing seems to make sense. Amazon knows it will get paid to provide 8,760 hours of that m4.xlarge for the year. In exchange for that knowledge and its ability to plan, it can afford to give the committer (you) a decent discount.

What's the problem with it?

If you are a small startup or business, not much. You figure out that you need 2x m4.large, 5x t2.small, several others, and just commit.

But enterprises don't work that way. Enterprises are orders of magnitude larger than those small companies. They use hundreds, if not thousands, of each instance type.

To provide for these "elephant" use cases, Amazon has a sales team that is authorized to negotiate appropriately-priced deals, much larger discounts on the listed prices, or "rack rates".

However, the pricing remains built around the instance types you order.

The reason is that Amazon sets its prices to suit the vendor, rather than to fit the customer.

An enterprise is not a small business with an application that just happens to be 3 orders of magnitude larger. An enterprise is a diverse conglomerations of multiple divisions and their many applications, some of which are quite large, others very small, and everything in between.

Enterprises are not a large business; they are a dynamic ecosystem of businesses.

As a dynamic ecosystem, their needs change over time, sometimes from day-to-day, but certainly within the timeframes of AWS commitments. It is nearly impossible for an enterprise to know upfront that it will need 100,000 hours of m4.xlarge and 2,500,000 hours of t2.small.

What they do know is that they will spend roughly the equivalent of 100,000 * m4.xlarge + 2,500,000 * t2.small over the next year. However, from the enterprise's perspective, as a customer, they want to buy those as units of committed general usage, not committed specific usage.

What would buyer pricing look like? Surprisingly, it is much simpler: For $100,000 in annual committed total spend, get a 10% discount; for $1,000,000, get a 25% discount; etc.

The actual thresholds and discount ratios need not be those listed above, but the principles hold. This has several distinct advantages:

  • Like all transparent pricing, it eliminates a lot of the effort, or friction, of signing up large customers
  • It makes it possible for Amazon to eliminate a lot of the sales labour effort
  • Most importantly, it makes the pricing model fit the customers

So why doesn't Amazon do it? I suspect several reasons:

  1. It involves bearing the usage risk
  2. It requires a lot of effort to migrate that risk
  3. It requires thinking as a customer, rather than as a vendor

Mindsets can be changed over time. Risk of instance supply-demand mismatch is an issue, but the reality is that customers are absorbing this risk every single day. It is costing them time and money to figure out how much of each to buy. Make it easy for them, and they will buy more.

Of course, every service for a customer - of which removal of risk and effort is one - is a business opportunity. Amazon can - and should - build it into the pricing. Enterprises happily will pay a slightly lower discount in exchange for the flexibility such a model provides.

Summary

Your pricing should match your customers' needs, not your supply structure. If providing that kind of pricing model means you absorb risk and effort from our customers, it is a revenue opportunity; build it into your pricing.

Does your pricing reflect your customers' needs? Ask us to help.