A FinOps review finds ~$20-23K/yr across a multi-region media platform on AWS
An AWS-validated reference, published anonymized — the customer's name is held on file with VeUP and available on request.
A multi-region streaming-content and micropayment platform wanted to know where its AWS money was going — and how to get some of it back. VeUP took a FinOps review to the live multi-account org and answered with numbers: a per-service spend profile, quantified Graviton right-sizing, Reserved-Instance and Savings-Plans moves, a gp2→gp3 storage migration, and AWS Compute Optimizer to keep the discipline going.
The challenge
The customer runs a content and micropayment platform across multiple AWS Regions, with a database-heavy application tier and content delivery at scale. As usage grew, the AWS bill grew with it — and leadership wanted a clear, prioritized view of where the money was going and where it could be pulled back without touching the customer experience. The team didn't want a generic checklist; they wanted a per-service spend breakdown, concrete right-sizing and commitment recommendations they could action, and a repeatable mechanism to keep cost under control as the platform scaled.
The solution
VeUP ran a dedicated FinOps workstream against the live multi-account AWS organization. The review first mapped spend to its top five drivers — Amazon RDS (28%), Compute Savings Plans (20%), EC2-Other (11%), Amazon Managed Service for Prometheus (7%), and EC2 Instances (6%) — so every recommendation tied back to a real line of spend. The data tier came first: Amazon RDS moved onto Graviton generations (db.r5 → r6g/r7g, db.t3 → t4g) with Reserved-Instance commitment coverage, each move carrying a quantified monthly saving. Compute followed: newer-generation and Graviton EC2 families (t2 → t4g, c5 → c6g/c6i, m5 → m6i/m6g/m6a), plus on-demand headroom the existing Compute Savings Plans could absorb. Storage and network were tightened up — a gp2 → gp3 EBS migration, unattached-volume and idle-NAT-gateway cleanup, snapshot lifecycle policies, and data-transfer optimization. And to keep the gains, AWS Compute Optimizer became the standing right-sizing engine.
Production outcomes
| KPI | Result |
|---|---|
| Production outcomes | The customer got a full per-service cost profile of the live multi-account organization, with the top five spend drivers quantified as a share of total AWS spend. On the data tier, right-sizing plus a one-year, no-upfront Reserved-Instance commitment opened a savings band of roughly $480–$530 a month (~$387/month from the RI commitment alone). EC2 modernization added an estimated $180–$350 a month, with roughly $1,000 a month of on-demand headroom sitting under existing Compute Savings Plans. The gp2→gp3 migration cut EBS storage cost by about 20% (~$66/month), alongside cleanup and lifecycle recommendations. And AWS Compute Optimizer now stands as the ongoing cost-optimization mechanism. |
| Engagement window | The per-service FinOps review and quantified remediation plan landed in August 2024, and the relationship continues today. |
| Cost / TCO posture | Cost was the whole point. Quantified recommendations: RDS $480–$530/mo (incl. ~$387/mo RI), EC2 modernization $180–$350/mo, ~$1,000/mo of on-demand headroom under existing Savings Plans, EBS gp2→gp3 ~20% (~$66/mo), plus cleanup and lifecycle savings — with AWS Compute Optimizer keeping the discipline continuous. Figures are quantified recommendations, not measured realized savings. |
| Lessons & continuation | Tying every recommendation to a real per-service spend line (top-five drivers as a % of total) is what makes a FinOps review actionable rather than a generic checklist. Adopting AWS Compute Optimizer as the standing right-sizing engine turns a point-in-time review into ongoing financial governance — the savings discipline outlives the engagement. |
Architecture
The FinOps review in one picture — the estate as VeUP found it alongside the Graviton-modernized, commitment-covered target state, with the savings mapped to each component.

