We've been building on AWS since 2008, much of it regulated data platforms, payment systems and AI workloads for companies where a failed audit costs more than the migration that would have prevented it. CFOs tend to describe the same pattern to us. A cost program launches, the first quarter shows a healthy drop, and by the third quarter spend is climbing again. The industry numbers agree. In Flexera's 2026 State of the Cloud survey, wasted cloud spend rose to 29%, its first increase in five years, even though 63% of respondents now have a dedicated FinOps team.
To keep this concrete, we'll follow a made-up but typical company: a US healthcare billing firm with about $700 million in revenue, listed on Nasdaq, that processes claims for hospital groups and takes patient payments online. It rehosted its data center onto AWS in 2023 and runs a subsidiary in Dublin that serves clinics across the EU. Its AWS bill is about $850,000 a month. Last year's cost push did what most do, with rightsizing, a cleanup sprint and a three-year Compute Savings Plan. The bill fell about 14% by April and was back above its starting point by September.
In most estates we look at, it's a handful of choices made during the migration, plus a few that nobody got around to making. Cost Explorer can tell you which services cost the most. It can't tell you that the database is expensive because of a license, or that the warehouse is expensive because it was sized for three days a month. The cause map below is what we'd fill in during the first week.
When the billing company's bill went through it, most of the big rows lit up. Its claims database was Oracle Database Enterprise Edition on four large EC2 hosts, running on licenses brought over from the data center, and Oracle support alone cost about $900,000 a year, with the renewal due in June 2027. Its Redshift cluster had been sized for month-end close and never scaled down, so it ran all night and all weekend for queries that came in on weekdays. The claims pipeline pulled documents out of S3 through NAT Gateways and paid a processing fee on every gigabyte. Seven years of application logs were sitting on S3 Standard. The payment portal was on RDS for MySQL 8.0 and had been paying Extended Support since August 1, 2026. And about a third of the bill had no owner tag, so nobody could say which product it belonged to.
None of those are things a dashboard fixes. Each one is a change somebody has to design, test and cut over, which is why we read the right-hand column of the map as a list of engineering projects, each with an owner.
They run out of things to cut. Rightsizing, Savings Plans and Reserved Instances, Spot, idle-environment cleanup and tagging all belong in a program, and we'd never tell a client to skip them, but none of them changes how much capacity the architecture asks for. Once the obvious waste is gone, spend starts climbing again on its old slope.
Last year at the billing company went exactly like that. The team dropped oversized instances a size or two and deleted test environments nobody had touched in months. Then finance bought a three-year Compute Savings Plan sized against the EC2 footprint, Oracle hosts included. By September, claim volume was up 9%, a new AI pilot had come online, and the bill was back above where it started. The catch in that plan showed up when we read the fine print. A Compute Savings Plan applies to EC2, Fargate and Lambda, and Aurora isn't on the list, so once the claims database leaves its EC2 hosts, other EC2 work will have to soak up the commitment. The tools kept producing recommendations all year, too, and most of them ended up in a backlog that lost to roadmap work every sprint.
The rehost sits underneath all of it. A lift-and-shift brings the data center's access patterns, ungoverned data and fixed capacity along, and then AWS bills for them by the hour. Ammar Nizami, a senior forward-deployed engineer on our team, compared the two approaches in his piece on rehost vs. replatform, and his numbers are blunt: "Rework runs 30 to 45 percent of the original migration effort for rehost within 12 to 18 months," compared with 15 to 25 percent after a replatform.
AWS makes a similar point in its Well-Architected Framework, where cost is something you design for, like reliability or security. The billing company had been treating it as a purchasing problem. The table below compares the two ways of working.
It needed both columns and did them in the wrong order. Buying the long commitment before fixing anything structural is the sequencing mistake we run into most.
Commercial database licenses are the biggest cost we find that a FinOps tool can't touch. If the instance is license-included, the Oracle or SQL Server Enterprise fee is baked into every hour it runs. If the license was brought from the data center, as the billing company's was, the contract terms come with it, along with Oracle's core-counting rules and the chance of an audit. Finance teams have caught on: 64% of respondents to the FinOps Foundation's State of FinOps 2026 said they now manage licensing costs, against 49% a year before.
Deferred upgrades add a quieter tax. The billing company's payment portal found that out on August 1, 2026, the day after RDS for MySQL 8.0 left standard support. Every instance on it now pays Extended Support on top of its normal hourly price. In US East (Ohio) that's $0.100 per vCPU-hour in the first two years and twice that in year three. Upgrading to MySQL 8.4 stops the charge, and next to the Oracle work it's a small job, so we'd do it in the first month.
Of the four paths, only converting the engine takes the license line off the bill, and that's the one the claims database needs. We'd treat the renewal date as the real deadline. For the billing company that's June 2027, so the plan runs backward from it, with cutover by the end of April and a parallel run before that. A validation harness compares the new database against the live Oracle system claim by claim. If the conversion slips past the renewal, the company pays for another year of the support it was trying to drop. That's why we run application and database modernization to a fixed retirement date rather than an open-ended project plan.
Synaptics was in the same spot. Everyone agreed its Oracle-bound design analytics should move, and nobody had the hours to staff the work. In the Synaptics Oracle migration, agents took on the schema analysis, code conversion and validation harness, forward-deployed engineers owned the cutover, and the workload moved to Amazon RDS on a fixed date. The case study sums up the result: "The license renewal that was inevitable became the budget that funded the next initiative."
For CFOs, this is also where the AI budget is hiding. Our case for funding AI from your existing budget starts with the same lines on the bill: the license renewal nobody wants to defend, the warehouse no new workload runs on, and the integration tier that bills hours to keep itself alive.
Mostly as capacity that's billed whether or not anyone is using it. A warehouse that came over from the data center behaves the way it did there. It scans whole tables, keeps its old partitions, stays sized for the busiest hour of the quarter and parks cold data on the most expensive storage, except that now every one of those habits is metered. Steady traffic on on-demand pricing and spiky traffic on fixed capacity are still the two most common ways we see teams overpay.
The billing company's Redshift cluster is the second kind. It was sized for the three days of month-end close, when finance reruns every report, and it runs at that size for the rest of the month. Most of its tables are reloaded in full every night, even though only the previous day's claims changed. The fix we'd propose starts with the history, which would move to Apache Iceberg tables on Amazon S3. The nightly loads would become incremental, picking up only the day's changes, and queries would run on serverless or scheduled compute that stops billing when the work stops. Claim files kept only for compliance would drop to cheaper storage tiers through lifecycle rules or S3 Intelligent-Tiering.
We start our data platform modernization work with exactly this kind of inventory, because it shows which fix pays back first. When we moved Plume's analytics to an AWS lakehouse with AWS Professional Services, its analytics run-rate fell 58%, averaged across the 20 workspaces it moved.
Network costs follow topology, and topology is usually an accident of history. The billing company's claims workers sit in private subnets and read documents from S3 through NAT Gateways in three Availability Zones, so every gigabyte pays a data processing charge on top of the hourly one. A gateway VPC endpoint for S3 removes that charge, because AWS bills no data processing or hourly charges for gateway endpoints. It's a route table change, not a project.
Cross-AZ traffic is the next place to look. Measured per service, it usually points to a few chatty services that could share a zone without hurting the resilience design. Public IPv4 addresses come after that. AWS has charged $0.005 per public IPv4 address per hour since February 1, 2024, whether the address is attached to anything or not, and most estates have a few nobody can explain.
AI workloads are adding new causes faster than anything else we see. The billing company's claims-summary pilot runs on a GPU-backed endpoint that stays up overnight and on weekends, when nobody reads summaries. Idle endpoints like that one, duplicate vector stores built by separate teams, and retrieval pipelines that re-embed unchanged documents add up quietly. About one in five respondents in McKinsey's 2026 State of AI survey said AI operating costs, tokens included, had held back their use of AI. We'd give the pilot a unit cost, such as cost per summarized claim, and design the endpoint and retrieval path around it before it reaches production.
Compliance drives cost in two directions. Teams over-provision to stay safe, with full production copies in every environment, every log kept forever, and every workload running active-active across regions. Then, when finance pushes back, the same rules become the reason nobody is allowed to touch anything. The way out is to design compliance into the architecture so that audit evidence is a byproduct of how the system runs.
The billing company answers to more of these rules than most. It handles PHI for hospital groups, so HIPAA applies, and its payment portal is in PCI DSS scope. As a listed company it runs SOX controls over financial reporting, and the Dublin subsidiary's clinic data falls under GDPR. The figure below maps the main US and EU rules to the cost lever each one controls.
Two patterns cost regulated companies the most. The first is uniform resilience: every workload gets the most expensive recovery design because nobody tiered them. At the billing company, internal reporting runs active-active across two Regions, just like claims intake does. The second is retention by default.
Its seven years of logs on S3 Standard came from a policy that said to keep everything, not from any rule. PCI DSS v4.0.1 asks for twelve months of audit log history with the latest three immediately available, and HIPAA's six-year retention applies to the security documentation the company is required to keep. That's a lifecycle policy, with S3 Object Lock where a record must stay unaltered. Neither change weakens a control.
Built this way, the evidence comes with the system. In our branded payments modernization, agents generated the tests and parallel-run instrumentation while engineers sequenced the cutover, and the regulated payments platform came through with "No audit incident during cutover." For a healthcare company the same logic applies to PHI. Teams that capture audit evidence inside the claims workflow stop paying for parallel, manual controls.
The Dublin subsidiary adds one more date. Under the EU Data Act, cloud providers can't charge switching fees from January 12, 2027, and until then they may pass on only the direct cost of switching. Routine transfer between Regions or Availability Zones isn't covered. For the billing company, that mostly changes the exit-cost line in its cloud risk register.
In five phases, and none of them closes until finance and engineering both sign the gate at the end of it. This is the sequence we'd recommend to a CFO and CTO, whether they run it themselves or bring in help.
Here's how that would play out at the billing company. The first two weeks go to tagging, until the untagged third of the bill has an owner. Then the cause map gets built and ranked by payback, and the CFO and CTO sign off on the Oracle claims database as the first fix, with a ship date ahead of the June 2027 renewal. The conversion to Aurora PostgreSQL takes about a quarter and is done in slices, with every difference from Oracle explained before anyone signs. After cutover, the Oracle hosts get switched off and the support contract is allowed to lapse. Only then does the company buy new commitments. Database Savings Plans, which AWS added in December 2025, cover Aurora at up to 35% off on a one-year term, so the new database finally gets a discount that fits it.
The order matters more than it looks. Attribution comes first because you can't rank causes you can't see. Commitments come last because you want to buy them against the footprint you are keeping. Retirement gets its own phase because savings only become real when the legacy system is switched off and its license is cancelled; until then, you are paying for two systems.
Keep the math simple enough for a board slide and honest enough to survive the CFO's red pen. We'd add up what the cause costs to run for a year, meaning licenses, infrastructure and the hours people spend keeping it alive, and compare that with what the new design will cost at realistic utilization. The one-time cost covers the modernization fee, internal hours and the parallel run. Divide it by the monthly difference and you have the payback period.
For the billing company's claims database, the old setup costs about $1.5 million a year. Oracle support is $900,000 of that, the EC2 hosts with their standby copies and storage come to about $420,000, and DBA time is roughly $180,000. Aurora would run about $460,000 a year with support. Add the conversion, internal hours and a four-week parallel run, and the one-time cost comes to about $780,000. Nine months later the project has paid for itself, and that put it first on the billing company's list. When we rank causes for other companies, a licensed database or an always-on warehouse usually ends up first as well, and its renewal or capacity date sets the schedule.
|
Metric |
What it tells you |
Direction you want |
|---|---|---|
|
Share of spend attributed to an owner and product |
Whether anyone can act on the bill |
Up, and staying up |
|
Unit cost (per transaction, customer, claim, or inference) |
Whether efficiency improves as the business grows |
Down, or flat while volume grows |
|
Spend on commercially licensed database engines |
Exposure to renewals and audits |
Down after each conversion |
|
Legacy systems decommissioned |
Whether savings are real or still on paper |
Up, with a signed decommission record |
|
Commitment coverage on target-state workloads |
Discount captured without locking in old designs |
Up after cutover, not before |
|
Cost estimate attached to new architecture changes |
Whether causes are stopped before they ship |
Every material change, every time |
That last metric is where cost discipline becomes part of how you ship software. Practitioners are asking for the same thing. In the State of FinOps 2026 report, pre-deployment architecture costing "emerged as a top desired tool capability," which makes sense, since estimating cost before deployment is far cheaper than finding the cause on next month's invoice.
On timing, 12 weeks is our median to production across engagements. Each of those followed how we work, with the client signing off every phase and a decommission record at the end.
Most companies need visibility tooling plus someone accountable for the structural fix. The real decision is who carries the delivery risk when that fix touches a production database or a regulated workload.
For the billing company, the tooling stays. Cost Explorer and Cost Optimization Hub, which AWS provides at no additional charge, keep surfacing rightsizing and idle-resource work for the platform team. The Oracle conversion is a different kind of decision. It touches the database every hospital client depends on, so the question is who pays if cutover slips past June 2027.
Whichever route you choose, put these questions to any AWS cost optimization consulting provider before you sign. The answers separate firms that have skin in the game from firms selling hours:
Our own answers to the first two are written into our delivery commitment: a single date, and overage we absorb when the delay is ours. Delays on the customer side convert to time and materials at a rate disclosed up front. If a provider can't answer these questions in writing, that tells you who will be on the hook when the timeline slips.