Schedule first, then commit

SCHEDULE WORKLOADS WHERE POSSIBLE
THEN COMMIT ON THE PROVEN FLOOR

SCHEDULED workloads run partial hours
COMMITMENTS assume the resource runs 24/7
Combining a commitment with a schedule = under-utilization
  (paying committed rate for hours the resource isn't running)

THE FLOOR is what the workload runs even after scheduling
The floor is stable and predictable
Commit on the floor only; everything above can be on-demand

NON-PROD WORKLOAD: 100 instances always-on at $100/mo each
TOTAL: $10K/mo on-demand baseline

APPROACH A: Commit everything, no schedule:
  Buy RIs for all 100 at 30% discount
  Cost: $7K/mo
  Savings: $3K/mo (30%)

APPROACH B: Schedule, no commit:
  Schedule 60% of hours off (overnight + weekends)
  40% remaining hours running on-demand
  Cost: 40 × $100 = $4K/mo
  Savings: $6K/mo (60%)

APPROACH C: Schedule + commit on floor:
  Schedule 60% off → equivalent of 40 instances running 24/7
  Commit 40 instances at 30% discount
  Cost: 40 × $100 × 0.7 = $2.8K/mo
  Savings: $7.2K/mo (72%)

WINNER: Approach C captures both layers.
  C beats A by $4.2K/mo (2.4× savings)
  C beats B by $1.2K/mo (20% more savings)

APPROACH A in detail:
  100 instances on-demand: $10K/mo
  100 instances RI at 30% discount: $7K/mo
  Apparent savings: $3K/mo (30%)

  BUT: workload doesn't need 24/7 hours.
  60% of hours were waste (could have been scheduled off).

  Real savings vs ideal: $3K/mo vs $7.2K/mo
  $4.2K/mo of opportunity lost to over-commitment.

WAIT 60-90 DAYS after scheduling rollout before committing.

WHY:
  Schedule effect is real but settles over weeks
  Engineers adjust to scheduled environments
  Override patterns emerge (some teams need exceptions)
  Actual floor becomes clear

WITHOUT 60-day wait:
  Commit on speculative floor (often lower than reality)
  Realized floor is higher → under-coverage
  OR: commit higher than necessary → over-commitment

THE 60-DAY DATA:
  After 60 days, you have:
    - Actual schedule fire rate
    - Actual override rate
    - True minimum running capacity
    - Variance pattern (is the floor stable or seasonal?)

WORKLOAD: 100 instances, scheduled on 8AM-8PM weekdays

WEEKLY HOURS CALCULATION:
  Total possible hours: 168 (24 × 7)
  Scheduled-on hours: 60 (Mon-Fri, 8AM-8PM = 12 × 5)
  Scheduled-off hours: 108

  Floor %: 60 / 168 = 35.7%

INSTANCE-HOURS PER WEEK:
  100 instances × 168 hours = 16,800 max
  Scheduled-on: 100 × 60 = 6,000 instance-hours

EQUIVALENT 24/7 INSTANCES:
  6,000 instance-hours / 168 hours per instance = 35.7 instances

COMMIT TARGET: 36 instances (slight buffer for overrides)

VERIFICATION via ZopNight after 60 days:
  Actual instance-hours: __________
  Calculated equivalent: __________
  Matches estimate? ±5%

WORKLOAD LAYER                  OPTIMIZATION
──────────────────────────────────────────────────────────────────
Peak / burst demand              On-demand (variable; no commit)

Steady production floor          RI / SP commitment (predictable;
                                 24/7 utilization assumed)

Non-prod operational             Schedule on/off (variable; no commit)

Stateless batch                  Spot (interruptible; no commit)

Mixed: scheduled-on + commit on   Schedule reduces hours; commit on
floor                            the proven floor

SKEPTIC: "We should commit everything. The discount is real."

YOU: "The discount is real but multiplied by utilization. A 30%
discount with 35% utilization is 10.5% effective. A 0% commit
(no discount) plus a 60% schedule cut is 60% effective. The
math favors scheduling first."

SKEPTIC: "What if the floor moves?"

YOU: "We commit on the floor we've proven over 60+ days. We
re-baseline every renewal cycle (annually for 1-yr commits,
quarterly review for 3-yr). The floor for stable workloads
is very stable; we measure it before we lock in."

SKEPTIC: "Scheduling is annoying for engineers."

YOU: "It's a one-time setup. Engineers adapt to scheduled
environments within 2-3 weeks. The override mechanism handles
exceptions. The savings dwarf the operational friction."

MISTAKE                                   FIX
──────────────────────────────────────────────────────────────────
Commit before scheduling                   Schedule first; observe
                                          60 days; then commit

Commit on peak                              Commit on proven floor
                                          (equivalent 24/7 instances)

Use scheduling on committed workloads      Defeats the commit;
                                          either schedule OR commit
                                          per layer, not both on
                                          the same hours

Skip the 60-day wait                       Verify the floor before
                                          committing

Commit "for safety" above current usage    Over-commitment risk;
                                          conservative + add later
                                          beats over-buying

SURFACE                          USE
──────────────────────────────────────────────────────────────────
Reports → Cost Flow              See per-layer breakdown
                                  (committed / scheduled / on-demand)

Schedule rollout report           Track schedule fire rate post-rollout
                                  + override rate

Commitment Optimizer              Suggests RI/SP based on the proven
                                  floor (after 60+ days of scheduled
                                  data)

Saved schedules                   Per-workload schedule definitions
                                  with override budget

PROD WORKLOAD: 80 instances 24/7 baseline (no scheduling, no commits)
COST: 1 instance × 730 hr × $0.80/hr = $584/instance/mo

APPROACH A: Commit all 80 instances:
  RIs at 40% discount on all 80
  Cost: 80 × $584 × 0.6 = $28,032/mo
  Savings: $18,752/mo
  Effective discount: 40%

APPROACH B: Schedule 30 non-essential instances, no commits:
  50 instances run 24/7: $29,200/mo
  30 instances scheduled 60% off: 30 × $584 × 0.4 = $7,008/mo
  Total: $36,208/mo
  Savings: $10,624/mo vs baseline
  Mixed effective: 22.7%

APPROACH C: Schedule + commit on floor:
  Schedule 30 instances off 60% of hours → equivalent of 12 instances 24/7
  Total floor: 50 + 12 = 62 instances equivalent
  Commit 62 instances at 40% discount: 62 × $584 × 0.6 = $21,725/mo
  Remaining peak (above floor): on-demand
  Cost total: $21,725/mo
  Savings: $25,107/mo vs baseline
  Effective discount: 53.7%

WINNER: Approach C
  C beats A by $7,075/mo (annual: $85K)
  C beats B by $14,483/mo (annual: $174K)

The combined approach captures savings from both layers.

WORKLOAD 1: __________
  Class: prod / non-prod / batch / mixed
  Schedule-eligible? Yes / No / Partial
  Commit-eligible? Yes / No / Partial

  PROPOSED APPROACH:
  □ Schedule + commit on floor (combined)
  □ Schedule only (no commit yet)
  □ Commit only (no schedule applicable)
  □ On-demand only (truly unpredictable)

WORKLOAD 2: __________
  Class: __________
  Schedule-eligible? __________
  Commit-eligible? __________
  PROPOSED APPROACH: __________

CURRENT STATE: scheduling deployed? Commits in place?
  □ Both deployed
  □ Scheduling only
  □ Commits only (POTENTIAL OVER-COMMITMENT RISK)
  □ Neither

60-DAY DATA available?
  Yes: proven floor: __________ instance-equivalent
  No: wait before committing

NEXT STEP:
  □ Deploy schedules to schedule-eligible workloads
  □ Wait 60 days for data
  □ Then commit on the proven floor