AWS On-Demand, Savings Plans, and Spot: When to Use Each
AWS compute pricing is not one-size-fits-all. On-Demand, Savings Plans, Reserved Instances, and Spot Instances solve different cost and flexibility requirements.
D
Dilanix Engineering
Engineering Team
AWS compute pricing is a workload decision
Choosing between On-Demand, Savings Plans, and Spot should not be treated only as a pricing exercise.
Each option is designed for a different type of workload.
The right strategy usually combines several models instead of using only one.
On-Demand
On-Demand pricing offers maximum flexibility.
You pay for compute capacity without making a long-term commitment.
This is useful when workloads are unpredictable or temporary.
Good use cases include:
new applications with unknown demand
short-term projects
development environments
workloads with irregular traffic
capacity that may disappear soon
The main advantage is flexibility.
The disadvantage is price.
For stable workloads running continuously, On-Demand can become significantly more expensive than commitment-based pricing.
Savings Plans
Savings Plans are designed for workloads with predictable baseline usage.
You commit to a certain level of compute spending for a period of time in exchange for discounted pricing.
This works well when you already understand how much compute capacity your organization consistently uses.
Examples include:
production services running 24/7
stable backend workloads
long-running application servers
predictable container infrastructure
The key is to avoid committing to more capacity than you actually need.
An oversized commitment can turn a discount into another form of waste.
Get In Touch
Explore custom infrastructure software with Dilanix
We partner with high-scale engineering organizations to build focused solutions.
Spot capacity can provide very large discounts compared with On-Demand pricing.
The trade-off is interruption.
AWS may reclaim Spot capacity when it needs it.
That means Spot is best suited for workloads that can tolerate interruptions.
Good candidates include:
batch processing
CI/CD jobs
distributed data processing
fault-tolerant Kubernetes workloads
rendering
asynchronous workers
Critical workloads without interruption handling should not depend entirely on Spot capacity.
A blended strategy works best
Many organizations benefit from combining all three models.
A stable baseline can be covered by Savings Plans.
Variable traffic can run on On-Demand.
Interruptible workloads can use Spot.
For example, a Kubernetes cluster may keep core services on committed capacity while using Spot nodes for scalable worker workloads.
This approach balances reliability, flexibility, and cost.
Do not optimize only for discount percentage
The largest discount is not automatically the best choice.
A pricing decision should consider:
workload stability
operational risk
interruption tolerance
expected growth
engineering complexity
Saving money on compute is useful only if the infrastructure still meets business and reliability requirements.
The best AWS pricing strategy is the one that matches how your workloads actually behave.
4. Kubernetes Autoscaling: Scale With Demand, Not Guesswork
Slug:kubernetes-autoscaling-cost-efficiencyCategory:KubernetesRead time:7 min readExcerpt:
Kubernetes makes scaling easier, but poorly configured requests and autoscaling policies can still waste significant infrastructure capacity. Efficient scaling starts with measuring real workload demand.
Content:
Kubernetes does not automatically mean efficient infrastructure
Kubernetes provides powerful tools for running and scaling applications.
But Kubernetes can also make overprovisioning easier to hide.
A cluster may have plenty of unused capacity while still appearing healthy.
The most common reason is a mismatch between requested resources and actual workload requirements.
Requests matter
Kubernetes scheduling depends heavily on CPU and memory requests.
If an application requests 4 GB of memory but normally uses only 500 MB, the scheduler still reserves capacity based on the request.
Across hundreds of workloads, this can create a large amount of unused infrastructure.
The first step toward efficient autoscaling is understanding the difference between requested capacity and actual usage.
Horizontal Pod Autoscaler
The Horizontal Pod Autoscaler increases or decreases the number of application replicas based on demand.
It can react to CPU, memory, or custom metrics.
For example, an application may run three pods during normal traffic and scale to ten pods during peak demand.
This is usually more efficient than permanently running ten pods.
Vertical scaling
Vertical scaling focuses on the resources assigned to each workload.
If requests are consistently much higher than actual usage, they can be adjusted.
If workloads are frequently reaching their limits, additional capacity may be needed.
The objective is not to make requests as small as possible.
The objective is to make them realistic.
Cluster Autoscaler
Application scaling alone is not enough.
If pods scale down but Kubernetes nodes remain running, infrastructure cost may not decrease.
Cluster-level autoscaling allows the underlying node capacity to expand and contract as workload demand changes.
This is where application scaling and infrastructure cost optimization begin to work together.
Avoid scaling based on one metric
CPU utilization alone does not always represent workload demand.
Some applications are memory-intensive.
Others depend on queue depth, request count, latency, or custom business metrics.
Autoscaling should reflect the behavior of the application rather than relying on a default configuration.
Scaling is an ongoing process
Workload behavior changes.
Traffic patterns change.
Applications are updated.
Resource requirements evolve.
Autoscaling configurations should therefore be reviewed continuously.
The goal is to provide enough capacity when demand increases and release unnecessary capacity when demand falls.
Efficient Kubernetes infrastructure scales with real demand rather than assumptions.
