This is an illustrative engagement built from typical gaming workloads: a $3.0M-a-year estate split across AWS and Oracle Cloud, carrying spiky match traffic on on-demand compute and terabytes of replay data on hot storage. The plays below take it to about $2.0M, a 34 percent reduction, with Spot fleets, storage tiering and OCI flexible shape rightsizing.
This page is an illustrative composite based on patterns we see across gaming workloads, not a specific named client. The figures are representative and demonstrate the method, not a single engagement result.
A multiplayer game studio runs match servers, matchmaking and live-ops on AWS, with a regulated player-data and analytics tier on Oracle Cloud, spending about $3.0M a year across the two. Player demand is spiky by nature: weekend and event peaks several times the weekday floor, plus a long tail of replay and telemetry data that is written constantly and read rarely. The estate had grown on on-demand EC2 sized for peak, OCI flexible shapes provisioned well above real utilization, and replay data sitting on hot storage indefinitely. There was no shared view of the two clouds and no plan to absorb the spikes cheaply.
$3.0M annual spend across AWS and OCI · match servers on on-demand EC2 sized for peak · oversized OCI flexible shapes · replay and telemetry data on hot storage · no unified view of the two clouds.
We ran the engagement in our standard order, See, Cut, Lock, Run, treating both clouds as one estate. The AWS side of the work follows our complete guide to AWS cost optimization; the headline move was matching the right purchase model to each workload's interruptibility rather than paying on-demand for everything.
We pulled AWS Cost and Usage Report data and OCI cost data into a single FOCUS-normalized view and fixed allocation by game title, environment and owner. That exposed how much of the AWS compute was stateless, fault-tolerant match capacity, exactly the kind of workload that belongs on Spot rather than on-demand.
Match servers and batch telemetry processing are stateless and tolerant of being reclaimed, so we moved them onto diversified Spot fleets across multiple instance families and Availability Zones, with on-demand and a small Savings Plan layer as the stable fallback. Spot can run materially below on-demand for the same capacity when the workload is built to handle the two-minute interruption notice. The trade-offs and the guardrails are in our guide to Spot Instances and when the discount is worth the risk. This was the largest single lever.
We applied lifecycle policies to move cold replay and telemetry data off hot storage into infrequent-access and archive tiers matched to how rarely it is read, and we right-sized the OCI flexible shapes down to real OCPU and memory utilization. Together these removed a second large block of waste with no impact on player experience.
We set budgets and anomaly alerts on both clouds and built one rolling forecast across the estate, with tagging and compartment policy blocking untagged deployments. That keeps the Spot mix and storage tiers from quietly reverting as new titles ship.
Annual spend falls from $3.0M to about $2.0M, a 34 percent reduction, recovering roughly $1.0M a year. The bulk comes from moving interruptible match capacity to Spot, with storage tiering and OCI shape rightsizing contributing the rest, all on a baseline that finance can finally forecast as one number.
The lesson that generalizes beyond gaming: match the purchase model to the workload, not the other way around. Spiky, stateless, fault-tolerant capacity belongs on Spot; the steady core belongs on Savings Plans; and only data that is actually read often belongs on hot storage. Pay on-demand for everything and you overpay for both the peaks and the troughs.
We will map your spend across every cloud, find the interruptible workloads, model the right Spot and commitment mix, and tell you the number. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Illustrative scenario. Figures are representative of typical gaming workloads and are not a specific client result.