← All articles

Advanced Cloud Cost Strategy: Combine Savings Plans with Spot for Idle Compute

Why most teams miss the “Savings‑Plan + Capacity‑Optimized Spot” strategy

Most engineers focus on obvious levers—right‑sizing EC2, deleting unattached EBS, or buying Reserved Instances. Those actions shave dollars but rarely move the needle on a large, variable workload. The tactic that consistently slips under the radar is pairing AWS Compute Savings Plans with a capacity‑optimized Spot Auto Scaling group and then automating off‑peak shutdowns. The result is a three‑layer shield:

1. Baseline discount from a Savings Plan that covers predictable usage.
2. Spot capacity that fills the remaining demand at up to 90 % lower price.
3. Scheduled termination that guarantees no idle instances linger overnight.

When each layer is implemented correctly, the combined dollar impact can exceed the savings from any single tactic. Below we break down the components, show concrete CLI and console steps, and provide a reusable template you can adapt to any AWS account.

Understanding the building blocks: Savings Plans, Spot, and Auto Scaling

Compute Savings Plans

• What they are – A flexible commitment to spend a fixed amount ($/hour) on any EC2, Fargate, or Lambda compute. Unlike Reserved Instances, they apply across instance families, OS, and tenancy.
• How to buy – In the AWS console go to Billing > Savings Plans and click Purchase Savings Plan. Choose Compute type, set the hourly commitment, and select a term (1‑year or 3‑year) with All‑Up‑Front, Partial‑Up‑Front, or No‑Up‑Front payment.
• CLI example:

aws savingsplans create-savings-plan \
  --savings-plan-type Compute \
  --commitment 500 \
  --term 3yr \
  --payment-option PartialUpfront \
  --region us-east-1

Capacity‑Optimized Spot

• What it is – Spot instances are spare EC2 capacity sold at market price. The capacity‑optimized allocation strategy tells Auto Scaling to launch Spot instances from the most abundant pools, reducing interruption risk.
• Key settings – In an Auto Scaling launch template set InstanceMarketOptions with SpotOptions:

"InstanceMarketOptions": {
  "MarketType": "spot",
  "SpotOptions": {
    "AllocationStrategy": "capacity-optimized",
    "InstanceInterruptionBehavior": "terminate"
  }
}

Auto Scaling groups (ASG)

• Mixed instances – By defining multiple instance types and a On‑Demand base capacity, the ASG can satisfy the Savings Plan commitment with On‑Demand while pulling the rest from Spot.
• CLI creation (simplified):

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name prod-mixed-asg \
  --launch-template "{\"LaunchTemplateName\":\"prod-template\",\"Version\":\"$Latest\"}" \
  --min-size 2 \
  --max-size 20 \
  --desired-capacity 5 \
  --mixed-instances-policy "{\"InstancesDistribution\":{\"OnDemandBaseCapacity\":2,\"OnDemandPercentageAboveBaseCapacity\":30,\"SpotAllocationStrategy\":\"capacity-optimized\"},\"LaunchTemplate\":{\"LaunchTemplateSpecification\":{\"LaunchTemplateName\":\"prod-template\",\"Version\":\"$Latest\"}}}"

Step‑by‑step: Build a mixed‑instance Auto Scaling group that maximizes Savings Plans and Spot

1. Identify baseline demand – Use Cost Explorer or the free AWS waste finder tool at /tools/aws-waste-finder to extract the average hourly CPU and memory usage of your production fleet over the past 30 days.
2. Calculate a Savings Plan commitment – Subtract the expected Spot‑covered portion (typically 70‑80 % of total capacity) from the baseline. Purchase a Compute Savings Plan that matches the remaining on‑demand commitment.
3. Create a launch template – Include the common AMI, security groups, IAM role, and the Spot market options shown above. Example console path: EC2 > Launch Templates > Create launch template.
4. Define a mixed‑instances policy – In the ASG wizard, under Advanced options, enable Mixed instances policy. Set On‑Demand base capacity to the number of instances needed to satisfy the Savings Plan (e.g., 2 instances). Set On‑Demand percentage above base capacity to a low value (10‑30 %) to keep most capacity on Spot.
5. Specify instance type list – Choose a family that meets your performance envelope, e.g., c5.large, c5a.large, c5n.large. The ASG will rotate among them based on Spot availability.
6. Configure health checks – Use both EC2 and ELB health checks to ensure Spot interruptions trigger a graceful replacement.
7. Deploy – Review and create the ASG. Verify the initial instance distribution in the Instances tab; you should see a mix of On‑Demand and Spot.
8. Tag for cost allocation – Add a CostCenter=Prod tag on the launch template. This enables precise reporting in Cost Explorer and in the CloudBudgetMaster dashboard.

Validation checklist

• Savings Plan coverage – In Billing > Savings Plans, the Utilization column should show > 90 % after a week of steady traffic.
• Spot interruption rate – In EC2 > Spot Requests, the Interruptions metric should stay below 5 %.
• Instance count – The ASG desired capacity matches the workload, with Spot making up the majority of instances.

Automating off‑peak shutdowns with Lambda and Instance Scheduler

Even with Spot, idle capacity can linger during low‑traffic windows (e.g., weekends). Automating a shutdown eliminates the residual on‑demand cost.

1. Create an IAM role for Lambda with autoscaling:UpdateAutoScalingGroup and ec2:DescribeInstances permissions.
2. Write the Lambda function (Python example):

import boto3
import os

autoscaling = boto3.client('autoscaling')

def lambda_handler(event, context):
    asg_name = os.getenv('ASG_NAME')
    # Reduce desired capacity to zero during off‑peak
    autoscaling.update_auto_scaling_group(
        AutoScalingGroupName=asg_name,
        DesiredCapacity=0,
        MinSize=0
    )
    return {'status': 'scaled down'}

3. Deploy – Use the console Lambda > Create function, set the environment variable ASG_NAME to your mixed‑instance group, and attach the IAM role.
4. Schedule – In EventBridge > Rules, create a rule with a cron expression for the off‑peak window, e.g., cron(0 22 ? * MON-FRI *) to scale down at 22:00 UTC on weekdays.
5. Scale back up – Add a second rule that runs at the start of business hours, setting DesiredCapacity back to the original value (store it in Parameter Store for reference).

This pattern guarantees that no on‑demand instances stay alive when traffic is negligible, while Spot instances will be terminated automatically by the ASG if they cannot be replaced.

Monitoring and validating the dollar impact

After the architecture is live, you need a feedback loop to confirm the expected savings.

Export the Cost Explorer report as CSV and compare the month‑over‑month spend. The free AWS waste finder can also highlight any lingering idle resources that the ASG missed.

Comparison of three idle‑compute mitigation tactics

The table shows why the advanced mixed‑instance approach, while requiring more initial work, delivers the deepest, most sustainable savings.

Frequently asked questions

How do I know what size Savings Plan to purchase?

Calculate the average on‑demand hourly spend you expect to keep after Spot fills the rest of the capacity. Use the AWS waste finder to get a baseline, then round up to the nearest $100 increment for the commitment.

Will Spot interruptions cause downtime for my users?

When you configure the Auto Scaling group with capacity‑optimized allocation and enable ELB health checks, the ASG automatically launches a replacement Spot instance before the interrupted one is terminated. This provides near‑zero impact for stateless services.

Can I apply this strategy to workloads that require GPUs?

Yes, but Spot availability for GPU families (e.g., p3, g4dn) is lower. Use a higher On‑Demand base capacity (e.g., 50 %) and monitor the Spot interruption rate closely.

Do I need to modify my CI/CD pipeline?

Only if you want the pipeline to tag new resources with the CostCenter key used for allocation reporting. Adding a simple aws ec2 create-tags step after resource creation is sufficient.

Key takeaways

• Pair a Compute Savings Plan with a capacity‑optimized Spot mixed‑instance Auto Scaling group to lock in baseline discounts while harvesting cheap excess capacity.
• Automate off‑peak shutdowns with a lightweight Lambda function and EventBridge schedule to eliminate residual on‑demand hours.
• Validate savings through Savings Plan utilization, Spot cost share, and idle‑instance metrics in CloudWatch and Cost Explorer.
• Use the free AWS waste finder (/tools/aws-waste-finder) to establish a data‑driven baseline before committing to a Savings Plan.
• When you are ready to scale the practice across accounts, create a free account at /register to centralize reporting.

CloudBudgetMaster automates this workflow by scanning your AWS environment with read‑only permissions, identifying idle or under‑utilized resources, and reporting the exact dollar impact of the Savings‑Plan + Spot strategy. Support for GCP, Azure, and Snowflake is coming soon.