FinOps in Practice: Three Documented Cost Reduction Engagements

Real organizations. Real dollar amounts. Real root causes — including the AI cost and security billing patterns that surface in almost every mature FinOps engagement today.

Case studies are only useful if the numbers are real. Every dollar figure in this article traces to a named, public source. Where the original report did not disclose the company name, that is noted. The engagement patterns described — what the investigation found, in what order, and what the fix was — reflect documented real-world implementations, not hypothetical scenarios.

Case Study 1 — Multi-Cloud FinOps: $840K Annual Savings (42% Reduction)

Source: StrivenNimbus case study, publicly documented.

Organization: FinTech company running AWS, Azure, and GCP. Cloud spend: ~$2M/month, growing 30% year-over-year with no corresponding revenue growth to explain it.

Root causes identified:

• Compute over-provisioning across all three providers — instances sized for peak load running at 15–25% average utilization
• Cross-cloud data transfer charges accumulating between providers — workloads designed to run in one cloud generating egress charges by calling services in another
• No unified billing view — each cloud billed separately, no cross-provider spend correlation, anomalies in one provider invisible to the team monitoring another
• AI workloads without cost attribution — ML training jobs on GCP with no project tags, Bedrock inference on AWS with no team attribution, spend growing without a clear owner

What changed: A unified FOCUS-schema pipeline normalizing billing data from all three providers into a single Athena table. This is the architectural prerequisite for cross-cloud cost correlation — the same query that finds an OpenSearch OCU orphan on AWS can find an equivalent pattern on Azure Cognitive Services or GCP Vertex AI when the data is in the same schema. After normalization: rightsizing across all three clouds, elimination of cross-cloud data transfer for workloads that could stay within a single provider, and AI spend attribution enforced at the IaC level.

Result: $840K annual savings — 42% reduction from $2M/month to approximately $1.16M/month. Achieved without reducing workload scale or engineering velocity.

The AI billing discovery: During the engagement, the team found Bedrock inference charges appearing under two different cost centers — the AI platform team was attributing their inference costs correctly, but a separate product team's RAG pipeline was charging to the platform team's budget because the Knowledge Base was created from the platform team's account without a project tag. The fix was a tagging policy enforced at deployment: every Bedrock resource requires a team and product tag before the IaC module completes. This is the pattern the Lambda tagging enforcer automates.

Case Study 2 — Enterprise Multi-Account: $1.5M Annual Savings

Source: GlobalDots case study, publicly documented.

Organization: Large eCommerce group with 74 AWS accounts spread across 16 business units. No centralized optimization practices — each business unit managed its own cloud spend independently, with no cross-account visibility.

Root causes identified:

• RI/SP coverage: only 23% of eligible compute running on commitments. The majority of workloads paying full on-demand rates despite predictable utilization patterns.
• Orphaned resources at scale: across 74 accounts, orphaned EBS volumes, unattached load balancers, and stopped EC2 instances accumulating independently in each account — invisible without a consolidated billing view
• No cross-account anomaly detection: a cost anomaly in account #47 was visible only to the business unit that owned account #47 — no organization-level alert would fire until month-end

What changed: Consolidated billing analysis across all 74 accounts. RI/SP purchasing aligned to actual utilization across the organization rather than per-account. Automated orphan detection running at the organization level — a Lambda function scanning all accounts for resources meeting orphan criteria (near-zero consumption, non-zero billing, no recent tags update).

Result: $1.5M annual savings. Primary driver was commitment purchasing at scale — when you can see utilization patterns across 74 accounts simultaneously, commitment sizing becomes dramatically more accurate than when each account makes independent purchasing decisions.

The security signal discovery: During the consolidated billing analysis, the team found two accounts with DataTransfer-Out-Bytes charges in regions those accounts had never used before. One turned out to be a developer testing a new region for a legitimate project without going through the change management process — shadow IT, not an attack. The other was a misconfigured CloudFront distribution routing traffic through an unexpected region. Neither would have been caught by the per-account billing reviews that had been in place before. The new-region zero-threshold rule would have caught both within 48 hours of the charges first appearing.

Case Study 3 — Mid-Market SaaS: Snapshot Cleanup and Rightsizing

Source: HARMAN International FinOps case study (Maximizing Cloud Efficiency), publicly documented.

Organization: Enterprise technology division running a multi-service AWS architecture. Cloud spend growing without a clear cost driver.

Root causes identified:

• ~9,000 obsolete EBS snapshots with no expiry policy — snapshots accumulate silently because there is no automatic cleanup and the storage cost per snapshot is small enough to avoid attention individually
• S3 storage without lifecycle rules — data written to S3 defaulting to Standard storage class indefinitely, including logs and analytics data that could be tiered to Infrequent Access or Glacier after 30 days
• No automated snapshot expiry policy — the same snapshots taken for a decommissioned workload 18 months earlier were still billing

What changed: Automated snapshot audit and cleanup (9,000 snapshots removed in a single remediation pass). S3 lifecycle policies applied to all buckets — 30-day transition to Infrequent Access for logs, 90-day transition to Glacier for archives. Automated expiry policy applied going forward: snapshots older than 90 days with no associated running instance are flagged for deletion review.

Result: Substantial reduction in EC2 and S3 storage costs evidenced in Cost Explorer from December 2024 onward. The HARMAN report notes S3 costs of approximately $55,000 in February 2025 — the cleanup was measurable in monthly billing data within the same period the remediation ran.

The pattern that repeats: In almost every FinOps engagement, the first pass through billing data finds a class of resources that have been billing for months or years without anyone noticing because the individual charge was small and the resource was not in anyone's active mental inventory. Orphaned EBS snapshots at $0.05/GB/month are invisible individually; 9,000 of them add up. The same pattern appears with OpenSearch Serverless collections ($11.52/day each), SageMaker endpoints ($17+/day each), and idle NAT Gateways ($0.065/hour). Detection requires a query that finds the pattern across all resources simultaneously — not a human manually reviewing a list.

The Common Engagement Pattern

Across these three cases and the broader body of public FinOps case studies, the investigation sequence is consistent:

1. Get a consolidated view first. You cannot optimize what you cannot see. The first action in every case was building or fixing the billing data pipeline — consolidated exports, queryable format, cross-account visibility.
2. Quick wins fund the program. Orphaned resources, over-provisioned instances, and missing commitments consistently produce 40–60% of the total savings and can be identified and fixed within the first 30 days. These wins create organizational momentum for the longer-duration optimizations.
3. Tagging is always a gap. In every engagement, some significant portion of spend is untagged or under-tagged. The consequence is not just reporting friction — it means cost anomaly alerts cannot route to an owner, security billing events cannot be matched to a known project, and the fastest-growing spend categories are the ones with the weakest attribution.
4. Cost and security signals emerge from the same data. The billing dataset that quantifies cost waste is also a security signal layer. New regions, new services, unexpected data transfer patterns — these appear in billing data generated by AWS's billing control plane, independent of the log pipeline a compromised account can tamper with. Building the cost detection layer also builds a second sensor for security events that neither GuardDuty nor a SIEM sees by default, with no additional data infrastructure.