Understanding Cloud Pricing Part 2: Local SSD

Since publishing our Understanding Cloud Pricing blog post, one of the most frequent follow up requests (please keep your great questions and ideas coming!) has been a closer look at storage costs and performance, especially in areas where our products work a little differently from other cloud services.

Solid State Disk (SSD) is an incredible technology, but it’s really important to realize that the wide variety of devices, configurations, connectors, and drivers can create order-of-magnitude or larger differences in performance. Not all Solid State Disks are created equal.

Additionally, different cloud providers deliver SSD in very different packages. Once again, rather than just reciting the stats and leaving the real-world analysis to you, we're going to provide a clear example of a system that uses local SSD, and analyze the difference between running it on Google Cloud Platform and AWS.

Let’s imagine that we’re going to deploy a NoSQL key-value store backend for a web-scale application, similar to what we used in our first example. We’ll use conservative best practices and deploy a three-node cluster, hosting data on local SSD for maximum performance.

On Google Compute Engine, we’ll use n1-highmem-8 instances, with four attached local SSD volumes, which is almost identical in CPU, RAM, and SSD storage volume to the AWS i2.2xlarge instance. We’ll be set up to deliver at least 75,000 IOPS, blazing fast queries here we come!

Please note that we completed these calculations on April 3, 2015, and have included the output prices in this post. Any discrepancies are likely due to pricing or calculator changes following the publishing of this post.

Here's the output of the pricing calculators:

Google Cloud Platform estimate:
Monthly: $1883.04

Amazon Web Services estimate:
Monthly: $3744.18

You’ll notice that Google Cloud Platform comes in quite a bit cheaper. Some of that’s due to our automatic Sustained Use Discounts, but even without those, we’re still 39% less expensive. Here’s all the details by the numbers:

• i2.2xlarge advantages:
• 17% more memory
• 7% more SSD space
• n1-highmem-8 with 4 attached SSD partitions advantages:
• 39% less expensive
• 807% more read IOPS
• 380% more write IOPS

So what impact does this have for our NoSQL workload? Assuming a read-bound workload growing over time (many are, like reporting and analytics systems), as read capacity on the SSD in our instances gets exhausted, we’ll need to scale out our cluster by adding additional nodes. Let’s imagine read traffic multiplies by six (product success is a good problem to have).

Here's the output of the pricing calculators:

Google Cloud Platform estimate:
Monthly: $1883.04 (yup, exactly the same as above)

Amazon Web Services estimate:
Monthly: $22465.08

In order to equal the read throughput of our SSD, on AWS you’d need to step up to the next larger size instance (i2.4xlarge), and run three times as many of them. The extra read performance that Google Cloud Platform SSD provides means you not only keep the same, simple three-node system (saving you *real money* in admin/ops costs), but you keep the same low price. If you have a write-bound workload, you’d enjoy a similar advantage in picking Google; we’re nearly 4x the write performance, so you’d need to bump up your configuration similarly to keep pace.

What if you’re trying to get started smaller than where we started? Every app does not need 680k IOPS! This is one of the most important differences between Google Cloud Platform’s SSD implementation and the AWS instances: You can add SSD to standard, highmem, and highcpu instances in 375GB increments. This means that you can start on highly efficient SSD and scale more linearly. It’s important to note that AWS does include some small single-copy SSD on instances for use as an efficient scratch disk; these aren’t designed for heavy data usage and AWS does not provide a documented performance specification.

Because SSD is available on all of our primary instances, you can easily configure a much smaller instance type and still keep the power of local SSD. Let’s go down to the smallest three-node configurations we can get on each provider that still give us access to full performance SSD. For us, that’d be n1-standard-1 instances with 1x375GB local SSD, for AWS that’d be i2.xlarge instances with 1x800GB local SSD.

Here’s the output of the pricing calculators:

Google Cloud Platform estimate:
Monthly: $341.90

Amazon Web Services estimate:
Monthly: $1873.20

That’s a huge discrepancy. On Google, this system is so cost efficient, you can run it for 3 weeks and stay within our free trial with room for lots more experimentation!

Comparing Prices for SSD specifically

However, using publicly published AWS documentation, it’s possible to derive a price for EC2’s local SSD by comparing configurations and prices of similar instance types that differ only in price and amount of SSD. All configuration information comes from the EC2 instance type web page and all pricing information comes from the EC2 instance pricing page. In all cases, we use the on-demand prices in Northern Virginia.

The methodology is basically to compare r3 (memory optimized) and i2 (storage optimized) instance types. By grouping them together in pairs that have the same amount of CPU and memory but different amounts of SSD and different prices and dividing the difference in SSD capacity by the difference in price, you can derive the per-GB local SSD price that AWS charges its customers. Each of the four r3/i2 pair comparisons yields a local SSD price of $0.0007/GB/hour.

By comparison, we sell Local SSD in 375GB chunks for $0.218/GB/month. Normalizing that to hourly pricing, we get $0.0003/GB/hour. So there’s the bottom line: we charge 57% less for local SSD that’s at least 4.8x faster than AWS.