Schedule first, then commit · ZopDev University

Outcome

By the end of this lesson, you will be able to defend the “schedule first, commit on the floor” rule with the math, compute the proven floor for a workload, and design a combined optimization (schedule + commit) that captures both savings layers.


Prerequisites	M5.7.L1-L3 (commitment fundamentals) · T1 (scheduling)
Time	9 minutes

1. Concept

The most important commitment rule in FinOps:

SCHEDULE WORKLOADS WHERE POSSIBLE
THEN COMMIT ON THE PROVEN FLOOR

The two savings work on different things. Scheduling cuts the number of hours you run. A commitment cuts the price of each hour.

Because they multiply rather than overlap, doing both gets you both. Doing one gets you one, and committing before you schedule means committing to hours you were about to stop paying for.

Why the rule is mathematically airtight

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

The math: concrete example

NON-PROD WORKLOAD: 100 instances always-on at $100/mo each
  20 must run 24/7 (shared CI runners, shared databases)
  80 can be scheduled 60% of hours off (overnight + weekends)
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:
  20 always-on, on-demand: 20 × $100 = $2K/mo
  80 scheduled, on-demand: 80 × $100 × 0.4 = $3.2K/mo
  Cost: $5.2K/mo
  Savings: $4.8K/mo (48%)

APPROACH C: Schedule + commit on floor:
  Floor = the 20 instances that run every hour
  Commit those 20 at 30%: 20 × $100 × 0.7 = $1.4K/mo
  80 scheduled, on-demand: $3.2K/mo
  Cost: $4.6K/mo
  Savings: $5.4K/mo (54%)

WINNER: Approach C captures both layers.
  C beats A by $2.4K/mo (1.8× savings)
  C beats B by $0.6K/mo (12.5% more savings)

The math compounds: scheduling cuts hours; commitment cuts the rate on those hours. Combining them stacks the discounts. (30% is an example rate; L1’s table puts a 1-year RI nearer 40%.)

Approach A’s hidden failure

Approach A, committing everything without scheduling, is the silent failure. The 30% discount looks great on paper, but most of the workload was scheduled-eligible. Approach A locks in 70% of the full cost when scheduling could have cut 60% of the hours on 80 of the 100 instances.

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

  BUT: most of the workload doesn't need 24/7 hours.
  48% of all hours were waste (80 instances × 60% off).

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

This is Pattern 1 from L3 (non-prod commitment) in full clarity.

The proof step: wait before committing

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?)

Floor calculation

For a typical scheduled workload:

WORKLOAD: 100 instances
  30 run 24/7 (never scheduled)
  70 scheduled on 8AM-8PM weekdays (60 of 168 hours)

FLOOR = instances running in EVERY hour of the week
  Weeknights and weekends: 30 running
  Weekday business hours: 100 running
  Floor: 30 instances

COMMIT TARGET: 30 instances (or slightly fewer, as a buffer)

THE EQUIVALENT-HOURS TRAP:
  The 70 scheduled instances average 70 × 60 / 168 = 25
  "24/7 equivalents", which tempts you to commit on them.
  But a commitment covers hours, not averages: committing
  on the 70 scheduled instances leaves it idle 108 of 168
  hours: 36% utilization, below break-even for any
  discount under 64%.

VERIFICATION after 60 days (hourly usage in Cost Explorer
or your monitoring):
  Lowest hourly instance count: __________
  Matches the expected floor? ±5%

The instances that run in every hour are what you commit on. That’s the proven floor.

Combined optimization across workload classes

A typical mature estate has different optimization at each layer:

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

Each layer has its own optimization. The rule “schedule first, commit on floor” applies to layers where both apply.

Why the rule sticks (defending it to skeptics)

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

YOU: "The discount is real but only on the hours you use. A 30%
discount at 35% utilization is a loss: you pay 0.70 / 0.35 = 2x
the on-demand price for each hour you actually use. No commit
plus a 60% schedule cut saves 60%. 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."

The rule is defensible because the math is airtight. Don’t accept the bad commit unless the math actually supports it.

Common mistakes

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

Commit on peak                              Commit on proven floor
                                          (instances running every hour)

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

Tooling for schedule-first

SURFACE                          USE
──────────────────────────────────────────────────────────────────
Schedules + overrides             Cut hours; overrides cover
(ZopNight, or instance            exceptions without editing the
scheduler / Automation)           schedule

Schedule success rate             Track schedule fire rate
(ZopNight dashboard widget)       post-rollout

Cost Flow, Purchase layout        See the committed share of spend

Commitment recommendations        Suggest an RI, CUD or (AWS EC2)
(ZopNight, provider)              Compute SP once a resource shows
                                 60+ days of history and 70%+
                                 measured uptime

The order is what matters: schedule first, observe, then commit.

2. Demo

A production workload analysis showing the math:

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,688/mo (baseline 80 × $584 = $46,720/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,512/mo vs baseline
  Mixed effective: 22.5%

APPROACH C: Schedule + commit on floor:
  Schedule 30 instances off 60% of hours (on-demand): $7,008/mo
  Proven floor: the 50 instances that run every hour
  Commit 50 instances at 40% discount: 50 × $584 × 0.6 = $17,520/mo
  (committing on the scheduled 30 would leave commitment idle
  whenever they are off)
  Cost total: $17,520 + $7,008 = $24,528/mo
  Savings: $22,192/mo vs baseline
  Effective discount: 47.5%

WINNER: Approach C
  C beats A by $3,504/mo (annual: ~$42K)
  C beats B by $11,680/mo (annual: ~$140K)

The combined approach captures savings from both layers.

3. Hands-on (5 min)

For your team’s workloads, identify schedule-vs-commit fit:

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: __________ instances
  No: wait before committing

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

If your current state is “commits only,” investigate immediately: Pattern 1 from L3 is the likely diagnosis.

4. Knowledge check

Q1

A team buys RIs for non-prod resources without scheduling:

A. Best practice
B. Required
C. Non-prod commitment fallacy (Pattern 1 from L3)
D. Sensible, since non-prod is fairly predictable

Show answer

Correct: C. The team is paying committed rates for resources that could have been scheduled off. Schedule first, then commit on the proven floor.

Q2

The 60-day wait between scheduling rollout and commitment:

A. Unnecessary bureaucracy
B. Required by the cloud provider before any commitment purchase
C. Should be skipped to save time
D. Ensures the schedule effect is settled and the real floor is known

Show answer

Correct: D. Committing earlier means guessing the floor, and the realized floor will differ from the guess. 60 days of data gives confidence in the floor estimate to about ±5%.

Q3

Combined approach (schedule + commit floor) vs either alone:

A. Same outcome
B. Best
C. Worse, since the two levers conflict
D. Worse than commit-only

Show answer

Correct: B. Each lever fits a different layer: scheduling cuts hours on the instances that can stop, and commitment cuts the rate on the floor that never stops. The two layers stack.

5. Apply

For each workload class: identify schedule-eligibility, deploy schedules where applicable, observe 60+ days, commit on the proven floor. Commitment recommendations from ZopNight or your provider become meaningful once 60+ days of scheduled usage are in the data.

For mature teams, this is the discipline that produces net effective discounts of roughly 45-55%, as in the two examples above.

Glossary terms touched

Schedulable resource

Outcome

1. Concept

Why the rule is mathematically airtight

The math: concrete example

Approach A’s hidden failure

The proof step: wait before committing

Floor calculation

Combined optimization across workload classes

Why the rule sticks (defending it to skeptics)

Common mistakes

Tooling for schedule-first

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.