What If We Ran on AWS or Google Cloud?

The Question, and What This Is Not

Grade My Investments runs on Azure. That was a deliberate choice — the stack is .NET end to end, the team knew Azure, and the tooling fit. But "we picked it and never looked again" is not an engineering position, it's a habit. So this page does the arithmetic: what would the identical system cost on Amazon Web Services and on Google Cloud?

This is a priced thought experiment, not a migration plan. Nothing here is a recommendation to move, and the conclusion is not "cloud X is cheapest." The interesting result turned out to be somewhere else entirely — see what the numbers actually say.

How These Numbers Were Produced

The Azure column is not an estimate. It comes from two live sources: the actual resource inventory of the gmiapp-prod-rg resource group, and the Azure Retail Prices API, which returns the same public rate card the portal quotes. Those figures were then reconciled against the real invoice via the Cost Management API, broken out per meter and per resource. The AWS and Google figures are published list prices for the equivalent SKUs.

Excluded throughout because they are cloud-agnostic and would not change: the market-data license ($50/month minimum), the Anthropic API, Twilio messaging, domain registration, and Azure DevOps. Those follow the platform wherever it runs.

Service Equivalence Matrix

Every Azure service in the platform, named alongside what it would be called on the other two clouds. Rows marked in use are live in production today; the rest are what the corresponding capability is built from instead.

Three rows are worth reading twice. The job queue, the ML runtime, and the LLM integration are all capabilities the platform has without renting a product for them — a MySQL table, an in-process library, and a direct HTTPS call. On every cloud in this table those would otherwise be three more line items and three more vendor dependencies.

Scenario A — Lift and Shift

The same shapes, moved as-is: always-on managed hosts for the front-ends and the API, a managed MySQL server, one always-on batch VM. No re-architecture. This is the honest comparison, because it is the one that requires no rewriting.

AWS lands about 28% below the current Azure bill and Google about 29% below — roughly $500 a year either way. That is a real number, but it is not the largest number on this page.

Scenario B — Built the Way Each Cloud Wants

Now allow re-architecture: the four front-ends are already static files, so they belong on object storage behind a CDN, not on a rented always-on host. The API becomes request-billed instead of always-on. The database and the batch VM are unchanged, because neither has a serverless shape that fits.

Note what happens to Google Cloud here: it wins Scenario A and loses Scenario B, because its external load balancer bills roughly $18.25/month for the first five forwarding rules whether anyone visits or not. Five custom domains means paying that toll on day one. CloudFront charges no fixed fee at all and includes 1 TB of egress and 10 million requests every month, permanently. Azure Static Web Apps' free tier covers this workload outright. For a small static estate, the CDN billing model matters more than the compute rate.

What the Numbers Actually Say

1. The architecture gap is bigger than the vendor gap

Between the cheapest cloud and the most expensive, the spread is about $43/month. Between the current architecture and a better one on the cloud already in use, the spread is about $67/month. The lever that matters is not the logo on the invoice. Anyone who answers "our cloud is too expensive" by shopping vendors is optimising the smaller of the two numbers.

2. The single worst line item is a Windows licence nothing needs

The most expensive resource in production is an App Service Plan running Windows at $54.75/month. The identical plan on Linux is $13.14 — the other $41.61 is the Windows licence. What it hosts is four sets of static files. Neither AWS nor Google has an equivalent premium here, not because they are cheaper, but because nothing in this workload was ever going to need Windows. That is a provisioning mistake, and it costs more per year than switching clouds would save.

3. A meter nobody had counted

Reading the invoice per-meter rather than per-service surfaced Paid IO LRS IO Rate Operations billed against the MySQL server at roughly $14.50/month — almost exactly what the database compute costs. Burstable MySQL tiers meter storage IO separately, and it had never appeared in any estimate because service-level totals hide it inside "Azure Database for MySQL." The real run rate is ~$147/month, not the ~$125 previously carried. AWS and Google both fold baseline IOPS into the gp3 / persistent-disk rate, so the equivalent line simply does not exist on either — worth about $170/year on its own.

4. Azure wins the database, loses the compute

Managed MySQL compute is genuinely cheapest on Azure: $14.02 for B1ms against $23.36 for RDS db.t4g.small and $26.00 for Cloud SQL db-g1-small. That advantage is then given straight back at the paid-IO meter. On raw compute the position reverses — the same 2 vCPU / 4 GB batch machine is $36.43 on Azure, $24.53 on AWS Graviton, and $24.46 on Google. ARM is the difference: Azure's burstable B-series has no Graviton-class equivalent at this size, and the workload is portable .NET that would run on ARM without modification.

5. Nothing here is locked in — on purpose

The reason this comparison is even possible to compute is that the platform never adopted a proprietary datastore. It is MySQL, which all three clouds sell. The job queue is a database table, not a queue product. Forecasting is an in-process library, not a hosted ML endpoint. Blob access is behind a single interface seam. Those choices were made for simplicity and cost, and portability came free as a side effect — which is the reverse of how most "multi-cloud strategies" are sold.

What Would Actually Have to Be Rewritten

The bill is the easy half. A cost comparison that stops at the rate card is worthless, because the migration is paid in engineering time, not instance-hours. Honest inventory of the work:

Estimate the serious rows at a few focused weeks. Against a saving of roughly $500/year at Scenario A prices, the migration does not pay for itself on cost alone — and saying so is the point of doing the arithmetic. The same weeks spent moving the four static sites off a Windows plan and onto free static hosting would save more, on the cloud already in use, with no migration risk at all.

Related Reading

• Lean Cloud Economics — how the bill got this small in the first place, and the capacity ladder above it
• Blob Storage Architecture — the storage layer this page prices
• Infrastructure as Code — the Pulumi stacks that make the rewrite row above a bounded job
• Azure Architecture — what is actually deployed today