AWS Cloud Operations & Migrations Blog

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


When you migrate your on-premises applications to the cloud, you can use a cloud migration strategy. AWS supports the seven most common migration strategies, “The 7 Rs”. Which approach makes sense for a specific workload is situational and depends on that organization’s business drivers and strategy. Understanding the total cost of ownership (TCO) is usually a first step in building the business case. Methods to calculate TCO vary depending on the data available and tolerance for the time willing to invest in the analysis. Often businesses make 2-tiered decisions. The first is a high level estimate to gauge whether they warrant additional effort to perform the next level of detailed analysis. This two-part blog series outlines the methodologies to quickly return a high level estimate using two different scenarios, one with only server inventory information and two with only application-level information.

A standard modernization path organizations undertake to move workloads into AWS is to re-platform applications from server-based hosting environments onto orchestration platforms through containerization. Containers provide a standard way to package an application’s code, configurations, and dependencies into a single object. The containers enable organizations to deploy applications rapidly, scale as needed, and run as resource-isolated processes. These ensure quick, reliable, and consistent deployments, regardless of the environment. In addition, containers require fewer system resources and can be deployed anywhere consistently.
Using containers, organizations are able to create, configure, and manage workloads more efficiently. This leads to greater agility, improved portability of applications, and lower overall downtime. Building and deploying microservices, running batch jobs, machine learning applications, and moving existing applications into the cloud are just some of the popular use cases for containers. This blog provides details on how to calculate the TCO for this modernization path leveraging Container Services on AWS.

Modernization using Containers

Depending on the desired level of control over the underlying hosting infrastructure, AWS offers 3 different options for running and managing containers. In addition to the traditional path of hosting containers directly on Amazon Elastic Compute Cloud (Amazon EC2), AWS also offers a serverless compute option through AWS Fargate eliminating operational overhead so your teams can release quickly, get feedback, and iterate to get to market faster. AWS App Runner is a fully managed container application service that lets you build, deploy, and run containerized web applications and API services without prior infrastructure or container experience.

Calculating TCO for containerization.

There are a two different approaches to calculating TCO for a modernized workload running on containers that we will discuss in this blog; however, with any approach we will need to perform these five steps.

When you perform a TCO analysis the two components that we need to consider are the cost of AWS resources and the cost of effort that is need to modernize the application using containers.

Step 1: Assess current environment

In step one, you need to gather data about your current hosting environment, such as server configuration, utilization details like CPU, memory, and storage along with applications installed on them. To achieve this, you can leverage your existing configuration management database system (CMDB) data or discovery tool. The information obtained in this step will be used for calculating AWS resource costs.

You may not have all the details mentioned in step one that are needed for an accurate TCO. We will be discussing different scenarios where we can still achieve a directional TCO based on limited inputs.

Step 2: Choose AWS Container Services

In step two, you need to choose a container management tool of choice for hosting your application. You can select a specific platform based on your team’s skills or organization’s general direction. The cost of the solution depends on your choice of container orchestration platform.

Container management tools on AWS can be grouped into three categories: registry, orchestration, and compute. AWS offers services that give you a secure place to store and manage your container images and orchestration that directs when and where your containers run, and flexible compute engines to power your containers. AWS can help you manage your containers and their deployments, so you don’t have to worry about the underlying infrastructure.

AWS container options:

Registry Amazon Elastic Container Registry
Orchestration Amazon Elastic Container Service. Amazon Elastic Kubernetes Service Red Hat OpenShift Service on AWS
Compute AWS Fargate Amazon EC2 AWS App Runner
Tools AWS App2Container AWS Copilot

Choosing a container service at AWS does not need to be a binary decision. Amazon ECS and Amazon EKS work together seamlessly with shared operations, integrated security tooling, common Identity and Access Management (IAM), and consistent management tooling for compute and network options. Take advantage of the simplicity of cohesive AWS services in Amazon ECS, or roll your own using the flexibility of Kubernetes on Amazon EKS. See Amazon ECS vs Amazon EKS for additional guidance.

Step 3: Define target architecture

To define the target state architecture to modernize your workload, you must first consider your modernization path, such as,

  • Option 1: Run an existing monolithic application in a container.
  • Option 2: Minor application changes to take advantage of distributed architecture patterns.
  • Option 3: Rewrite and redesign (Refactoring) applications.

In this step, you want to create a target state architecture for your workload. Knowing how much compute/memory/storage is needed and the number of containers to run is required to get a more accurate TCO.

Suppose you are migrating fewer applications (<10). This is a manageable exercise using methods in Step 4. But in the case of 10s or 100s of applications or even an entire data center exit, this becomes unmanageable unless you spend months due to the effort involved in individually pricing each application, with a risk of analysis paralysis. You can mitigate this effort by identifying modernization patterns across your workloads, understanding the level of operational overhead desired for managing them (Fargate vs EC2) and categorizing them as such. In the scenarios outlined below we will show you examples of how to leverage patterns to calculate TCO at scale.

See Prescriptive Guidance for Containers and Microservices for example workload patterns

Step 4: Calculate platform costs

AWS offers you a pay-as-you-go approach for pricing. With AWS, you pay only for the individual services you need for as long as you use them.

AWS container services pricing:

Registry Amazon Elastic Container Registry
Orchestration Amazon Elastic Container Service (Free) Amazon Elastic Kubernetes Service Red Hat OpenShift Service on AWS
Compute AWS Fargate Amazon EC2 AWS App Runner
Tools AWS App2Container (Free) AWS Copilot (Free)

The total platform cost of solution = Container Registry cost + Container Orchestration cost + Compute cost (along with storage) + Tools cost.

Additionally, AWS Pricing Calculator is a web-based planning tool that you can use to create estimates for your AWS use cases. You can use it to model your solutions before building them, explore the AWS service price points, and review the calculations behind your estimates.

You can leverage the AWS Pricing Calculator for calculating costs for individual components.

Step 5: Calculate cost of modernization effort

The cost of the modernization effort depends on the complexity of the application, resources and number of hour of technical expertise required. We typically see one or more combination of the following three options.

Please reach out to your AWS account representative or AWS sales support for pricing details.

Application modernization is ambiguous by definition. In many scenarios, it isn’t easy to finalize the target state without some experimentation with different architectures to fit your business workflows, which decides the needed resources. Here, we will explore a scenario that can help you navigate the TCO analysis with limited inputs.

Scenario 1: Estimating TCO with only server inventory information

In this scenario, we will look at options for calculating TCO with just using server configuration details and without any application-level information.

The compute and storage are key components that drive containerization cost.Therefore, it is essential to perform a “Right sizing exercise“. This is a process that matches AWS instance types to your workload performance and capacity requirements at the lowest possible cost. Additionally, containerizing applications reduces the application’s footprint and enables better optimization of underlying resources. The container orchestration layer leverages container placement strategies to achieve this. Based on industry standards, this typically results in an additional 23% cost reduction.

If you only have server inventory and utilization information such as, server names and provisioned vs utilized CPU, Memory and storage details we can take the following approach.

1 (Workload assessment): Gather server inventory and utilization metrics such as provisioned vs utilized CPU, memory and storage details.(For VMware based environments this can be obtained from vCenter or by using 3rd party tools such as RVTools.
Once this data is available, we match it to the appropriate AWS instance type, For a large number of machines this can be done using Amazon EC2 instance recommendations tool within AWS Migration hub.

Example: Your assessment output cloud look like this, we will use just 3 servers to keep this simple.

Server name CPU allocated CPU Utilized Memory allocated Memory utilized Storage allocated Storage utilized ——– Additional metrics
Server 1 8 25% 32 70% 500 GB 180 GB
Server 2 4 65% 16 60% 350 GB 220 GB
Server 3 16 56% 64 80% 750 GB 450 GB

Mapping this to right EC2 instance type gives AWS EC2 instance recommendations

Server name Recommended instance EBS Storage
Server 1 m5.xlarge 180 GB
Server 2 t3.xlarge 220 GB
Server 3 m5.4xlarge 450 GB

2 (Compute and Storage resources cost): Calculate the cost of EC2 instances and storage using AWS Pricing Calculator.

Server 1 cost/month = EC2 $70.81/month (With AWS Compute savings plan) + EBS storage $14.40 = $85.21
Server 2 cost/month = EC2 $60.30/month (With AWS Compute savings plan) + EBS storage $17.60 = $77.9
Server 3 cost/month = EC2 $283.97/month (With AWS Compute savings plan) + EBS storage $36 = $310.97

3 (Savings): Add additional 23% cost reduction for compute to account for efficiencies with containerization.

Server 1 cost/month = EC2 $70.81/month * 23% = $54.52 + EBS storage $14.40 = $68.92
Server 2 cost/month = EC2 $60.30/month * 23% = $46.43 + EBS storage $17.60 = $64.03
Server 3 cost/month = EC2 $283.97/month * 23% = $218.65 + EBS storage $36 = $254.65

4 (One time Modernization effort): Calculate cost of modernization effort.

For example if your human resource rate is estimated at $100/hr, and it takes 5 hours, then your modernization resource cost would be
5 hours x $100 hourly resource rate = $500

5 (TCO): Total TCO = Sum of cost calculated in Step 3 and Step 4

Total TCO = Server 1 $68.92+ Server 2 $64.03+ Server 3 $254.65+ modernization effort $500 = $887.6


Calculating the TCO for modernizing applications using containerization is a challenging and ambitious process. In this part 1 blog, we explored containers hosting options. 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. It is important to note that this methodology is intended to provide high-level estimate of costs to enable early investment decisions. As the project moves forward and PoC experiments are performed, we can produce new figures based on the application architecture.

About the Authors

Keith Andrew author image

Keith Andruch

Keith Andruch is an AWS Principal Enterprise Architect Leader based in Toronto, Canada.He has deep expertise in enterprise transformations, cloud migrations, automation and designing cloud-based solutions on Amazon Web Services.

Kiran Kuppa author image

Kiran Kuppa

Kiran Kuppa is a Principal Solutions Architect at AWS, focusing on Migrations and Modernization. Kiran has extensive experience helping greenfield and enterprise customers adopt AWS cloud-based solutions.