Spending Less: Commitments and Right-Sizing

On-demand pricing is convenient — spin something up, pay the listed rate, stop any time. But "convenient" is also a polite word for "the most expensive per unit." Cloud providers offer real, substantial discounts to customers who are willing to give up a little flexibility or choose their resources more carefully. These are the levers every cost-conscious team eventually reaches for.

The analogy: a mobile phone plan. Pay-as-you-go SIM cards are available at every airport kiosk — perfectly adaptable, no commitment, but the price per minute is steep. A monthly contract is considerably cheaper if you know you will use the phone regularly. And if you have a second SIM you barely use, cancelling it entirely saves more than any discount could. The cloud offers all three of these options: contracts (commitments), cheaper leftover capacity (spot/preemptible), and simply turning off what you do not need (right-sizing and cleanup).

Commit for a Discount

The single most common cost-reduction move for cloud teams with predictable workloads is to promise the provider a certain level of usage for a set period — usually one or three years — in exchange for a substantially lower hourly rate. The reduction is real: depending on the provider and commitment length, prices can drop by 30–70% compared to on-demand.

The commitment does not lock you into a specific machine. On AWS, for instance, Savings Plans let you commit to a dollar amount of compute usage per hour — not to a particular server. On Google Cloud, Committed Use Discounts apply to specific machine types in a region. The mechanism differs, but the idea is the same: predictability earns a discount. And importantly, any usage above your committed level still bills at the normal on-demand rate — you are not locked out of flexibility, you have just pre-bought the baseline.

Use Spare Capacity at a Discount

At any given moment, a cloud provider has more physical capacity than customers are actively using. Rather than leave that spare capacity idle, providers offer it at a steep discount — often 60–90% below on-demand. The catch: the provider can reclaim those machines at any time, with short notice, if they need the capacity for paying on-demand customers.

These discounted machines go by different names depending on the provider — Spot Instances on AWS, Preemptible or Spot VMs on Google Cloud, and Spot VMs on Azure — but they all work the same way. They are real, full-speed machines. They are not slow or second-rate hardware. The only difference is that they can be taken back. That makes them well-suited for work that can handle an interruption: batch jobs, data processing, rendering pipelines, and machine-learning training runs that checkpoint their progress. They are not suitable for the main server handling live user requests, where an unexpected shutdown would cause an outage.

Right-Sizing: Match the Machine to the Need

Cloud providers offer machines in a wide range of sizes — from tiny, low-cost instances with 1 virtual CPU and 1 GB of RAM up to enormous machines with hundreds of CPUs and terabytes of memory. It is easy, when you are in a hurry or uncertain, to reach for a machine that is larger than necessary "just to be safe." That caution has a cost: a machine running at 5% of its capacity bills for 100% of the machine.

Right-sizing means reviewing what your machines actually use and choosing the appropriate size. Modern cloud consoles show CPU and memory utilization graphs, and most providers include recommendation tools that flag machines running well below their capacity. A server consistently sitting at 10% CPU utilization is a strong signal to move to a smaller machine type and cut that cost immediately.

Right-sizing is not a one-time task. Workloads change — a service that needed a large machine during a product launch may need only a small one three months later. The habit of reviewing utilization on a regular schedule is what keeps the bill aligned with actual need rather than the fear of running short.

Turn Off What Is Idle

The simplest cost reduction of all is deleting or stopping resources that are not being used. Development and test environments are the classic source of waste: teams spin up servers and databases for a sprint, the sprint ends, and the resources keep billing for months or years because no one remembered they were there. The same applies to old machine images, forgotten snapshots, and databases no longer connected to any application.

Auto-scaling — described earlier in the scaling chapter — also helps here: instead of sizing machines for peak load and running that size all the time, an auto-scaling group grows under load and shrinks when demand drops, matching actual need rather than the worst-case scenario. That alone can cut compute costs significantly for workloads with predictable patterns of busy and quiet periods.