We have all seen the latest trend in mobile gaming. Freemium applications that entice us with energy refreshes, extra lives, or special unlocks but only at a price. Like many of you, I found myself sucked into this world. My game of choice is the EA hit Star Wars: Galaxy of Heroes. I will freely admit that I succumbed to the temptation to simply buy a premium pack. ‘Hey, it is only $1.99 and why not support the developers’ I thought. After one or two or, who am I kidding, several of these purchases, I find that my credit card shows a big investment into my little hobby. I am sad to say but I had a bit of a sticker shock. I began to think about what happened when I started working in the public cloud.

Over the past few years, I have worked very closely with AWS and Azure environments and I have felt the pain of runaway expenses. The concept of pay-as-you go is prevalent in cloud environments. This freedom comes at a cost and sometimes is buried deep into the fine print of that simple purchase of a Windows server. In this post, we will look at what happens when we start to build a complete solution in the cloud and how our simple transaction can quickly skyrocket.

Starting with a model
In order to make this more of a real-world example, I would like to start by defining the architecture to mirror a common solution. We will need to make this highly available and resilient. Let’s start by defining our basic 3-tier application – front-end Web Server, midware .NET server, and a SQL Database server with 150GB of databases. This is an extremely common scenario in the world of applications so it makes sense to leverage this solution. It will also allow us to look at a somewhat complex solution and the overall total cost of ownership to support this single application in AWS.

Getting to know your cloud
As of this writing, Amazon has fourteen regions (there is a fifteenth though it is part of the GovCloud and not applicable to our conversation) and those regions each have different pricing models based on the services that you choose. We will leverage the oldest and most often used region US-East-1 (N. Virginia) as our production site and US-West-2 (Oregon) as our disaster failover site.

Elastic Compute Cloud (EC2) is Amazon’s cloud computing service and generally runs on a pay-as-you-go model. There are a couple of ways to consume the service but we will focus on the basic on-demand usage style. In this case, we ‘rent’ the servers by the hour and pay an all-included usage fee for the server. Well, almost all included. Here are the three instance types that we will use and their cost per hour:

• NodeJS Linux server – m4.large (2 cores with 8GB of RAM) is $0.108/hr USD
• IIS .NET server – m4.xlarge (4 cores with 16GB of RAM) is $0.404/hr USD
• SQL 2014 Standard RDS Multi-AZ – db.r3.xlarge (8 cores with 61GB of RAM) is $3.040/hr USD (includes SQL Server license)

Amazon Relational Database Service (RDS) is a database-as-a-service offering where AWS will manage and support the OS and Application patching and resiliency of your database environment. This frees your team to focus on the application configuration and data. The options are Single-Availability Zone (Single-Az) or Multi-Availability Zone (Multi-Az). AWS will keep a single Standby copy available for deployment if the primary fails.

This is cheap, right? These machines feel as if they cost relatively nothing in the grand scheme of things but those 3 servers will cost over $8,700.00 per month to run 24/7. See how that little tiny micro-transaction can start accelerating quickly? We are not done as this solution doesn’t account for high availability or resiliency.

Building for failure and the effect on the bank
AWS Best practice is to leverage the rule of three – 3 copies of your data, 3 instances of your application, and 3 ways to recover. Failures are inevitable and you must plan for a system to go away. In this case, we will design our solution to have a minimum of three servers. We will need to update our pricing to cover this. We can’t configure RDS to use three availability zones so we will put our faith in AWS to keep things going.

In our case, we will need to add a few more things to the equation:

• Elastic Load Balancer for public (NodeJs servers) and private (.NET servers) communication
• Database backups
• Data transfers to the internet
• VPC Peering
• Cross-Region replication
• Second set of servers
• Second RDS environment

Very quickly, our little $0.10/hr solution has skyrocketed to almost $9,000/mo (over $100,000/yr USD) and this is only one application with no disaster recovery (essentially double this cost for full always-on disaster failover). This might seem like an exaggerated example but this is far from an outlier. I don’t want to seem like I am underselling the value of AWS or the cloud but I do caution those investigating the cloud to plan your migration carefully. There are several things that we can do to mitigate some of this cost or improve some of the keystone use cases – Reserved Units for long-running servers, Auto-scale groups or Elastic Beanstalk or both, etc.  We should also not discount the value of the automation and the scale and the lack of maintenance fees.  At the end of the day, moving to AWS or the public cloud is not an immediate cost killer.  It just changes how and when you incur those costs.