Estimating Total Cost of Ownership (TCO) for modernizing workloads on AWS using Containerization – Part 2

Introduction

Part one of this series described the methodology used to calculate the TCO for containerization and we covered the first scenario of estimating TCO with server inventory information. In the second part we focus on second scenario where we will estimate TCO with application level information.

Scenario 2: Estimating TCO with only application level information

In a scenario where you have application inventory without any server details, you can calculate the AWS resources cost and containerization effort based on a few assumptions of the applications to get a directional TCO.

A quick recap from Part one, for calculating TCO we need to perform these five steps.

To illustrate this scenario, we will follow the five step process using an example workload. Before we get to estimating costs, we need to execute steps 1-3 to define scope of what applications we are targeting to containerize on AWS.

Step 1 (Application assessments):

Here we will target three, multi-tier applications comprised of different technology stacks.

Step 2 (Choose Container Service):

Here we will choose Amazon Elastic Container Service (ECS). For simplicity, we will not include the use of a registry (ECR) or additional containerization tools. But don’t forget these additional costs if your scenario calls for them.

Step 3 (Target Architecture):

Some design questions to consider when going through this process:

• Can you split the legacy application in multiple containers (single process per container, like a cron job)?
• Does your application have specific hardware requirements (GPUs, sound cards, USB licensing keys)?
• Does your application have persistent memory requirements (persistent data is not saved in containers, only the volumes)?
• Does your application use a framework where docker images already exist (Spring boot, Tomcat, .NET)?

For Step 3 we will choose to replatform the applications in their current architecture without making any changes.

Preparation for Steps 4 and 5:

You can identify patterns across your workloads to simplify estimation at scale. For Step 4 and Step 5, you can leverage a containerization model that has been developed by AWS Professional Services to categorize each application to different levels of complexity. The model is broken down into three distinct categories of complexity ranging from Low, to Medium, or High. Each category has variances of complexity to represent the level of effort it would take to containerize the applications and the number of tasks to run these workloads on ECS.

• A low complexity application might consist of a single Java package (WAR file) or a Microsoft .Net component (.NET) with no UI (User Interface) or have an internal UI.
• A Medium complexity application might have a single to multiple .war or .NET components with an external UI and
• High complexity application might have multiple .war or .NET components with both internal and external UIs.
  Here is a chart you can follow as a guide:

The following table shows the complexity of our example workload:

Once you categorize your applications into three levels based on the complexity, you can look at identifying the number of Task Definitions and containerization effort that are required for each level. This provides the basis to execute Steps 4 and 5.

The illustration below represents the containerization effort model used today.

Using our example, you could come up with the following for number of tasks and containerization effort:

Step 4 (Platform Costs):

The number of tasks will be used to estimate your annual platform costs.

Assumptions and Considerations:
When using ECS as the orchestration platform, there are no costs for use of the platform itself. If there is a desire to use EKS, then consider adding runtime costs. Costs vary per region, so make sure you input from the region into which you plan to deploy. For this scenario we will standardize on US East 1. Calculations shown are for annual basis.

To determine the total platform costs, we need to calculate the costs of the following technical components of the target architecture:

1. Compute (EC2 & Fargate)
2. Storage
3. Network (Load balancers)

1. Compute:
Cost calculations will differ depending on whether you choose EC2 or Fargate as the underlying compute launch type. We will cover EC2 first and then Fargate:

a. Compute Type – EC2:
To calculate the annual expected compute costs, use the following formula:

Hourly rate/instance * number of expected instances * expected average daily duration(in hours)/instance * 365 (days in year)

Now let’s look at how we arrive to the value for each component of the equation.
hourly rate/instance: The rate will depend on the instance type, the instance purchasing option and the region in which it will be deployed. If you have a good idea of your instance type, then you can pick that. If not, for rough estimating purposes, we recommend picking a middle of the pack general purpose instance like m5.large. You can look up instance types here: https://aws.amazon.com/ec2/instance-types/.

Pricing will depend on the purchasing option and possible savings plans you may have available to you. If you have a good idea that you can use reserved instances for workloads that you know will be needed on a daily basis for more than 1-3 years, you can look at reserved instance pricing. But to be conservative for estimation processes, we recommend you start with OnDemand pricing here: https://aws.amazon.com/ec2/pricing/on-demand/

Number of expected instances: The number of expected instances is a factor of the number of Tasks you defined in the previous exercise using the Complexity Model. The actual number of instances required to host all the tasks will eventually be determined by the actual usage and will be optimized over time. But as a general rule of thumb for estimation purposes we recommend assuming 3 tasks per instance as based on historical experience.

Expected average daily duration/instance: In general most workloads are expected to be under continuous provisioned status and then you can select 24 hrs/day. However, if you know that certain workloads will only be provisioned for lesser periods (for example Dev and QA contexts or to address elasticity), you can try to factor that down. But for a conservative approach, recommend assuming continuous provisioned status.

Example:
Using our 3 applications with 40 tasks and assuming m5.large and continuous provisioned status and the hourly rate in the US-East (N.Virginia) at the time of this blog posting. your calculation would look as follows:

$0.0960 hours/instance * 40/3 instances * 24 hours * 365 days = $11,212 as your estimated annual compute costs.

b. Compute Type – Fargate:
AWS Fargate pricing is calculated based on the vCPU, memory, operating systems, CPU architecture and resources used from the time you start to download your container image until the Amazon ECS Task or Amazon EKS Pod terminates, rounded up to the nearest second

To calculate the annual expected compute costs, use the following formula:

Number of tasks or pods per day * average duration (hours) per day * (amount of vCPU allocated * price per vCPU/hr + amount of memory (GB) allocated * price per GB/hr) * 365 (days in year)

Example:
Using our example, three applications with 40 tasks assuming continuous operation in the US-East (N.Virginia) region at the time of this blog posting:

40 tasks *24 hours * (1 * 0.04048 price per vCPU/hr + 2 GB memory * 0.00445 price per GB/hr) * 365 = $17,302 as your estimated annual compute costs.

You will notice that the cost of Fargate serverless is higher than using the EC2 launch type. But keep in mind Fargate, is a fully managed service, compensates for the operational costs associated with managing the EC2 launch type.

Now that you have estimated your compute costs, let’s move on to storage costs.

2. Storage:
To calculate the annual expected storage cost, use the following formula:

storage amount (GB) * storage price per GB/month * tasks * 12 (months in year)

Your Storage Amount (GB) is what you are currently using today for the applications you plan on migrating to the AWS Cloud less the storage consumed by your operating systems. It is important to be aware that task storage is non-persistent and any requirement to persist storage should leverage EFS or other AWS storage services, and be included in your calculations.

Storage Price Per GB per Month. This calculation will depend upon a number of factors such as region, type of storage, desired throughput, IOPs, etc. If storage type isn’t known at this point, you can use EBS as an assumption for calculation purposes as most typical workloads will utilize this service. To help calculate what this could be for your organization, please see the AWS EBS storage pricing calculator for further details.

Example:
We will assume a regional Storage Price Per GB per Month of $0.100 for general purpose SSD (gp2) and that EBS snapshots are retained for one month and then subsequently deleted. Using 20 GB of storage per task as a starting point, your storage cost would look as follows:

20 GB * $0.1 price per GB/month * 40 tasks * 12 months = $960 as your estimated annual storage costs.

Fargate provides the first 20 GB per task at no extra cost. So in this scenario your storage costs would be $0.00 until you exceed that initial threshold. So you can use the same formula but only include the amount of storage you would expect in excess of the first 20 GB.

3. Network:

Most ECS implementations are likely to be fronted with an elastic load balancer (ELB), particularly to increase resilience through a highly available architecture. Accurate cost estimation can be determined through the pricing calculator which takes into account detailed usage characteristics. ELBs are priced by the hour of uptime plus LCUs (which capture expected usage characteristics) . Since knowledge about potential characteristics might not be readily available per application, we offer an alternative short cut formula that can act as a reasonable rough order of magnitude estimate:

#tasks * hourly rate * 8736 (# hours in year)

Example:
So continuing with the example of 40 tasks and taking the hourly rate in US-East (N.Virginia) for an ALB at the time this blog was posted, the formula would calculate as

40 tasks * $0.0225 price per hour * 8736 hours per year = $7862.4 per year

This completes our calculation of platform costs.

Step 5 (Effort Costs):

You can use the number of hours calculated following the complexity model described earlier in this scenario to estimate your resource and support costs. To determine your resource costs, you simply take the total number of estimated hours (280 in example) and multiply it by the expected human resources rate. That rate will be determined by either an estimate of your internal rate if performed by your internal employees or by the service rate if performed by a 3rd party provider or a mix of both. This amount represents an estimate of the one-time modernization costs.

Example:
If your internal human resource rate is estimated at $100/hr, then your modernization resource cost would be

280 hours x $100 hourly resource rate = $28,000.

Now that we have our effort costs, let’s move on to calculate the Total Cost of Ownership.

TCO Final Calculation:

Total TCO = Costs calculated in Step 4 + Step 5

Example:
To calculate TCO for the EC2 launch type in our example, we have:
$11,212.8 compute + $960 storage + $7862.4 network = $20,035.2 per year

To calculate TCO for the Fargate launch type in our example, we have:
$17,302 compute + $0 storage + $7862.4 network = $25,164.4 per year

You may want to consider including your estimated recurring support and maintenance costs (not covered in this blog) to get a more complete recurring TCO estimate. And lastly let’s not forget the one time modernization cost we estimated at $28,000.

Conclusion:

Part 1 and Part 2 conclude the TCO calculation model for modernizing applications using containerization. In this series of blogs, we explored a few options for hosting on containers. Then, we built a step-by-step approach to arrive at a directionally accurate and meaningful TCO based on AWS Professional Services experience and industry-standard assumptions. Reiterating from blog Part 1, it is important to note that this methodology is intended to provide a ball park estimate of costs to enable early investment decisions. As the project moves forward and assumed PoC experiments are performed, we can produce new figures based on the application architecture

About the Authors