AWS Cloud Migration - Pricing Calculator 101
One of the most common questions I get in the consulting world of cloud migrations (and understandably so) is “How much will it cost us to move to AWS”. When having to align to business cases and CAPEX/OPEX budgets - “it depends”, or “how long is a piece of string” is never a suitable answer (sadly)!
This is intended to be a bit of a guide, to give you a head-start, and to provide some thought provoking conversations to help you understand at a deeper level, how much running typical workloads can cost in AWS.
Obvious caveat - your mileage may vary, this is only a specific sample to build off, and the more accurate data you can input in the pricing calculator - the closer your pricing estimates will be.
Getting started
Head on over to the AWS Pricing Calculator
Give your estimate a name (note these links are unique but public, so you may want to omit sensitive customer information)
Groups are your friend
You’ll see here in my example, I like to logically group the building blocks required that comprise the overall solution. This enables an easily repeatable pattern, that you can clone for additional workloads, deployment options, pricing models, and more without having to reinvent the wheel each time.
Groups can be cloned for re-use and edited once created (so don’t worry about any typos), and they can be nested depending on the granularity required. I like to start simple, and build on from there:
For multiple services, use cloning. Save yourself those button clicks!
When you’re ready you can share the link of the pricing calculator you’ve created as required, and/or export it to a file:
Here is my example AWS Pricing Calculator that all you need to do it open the link, make your edits, and re-share (this generates a new URL) and use as you like.
Take note of the currency in use (and estimates are priced at time of creation and subject to change) as are any Fx rates you are working to if applicable.
The finished product:
General pricing tidbits
Know your AWS pricing models There are often caveats between AWS regions in terms of what services are available in what regions, and these are coupled with pricing models.
For example you can’t at the time of writing purchase a 3 year reserved instance for RDS Microsoft SQL Server in the ap-southeast-2 region.
Be realistic. Sure, all up-front payments are cheaper on the whole - but who actually wants to upfront all that cash, to save a few bucks each month!? I tend to stick with:
- On-demand
- 1 year reserved instance
- 3 year reserved instances
And make a separate AWS Pricing Calculator for each payment option, so as not to confuse the overall cost - and to provide a comparator across each option.
Convertible instances for EC2 are a great way to use a savings plan, and swap OS families and types to give you the flexibility of changing and not be stuck with what you picked at the time of creation. Things change over the time, and particularly after a migration in the “right-sizing” and FinOps stages, you want to be running the most efficiently you can with what you have.
Take note of the data transfer costs as I mentioned above (where applicable) and again, the more accurate data you can gather to feed into the pricing calculator will give you the most accurate estimates. Take note of all the possible inputs in each service, and tune to your requirements.
It’s often better to shoot for the moon, and scale back from there as/where required. There’s nothing worse than over-promising and under-delivering!
This is what I’ve included in my example pricing calculator link for reference.
Multi-AZ, Single-AZ, or Multi-Region?
This pricing example talks to a standard single region (ap-southeast-2) Sydney as it is where the majority of our workloads are deployed due to customer proximity and location for the least latency. I am using Multi-AZ in this region, to give the best availability and fault tolerance with workloads being deployed over (two or more), three in this example Availability Zones which are geographically isolated, and redundant from each other as part of the AWS Global Network architecture
Single-AZ is of course possible, and easily configurable in the calculator and whilst not recommended for production workloads can be used in DEV/TEST designated environments for cost savings where workloads aren’t mission critical.
Multi-region is doable in the AWS pricing calculator with some finessing. But is not something that I often experiment with or estimate with often, when using Multi-AZ as per the above.
Don’t forget the core infrastructure/networking costs
Often migrations can be regarded as a 1:1 migration. Move a VMWare VM to an AWS EC2 instance. But this is only the beginning from a technical and cost perspective.
Things to note: In my example I am configuring:
- 3 NAT Gateways for internet egress with availability (these can be adjusted if shared across environments, or unique per environment etc)
- VPC’s similarly
- Transit Gateway attachments
- No ingress costs added (assuming a one time migration and data transfer INTO AWS is free)
- No egress costs added (assuming data remains in this AWS region once in AWS and backups are to EBS/S3 in the same region) this would differ if using 3rd party SaaS backup products for example.
- 3 site to site VPN’s for remote access (with redundancy)
Remote Access
A single AWS Workspace for remotely accessing the RDS database and EC2 instances (often forgotten and Workspaces costs can get high quickly)
Database
A single instance multi-AZ PostgreSQL Database
Note: I have not included in this example, but it is important for a cloud migration to consider the one-off migration costs required to move to AWS. These are typically covered as CAPEX costs in a business case. This typically could include AWS Database Migration Service, to run, any replication tasks ongoing, and running/using the replication instance itself.
Application/Compute
Three Linux EC2 instances for a multi-AZ configuration running in an auto-scaling group for the best resilience and fault tolerance. Typically most standard three tier web applications are stateless. So we don’t often look to migrating servers themselves, and re-deploy the required source code once they are running in AWS. But this may not always be the case!
Note: as above, extra costs could include AWS Application Migration Service
Storage
S3 storage is cheap! Adding a TB (or five) is great insurance, and handy to have available. Noting the storage costs for RDS (EBS, and EBS backed EC2’s are covered under RDS and EC2 respectively already)
I haven’t included it here, but in a Windows environment, adding in FSx for Windows as a file share can be handy for a more 1:1 block storage mapping from on-premise to AWS storage, and similarly FSx Lustre for Linux compared with S3 object storage.
So there you have it a way to build some well-rounded AWS pricing estimates using the AWS Pricing Calculator. Hopefully this helps!