Most cost-cutting projects and most modernization projects are run by different people, on different timelines, with opposite instincts. The cost project wants to freeze change and squeeze what exists. The modernization project wants to rebuild, which in the short term costs more. So teams pick one, and usually pick cost — which means the environment gets a little cheaper and stays exactly as fragile as it was.
We think that's a false choice. The most durable way to cut a cloud bill is to fix the reasons it's high in the first place, and those reasons — no guardrails, no standard patterns, every team inventing its own infrastructure — are the same reasons the platform is hard to secure and slow to change. Fix the foundation and the savings follow. On one recent public-sector migration, that approach took a client off an aging on-premises data center and into a governed Azure landing zone in under four weeks, and cut infrastructure cost by roughly half in the process. This is how that works.
Why cloud bills drift high
A surprising amount of cloud spend isn't buying anything. It's the accumulated cost of decisions no one revisited. A few patterns show up almost everywhere:
- Everything is provisioned for peak, all the time. Environments sized for the busiest hour of the busiest day run at that size at 3 a.m. on a Sunday. Non-production environments — dev, test, staging — often cost as much as production because nobody turns them off.
- Nothing has an owner. When a resource can't be traced to a team or a service, no one is accountable for whether it should exist. Untagged, unowned resources are the single biggest source of waste we find.
- The pricing model doesn't match the workload. Steady, predictable workloads run on on-demand pricing that assumes they might disappear tomorrow. Storage sits in hot tiers holding data no one has read in a year.
- Redundant everything. Two monitoring tools, three backup mechanisms, overlapping networking appliances — each added by a different team solving the same problem in isolation.
None of these are cloud problems. They're governance problems that a cloud bill makes visible. And that's the opening: the work that removes the waste is the same work that turns a sprawling environment into a managed platform.
A landing zone is a cost control, not just a security control
A landing zone is a pre-built, governed foundation for everything you run in the cloud — the networking, identity, policy, and deployment patterns that every workload inherits instead of reinventing. People usually justify it on security and compliance grounds, which is fair. But its effect on cost is just as direct, because a landing zone answers the exact questions that let bills drift.
When you provision workloads through a governed landing zone built with infrastructure-as-code — Terraform, following the Cloud Adoption Framework — several things become true at once:
- Every resource is deployed from a known pattern, so it's tagged, owned, and sized to a standard by default. Waste can't accumulate anonymously.
- Policy guardrails block the expensive mistakes before they happen: oversized SKUs, public endpoints that shouldn't exist, storage in the wrong tier, regions you don't operate in.
- Because the whole environment is code, it's reproducible — which means non-production can be torn down at night and rebuilt in the morning, and nobody's afraid to do it.
- Cost visibility is built in, broken down by team and service, so spend has an owner and a trend instead of arriving as one unexplained monthly surprise.
The savings aren't a separate initiative you run after modernizing. They're a property of having modernized correctly.
The sequence that saves money and de-risks at the same time
The order matters. Teams that chase savings first — resizing here, deleting there — get a one-time dip and then watch the bill climb back, because nothing stopped the drift. Teams that build the foundation first get savings that hold. A migration we ran for a public-sector organization followed this sequence, and it's the one we reuse.
Start with an honest assessment. Before touching anything, map what's actually running, what it costs, what it depends on, and what it's for. This is where you separate workloads worth migrating as-is from ones worth re-platforming and ones that should simply be retired. A meaningful share of the eventual savings is just switching off things that turned out to have no owner and no users.
Lay down the landing zone. Build the governed foundation in code — network topology, identity and RBAC, policy guardrails, cost tagging, deployment pipelines through GitHub Actions. This is the step that makes every later decision cheaper, because from here on, doing the cheap, safe thing is the default path rather than the exception.
Migrate in waves onto the standard. Move workloads onto the foundation in controlled waves, each one landing on the approved patterns. Right-sizing happens naturally here — you're not migrating the old oversized footprint, you're placing the workload on what it actually needs, on the pricing model that fits its behavior.
Then optimize continuously. Once workloads run on a governed platform, ongoing FinOps becomes a steady practice rather than an annual panic: reserved-capacity commitments for the steady baseline, autoscaling for the variable part, storage lifecycle policies that tier cold data automatically, and regular reviews that catch drift while it's small.
You don't cut a cloud bill once. You remove the conditions that let it grow — and that's the same thing as modernizing.
What "50%" actually requires
A halving of infrastructure cost is real and repeatable, but it isn't a discount you negotiate. It comes from stacking several independent reductions: retiring dead workloads, right-sizing the survivors, moving steady workloads to committed pricing, tiering storage to match access patterns, collapsing redundant tooling, and shutting non-production off when it isn't in use. No single one of these gets you to half. Together, on an environment that has never been governed, they routinely do — and because they're enforced by the landing zone rather than done by hand, the number stays down after the project ends.
The important part is what you're left with. The old way of cutting costs leaves you with the same brittle environment, slightly smaller. This way leaves you with a platform that is cheaper and auditable, reproducible, secure, and faster to build on — the savings and the modernization are the same asset, seen from two directions.
Where to start
If your cloud bill is climbing and your platform still feels fragile, resist the urge to treat those as two problems. They're one problem with one fix. Start with the assessment — you almost certainly can't see where the money is going yet, and the map is cheap to produce and immediately useful. From there, the landing zone is what converts a one-time clean-up into savings that last.
Deop helps organizations modernize onto governed Azure landing zones that are cheaper to run by design — with the FinOps practices to keep them that way. See how we approach public-sector cloud migration or explore our services.