Outcome
By the end of this lesson, you will be able to name the four levers of cloud cost optimization and rank them by typical impact and time-to-value.
New to the cloud? The optional track Cloud, from zero covers the basics first.
| Prerequisites | L1, L2 |
| Time | 10 minutes |
1. Concept
FinOps, the practice of managing cloud spending jointly across engineering, finance and the business, has three phases. Optimize is the second: actually spending less. There are exactly four ways to do it, called levers, and every cost programme is some mix of them.
The order you pull them in matters more than which ones you pull. Do them in the wrong order and the early wins cancel the later ones out.
LEVER IMPACT (typical) TIME-TO-VALUE RISK─────────────────────────────────────────────────────────────────1. Eliminate waste 20-40% of bill Days-weeks Low2. Rightsize 10-30% of bill Weeks Medium3. Rate optimize 5-25% of bill Weeks-months Medium-High4. Architect / design varies (5-50%+) Quarters HighLever 1: Eliminate waste
Stop paying for things nobody is using. Turn off test environments at night. Delete disks that outlived their servers. Clear snapshots (saved copies of a disk) nobody will restore. Release reserved internet addresses nothing points at. This is the list from M0.1 L5.
Why first: it is the lowest risk and the fastest to pay back, and nobody has to agree on a redesign. Turning off a development environment overnight changes nothing about how the system works, and the saving lands on the next bill.
When to stop: once avoidable spend (money going on things nobody needs) is under 5 to 8 percent of the bill. Below that, what is left is in how the system is built rather than in how it is run, which is lever four.
Lever 2: Rightsize
Rightsizing means running things at the size they actually need. Drop an oversized machine a class or two. Move a database down a tier when its CPU (processor use) and connection counts stay low. Switch AWS disks from the older gp2 type to gp3, which performs the same and costs less. Lower the resources reserved by Kubernetes workloads that never use them (Kubernetes is a system that runs many small applications across a shared group of machines).
Why second: it takes more judgement than deleting waste, but it is still mostly mechanical. A rules engine, software that checks every resource against a list of known waste patterns, can produce the candidate list for you. What it cannot decide is how much risk the workload can take.
Where it gets hard: databases, which cannot be resized automatically and need a maintenance window (an agreed time when a short interruption is acceptable), and anything with spiky traffic, where the size is set by the worst few minutes rather than by the average.
Lever 3: Rate optimize
Pay a lower price for the same thing. This is where commitments live: you promise the provider a year or three of usage and they charge you less per hour. Every provider has its own name for it. AWS calls them Reserved Instances and Savings Plans; Google calls them committed use discounts (CUDs); Azure calls them reservations. There is also interruptible capacity (Spot on AWS), sold cheap because the provider can reclaim it, and there are negotiated discounts for large accounts.
Why third rather than first: a commitment only pays back on usage you genuinely keep for the whole term. Committing to capacity and then switching it off at night destroys value twice over: you pay for the commitment and lose the saving.
The order is: turn off what you do not need, resize what is left, then commit to the floor that remains.
Where it gets dangerous: committing too much. A one-year commitment on capacity you run for six months loses money outright, and a three-year commitment on the wrong machine family (a group of machine types) locks the mistake in.
Lever 4: Architect / design
Change the workload to cost less. Replace a 24/7 service with a serverless equivalent, where the provider runs your code only when it is called and you pay nothing while it is idle. Move an analytics pipeline from EMR (AWS’s rented cluster service for big data jobs) to Athena (an AWS service that queries files directly and charges per query). Re-implement a real-time feature to run only when something happens. Split one large application into parts so non-critical paths can run on cheaper compute.
Why last: highest impact ceiling, highest risk, longest time-to-value. An architectural change touches code, how it is released, who gets paged at night, and the reliability targets the team has promised. The return on investment must account for engineering time.
Where it shines: the steady-state floor cost after levers 1-3 have been applied. If you are still spending $200K per month on a workload that could be re-architected to $80K, the prize is there. But sequence it after the easy wins.
The lever ranking is not opinion
IMPACT ─→ ┌──────────────────────────────────────────────────────┐ │ 4 ARCHITECT/DESIGN (highest ceiling, slowest)│ │ 3 RATE OPTIMIZE (mid impact, medium speed)│ │ 2 RIGHTSIZE (mid impact, fast) │ │ 1 ELIMINATE WASTE (consistent, fastest) │ └──────────────────────────────────────────────────────┘ TIME-TO-VALUE →The diagonal: lever 1 is in the bottom-left (fast, modest), lever 4 is in the top-right (slow, biggest). Most teams should travel up-and-right diagonally over 12 months, not jump straight to lever 4.
The most common sequencing mistake
Buying reservations before scheduling (switching non-production machines off at set times). The reservation locks in capacity you intend to schedule down, destroying the savings on both sides. The fix is mechanical: schedule first, observe the resulting steady-state floor for 60 days, then commit on the floor only.
Where ZopNight focuses
ZopNight is the cloud cost product taught in later tracks. Lever 1 (scheduling) and lever 2 (rightsizing recommendations + autoscaling, which adds and removes machines as load changes) are first-class. Lever 3 (commitments) is covered by advisory reserved-instance and committed-use recommendations: ZopNight suggests the purchase, and you decide whether to buy. Lever 4 (architecture) is out of scope; that is application engineering work, not platform automation.
2. Demo
A real (anonymized) optimization sequence at a mid-size SaaS (software sold as an online service) company, applied over 6 months. RC-003 is the name of one rightsizing rule, RDS is AWS’s managed database service, and a NAT gateway (NAT GW) lets private machines reach the internet:
| Month | Lever | Action | Realized monthly savings |
|---|---|---|---|
| 1 | Lever 1 | Schedule all non-production (dev, staging, short-lived test) environments off after hours and weekends | $24,000 |
| 2 | Lever 1 | Delete 1,200+ orphan EBS volumes (AWS disks attached to nothing) and forgotten snapshots | $1,800 |
| 2 | Lever 2 | Apply RC-003 EC2 rightsizing recs (31 resources) | $4,100 |
| 3 | Lever 2 | Downsize 4 RDS instances at planned maintenance | $2,800 |
| 3 | Lever 1 | Eliminate 6 always-on NAT GWs in non-prod (consolidate to one) | $194 |
| 4 | Lever 3 | Buy 1-yr Savings Plan on the post-schedule steady-state floor (the usage that never switches off) | $7,200 |
| 5 | Lever 4 | Re-architect one analytics job from EMR to Athena | $3,400 |
| 6 | (review) | (re-baseline) |
Cumulative monthly savings by month 6: $43,494. Total project effort: ~140 engineering hours. Effective rate: $310 saved per engineering hour.
3. Hands-on (8 min)
For your own estate, score yourself on each lever:
LEVER 1: Eliminate waste[ ] Are non-prod resources scheduled off after hours?[ ] Is the avoidable-spend KPI below 8% of bill?
LEVER 2: Rightsize[ ] Are rightsizing recommendations reviewed weekly?[ ] What's the average gap between "recommendation surfaced" and "remediated"?
LEVER 3: Rate optimize[ ] What share of usage is covered by commitments (RI, Savings Plan, CUD)?[ ] Was the most recent commitment purchased on the post-schedule floor?
LEVER 4: Architect/design[ ] Are there any workloads in active redesign for cost reasons?[ ] Is engineering time being tracked against cost-driven redesigns?If lever 1 is incomplete, do not move to levers 2-3. The sequence is not “do all four in parallel.” It is “do 1 first, then 1+2, then 1+2+3, then all four.”
4. Knowledge check
Q1
A team has $200K monthly cloud spend, mostly non-prod always-on, and wants to start optimizing. The first move is:
A. Schedule non-prod off nights and weekends
B. Buy a 3-year Reserved Instance pool to lock in savings
C. Migrate to Kubernetes
D. Hire a FinOps consultant
Show answer
Correct: A. Lever 1 first. A 3-year RI (a commitment to pay for machines for three years) on always-on non-prod is the textbook over-commitment mistake. Migration to Kubernetes is a lever-4 redesign with quarters of payback. Consultants can help but the first move does not require one.
Q2
A FinOps team reports: “We applied 30 rightsizing recommendations this month and saved $4,100. We applied 1 schedule and saved $24,000.” Which lever returned more savings per action this month?
A. Lever 2 (rightsizing)
B. Both equally
C. Lever 3 (commitments)
D. Lever 1 (scheduling)
Show answer
Correct: D. One schedule saved $24,000, while each rightsizing change saved about $137 on average ($4,100 across 30). Even in total, the single schedule saved almost six times as much. Before scaling lever 2 effort, check how much always-on non-prod is still unscheduled (more non-prod tiers, Kubernetes workloads, Databricks data-processing clusters).
Q3
A CFO proposes locking in a 3-year RI on the current peak compute usage to “guarantee savings.” Best response:
A. Agree, locking in is good
B. Wait one year
C. Push back
D. Use Spot instead
Show answer
Correct: C. 3-year RIs on current peak are at high risk of over-commitment if usage shifts. The defensible move is 1-year commitment on the post-schedule, post-rightsizing floor: not on current peak. Commitments are calibrated to the floor, not the peak. The floor is what the workload will demand even in a slow quarter. Current peak is a fluctuating ceiling.
5. Apply
ZopNight, the product taught from Track 1, is built around levers 1 and 2 because that is where the fast, repeatable savings live for most estates:
- Lever 1 → Schedules (any time you can stop a resource), Recommendations idle/orphan rules
- Lever 2 → Recommendations rightsizing/category rules, VM Autoscaling
- Lever 3 → coverage tracked in Costs → Flow, with a layout that includes Purchase
- Lever 4 → out of scope; engineering ownership
Related lessons
- L4: Operate: the discipline that beats one-shot wins (next)
- M0.3: Why scheduling beats commitments
- T5.M5.7: Commitments demystified
Glossary terms touched
FinOps lifecycle · Right-sizing