Its Up to You to Decide if Apps are Cheaper in the Cloud

Whenever I talk cloud with a customer, there is inevitably a discussion around how much the cloud costs vs what is in the data center. The conversation usually starts with one of several declarations.

Well yes, if you’ve paid attention, those are two different arguments about why you need cloud, and both of them came to different conclusions about whether or not the public cloud is more expensive or less expensive than running your own data center.

This post is designed to show a simple example of how the public cloud is both more expensive and less expensive, but it depends on your application architecture.

An Example with IaaS

For the example I’m about to use, I’ve chosen a sample three-tier application that might be running on a hyper-converged solution on-premises. It includes web, app, and database virtual machines and for simplicity have all been sized at 2 vCPUs, 8 GB of virtual memory, and 30 GB of disk.

Now before I go any further, I know that a HUGE benefit to cloud is a switch to PaaS offerings which can drive down TCO because we don’t need to maintain the underlying pieces, but I’m ignoring that argument for this example. Trust me, it IS a consideration if you’re moving to cloud. For this example IaaS is being used, because you can much more easily do IaaS on-premises than PaaS and I’m trying to show a close equivalent to the app in the cloud regardless of if you swap in PaaS for parts of it.

So the first step in this example is to estimate the on-premises costs for our virtual machines per month and the equivalent on AWS for the same sized VMs. Assume we’re about to do a “lift and shift” for those VMs. Lets see what the costs broke out to be.

So the on-premises VMs came out to about $25 per month for a 2 vCPU / 8 GB vMem / 30 GB vDisk on a popular hyper-converged solution. We then used the AWS pricing calculator to determine what those same sized VMs would cost on AWS with the standard on-demand hourly pricing. You can see that the public cloud is in fact more expensive if you run your infrastructure this way.

I also want to note that the price on-premises doesn’t include data center overhead such as physical security, HVAC, power, property taxes, etc. It only counts the hardware it runs on. Those items are tough to calculate since every region has different power prices, data centers are different sized so cooling is hard to calculate, etc., so we’ve ignored them. Clearly the price of the instances in AWS have these additional items included in the price so the AWS price looks inflated already, but you get the idea.

Now, lets start making some changes to the application in AWS to take advantage of its features while still keeping the application IaaS based on EC2 only.

Add Reserved Instances

The simplest way to decrease your costs is to add a Reserved Instance (RI). An AWS RI is a way for you to commit to running this instance long term and you can get a discount. These RIs come in 1 year or 3 year terms and since the calculations for the on-premises VMs used a three year depreciation schedule, I’ve used a three year RI to see what happens to the price. Note that no architectural changes were made to the app at this point.

We didn’t do anything other than commit to running these instances full time for the next three years and purchased an RI. You can see the price of those AWS EC2 instances came way down and they are almost as cost effective as the VMs on-prem now. If you factor in the data center overhead, they probably are more cost effective now but based on our premise, we’re still cheaper to run on-premises than in the cloud.

Change the Architecture

Lets make one more change to our application to add in some elasticity to the application. This is still an IaaS play because we’re only running on EC2 instances. Meaning, we haven’t swapped out the application server with Lambda [serverless] functions, or the database with RDS [database PaaS solution] or anything like that.

Here we’ve taken the three tier app, resized it and added an autoscaling group for the web and app tier. Lets break down what happened.

We resized our Web and App EC2 instances from 2 vCPU and 8 GB of memory to 1 vCPU and 2 GB of memory. After we did that we added 3 year Reserved Instances to those to further drive down the price but we know those instances will run 100% of the time. Our database remained the same size with its own 3 year RI as well.

The blue boxes are the interesting parts. We obviously sized the VMs on-prem for a reason, most likely to hit maximum spikes in demand. In the cloud we can scale out our application when we need extra capacity. So we’re allowing our application tier and web tier to scale (they scale the same in this example) and the instances aren’t always provisioned. In the example I have one Web EC2 instance running 100% of the time. A second Web instance runs 25% of the time, a third runs 10% of the time and a fourth runs 5% of the time to hit those top peaks in demand. The same is done for the application even though you can now see that the web service and the application layer can now scale independently from each other.

We finally have an application that is finally cheaper to run in the cloud than on-premises even though we didn’t use PaaS services, or take into account data center overhead like HVAC, physical security, power or taxes.

Summary

The decision about whether the cloud is cheaper or more expensive really comes down to how you are building your applications more than price per unit. AWS needs to make a profit someplace so a straight lift and shift probably is more expensive than running that workload on-premises. But if you’re committed to re-architecture your applications into a more elastic pattern, you can save money in the cloud as well as providing higher availability for those applications through scaling and automation.