Right-Sizing an Over-Provisioned Three-Tier Stack
A team runs a three-tier web application on AWS: an Application Load Balancer, an Auto Scaling group of 6 m7i.2xlarge instances (8 vCPU, 32 GiB) that rarely exceed 18% CPU but spike to 60% during a nightly batch, and a Multi-AZ RDS PostgreSQL db.r6g.4xlarge (16 vCPU, 128 GiB) whose average CPU is 9% and whose buffer pool hit ratio is 99.7%. The batch job runs 90 minutes and is latency-tolerant. The finance owner wants a 35% cost reduction within one quarter without changing the customer-facing SLA. The team has no reserved instances and no Savings Plans. They are nervous about breaking the nightly batch and about database failover behavior during any resize.
1. Propose a cost-reduction plan that meets the 35% target, and justify each move against the stated constraints.
Read the worked answer
Split the workload by shape rather than cutting uniformly.
- Compute (largest lever). The ASG is memory- and CPU-idle most of the day; 18% of an 8-vCPU box means roughly 1.5 vCPU of steady demand. Move steady web traffic to a smaller family (e.g., m7i.xlarge) via a new launch template and a rolling instance refresh, keeping min capacity high enough that a single AZ loss still serves traffic. Because the nightly batch is latency-tolerant, move it off the ASG entirely onto a scheduled batch path (e.g., Spot or a scheduled ECS/EC2 job) so the ASG no longer needs to be sized for the 60% spike. This lets the steady fleet be sized for 18%, not 60%.
- Commitment. After right-sizing, buy a Compute Savings Plan covering the new, lower baseline (not the old one). Committing before right-sizing locks in waste.
- Database. 9% CPU and a 99.7% buffer hit ratio on a 16-vCPU/128 GiB instance is over-provisioned. Resize down one or two steps, but do it via a Multi-AZ modification with a maintenance window, understanding that RDS performs the change on the standby first and then fails over, causing a brief write interruption. Validate the working set still fits in the smaller instance's memory before committing - the hit ratio is the guardrail, not CPU.
Sequence matters: right-size first, observe for two weeks, then purchase commitments sized to the observed baseline. That ordering is what makes 35% achievable without touching the SLA.
2. The team proposes instead to simply buy 3-year All Upfront Savings Plans on the current fleet to hit the target faster. Evaluate this.
Read the worked answer
It hits the number on paper but is the wrong judgement call for three reasons.
- It locks in the waste. A 3-year All Upfront commitment on an over-provisioned fleet converts a reversible sizing mistake into a three-year sunk cost. If the app is later containerized or moved, the commitment follows the usage, not the instance - but the usage baseline it was sized against was inflated.
- It maximizes financial risk for the least flexibility. All Upfront front-loads cash and gives the least ability to absorb a change in instance family or Region. A No Upfront or Partial Upfront plan on a right-sized baseline captures most of the discount with far less exposure.
- It doesn't address the database or the batch. Savings Plans cover compute, not RDS instance hours in the way the team assumes, and they do nothing about the 90-minute batch that forced the oversized ASG in the first place.
Better: right-size, then commit on the observed baseline with a shorter term and Partial Upfront, and revisit at renewal. The goal is a durable 35%, not a one-time accounting win.