Right-sizing instances from real observed utilization rather than guesses, S3 lifecycle policies as an easy cost lever, reserved instances vs savings plans for predictable workloads, and why cost is a lead's accountability, not just a finance concern.
Published September 23, 2026
Initial provisioning (a guess): m5.2xlarge "to be safe"
Actual observed utilization (Metrics & Monitoring, weeks later): 12% average CPU
→ right-sized: m5.large — same headroom for real observed peaks, a fraction of the cost
Instances are routinely over-provisioned at launch out of caution, and then never revisited — a genuinely common, easy-to-fix source of wasted spend. Right-sizing means periodically reviewing ACTUAL observed resource utilization (the same metrics from Probes & Autoscaling's requests/limits discussion, and Metrics & Monitoring generally) against provisioned capacity, and adjusting DOWN when real usage clearly doesn't need the current size — this requires the monitoring infrastructure from Monitoring in Production to already be in place; you can't right-size what you're not measuring.
As covered in S3, lifecycle policies automatically transition aging, infrequently-accessed data to cheaper storage tiers (or expire it entirely past a retention window) — for any workload accumulating data over time (logs, old application data, historical records), this is one of the highest-leverage, lowest-effort cost optimizations available: a one-time policy configuration, with ongoing savings that compound as data accumulates, requiring zero ongoing manual effort once set up correctly.
On-demand: pay full price, no commitment, maximum flexibility
Reserved/Savings: commit to a usage level for 1-3 years, in exchange for a
substantial discount (often 30-60%+ off on-demand pricing)
For workloads with genuinely PREDICTABLE, steady-state usage (a baseline of instances that are essentially always running, unlike the interruptible spot-instance workloads from EC2), committing to a Reserved Instance or Savings Plan trades flexibility for a significant discount — the commitment only makes financial sense when the predicted usage is confident enough that paying for unused reserved capacity (if usage drops below the commitment) doesn't erase the savings; this is a genuine forecasting exercise, not a default "always commit" decision.
A lead who only tracks feature delivery velocity while treating infrastructure spend as someone else's (finance's, or a platform team's) problem is missing a real part of the role — infrastructure cost is a direct, controllable output of architecture and operational decisions the team makes (Right-sizing, S3 lifecycle policies, choosing EC2 vs a managed service from earlier in this course), and reviewing spend TRENDS regularly (not just reacting to an unexpected bill spike after the fact) is how a lead catches a cost problem while it's still small and easy to fix, rather than after months of compounding waste.
Q: How often should right-sizing review actually happen? A: Regularly enough to catch drift as traffic patterns change, but not so frequently it becomes its own overhead — a common cadence is a periodic (e.g. quarterly) review of utilization trends across the fleet, plus an ad-hoc review whenever a service's traffic profile changes significantly (a major feature launch, a traffic pattern shift) rather than purely a fixed calendar schedule.
Q: What's the risk of committing to Reserved Instances too aggressively? A: If actual usage later drops below the committed level (a service gets decommissioned, traffic genuinely declines), you're still paying for the RESERVED capacity regardless of whether it's used — over-committing based on optimistic growth projections that don't materialize is a real, common way reserved-capacity strategies backfire financially.
Q: Does cost awareness ever conflict with the reliability/resilience patterns covered elsewhere in this course (like Multi-AZ, extra replicas for HPA headroom)? A: Yes, genuinely — redundancy and headroom (Multi-AZ standbys, HPA's extra replica headroom, maxSurge capacity during rollouts) all cost real money, and a lead needs to make an explicit, honest tradeoff between reliability and cost for each specific system, rather than either maximizing reliability regardless of cost or minimizing cost regardless of reliability risk — the right balance depends on how critical that specific system actually is.
Q: How would a lead present a cost-optimization recommendation to convince a team to actually act on it? A: Similar to the design-document skill from Design Documents later in this course — a concrete, quantified recommendation ('right-sizing this instance family saves $X/month, based on Y weeks of observed utilization data, with Z headroom preserved for genuine peak load') is far more actionable and persuasive than a vague 'we should probably reduce costs somewhere,' since it gives the team a specific, evaluatable decision rather than an open-ended directive.