How to Track and Optimize Cloud Costs Across Multiple AWS Accounts After a Big Migration

Key Points:

• The best post-migration stack has four layers, and most teams buy only one. Layer 1, visibility and allocation: AWS Cost Explorer plus Cost and Usage Report 2.0 in Athena (free), Vantage, CloudZero, or Apptio Cloudability. Layer 2, commitment and rate optimization: ProsperOps, nOps, or self-managed Savings Plans. Layer 3, resource waste remediation: CloudFix, AWS Compute Optimizer, Sedai. Layer 4, structural environment lifecycle: Qovery, or scheduling you build and maintain yourself.
• Build the free AWS-native foundation before you buy anything. AWS Organizations with consolidated billing, cost allocation tags enforced by tag policies and SCPs, Cost and Usage Report 2.0 exported to S3 as Parquet and queried in Athena, plus AWS Budgets and Cost Anomaly Detection. Every paid FinOps tool reads that same CUR, so bad tags in means bad dashboards out.
• Do not buy Savings Plans in the first weeks after a migration. Delete waste and right-size first, then commit against a stabilized baseline. A 1 or 3 year commitment bought on lift-and-shift usage locks in the exact over-provisioning you migrated to remove, and AWS Migration Acceleration Program credits make the first months' baseline fiction.
• Non-production is usually the biggest recoverable line item. An always-on dev or staging environment runs 168 hours a week for a team working about 50, so it sits idle roughly 70% of the time. Stopping or destroying it outside working hours removes that cost with no developer trade-off.
• Rank tools by which layer they own and whether they act on your infrastructure or only report on it. Cost dashboards are read-only. Qovery does not replace CloudZero, Vantage, ProsperOps, or Kubecost: it deploys apps inside your own AWS, GCP, Azure, or Scaleway account or your existing Kubernetes cluster (BYOC), and cuts spend structurally with environment auto-stop, per-pull-request preview environments, and shared right-sized clusters, so the bill, the EDP, and the Savings Plans stay in your name.

---

Most teams come out of a big migration and buy a dashboard. A dashboard has never deleted an idle environment.

If your job this quarter is tracking and optimizing cloud costs across multiple AWS accounts after a large migration, the honest answer is a four-layer stack, and almost every "top 10 tools" listicle stops at layer one. Layer 1 is visibility and allocation (AWS Cost Explorer plus Cost and Usage Report 2.0 in Athena, then Vantage, CloudZero, or Apptio Cloudability). Layer 2 is commitment and rate optimization (ProsperOps, nOps, or Savings Plans you manage yourself). Layer 3 is resource waste remediation (CloudFix, AWS Compute Optimizer, Sedai). Layer 4 is structural environment lifecycle (a platform like Qovery, or scheduling you build and maintain forever).

The reason this matters is that the waste is real and it is growing. Flexera's 2026 State of the Cloud Report, its 15th annual edition published in March 2026, puts estimated wasted cloud spend back up to 29%, the first rise in five years. The FinOps Foundation's State of FinOps 2025 found that reducing waste and optimizing usage was the top priority practitioners reported, ahead of everything else. So the market agrees on the problem. It just keeps buying the layer that reports on it instead of the layers that fix it.

Here is the part nobody in those listicles will tell you: do not buy Savings Plans right after a migration. I will come back to why that is the most expensive mistake on this list.

What actually goes wrong with cloud costs after a large migration?

Post-migration cost overruns are structural, not a pricing problem. The five recurring causes are on-prem-sized instances, always-on non-production environments, zombie resources like unattached EBS volumes and idle NAT gateways, per-team account sprawl with no tag hygiene, and AWS Migration Acceleration Program credits hiding the real run rate. A cost dashboard surfaces every one of them and fixes none.

Take them in order of typical dollar impact:

• On-prem-sized instances. Lift-and-shift copies the datacenter, including the 3x headroom you provisioned because buying a new server took six weeks. In the cloud that headroom is a monthly charge.
• Always-on non-production. Dev, staging, and QA get cloned from production sizing and then run nights and weekends for nobody. More on this in its own section, because it is usually the single biggest recoverable number.
• Zombie resources. Unattached EBS volumes, stale snapshots at $0.05 per GB-month, idle NAT gateways at $0.045 per hour plus $0.045 per GB processed, unused Application Load Balancers at $0.0225 per hour, gp2 volumes never moved to gp3, and every public IPv4 address now billed at $0.005 per hour whether attached or not.
• Account sprawl without tags. Consolidated billing rolls every account into one invoice. Without activated cost allocation tags, nobody can answer "whose $40k line item is this?"
• MAP credits masking the run rate. AWS Migration Acceleration Program credits offset your first months, so bill shock lands in month four to six, not month one. Any commitment baseline you calculate before credits burn off is fiction.

What should you set up in AWS before buying any cost tool?

Before you buy anything, build the free AWS-native foundation: AWS Organizations with consolidated billing, an enforced tagging standard, Cost and Usage Report 2.0 delivered to S3 as Parquet and queried with Athena, plus AWS Budgets and Cost Anomaly Detection. Every third-party FinOps tool ingests that same CUR, so buying one before this step just buys a prettier view of the same blind spots.

Do these in order:

• Turn on AWS Organizations with consolidated billing. Savings Plans and Reserved Instance discounts are then shared automatically across every linked account. When one team must not absorb another's commitment, the management account can turn discount sharing off per account from the same page.
• Enforce a tagging standard. Cost allocation tags can only be activated from the management account, and take up to 24 hours to appear in billing data. They apply going forward, not to history, so a late tagging program leaves a permanent blind spot on past spend. Enforce them with AWS Organizations tag policies and service control policies rather than a wiki page nobody reads.
• Export Cost and Usage Report 2.0 to S3. Through AWS Data Exports you get Parquet output with hourly, resource-level, multi-account granularity that Cost Explorer alone cannot give you. The report itself is free; you pay only for S3 storage and the Athena data you scan.
• Wire up alerting. AWS Cost Anomaly Detection is offered at no additional cost, and your first two action-enabled AWS Budgets are free before the $0.10-per-day charge kicks in.
• Do showback before chargeback. Assign a named owner to every account and every environment before you argue about numbers. That is the FinOps Framework's Inform phase, and skipping it is why cost meetings turn into blame meetings.

One pitfall deserves a loud warning: Kubernetes and shared EC2 instances break tag-based allocation. Dozens of workloads share one node and one instance ID, so no amount of tagging discipline tells you what the checkout service cost. That is the exact gap Kubecost and OpenCost fill, and tags will never close it.

Which tools track and optimize costs across multiple AWS accounts, and how do they differ?

No single tool covers all four layers well, so the honest answer for multiple AWS accounts is a stack: one allocation tool (Vantage, CloudZero, or Apptio Cloudability on top of CUR 2.0), one commitment engine (ProsperOps or nOps), one waste-remediation mechanism (CloudFix or Compute Optimizer plus scripts), Kubecost or OpenCost for shared clusters, and one platform layer that stops waste being created (Qovery). Rank vendors by which layer they own and whether they act on your infrastructure or only report on it, because that single distinction explains most disappointment with FinOps tooling.

Visibility and allocation. Vantage has a genuine free Starter tier (up to $2,500 in monitored cloud spend, three users) and paid tiers from $30 a month, and it is built for engineers. CloudZero and Apptio Cloudability are quote-based and lean toward finance and unit-cost reporting. CloudCheckr is now part of the Spot portfolio that Flexera acquired from NetApp in March 2025, so treat it as a Flexera product now. Amnic prices on cloud spend plus team size with a free 14-day audit. All of them read the same CUR you already have.

Commitment and rate optimization. ProsperOps automates Savings Plan and Reserved Instance laddering and charges a share of realized savings; it also promotes a metric it calls Effective Savings Rate, which is a ProsperOps definition, so read it as a vendor metric. nOps does commitments plus scheduling, with share-of-savings pricing on the rate side. Or you buy Savings Plans yourself off Cost Explorer recommendations, which is free and fine if someone owns it.

Automated waste remediation. CloudFix applies AWS-specific fixes automatically, such as gp2 to gp3 and idle-resource cleanup, and publishes a claim of cutting AWS bills by 20 to 35% (that is CloudFix's own marketing number). Its pricing is a flat fee scaled to your AWS spend, not a cut of savings. Sedai does autonomous rightsizing. Both mutate live resources, which is exactly why they need real change management and a rollback story before you point them at production.

Kubernetes cost allocation. Kubecost, now an IBM/Apptio product, and the CNCF OpenCost project (Incubating since October 2024) break cost down per namespace, per deployment, and per label inside shared clusters. Kubecost's free tier covers unlimited clusters up to 250 cores with 15-day retention. This is the one job tags cannot do.

Structural environment lifecycle. Qovery sits here, and I am keeping it to one line until the sections where it belongs: it reduces spend at creation and shutdown time instead of reporting after the fact. Details in sections 5 and 6.

One caution on pricing models. A tool that charges a percentage of your total cloud spend earns more when your bill grows, which is a quiet misalignment worth naming. Share-of-savings pricing (ProsperOps, nOps rate optimization) flips that incentive so the vendor earns only when you save, though it means handing over a slice of every saved dollar for as long as you use it. Neither is wrong. Just know which side of the table the meter is on.

How should you sequence cost work after a migration in the first 90 days?

Sequence the work by payback speed and reversibility: delete obvious waste in days 0 to 30, right-size and schedule non-production in days 30 to 60, and only buy Savings Plans in days 60 to 90 once your baseline stops moving. Committing in week two is the most expensive mistake teams make after a migration, because a 1 or 3 year Savings Plan locks the inherited over-provisioning in for the whole term.

Days 0 to 30, reversible and near-zero risk. Delete unattached EBS volumes, stale snapshots, and unassociated public IPv4 addresses. Remove idle NAT gateways and load balancers. Migrate gp2 to gp3 for a saving of up to 20% with 3,000 IOPS and 125 MiB/s baseline included. Apply S3 lifecycle rules and Intelligent-Tiering. Turn on Budgets and Cost Anomaly Detection.

Days 30 to 60, engineering effort and the biggest wins. Right-size with Compute Optimizer. Schedule non-production shutdown outside working hours. Test Graviton, which AWS states costs up to 20% less than comparable x86 instances, for supported workloads. Consolidate per-team clusters into shared, right-sized clusters.

Days 60 to 90, commitments. Now, and not before, buy Compute Savings Plans (up to 66% off On-Demand) or EC2 Instance Savings Plans (up to 72%) against the stabilized baseline. Ladder purchases in monthly tranches instead of one big buy. Add Spot for fault-tolerant and batch work, up to 90% off with a two-minute interruption notice. Re-check coverage and utilization every month.

Three warnings I will repeat because they cost the most: right-size before you commit; avoid 3-year all-upfront on anything you plan to refactor or containerize; and strip MAP credits out of the baseline before you calculate commitment volume. After that, move the conversation from monthly totals to unit economics: cost per environment, per service, per deployment, per customer.

Why does non-production spend dominate post-migration waste, and what actually fixes it?

Non-production is usually the largest recoverable line item after a migration, because dev, staging, and QA get cloned from production sizing and then run 168 hours a week for a team that works about 50. That is roughly 70% idle time, and only two things fix it durably: stopping environments automatically outside working hours, or destroying them entirely when the pull request merges.

Do the arithmetic in the open. A week has 168 hours. A team works maybe 50 of them. An always-on dev or staging environment is therefore idle about 118 hours a week, close to 70%, paying full price the whole time. AWS ships the Instance Scheduler on AWS solution specifically to start and stop EC2 and RDS on a schedule for exactly this reason.

The trouble is that the do-it-yourself fixes rot:

• Cron jobs and Lambda schedulers lose their owner. Exceptions pile up, someone disables the job after one bad demo, and the savings quietly disappear within a quarter.
• The durable pattern is ephemeral preview environments per pull request. Created on open, destroyed on merge, so idle cost trends toward zero without anyone remembering to switch anything off.
• Cluster consolidation compounds it. One shared, right-sized cluster with per-environment RBAC beats one cluster per team, because per-cluster control-plane fees stack up fast: EKS at $0.10 per cluster-hour, GKE at $0.10 per cluster-hour, and AKS charging for its Standard uptime-SLA tier. Multiply by account count and the arithmetic is obvious.

This is where Qovery fits naturally. It gives you git-push deployments, per-PR preview environments, environment auto-stop through Deployment Rules, managed cluster upgrades, and per-environment-type RBAC, all running inside your own AWS, GCP, Azure, or Scaleway account or an existing Kubernetes cluster. Because it runs in your account (BYOC), the bill, the EDP discounts, and the Savings Plans stay in your name. This is not AWS-only; the model is identical on GCP, Azure, Scaleway, or your own Kubernetes.

I will name the trade-off honestly, because it is real: environment auto-stop needs stateless-friendly workflows, seeded test data, and a shared agreement that non-production is not always-on. If a team insists staging must never sleep, this control does not apply to them, and that is a conversation, not a config flag.

Where does Qovery fit alongside CloudFix, ProsperOps, nOps, and Kubecost?

Qovery is complementary to FinOps tooling, not a replacement for it. CloudFix remediates AWS resources, ProsperOps and nOps ladder commitments, Vantage and CloudZero and Apptio Cloudability own chargeback reporting, and Kubecost and OpenCost allocate Kubernetes spend; Qovery changes how much infrastructure gets created and how long it runs. If you need chargeback reporting or autonomous commitment laddering, you still need one of the others.

Let me be explicit about who wins what, because credibility here matters more than a pitch:

• Chargeback and finance reporting belong to Vantage, CloudZero, or Apptio Cloudability. Qovery produces no amortized-cost or chargeback reports.
• Autonomous commitment management belongs to ProsperOps or nOps. Qovery does not buy or ladder Savings Plans at all.
• Automated AWS resource remediation belongs to CloudFix. It does gp2-to-gp3 and idle cleanup better than Qovery, which does not touch that layer.
• Per-namespace Kubernetes allocation belongs to Kubecost or OpenCost. Qovery does not replace them.

Where Qovery genuinely differs is BYOC and timing. Workloads run in your own cloud account, so the bill, the EDP discounts, and any Savings Plans stay with you, not on a vendor's consolidated invoice. It is cloud-agnostic across AWS, GCP, Azure, Scaleway, and bring-your-own-Kubernetes. And it reduces spend at creation and shutdown time, before the resource exists, instead of reporting on it after the invoice lands.

If you just migrated 20-plus AWS accounts, here is the stack I would actually build: AWS Organizations plus CUR 2.0 in Athena for the foundation, one allocation tool (Vantage if budget-conscious, CloudZero or Cloudability if finance-led), one commitment engine (ProsperOps or nOps), CloudFix or scripted cleanup for resource waste, Kubecost or OpenCost for shared clusters, and Qovery for environment lifecycle. Five layers, five owners, no overlap.

How do you keep costs across multiple AWS accounts under control after the migration?

Make cost a property of the platform and the deployment workflow, not a monthly report someone skims: route anomaly alerts to the owning team, publish unit-cost metrics next to engineering metrics, enforce tags and instance-type allowlists with SCPs at provision time, and give sandbox accounts and ephemeral environments a TTL. Teams that stall at the Inform phase of the FinOps Framework watch their savings decay within two quarters.

The pattern that lasts is guardrails at provision time over cleanup after the fact:

• Route Cost Anomaly Detection alerts to the owning team, not a central inbox. The person who can fix the spike has to be the person who gets pinged. Central FinOps queues become where alerts go to die.
• Track unit economics, not just totals. Cost per environment, per service, per deployment, per customer. The FinOps Foundation calls this out as its own Unit Economics capability, and it is what turns "the bill went up" into "we shipped 30% more and cost per customer fell."
• Review commitments quarterly. Refactors, Graviton migrations, and containerization all move the baseline you committed against.
• Enforce guardrails with SCPs and tag policies. Instance-type allowlists, mandatory tags, TTLs on sandbox accounts and ephemeral environments, and AWS Budgets actions that stop runaway spend before the invoice.
• Give the practice a named owner, even part-time. Unowned cost programs die quietly. The FinOps Foundation's own data shows teams stay small even at large scale, which means ownership has to be explicit or it evaporates.

The next step I would point you to is the FinOps Foundation Framework itself: map your team against the Inform, Optimize, and Operate phases, decide which capability you are weakest in, and buy or build for that gap rather than for the tool with the best demo.