Over-commitment patterns

1. NON-PROD COMMITMENT       The classic: RIs on resources that
                              should be scheduled off

2. PEAK-BASED COMMITMENT      Committing on peak hours rather than
                              the floor

3. ARCHITECTURAL MISMATCH     Commitment doesn't match the workload
                              after migration

4. RI HOARDING                Buying ahead of projected growth that
                              didn't materialize

5. EARLY COMMITMENT           Committing before workload patterns
                              are clear

SCENARIO:    Bought RIs for dev/test environments
PROBLEM:     Dev/test should be scheduled off; RI assumes 24/7
RESULT:      Paying for committed hours when resources are off

EXAMPLE:
  $100K of RIs on dev/test resources
  Schedule reduces hours by 65%
  Effective utilization: ~35%
  Effective discount: 1 - 0.60 / 0.35 = -71% (a loss; break-even is 60%)
  vs pure on-demand with schedule: the hours you use are worth ~$58K
  at on-demand rates, so the $100K commit wastes ~$42K

LESSON: schedule first, commit only on the proven floor.

SCENARIO:    Bought RIs for the workload's peak capacity
PROBLEM:     Peak is intermittent; commitment runs 24/7

EXAMPLE:
  Workload peak: 100 instances during Black Friday
  Workload typical: 30 instances
  Commitment: 100 instances

  Peak runs 1/8 of hours; the other 7/8 run the typical 30
  Average running: (100 + 7 × 30) / 8 = 38.75 instances
  Effective utilization: 38.75% of the 100 committed
  Effective discount: 1 - 0.70 / 0.3875 = -81% (a loss; break-even is 70%)

LESSON: commit on the typical floor; on-demand for peak.

SCENARIO:    Bought m5.large RIs; workload migrated to t3.large
PROBLEM:     Different family; original RIs don't apply

EXAMPLE:
  $50K of m5.large RIs purchased Q1
  Migration to t3.large (lower memory needed) in Q2
  m5.large RI utilization: 0%
  t3.large: 100% on-demand

  Net: paying both RI cost AND on-demand cost

LESSON: plan workload migrations BEFORE committing.

SCENARIO:    Bought RIs in anticipation of growth
PROBLEM:     Growth didn't materialize at the projected scale

EXAMPLE:
  Committed: 50 m5.large for next year (anticipating 2× growth)
  Actual growth: 25 m5.large (50% of projection)
  Utilization: 50%
  Effective discount: 1 - 0.70 / 0.50 = -40% (a loss; break-even is 70%)

LESSON: conservative commits with ability to add later beats over-buying.

SCENARIO:    New workload at month 1; committed at year 1
PROBLEM:     Workload patterns not stable yet

EXAMPLE:
  New product launches; team commits to 50 instances for 1 year
  By month 3: workload re-architected; needs 80% less compute
  RI utilization: 20%
  Wasted spend: $40K for the year

LESSON: wait 60-90 days post-launch before committing.

PORTFOLIO HEALTH CHECK:
  □ Any commitments on dev/test/sandbox? → Pattern 1 risk
  □ Any commitments above the steady floor? → Pattern 2 risk
  □ Any commitments on workloads scheduled to migrate? → Pattern 3 risk
  □ Any commitments larger than current usage? → Pattern 4 risk
  □ Any commitments on workloads <90 days old? → Pattern 5 risk

  Effective discount per commitment (calculated):
    Commitment A: ____% (target 25%+; flag if below)
    Commitment B: ____%
    Commitment C: ____%

  Any below break-even utilization (1 - d)?
    Yes → losing money vs on-demand; remediate immediately

SURFACE                          FINDS
──────────────────────────────────────────────────────────────────
Provider utilization reports     Utilization per instrument
(Cost Explorer RI/SP              (the source of truth)
utilization, Azure reservation
utilization, GCP CUD reports)

Provider coverage reports        Coverage per instrument type
                                   over time

ZopNight Cost Flow,              Current portfolio mix
Purchase layout                    (spend only, no utilization)

OPTION                            APPLIES WHEN
──────────────────────────────────────────────────────────────────
Exchange (AWS Convertible RIs      Architectural mismatch; can swap
only)                              to current instance type

Sell on RI Marketplace (AWS        Stranded RI; resale recovers part
Standard RIs only)                 of the value (small loss vs unused)

Accept the loss + replan            Final option; document lesson
                                   for next cycle

Increase coverage on the floor      Under-coverage; commit more to
                                   raise effective discount

Decrease coverage (let expire)      Over-coverage; let unused commits
                                   expire; rebuy at appropriate level

Buy an SP, let the RIs expire      More flexibility for future
(AWS; an RI cannot be converted    workload changes
to an SP)

DOUBLING DOWN on a failing commitment       Don't buy more to "make up"
                                            the loss; sunk-cost trap

IGNORING the marketplace                    For AWS Standard RIs, the
                                            marketplace recovers some value

NOT DOCUMENTING the lesson                  Without documentation, the
                                            same mistake happens next
                                            commitment cycle

WAITING for renewal to remediate            Some remediations work
                                            mid-term (exchange, sell);
                                            don't wait the full term
                                            for an obvious mistake

TEAM finds over-commitment via quarterly review:

DISCOVERY:
  AWS RI utilization report shows m5.large RIs at 35% utilization
  Break-even utilization for a 40% RI: 1 - 0.40 = 60%
  Current: 35% < 60% → the commitment LOSES money vs on-demand.
  You pay the committed rate on 100% of the hours but use only 35%;
  the overpayment on unused hours exceeds the discount earned. This
  is a net loss, not a smaller gain.

INVESTIGATION:
  Workload migrated to m6i.large in March (improved performance)
  m5.large RIs no longer match the workload (Pattern 3)

OPTIONS evaluated:
  1. Exchange RIs (they are Convertible RIs, so AWS allows
     an m5 → m6i exchange)
     Pros: full value recovery
     Cons: requires AWS API call + reconciliation
  2. Sell on the RI Marketplace
     Not available: only Standard RIs can be resold, and
     these are Convertible
  3. Accept and replan
     Pros: simplest
     Cons: ~$30K of stranded spend

DECISION: Exchange via AWS
EXECUTION: completed in 2 weeks; new RIs match m6i.large workload

NEW STATE:
  Coverage: 90%, Utilization: 95%
  Effective discount: 0.9 × (1 - 0.60 / 0.95) = 33.2%
  Savings recovered: ~$25K/year

LESSON CAPTURED:
  Added a workload-migration check to the commitment-purchase runbook
  Quarterly review now flags "instance type evolved within term"
  Documented in postmortem retrospective

CURRENT COMMITMENTS:
  Commitment A: __________ (type, term, target)
    Coverage: ____%   Utilization: ____%
    Effective: ____% (= coverage × (1 - (1 - discount) / utilization))
    Pattern risk (1-5): __________

  Commitment B: __________
    Coverage: ____%   Utilization: ____%
    Effective: ____%
    Pattern risk: __________

ANY COMMITMENTS below break-even?
  Yes / No / Don't know

TOP-RISK pattern:
  □ Pattern 1: Non-prod commitment
  □ Pattern 2: Peak-based
  □ Pattern 3: Architectural mismatch
  □ Pattern 4: RI hoarding
  □ Pattern 5: Early commitment

REMEDIATION plan for highest-risk commitment:
  □ Exchange (AWS Convertible RIs only)
  □ Sell on marketplace (AWS Standard RIs only)
  □ Let expire and rebuy
  □ Accept loss; document lesson

QUARTERLY REVIEW scheduled? Yes / No
  If no, schedule now.