In my last blog post on Amazon EC2 Costs, I looked at basic costs for launching various kinds of EC2 instances on AWS. I also broke down these costs by various hardware characteristics to see if some instance types offered better pricing for usage of particular hardware. The answer was an unequivocal “yes.” For example, if you wanted cheap storage, selecting the appropriate Storage Optimized instance could save you one to two orders of magnitude per GB on a yearly basis.

That analysis would be helpful if you already have a basic profile of an application which you want to deploy to AWS, the platform(s) have been chosen, and it is just a matter of making the most cost-effective choices for instances.

However, what if you want to deploy a database solution to Amazon, or any computing solution in general, and want to understand the cost implications? Or you have not yet chosen a platform but want to choose based on hardware costs – in other words, engineer your platform choice to optimize costs running on AWS?

In other words, what is the cost premium for running an alternative operating system like Red Hat Enterprise Linux, Windows, or another OS offered by Amazon versus the base CentOS distribution that is normally deployed?

You might ask – this is not a DB question so what does it have to do with our analysis? Well, your database still has to run on an operating system. So to deploy a DB solution you first have to determine the OS choice and the cost premium that you are willing to pay. Do you want Windows if it is going to cost you $X/year more than an alternative Linux solution? If you are running SQL Server you don’t have a choice, but you do have a choice with other platforms. Also, what is the cost to choose a Linux vendor such as Red Hat or SUSE to handle aspects of support for versus doing it yourawld?

Let’s start by looking at OS cost premiums in dollar amounts:

Well, we can see here that the cost premiums for Red Hat Enterprise Linux and Suse Linux Enterprise Server are both fairly straightforward.

1. RHEL – This will cost you an extra $518.40/year for any micro, small, medium, large, or xlarge instance compared to the base Linux price. It will cost you $1123.20/year more for any 2xlarge, 4xlarge, or 8xlarge instance.
   1. This does not seem like a bad deal compared to Red Hat’s costs for licensing as defined here: https://www.redhat.com/wapps/store/catalog.html
   2. However, when looking at Red Hat’s licensing it appears they have options for Standard and Premium subscriptions, and there is also an option for “Smart Management.” So it’s not clear if what you are paying for with Amazon is equivalent to Red Hat’s “Standard” or “Premium” levels and whether it includes “Smart Management” or not.
2. SLES – This will cost you $86.40/year more for any micro instance, $259.20/year more for any small instance, or $864.00/year more for anything large.
   1. SLES licensing costs here for comparison: https://www.suse.com/products/server/how-to-buy/
   2. SUSE also has various support levels and options, so a more in-depth comparison of exactly what Amazon is giving you for an included SLES license and how it compares to the SLES support levels would be needed.

Windows, however, is a little more complex. I am not surprised by this, as I am sure that Microsoft would not want to let users pay the same thing for a 2xlarge instance as they would for an 8xlarge instance. They would want a more sophisticated licensing model that more closely mirrors their existing model for internal/in-house licensing so customers don’t get a much better per-license cost on AWS than they do in-house. Microsoft licensing is quite complex, as you can see here: http://www.microsoft.com/en-us/server-cloud/pricing-and-licensing.aspx. For now, let’s limit ourselves to understanding if we can find a more consistent pattern to how Microsoft prices themselves on AWS and if there are any guidelines to decision-making that we can find.

There are some other consistent factors that we can see in Windows licensing. ¹

1. We can see that for smaller instances – micros, smalls, mediums, and even a couple of the larges – Windows is actually cheaper to license then RHEL and even in some cases than SLES from an absolute cost perspective. Windows licensing does grow more expensive at a greater-than-linear rate as instance size continues to grow whereas the other licensing options stay constant. In some cases there are also benefits in just having a simpler licensing model to deal with (as in RHEL and SLES) versus having to do more complex calculations.
2. Windows licensing often, although not always, stays consistent on a % basis within a particular Tier Size, Generation, and Purpose. Large and Extra Large Tier Sizes tend to fall in the same group or set for this.
   1. For example, Large and Extra Large generation 4 Compute Optimized instances always charge a 75% premium to license Windows over base Linux.
   2. Large and Extra Large generation 3 Compute Optimized instance always cost 79% more.
   3. Large and Extra Large generation 4 General Purpose instances command a 100% premium.
   4. GPU and Storage Optimized instances are in more of a range, although in both cases the range is within 10% or so.
   5. I don’t know what to say about Memory Optimized instances – this is all over the place. It might correlate to amount of memory in the box.²

Finally, let’s break down hardware costs by OS type in some whisker charts. These visualizations use colors to indicate the instance purpose (e.g. Compute Optimized, General Purpose), and size of the dots indicate overall yearly price. This should let us better understand how much various OSes will cost if we are optimizing for a particular type of computational task which we already know will need more CPU, memory, or storage. Let’s look at: Yearly cost per ECU sliced by OS:

Yearly cost per vCPU sliced by OS:

Yearly cost per memory unit (GiB) sliced by OS:

Yearly cost per storage unit (GB) sliced by OS:

Storage is a bit special because of the large price difference between machine with HDDs/spinning disk and SSDs. HDDs are MUCH cheaper from a $/GB/year basis than SSDs although they are only available in larger instance types. Mixing these in the same whisker chart was throwing off the medians and quartiles in a way that was not representative of the underlying data, so I split them out.

Conclusions from these specific charts:

1. Linux has a significantly lower ECU yearly cost median ($191.52), vCPU cost median ($544.32), memory (GiB) ($246.10), and storage (GB) ($28.73) than any other option. Differences are at least 20% compared to RHEL and SUSE depending on hardware category, and can come close to a 100% difference for Windows. This is not surprising as base Linux omits any software licensing charges.
2. Those of you who are detail-oriented might note that I started including Redshift in these calculations. Redshift has some special instance types associated with it that did not seem to be available as “standard” EC2 instance types, specifically Dense Compute (dc) and Dense Storage (ds.) I thought that it still might interesting to compare Redshift from a hardware price/performance perspective given that our end goal in this series of blog posts is database performance.
   1. Redshift is interesting – from a computing perspective per vCPU or ECU it is moderately expensive, somewhere between double and triple the cost of base Linux. However, per GiB of memory it is very close (only ~5% more) and for storage its only competition are the Storage Optimized instances. Amazon also advertises that you typically get 3x compression on data stored, and these metrics are only for uncompressed data.
   2. There are dangers in trying to compare CPU cycles across platforms and applications, because one application or platform might be able to accomplish significantly more than another with any given CPU cycle. However, we have to start somewhere.

Final conclusions from today:

1. If you just want raw computing power and want to maintain everything yourself, base Linux is definitely the cheapest option ☺.
   1. I realize this may have seemed obvious, but it’s always good to verify.
2. RHEL and SUSE have a relatively simple additional licensing cost model per instance.
   1. The larger the instance, the less additional cost they introduce because their license fees are flat.
   2. Their costs are not exactly the same, but unless you are running thousands of instances, it’s probably not a huge cost difference between the two. Therefore, your choice will probably be determine by other factors, such as what you are already using in-house, current application requirements or needs, or sysadmin voodoo.
3. Windows has a more complex licensing model and scales generally by instance or processor size, although not linearly in all scenarios.
   1. You are definitely going to pay a premium for computing power for Windows on AWS versus other Linux options.
   2. It might be interesting to price out Azure’s options and compare to see if Microsoft has prices encouraging folks to move there from AWS. I have to imagine that is what they would do.
4. As I noted in the last blog entry on this subject, Amazon clearly means it when they label instances by type. You will consistently pay a lot less, no matter the generation nor the tier, for CPU cycles on a Compute Optimized instance. And if you make a bad choice you will pay a lot more than you need to.
   1. The corollary to this is that if you choose General Purpose instances, you won’t pay the most for any given unit ³ – but you certainly won’t get the best deal either. If you start prototyping on a General Purpose instance and are doing computing at any scale, you should quickly profile your application performance and move to instance types which are optimized for your needs.

Things we will try to get to next time (I keep having to push topics into the future when each topic takes longer than I think it will ☺):

1. What is the cost difference between running various databases? In other words, how much more is Oracle going to cost than MySQL or PostgreSQL?
   1. I am only discussing direct Amazon costs here – not additional support or external costs. We would need a more advanced model to price out a whole solution, which we will hopefully eventually get to.
2. For commercial databases such as Oracle and SQL Server, Amazon offers the option to bring your own license (BYOL) or to roll licensing costs into their hourly rates. Is it more cost advantageous to purchase your own license independently, or better to pay Amazon as you go?
   1. This will get interesting quickly, as Amazon would have had to negotiate these licensing costs with Oracle and Microsoft, both of whom have their own cloud platforms and therefore do not have an incentive to provide advantageous pricing for AWS.
   2. This post will only tell you the price premium you pay on Amazon – calculating actual in-house licensing costs for vendors can be a complicated exercise and we will not have space to do this all today. One might almost think that the vendors engage in a “confusopoly.”
3. Amazon includes the possibility to pay for various flavors of SQL Server licensing bundled into the OS costs through EC2. They also allow for one to purchase an RDS instance with the same license costs built in. Does it end up being the same cost to us if we, say, pay for a c4.large through EC2 with a SQL Standard license versus paying through it for RDS? Or is there a difference?

1. One note – Amazon Windows licenses include the option to use Windows Server 2008, 2008 R2, 2012 and 2012 R2. Also note that the Windows Standard Server licensing agreement allows for two physical processors per server license. So, if you have a server with 4 physical processors and were licensing it yourself, you would need to purchase 2 Windows Server Standard licenses. Windows Server Datacenter is a whole different kettle of fish, but Amazon doesn’t allow you to license that anyway. Unless you want to virtualize your virtualization, but I feel like Ice T would have something to say about that.
2. Those of you who are Microsoft administrators might notice that I have not mentioned Client Access Licenses (CALs) up to this point. This is because CAL licensing is the nightmare of every IT manager whose responsibility it is to track licenses. Read this if you don’t believe me. CALs do not seem to be required if you are paying for per-processor licenses, and I believe when you pay Amazon on an hourly basis the nature of the license you are paying for is per-processor. However, Amazon’s website discussing Windows on AWS does not specifically dig into the CAL issue.
3. With a few exceptions for outlying small and medium instance types in some situations