The typical cloud cost story goes like this: migration happens, the first bill is a shock, someone gets assigned to 'look into cost optimization,' a dashboard gets built, and six months later the dashboard is still open in a browser tab that nobody's looked at since April. Cost governance added after the fact almost always ends up as observability without action, because by then cost decisions are baked into architecture that's expensive to unwind.
The alternative is treating cost as an architectural constraint from the landing zone design onward, the same way you'd treat security or availability. That means deciding on a tagging strategy before the first resource is provisioned, so it's never a thousand-resource retrofit later. And it means environment segregation obvious enough that dev, staging, and production spend can't be confused, enforced by the account or subscription structure itself, not by someone's memory.
It also means budgets and alerts configured as code alongside the infrastructure they're monitoring, so a new environment can't exist without cost visibility attached to it from the moment it's created. This is a small amount of extra setup work at the start and it eliminates the much larger cleanup project six months in.
The other piece people underweight: right-sizing needs revisiting continuously, because workloads never stay still. A landing zone designed well makes that cheap: reserved capacity decisions that can be reversed, autoscaling configured from day one rather than bolted on after someone notices a server idling at 4% utilization for a year.
None of this requires exotic tooling. It requires deciding, before the first workload migrates, that cost is a first-class design constraint rather than a problem for later. Later is expensive. Now is just a design decision.