A Florida hospitality group ran four seasonal travel brands on one AWS estate. The buyer side response cut the compute contract 20 percent without moving a single workload off AWS.
A Florida hospitality group cut its AWS compute contract by 20 percent, roughly 480 thousand dollars a year against a 2.4 million dollar baseline, without moving a single workload off AWS. The saving came from commitment shape and instance choice, not a discount fight. The estate ran four seasonal travel brands behind one shared platform.
The group had drifted into a familiar pattern. Savings Plan coverage sat low, the fleet ran on x86 by default, and instances were sized for a peak that only one brand hit at a time. The buyer side response rebuilt the compute baseline around the combined, counter seasonal demand curve.
The client is a privately held hospitality and leisure group headquartered in Florida. It runs a portfolio of consumer travel booking brands on one shared AWS platform, with a common booking engine, a shared search tier, and brand specific front ends.
The group asked one question. The AWS bill kept climbing while bookings stayed flat across the off season. The buyer side answer was that the compute baseline had never been rebuilt around how the brands actually share load.
Four consumer brands sit on the platform. Their peaks fall in different seasons, which is the heart of this case study.
Annual compute spend ran at 2.4 million dollars across EC2, a managed database tier, and a search cluster. Savings Plan coverage sat at 35 percent. The fleet was almost entirely x86. Non production environments ran around the clock.
The 20 percent saving sat on four levers, each carrying a measured business case. None of them required a workload to leave AWS. The table sets the before and after on each lever.
The four compute levers, before and after
| Lever | Before | After | Result |
|---|---|---|---|
| Savings Plan coverage | 35% | 78% | Lower steady rate |
| Graviton share of fleet | Under 5% | 40% | Better price performance |
| Instance sizing | Peak sized | Load matched | Fewer idle cores |
| Non production hours | Always on | Off out of hours | Wasted hours removed |
Coverage rose from 35 percent to 78 percent of steady state. The buyer side model committed against the combined demand floor across all four brands, not against any single brand peak. Compute Savings Plans were chosen over Reserved Instances so the commitment held while the fleet reshaped to Graviton.
Around 40 percent of the fleet moved to AWS Graviton. The web tier, the API tier, and the search workers all moved cleanly and returned a 15 to 20 percent price performance gain. The database tier and two licensed components stayed on x86 where the move carried risk.
Instances had been sized for the busiest brand at its own peak. We matched each tier to its measured load and let auto scaling absorb spikes on demand. The idle core count fell sharply across the off season months.
Development and staging environments had run around the clock. We scheduled them to stop overnight and at weekends. The change took two days to implement and removed a steady block of wasted compute hours.
Counter seasonal demand means the combined baseline is far steadier than any single brand. When golf and beach traffic falls, ski traffic rises, so the shared floor barely moves. That steady floor is exactly what a Savings Plan should be sized against.
The new commitment was built to survive the next budget year, not just to cut this one. Five structural choices held the saving in place.
The 20 percent saving did not come from leaving AWS. It came from sizing one commitment against the demand the four brands actually share, then moving the elastic tiers to Graviton.
If your AWS compute bill is climbing while usage stays flat, the buyer side response starts with measurement. The ordered checklist below mirrors the engagement that closed this case.
Redress runs AWS compute optimization inside the Vendor Shield subscription, the Renewal Program, the Benchmark Program, and the Software Spend Assessment. Every engagement starts with a trailing usage analysis.
Read the related benchmarking, about us, locations, and contact pages. Or open the AWS advisory practice for the full scope.
The common advice is to buy the deepest three year, all upfront commitment you can, because the rate is lowest. We disagree for a business like this one. A fleet that is actively migrating to Graviton and reshaping instances should not lock its whole spend into a rigid three year shape, because the very changes that cut the bill can strand a commitment bought against the old fleet. The buyer side move on the AWS Cost Management data is to commit a flexible Compute Savings Plan against the steady combined floor on a one year term, take three year Reserved Instances only on the fixed database nodes, and review coverage every quarter. You keep most of the discount and all of the flexibility.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
An AWS compute commitment rewards the buyer who sizes against the floor they can evidence. Buying the deepest rate against a fleet you are about to change buys discount you pay back in stranded commitment.
The Florida hospitality group cut its annual AWS compute spend by 20 percent, roughly 480 thousand dollars a year against a 2.4 million dollar baseline. The saving came from Compute Savings Plans coverage, right sized EC2, a Graviton migration, and seasonal scheduling. No workload was moved off AWS.
Four levers drove the saving. Compute Savings Plans coverage rose from 35 percent to 78 percent of steady state. Roughly 40 percent of the fleet moved to Graviton. Oversized instances were right sized against measured load. Non production environments were scheduled off out of hours.
The brands carry counter seasonal demand, so the combined baseline is far steadier than any single site. Golf and beach traffic peaks in the warm months while ski traffic peaks in winter. We sized one Compute Savings Plan against the combined floor and let auto scaling absorb each brand peak on demand.
A Compute Savings Plan is a one or three year commitment to a steady hourly compute spend in exchange for lower rates. It applies across instance family, size, region, and operating system. That flexibility fit a fleet that was actively migrating to Graviton and reshaping instances during the engagement.
Roughly 40 percent of the compute fleet moved to AWS Graviton processors during the engagement. Graviton delivered better price performance on the web tier, the API tier, and the search workers. The remaining fleet stayed on x86 where a dependency or a licensed component blocked the move.
The group standardized on Compute Savings Plans for the elastic web and API fleet and kept a small set of Standard Reserved Instances for the fixed database tier. Compute Savings Plans gave the flexibility the migrating fleet needed. Reserved Instances held the steady database nodes that never change shape.
Redress ran the buyer side advisory across the usage analysis, the commitment model, the Graviton business case, and the AWS commercial conversation. We are independent of AWS and carry no AWS Partner Network status. The engagement was paid by the client, never by AWS.
The engagement ran about four months from the first usage pull to the signed Savings Plan and the migrated fleet. The first month was measurement. The middle two months were the right sizing and the Graviton migration. The final month locked the commitment at the new, lower baseline.
A buyer side reference on Compute Savings Plans, Reserved Instances, Graviton migration, and the coverage math that holds the saving through a fleet change.
Independent. Buyer side. Written for CFOs, heads of platform, and procurement leaders. No vendor influence. No sales kickback.
AWS Savings Plan Optimization Guide
Open the white paper in your browser. Corporate email only.
Read the Paper →The bill fell 20 percent and nothing left AWS. We just sized one commitment against the demand the brands actually share, then moved the elastic tiers to Graviton.
We have run 500+ engagements across 11 publishers. Every engagement starts with one conversation.
Savings Plan coverage math, Graviton migration patterns, right sizing tactics, and the commitment review calendar across every AWS engagement we run.
