Cloud
Model the cloud bill before you move the workload
A method for building a defensible cloud cost estimate before a migration, and the line items a first model leaves out.
Most cloud estimates start by pricing the servers. Someone counts virtual machines, matches each to an instance size, multiplies by hours in a month, and calls the result the cloud bill. Compute is the easiest line to get right and rarely the source of surprise. The items that move a budget are the services around the compute: storage growth, data movement, log retention, backups, and the second copy of everything that exists for disaster recovery.
The estimate has to exist before the migration because the funding request comes first. A number produced afterward explains an invoice instead of shaping a plan. The method below is the one we use internally when sizing a workload for our own builds: an inventory, a mapping, a run rate, and a range.
Start from an inventory of what the workload does
A server is the wrong unit to count because it contains several billable things. For each component of the workload, record the compute shape and its utilization across a week, storage capacity and growth trend, the database engine and how it is licensed, how much data moves in, out, and between tiers, retention periods for backups and logs, the number of non-production environments, and the actual availability requirement.
On-premises budgets hide most of this: the hardware was bought once and the network was flat. Cloud pricing meters each dimension separately, so the inventory needs more detail than an asset list.
Utilization is the most useful column. A server sized for a peak that happens twice a year is a candidate for a smaller instance that scales on demand, and that decision usually changes the estimate more than any discount negotiation.
Map to services, then to a monthly run rate
Every major provider publishes a price list and a calculator. Use them, but drive them from the inventory, and keep the model in a spreadsheet you control. A budget officer needs to see the assumptions, and a calculator link is not a work product.
Give every assumption its own row: quantity, unit, price source, and monthly cost. Group the rows into compute, storage, database, network, observability, security tooling, support, and licensing. When the estimate is challenged, the goal is to change one number, not rebuild the model.
The line items that get left out
These are the categories we check first, because a first draft usually omits them:
- Data transfer and gateway hours. Traffic to the internet, between availability zones, and through managed gateways is metered separately from the servers that generate it. Address translation gateways, load balancers, and private endpoints also bill per hour, including while idle.
- Log and metric ingestion. A chatty application can spend more on telemetry than on compute, especially with long retention.
- Backups and snapshots. Multiply the retention schedule by the growth rate, not by today's volume.
- The non-production estate. Development, test, staging, and training environments are often larger in total than production.
- Disaster recovery. A warm standby approaches the cost of a second production environment. Set the recovery time and recovery point objectives first, then price the design that meets them.
- Support plans. Provider support is commonly priced as a percentage of spend with a monthly floor, so it scales with everything else.
- Database licensing. License-included and bring-your-own-license paths price differently, and an existing agreement may not transfer to a cloud host.
- Commitment discounts. Reserved capacity and savings plans require a term commitment, typically one or three years. Confirm the funding arrangement supports it before modeling the discounted rate.
- Compliance boundaries. Regions and service tiers built for government workloads can price differently and offer a narrower catalog than commercial regions. FedRAMP authorization applies to an individual cloud service offering rather than to a provider as a whole, so check each service in the design and whether it exists in your target region.
- One-time migration cost. Dual running during cutover, egress from the current host, data migration services, and staff time are real costs and are not part of the run rate.
Build a range, not a number
Produce a low, expected, and high case by varying the drivers that matter: data growth, egress volume, log retention, and disaster recovery posture. If the high case sits far above available funding, the workload needs a design change, not a better spreadsheet. Write down what would invalidate the estimate, and name who owns each assumption.
Validate the model against something real
We keep reference builds of common workload shapes in our own accounts and run load through them for a full billing cycle, because an invoice reports what a calculator cannot. An agency can run a smaller version: move one non-critical workload first, tag every resource from day one, and compare the first full month of billing against the model. That corrects the assumptions while the stakes are small.
What this means for an agency
Ask any vendor proposing a migration for the model, not only the total, and check it against the list above. Budget the recurring run rate and the one-time migration cost separately, because they behave differently across fiscal years and may draw on different funds. Revisit the model once the first workload has run a few months. An estimate corrected early is a plan. One corrected at the end of the fiscal year is a budget adjustment.