Today we’re going to talk about something very important to a lot of organizations. Cost analysis. The VMware Cloud Services team has a pretty substantial demo environment built out. Our “company” is called ACME Fitness. We manufacture smart unicycles. In order to sell these unicycles, we have a multi-tiered application called Fit Cycle. The application takes user registrations on the front end and allows the “marketing” department to use the API to pull out prospects from the back end. This application is built out with terraform on AWS, Azure, and soon to be GCP. For this blog, we’re going to talk about the AWS build.

Application Architecture

We have several versions of the application. A big app with high availability, a small app with no HA, and a Kubernetes version of the app. Today we’re just talking the big app. And for that one, we actually have two different sub-versions. We have one that is using MySQL on full EC2 instances, and the other running MySQL backed RDS. The architecture is pretty straight-forward. Web tier into App / API tier into load-balanced DB tier.

Costing Configuration

Now that we’ve talked about how the applications look, let’s take a look at how we can quickly and easily view the costing for these resources. For this, we’re going to utilize CloudHealth. To make this easier to create reports based on just the resources we want to see, I have added tags in AWS to the two EC2 instances, and the 2 RDS instances. The category is ‘Cost Reporting’, and the value is ‘timd‘.

The first thing we should do is to create a new perspective. CloudHealth Perspectives enable precision reporting. They let you create unique business groups that reflect different sets of analysis, management and evaluation criteria. I am going to add the two EC2 instances and 2 RDS instances to it. The tags will make it easy to filter and add the resources to my perspective.

Now that we have our perspective setup with the correct resources, we’re going to need to let it churn away for a short bit. CloudHealth actually goes in and starts generating reporting information based on the assets that you add to the perspective. This allows for much easier report creation and reading.

EC2 Reports

Let’s start by checking out the monthly cost of our EC2 instances. To do this, we go to Reports, Cost, EC2 Instance. From there, we want to filter based on our perspective and select the Amazon EC2 Instances group we created.

I then filtered the results by a Monthly interval. This allows us to see a nice view of the past few months worth of EC2 spend. Remember, this report is generated only off the 2 MySQL EC2 instances we have configured for our perspective.

As you can see in the report, we spent $19.87 last month. That’s not too bad, is it? Remember, this is only for 1 tier of a tiny application. Let’s do the exact same thing again, but this time we’ll go to Reports, Cost, RDS. And we’ll do the same filtering.

RDS Reports

As we can see here, we spent $37.20 on the RDS instances. This is just over double the cost of our EC2 MySQL DB’s. You’d wonder why someone would do RDS vs EC2 with MySQL when given just this data.

One other thing you may be asking yourself is why we’re using RDS the exact same way we use EC2 DB’s. Using multiple instances and a DB load balancer. Not really the pinnacle of “Cloud Native” design, right? Well, I have great news for you. This is going to be a two-part blog. I will be going in and rearchitecting the RDS application. I am going to remove the EC2 instance with HA PRoxy (DB Load Balancer) and point the app servers directly to an RDS instance. For high availability purposes, it will be a Multi-AZ RDS instance. So, while that type of RDS instance is more expensive than a Single-AZ instance, removing the second instance and the DB load balancer EC2 instance may just bring the cost down. Stay tuned for the follow-up blog.

Part 2 can be found here.