How I derived at AWS Modernization Cost estimate for my Microsoft workload?
Tags: aws, modernization, totalcostofownership, appmigration
Published: 2023-09-02 02:40:10

Welcome back to AWS Community Member, Builder or cloud aspirant to another interesting use case rather a narration of my experience in estimating the cost to run my on-premise Microsoft Workloads on AWS. Let's begin !!
  
 
**Scenario:**

We had a three-tier web application, storing data in a relational database, both processing & serving huge volumes of data with hard code data transformation, calculations for reporting

Like any other Organization and Architect team, we have thought about the risks & concerns prevailing around moving from the existing, well-functioning application. Obviously, there were some drawbacks, which lead us to think & move towards Application Modernization with AWS. 

**Few of them are** 
1) limitations surrounding data volume handling/retreiving
2) latency
3) handling data load(s) day & night with tightly coupled tiers
4) Scaling to serve data & reports to end users
5) Application availability for analysts & strategists were as well, a bottle neck
6) Disaster recovery was relied on one other server for application server as a fallback option
7) Deploying application code fixes or database definition language changes or changes to business logic in middle tier, were all involved downtime of whole application, as all three tiers, Presentation, Middle & Data tiers were integrated
8) On failures, either rollback or fix forward was the options available rather the blue/green deployment modes, as compared to latest trends

Offffff, with all these on mind, I looked up on the pricing calculator for deriving at costs to host application & DB in EC2 servers. But then, came across the link on "Application Modernization calculator for Microsoft Workloads" and decided to give it a try

What say? I started off with few background work, in gathering all details of the existing data aspects & application architecture and proceeded. I have narrated in steps with the decisions on why the specific option has been selected, at each stage of the estimation. 

**Step 1**

To start with, reach out to the link  [Link](https://calculator.aws/#/) and later [Link](https://tinyurl.com/AWS-calc-MS-workloads)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/einc6efjrehso8wer06a.png)

1. Named the application
2. On-premise as was the case
3. Out of the three choices, "Architecture Pattern" was selected, as we had clearly defined 3-tier architecture. But if you have use cases, you can select them or even a "Custom" option is provided, in case the application doesn't fit into either an architecture or use case


**Step 2**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ts5kkbkz0zzc05ye9fyk.png)

1. As mentioned in Step #1, the existing architecture had 3 tiers, front end web server, business logic as middle tier & data layer with relational data and hence this selection was easy

**Step 3**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7le6ftwt4s6k3q88xg5b.png)

1. This had more ground work to be performed. After clearly, assessing the usage pattern, "Daily Spikes" was most apt one as access wasn't constant or other
2. There were around 500+ people using the application though not 1000 users but still went with 500+ option as it was clearly above 500
3. Though less users were using, it clearly is a data intrinsic application, holding 1 TB of data in Production DB
4. With the given situation, application usage was expected to grow by 25%


**Step 4**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yej5ajgvbjat9rxlt1wq.png)

1. well, definitely, as medium architecture pattern

**Step 5**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9jiyptg87udorfndfdxs.png)

1. This is where the transformation of application happens. Three choices were given based on the selection made in previous choices, and out of these, I chose "Serverless using EKS" Architecture
2. Reasons, were end users were served authenticated via Amazon Cognito
3. Web server can be guarded with AWS WAF
4. Images for web server can be stored in S3
5. Data will be served via Amazon Cloudfront
6. Application Load Balancer to handle the load
7. Features of application can be re-created as Microservices being hosted on AWS Fargate serverless, managed K8S, in a Private subnet
8. Relational data can be stored in Amazon Aurora which replicates in three AZs 
9. Amazon Elasticache for memory based data serving
 
Ok, all looks good and let us see what more is there to this


**Step 6**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wr2mj5dq2ad215i3koll.png)

1. Selected the AWS Region based on my end user location and here comes the "Monthly Estimated Effort" of running the existing application on-prem on AWS Cloud with the selected services.
2. I can also select, many other services, as needed along with the listed ones 

**Step 7**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bfruiu1sgv2fwgkceneo.png)

1. Services wise cost split which comes around USD $99x.xx per month for this use case

**Step 8**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sqx9pt321pwnavtvbr9c.png)

1. Another pictorial view

**Step 9**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/18gnpmhj2p980u5etvyp.png)

1.Lastly, I can generate a link for my estimate(this link stays valid for 3 years) and share it with stake holders or even download as Excel sheet & track progress or use it for discussion(s)
2. I can also amend my selections right from the beginning and re-evaluate the costs with many combinations

So, thus derived !!

Hope this is promising & realistic and inspires many to try this tool. Another advantage is, many folded aspects were also unearthed during this journey of estimation to "AWS Application Modernization"

Thanks for reading !!