Why 730 hours, and why the month you assume matters
Every major cloud provider quotes compute by the hour or the second and bills monthly, so somewhere a conversion happens. The convention is 730 hours: 365 days × 24 hours ÷ 12 months = 730. It is not the length of any actual month — February has 672 or 696, and a 31-day month has 744 — but it is the figure providers use for reservation amortisation and the one you should use for budgeting, because it averages out over a year.
Using 720 instead, which is the tempting round number, understates an always-on instance by 1.4%. On a $50,000 monthly compute bill that is $700 a month, or $8,400 a year, which is enough to matter in a forecast.
The compute line is only part of the bill. Block storage is charged on provisioned capacity, not used capacity, and it keeps charging when the instance is stopped — which is why a fleet of stopped development instances still generates an invoice. Outbound data transfer is charged per gigabyte leaving the provider's network, and on content-heavy workloads it can exceed the compute cost outright. Traffic between availability zones and between regions carries its own separate rate.
This calculator prices those three components across three purchasing models, because the right question is rarely “what does this instance cost?” It is “which way of buying this instance costs least, given how much of the month I actually need it?”
The three purchasing models and where each one wins
On-demand is the simplest: rate × running hours × instance count. You pay for what you consume, per second or per hour depending on the provider and the operating system, and you can stop at any moment. It is the most expensive per hour and the only model with no commitment.
Reserved instances — and their cousins, savings plans and committed-use discounts — trade flexibility for a lower rate. You commit to a term, usually one or three years, and you may pay some or all of it upfront. The effective hourly rate is the ongoing hourly charge plus the upfront payment amortised across the term: upfront ÷ (term months × 730).
The critical property, and the one this calculator exists to make visible, is that a reservation bills for all 730 hours of every month whether the instance runs or not. Turning a reserved instance off saves you nothing. So the comparison against on-demand is not a comparison of hourly rates; it is a comparison of a fixed monthly charge against a variable one. Setting them equal gives the break-even: h = effective reserved rate × 730 ÷ on-demand rate. Below that many running hours, on-demand is cheaper despite its higher headline rate.
Spot (AWS), pre-emptible (Google) and spot (Azure) capacity sells the provider's spare inventory at a large discount, with the condition that it can be reclaimed at short notice. Pricing is rate × (1 − discount) × running hours, and the discount varies continuously by instance family, region and availability zone. Spot is not a cheaper version of on-demand: it is a different product with an interruption model, and it only fits workloads that can checkpoint, retry or drain.
Storage and egress are the same in all three columns, which is why a bill dominated by them barely moves when you change purchasing model. When that is the case, the calculator flags it, because the effort is better spent on volume right-sizing and on a CDN than on reservation strategy.
Worked example: four instances, always on, with a one-year reservation
You run four instances at $0.096 an hour on demand. Each set carries 200 GB of general-purpose SSD at $0.08 per GB-month and the application pushes 500 GB of egress at $0.09 per GB. A one-year reservation quotes $300 upfront per instance plus $0.034 an hour.
- On-demand compute. $0.096 × 730 h × 4 = $280.32 a month.
- Storage. 200 × $0.08 = $16.00.
- Egress. 500 × $0.09 = $45.00.
- On-demand total. 280.32 + 16.00 + 45.00 = $341.32 a month, or $4,095.84 a year.
- Amortise the upfront. $300 ÷ (12 × 730) = $300 ÷ 8,760 = $0.034247 per hour.
- Effective reserved rate. $0.034 + $0.034247 = $0.068247 per hour.
- Reserved compute. $0.068247 × 730 × 4 = $199.28 a month, billed regardless of running hours.
- Reserved total. 199.28 + 16.00 + 45.00 = $260.28, saving $81.04 a month or 23.7% of the on-demand total.
- Break-even. $0.068247 × 730 ÷ $0.096 = 519 hours a month, which is 71% of the month.
- Spot. At a 70% discount the rate is $0.0288: $0.0288 × 730 × 4 = $84.10 of compute, for a total of $145.10.
Read step 9 carefully, because it changes the decision. The reservation is worthwhile at 730 running hours. At a 24×5 schedule of 521 hours it is marginal — on-demand compute would be $0.096 × 521 × 4 = $200.06 against the reservation's fixed $199.28, essentially a tie. At a 12×5 schedule of 261 hours, on-demand compute is $100.22 and the reservation still charges $199.28, so committing would nearly double the compute bill. The saving percentage on the headline rate is 29%, but the saving you actually realise depends entirely on utilisation.
Note also that the saving is 23.7% of the total but 28.9% of the compute, because storage and egress are identical in both columns. Quoting the compute-only percentage to a budget holder overstates what the invoice will do.
How to read the result
Compare the break-even hours against your real schedule, not your intended one. Development and test fleets almost never run the hours their owners assume. Pull actual instance-hours from the provider's cost explorer for the last three months before committing to a term.
A negative reserved saving is not an error. It means the reservation costs more than on-demand at your running hours, which is the expected outcome for any workload below break-even. The calculator reports the sign honestly rather than hiding it, because this is the single most common way cloud commitments waste money.
The all-in cost per instance-hour is the number to benchmark with. It includes storage and egress spread across the hours you actually run, so it is directly comparable against a dedicated server or a competing provider's quote in a way that the compute rate alone is not.
Check what fraction of the bill is compute at all. If storage and egress exceed 40% of the total, reservation strategy is a second-order lever. Right-sizing volumes, deleting orphaned snapshots and putting a CDN in front of static content will move the invoice further.
Spot is a different risk profile, not a discount. Treat the spot column as the cost of the workloads you can architect for interruption, and price the rest with the other two columns.
Running hours per month for common schedules
| Schedule | Hours per month | Share of always-on | Compute saving vs always-on |
|---|---|---|---|
| 24 × 7 (always on) | 730 | 100% | 0% |
| 24 × 5 (weekdays only) | 521 | 71.4% | 28.6% |
| 16 × 7 | 487 | 66.7% | 33.3% |
| 12 × 7 | 365 | 50.0% | 50.0% |
| 12 × 5 | 261 | 35.7% | 64.3% |
| 10 × 5 | 217 | 29.8% | 70.2% |
| 8 × 5 (office hours) | 174 | 23.8% | 76.2% |
| Weekends only, 24 h | 209 | 28.6% | 71.4% |
Weekday schedules are 730 × (hours per day ÷ 24) × (5 ÷ 7). A stopped instance still incurs block-storage and elastic-IP charges, so the realised saving on the whole bill is smaller than the compute saving shown here.
A reservation is a financial commitment, not a technical setting
Reserved instances and committed-use discounts are contracts. If you shut the workload down, migrate it to a different instance family, or move region, you keep paying unless the reservation is convertible or resellable — and the resale market only exists on some providers, for some reservation types, at whatever price a buyer will pay. Savings plans and flexible commitments reduce this risk by committing to a dollar amount per hour rather than to a specific instance type, usually at a slightly smaller discount. Match the commitment length to your confidence in the workload, not to the largest discount on offer.
What this calculator does not include
- Licensing. Windows, SQL Server, RHEL and commercial database licences are billed on top of the compute rate and can exceed it. Bring-your-own-licence terms differ by provider.
- Inter-zone and inter-region transfer. Only internet egress is priced here. Cross-zone traffic inside a region carries its own per-gigabyte charge on most providers and surprises a lot of multi-AZ designs.
- Managed services around the instance. Load balancers, NAT gateways, snapshots, backups, monitoring and log ingestion are separate line items, and NAT gateway data-processing charges in particular are a well-known source of unexpected spend.
- IOPS and throughput provisioning. Higher-performance volume types charge for provisioned IOPS and throughput separately from capacity.
- Free tiers, private pricing and enterprise discounts. Negotiated rates and committed-spend agreements override list prices entirely.
- Sustained-use discounts. Some providers apply an automatic discount as monthly usage rises, with no commitment at all — worth checking before buying a reservation.
Getting the input numbers right
The hourly rate is easy to find and easy to get wrong, because it varies by region, by operating system and by tenancy. Take it from the provider's own pricing page for the exact region you will deploy in; the difference between regions for the same instance size is routinely 10–30%, and it is the single cheapest optimisation available if your workload has no data-residency constraint.
Running hours should come from measurement. Every provider's cost tooling reports instance-hours by tag and by resource, and three months of history tells you what your schedule really is. If the answer is close to 730 for a fleet that was supposed to be office-hours only, an automated start-stop schedule will save more than any pricing model.
Egress is the number people forget entirely, and it is the one that scales with success. Estimate it from your traffic: bytes served per month equals requests times average response size. If you serve media, put a CDN in front — CDN egress is normally cheaper per gigabyte than origin egress, and the cache absorbs most of the requests. Converting between the transfer rate your monitoring reports and the monthly volume your invoice charges for is exactly what the Mbps to MB/s converter does.
Two neighbouring calculations complete the picture. If part of your spend is an AI feature calling a hosted model, that line is priced per token rather than per hour — the LLM API token cost calculator handles it. And if you are deciding whether to keep storage on-premises instead, compare the cloud figure against the drive purchase in the RAID capacity calculator, remembering that the cloud price includes replication, power, cooling and replacement that your own array does not. Availability commitments are worth checking too: the MTBF and availability calculator turns a provider's SLA percentage into the outage minutes you are contractually allowed, which is often the deciding factor between a single-zone and a multi-zone design — and multi-zone changes the transfer costs above.
Finally, a note on IP addressing, because it affects cost more than it used to: most providers now charge for public IPv4 addresses whether attached or idle. Sizing your subnets and NAT strategy deliberately — see the hosts per subnet calculator — keeps that line small.