Bayu Permadi Your Cloud Bill Keeps Rising, Yet Your Workloads Have Barely Changed
Why a Single Pricing Model Rarely Works
Many companies run all of their servers on a single pricing model, usually on-demand, because it is the easiest option when first moving to the cloud. The problem surfaces a few months later. Workloads become stable, the number of servers grows, and the monthly bill climbs without any new features to justify it. For decision-makers, this often feels odd: the systems run normally, yet costs keep growing.
The cause is usually not a technical mistake but a mismatch between the pricing model and the nature of the workload. A server that runs 24 hours a day is paid for at a rate designed for temporary needs. Meanwhile, jobs that could be postponed or restarted run on expensive capacity.
The Costs You Can Actually Control
Before talking about discounts, one question is worth asking: how much of your infrastructure is needed continuously, and how much appears only at certain hours or seasons? The answer determines which pricing model makes the most sense. If you do not yet have a clear picture, start with our discussion of expensive cloud bills caused by early design mistakes, because the root cause often lies there.
Understanding the Three Pricing Models Before Combining Them
On-Demand: Flexible, at Full Price
On-demand means you pay for what you use, with no long-term commitment. Capacity can be added or shut down at any time. This model is best suited to new workloads with unclear patterns, unexpected traffic spikes, or short-term testing environments. Its drawback is simple: it carries the highest hourly rate, which makes it inefficient for workloads that run continuously.
Reserved Instance: A Commitment for Stable Workloads
Reserved instances trade a usage commitment, typically one or three years, for a much lower rate. According to AWS documentation, commitment-based plans like this can deliver savings of up to roughly 72 percent compared with on-demand, depending on instance type, term length, and payment option. This model suits production databases, core applications, and services that will almost certainly keep running all year. The risk lies in planning: if your needs shrink or your architecture changes, the commitment you purchased still has to be paid. You can read the details of the scheme on the official AWS Savings Plans page.
Spot Instance: Cheap, but Interruptible
Spot instances use the cloud provider’s spare capacity at a much lower price. AWS cites discounts of up to roughly 90 percent compared with on-demand. In exchange, the provider can reclaim the instance on short notice. For this reason, spot is safest for interruption-tolerant work such as batch processing, data processing, CI/CD build pipelines, or rendering. For a technical overview, see the Amazon EC2 Spot Instances page.
A Realistic Blended Strategy for Companies
Allocating Shares Based on Workload Characteristics
The approach that most often works is to divide infrastructure into three layers. The base layer, meaning the minimum capacity that is always running, is covered with reserved instances. The middle layer, meaning capacity that rises and falls with peak hours, stays on on-demand to remain flexible. The top layer, meaning work that can be postponed or rerun, runs on spot. As a starting point for discussion, many teams begin with half or more of their base capacity on reserved, then adjust after reviewing actual usage data. This figure is only an illustration, not a fixed standard, and every company needs to recalculate it from its own data.
Risks to Anticipate
A well-designed mix still has weak points. A reserved commitment that is too large can become a burden if demand falls. Spot placed on a service that is not prepared to lose servers will disrupt customers. For that reason, set clear boundaries: services directly tied to customer transactions should not depend on spot. Also monitor spending regularly, for example with cloud cost anomaly detection, so that spikes are not discovered only at the end of the month.
Tagging Discipline as a Foundation
Any strategy is hard to execute if you do not know which costs belong to which team or service. Tagging and cost allocation practices make commitment purchases data-driven rather than guesswork. We cover this in our article on tagging and cost allocation as the foundation of FinOps. For a broader framework, the FinOps Foundation offers guidance that can serve as a reference.
A First Step You Can Start This Week
Begin with an Audit of Usage Patterns
You do not need to buy a large commitment right away. Start by reviewing server usage over the past three to six months, then separate what is constant, what is seasonal, and what can be rerun if interrupted. From this simple mapping, it is usually clear which parts are the best candidates to move to another pricing model. Make changes gradually and measure the impact on your bill before adding the next commitment.
Discuss the Scenarios with a Team That Understands Your Context
Determining the right mix requires an understanding of your workloads, risk tolerance, and business growth plans. If your internal team does not yet have time to analyze this, Pandawa Cloud .Net can help review your usage data and build a suitable blended scenario, with no obligation to proceed. That way, commitment decisions are based on clear numbers rather than estimates.
