Savings Plans vs Reserved Instances for mixed compute

WHAT THIS TESTS This assesses whether you can navigate AWS commitment-based discounts for a fleet spanning EC2, Fargate, and Lambda, and size commitments with data rather than guesswork.

A GOOD ANSWER COVERS Standard Reserved Instances commit you to a specific instance family, region, and often OS for one or three years, offering the deepest discount but the least flexibility, and they only cover EC2. EC2 Instance Savings Plans commit to an hourly spend within a chosen family and region, allowing size and OS changes, with discounts comparable to RIs. Compute Savings Plans commit to a flat hourly dollar amount and automatically apply across any EC2 family, region, Fargate, and Lambda, trading a slightly lower discount for broad flexibility. For a mixed and evolving fleet, Compute Savings Plans are usually the right recommendation because they cover all three compute types and survive migrations between them. To size the commitment, analyze several months of usage, find the consistent baseline floor of spend that is almost always present, and commit to that floor, leaving variable and growth usage on On-Demand. Layer additional commitments as the floor proves stable.

COMMON WRONG ANSWERS Recommending Standard RIs for Fargate or Lambda, which they do not cover. Committing to peak or average usage rather than the reliable floor, creating waste during troughs. Ignoring that a one-year term and partial upfront option reduce risk versus three-year all-upfront. Treating Savings Plans as reserving capacity, which they do not.

LIKELY FOLLOW-UPS How do you handle a planned migration off EC2. How does convertible RI flexibility compare. How do you track coverage and utilization over time.

ONE CONCRETE EXAMPLE Usage reports show a steady floor of roughly twelve dollars per hour across EC2 and Fargate with spiky growth on top. You buy a one-year Compute Savings Plan at that floor, keep elastic load on On-Demand, and revisit quarterly, capturing most of the discount while avoiding lock-in to a shrinking instance family.