How I Cut a $200K/Year Cloud Bill by More Than 70%: A Solo GCP to Azure and AWS Migration

How do you cut a $200K/year cloud bill by more than 70%?

By changing what you pay for, in a fixed order: secure credits, place each workload where its pricing is best, move steady workloads off per-request billing onto reserved capacity, tier storage, route model calls, and retire the DevOps queue. That took AccioJob's run rate from more than $200K a year to under $60K.

I did it at AccioJob, where I am Head of Engineering, and I did it alone: a full migration from GCP to Azure and AWS with no external DevOps support and zero downtime. The stack on the other side is ordinary: Terraform, Docker, Kubernetes, PostgreSQL and Redis. Nothing below depends on a tool you cannot buy or download today.

Most teams run the levers in reverse. They start with instance right-sizing, which is per-resource work with per-resource payoff, spend a quarter on it, and conclude that cloud cost is the price of doing business. Right-sizing came after the architecture work here, and it was the smallest of the changes.

Treat the numbers as one estate's, not a benchmark. The split of the bill, the credit amounts and the timeline will differ for you. What transfers is the order of the changes, and the rule that every change is measured at list price before anyone calls it a saving.

Where was the $200K a year going?

Into four places: compute and managed services billed per request (about $120K a year), over-provisioned databases and storage not tiered by access (about $40K), AI inference whose cost grew in a straight line with usage (about $40K), and a DevOps function that every deploy and incident queued behind. The split is approximate; the projected total was more than $200K.

Per-request pricing was the biggest line and the most avoidable. The infrastructure had grown organically on GCP, and managed services that bill per request are the right choice when you do not yet know your load. By the time I looked, much of that load was steady: the same services, busy all day, paying an elasticity premium for elasticity they never used.

The inference line was the fastest-growing. Its cost scaled in a straight line with usage, and nothing routed easy requests to a cheaper model. The databases were over-provisioned for the load they carried. And the DevOps role was a cost twice over: a salary, and a queue that slowed every change that touched infrastructure.

Before any of this was fixable it had to be visible. I mapped three months of billing data line by line before changing anything. That step produces no saving on its own, which is why most teams skip it, and every later decision depended on it.

Why secure cloud credits before changing any code?

Because credits pay for the destination while both clouds are running, and that overlap is usually the most expensive part of a migration. With both applications in before the first workload moved, $200K from Microsoft for Startups and $100K from AWS Activate, no deadline forced a rushed cutover.

The applications were pitches, not forms. What carried them was high-volume production AI usage already running, named workloads with their current volumes, and a specific account each provider would keep after the credits ran out. Providers award large credits to workloads they expect to keep. An application that shows real traffic and a migration date gives them something to underwrite; a projection deck does not.

The published programmes have moved since. Microsoft now advertises up to $150,000 on its Microsoft for Startups page, less than the $200K I received. AWS Activate lists up to $200,000 on its Portfolio tier, which needs an Organization ID from an Activate Provider, for pre-Series B companies founded in the last ten years. The full walkthrough is in how to get cloud credits.

One rule kept the credits honest: I did not count them as savings. The 70% is the list-price run rate after the re-architecture. The credits covered bills during the move and bought time to do it properly, and a cost model that only works while someone else pays for compute has a cliff in it.

In what order did the migration run, and how did it avoid downtime?

In four phases over about four months: audit and credit applications, workload placement, steady workloads moved to reserved capacity, then cross-training and retiring the DevOps role. Within each move, stateless services went first behind a traffic-shifting layer, the primary datastore went last, and a rollback path stayed live until the destination had proven itself.

Placement was decided per workload, by price and credit position, not by preference. Loosely coupled workloads with their own data can sit on a second cloud with little coupling cost, because they talk to the rest of the system across an API rather than a shared database. Tightly coupled pieces stayed together, because splitting a chatty service from its database across two clouds would have spent the credit on cross-cloud traffic.

Zero downtime came from sequencing, not tooling. Stateful systems were replicated and cut over with a short write pause rather than an outage, and the rollback path stayed warm until the events that worried me had passed. The egress, dual-running and identity costs of a move like this are broken down in GCP to AWS migration cost.

Budget for the data to move more than once. A migration that cannot take a long outage copies data at least three times: a bulk sync, one or more delta syncs, and a final catch-up at cutover. That makes deleting data nobody needs, before the first sync, the cheapest saving in the project: it shrinks the transfer bill and the destination's storage bill at the same time.

Which cloud cost changes removed the most money?

Moving steady workloads off per-request managed services onto self-hosted equivalents on reserved capacity removed the most. The other changes were placing each workload where its pricing and credits were best, removing per-gigabyte network paths, aggressive storage tiering, and model routing for inference. Right-sizing mattered least.

The test for each workload was simple. If it runs all day at a predictable load, per-request pricing charges a premium for elasticity it never uses, and reserved capacity is cheaper. The published ceilings show the size of that premium: AWS lists up to 72% off on-demand for EC2 Instance Savings Plans and up to 66% for Compute Savings Plans (AWS), and Azure lists up to 72% for reserved virtual machines (Azure). Spiky workloads stayed serverless, because moving them would have cost more.

Storage and network were the quiet lines. Rarely read data moved to colder classes: on AWS, S3 Standard is $0.023 per GB-month against $0.00099 for Glacier Deep Archive, per the rates in the AWS cost optimization checklist. Per-gigabyte network paths were removed wherever a cheaper route existed, because a per-gigabyte meter never shows up in a CPU graph.

Inference got its own treatment. Routing sends each request to the cheapest model that handles it well and keeps the expensive model for the requests that need it, which breaks the one-to-one link between usage and cost. Routing, caching and batching are covered in LLM inference cost optimization.

How did removing the DevOps function save money without slowing delivery?

By cross-training application engineers to own deploys and infrastructure, so the role stopped being a queue. Every deploy, infrastructure change and incident had routed through one person, which was expensive and slow. Once the estate was simpler, engineers could own their own changes, and delivery held because the bottleneck left with the line item.

The order matters. Cross-training came last, after the architecture had removed most of what a specialist had been needed for. Asking application engineers to own a sprawling estate of per-request services and hand-tuned databases would have moved the queue, not removed it.

It is the same lean-team logic as a separate change I made to the engineering organisation, restructuring 20 people into a cross-functional team of seven and taking its run rate from $60K to $12K a month. A small team with broad skills can move without coordinating across silos, which is also why one person could run the migration.

The caveat: this works when your infrastructure is simple enough for application engineers to own. If you run multi-region Kubernetes under strict compliance requirements, keep the specialists.

What did the migration save, and what did the credits pay for?

The run rate fell from more than $200K a year, projected, to under $60K, a cut of more than 70% at list price, and the dedicated DevOps role went to zero. Separately, $300K of credits covered the bills on the destination clouds while they lasted. Only the first number is a saving; the credits were runway.

Why keep them apart? A saving that depends on credits disappears the day they expire, and the board sees the bill jump. A saving from architecture survives expiry. The credits were worth more used this way: they paid for the months when both clouds ran, on workloads that were already cheaper at list price.

Against the projected run rate, more than $140K a year stopped leaving the company, and it accumulates: every month the bill stays down is money that never leaves again. The other effect was slower to see. With the queue gone, infrastructure changes stopped waiting on one person, and cost became something engineers could see and act on.

Report a cut the same way if you want it to survive scrutiny: the run rate before and the run rate after, both at list price, with credits shown as a separate line. A cut that only exists net of credits will not survive the first review after they expire, and the team that reported it loses the credibility it needs for the next change.

What would I do differently next time?

Instrument list-price spend and tag every resource from day one. For a while the bill looked healthy because credits were absorbing it, and reconstructing the true unit economics afterwards took real time. The rule I would keep: buy commitments only after the architecture stops moving, never in the middle of a migration.

The tagging lesson is specific. I spent longer than I should have working out which team owned which line item, and every hour of that was an hour not spent cutting. On a fresh estate, tags are nearly free; on an old one, reconstructing ownership is the most tedious work in cost engineering.

The second lesson is about ownership. Nobody is promoted for lowering the cloud bill, so nobody owns it, and it grows until someone senior sees a number they cannot explain. Give one senior engineer the bill as a metric with a target. The return beats most features you could ship in the same quarter, and unlike most features it keeps paying every month.

How can you apply this playbook to your own cloud bill?

Run the same steps in order: map three months of billing by line, apply for credits before moving anything, classify every workload as steady, spiky or tiny, move steady ones to reserved or self-hosted capacity, tier storage and route model calls, then give one engineer the bill with a target.

Do not start with a migration. Most of the saving people expect from changing clouds (commitments, storage lifecycle rules, network paths, log retention) is available on the cloud you are on. Migrate only for a structural reason: a pricing model that fits your workload better, a service you need, a compliance requirement, or credits large enough to fund the move several times over, which is the position I was in.

Size the prize before spending engineering time on it. Put your current bill into the cloud cost calculator to see where the per-request and per-gigabyte lines sit. If the bill belongs to a product you have not built yet, the AI product cost estimator prices the build and its monthly hosting, with cloud credit applications as an option. Below about $2,000 a month, set billing alerts and revisit next quarter; the engineering time costs more than the saving.

If you would rather have the audit and the re-architecture done for you, that is cloud cost optimization: a fixed-fee audit that maps every leak, or a savings share where I implement the changes and am paid from the verified savings, so if your bill does not drop, I do not get paid.