Strategy

Advanced Cloud Cost Optimization Strategy Teams Overlook

Q: How often should I refresh the Compute Optimizer recommendations?

Compute Optimizer updates its recommendations every 12 hours. Running the `get-recommendations` command once daily is sufficient for most teams, but you can increase frequency during a cost‑reduction sprint.

Q: Will stopping an EC2 instance delete its attached EBS volumes?

No. Stopping preserves the root and any attached volumes. You continue to pay for the storage, but you eliminate the compute charge. If you also want to snapshot or delete the volumes, add a separate Lambda step after the stop action.

Q: Can I apply this strategy to spot instances?

Spot instances can be stopped and started, but you lose the spot price advantage when you restart. The safest pattern is to use the automation only on on‑demand or reserved instances that run continuously during business hours.

Q: What about services that do not support a stop API (e.g., S3, DynamoDB)?

Those services charge based on usage rather than instance uptime, so the start‑stop tactic does not apply. Instead, focus on lifecycle policies, TTL settings, and request‑level throttling for those resources.

October 24, 2026·6 min read·CloudBudgetMaster

The single tactic most cloud teams ignore: automated start‑stop scheduling based on real utilization data

If you want to shrink your cloud bill without sacrificing performance, the most effective yet underused strategy is to automatically stop idle compute resources and start them only when demand exists. By pairing AWS Compute Optimizer insights with EventBridge‑driven Lambda functions (or the built‑in Instance Scheduler), you can eliminate hours of waste on EC2, RDS, Redshift, and Elasticache while keeping workloads available on demand.

Why idle compute still hurts your bottom line

Even when an instance is not serving traffic, the underlying hardware, attached EBS volumes, and associated networking resources keep accruing charges. Common symptoms of hidden waste include:

Low CPU or memory utilization over a 30‑day window (often < 10%).
Scheduled workloads that run only during business hours but remain on 24/7.
Development or test environments left running after a sprint ends.

AWS bills per‑second for many services, but the minimum charge for an EC2 instance is still the full hour. Stopping the instance drops the compute charge to zero while still retaining the EBS volume, IP address, and instance metadata.

Step‑by‑step: Build an automated start‑stop pipeline

Below is a practical, repeatable workflow that works for any AWS account with read‑only permissions. The process uses only native services, so you do not need third‑party tools.

1. Identify low‑utilization resources with Compute Optimizer

aws compute-optimizer get-recommendations \
    --service EC2 \
    --account-ids $(aws sts get-caller-identity --query Account --output text) \
    --output json > ec2-recs.json

Open the JSON file and look for UtilizationMetrics where Cpu and Memory are consistently below a threshold you define (e.g., 10%).
Tag each candidate with CostOptimization=Idle so downstream automation can filter reliably.

2. Create a tagging policy with AWS Config (optional but recommended)

aws configservice put-config-rule \
    --config-rule-name "require-cost-optimization-tag" \
    --source "Owner=AWS,SourceIdentifier=RESOURCE_TAGGING" \
    --input-parameters '{"tagKey":"CostOptimization","tagValue":"Idle"}'

This rule ensures any new resource that matches the utilization pattern gets the proper tag automatically.

3. Set up an EventBridge rule to trigger a Lambda function at off‑peak times

aws events put-rule \
    --name "StopIdleInstancesNight" \
    --schedule-expression "cron(0 22 ? * MON-FRI *)"   # 22:00 UTC on weekdays

Create a second rule for the start‑up window:

aws events put-rule \
    --name "StartIdleInstancesMorning" \
    --schedule-expression "cron(0 6 ? * MON-FRI *)"   # 06:00 UTC on weekdays

4. Write the Lambda function (Python example)

import boto3
import os

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    action = os.getenv('ACTION')   # STOP or START
    # Find instances with the CostOptimization tag
    resp = ec2.describe_instances(
        Filters=[
            {'Name': 'tag:CostOptimization', 'Values': ['Idle']},
            {'Name': 'instance-state-name', 'Values': ['running' if action=='STOP' else 'stopped']}
        ]
    )
    ids = [i['InstanceId'] for r in resp['Reservations'] for i in r['Instances']]
    if not ids:
        return {'status': 'no instances to {}'.format(action.lower())}
    if action == 'STOP':
        ec2.stop_instances(InstanceIds=ids)
    else:
        ec2.start_instances(InstanceIds=ids)
    return {'status': '{}ed {} instances'.format(action.title(), len(ids))}

Deploy the function twice (once with ACTION=STOP, once with ACTION=START) and attach each to the corresponding EventBridge rule.

5. Extend the pattern to RDS, Redshift, and Elasticache

All these services support a stop-db-instance or pause-cluster API call. Replace the EC2 client with the appropriate service client and adjust the tag filter. Example for RDS:

aws rds stop-db-instance --db-instance-identifier my-db-instance

Add the same CostOptimization=Idle tag to the DB instance so the Lambda can discover it.

6. Verify cost impact with Cost Explorer

aws ce get-cost-and-usage \
    --time-period Start=$(date -d '-30 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
    --granularity DAILY \
    --filter '{"Tags": {"Key": "CostOptimization", "Values": ["Idle"]}}' \
    --metrics "UnblendedCost"

Compare the daily spend before and after the automation to quantify savings.

Comparison: Manual shutdown vs EventBridge/Lambda vs AWS Instance Scheduler

Approach	Setup effort	Granularity	Maintenance overhead	Typical savings
Manual `aws ec2 stop/start` (ad‑hoc)	Low (single CLI command)	Per‑instance, on‑demand	High – requires human action each cycle	Low – only occasional stops
EventBridge + Lambda	Medium – create rules, Lambda code, tags	Automated, schedule‑based	Medium – update code when new services added	High – consistent nightly stop/start
AWS Instance Scheduler (managed solution)	Medium – deploy CloudFormation stack, configure tags	Automated, supports multiple services	Low – AWS handles schedule evaluation	High – same as custom Lambda but with built‑in reporting

The custom Lambda approach gives you full control over which resources are affected and lets you embed additional logic (e.g., skip instances with a DoNotStop tag). The Instance Scheduler is a quick‑start for teams that prefer a managed solution.

Integrating the strategy into a broader FinOps workflow

Discovery – Run the free AWS waste finder to surface all idle resources in your account. The tool lists each resource, its current utilization, and the estimated monthly waste.
Tag enforcement – Use the Config rule from step 2 to keep tagging consistent across new deployments.
Automation – Deploy the EventBridge/Lambda pipeline (or Instance Scheduler) to enforce the start‑stop policy.
Monitoring – Add a CloudWatch dashboard that shows CPUUtilization and InstanceState for all CostOptimization=Idle resources. Set an alarm if any instance stays stopped longer than a defined window (e.g., 30 days) – that may indicate a forgotten environment.
Reporting – Schedule a weekly Lambda that calls the Cost Explorer API (as in step 6) and emails the cost delta to the engineering lead.

By embedding the tactic into a repeatable cycle, you turn a one‑time cleanup into a continuous cost‑saving engine.

Frequently asked questions

How often should I refresh the Compute Optimizer recommendations?

Compute Optimizer updates its recommendations every 12 hours. Running the get-recommendations command once daily is sufficient for most teams, but you can increase frequency during a cost‑reduction sprint.

Will stopping an EC2 instance delete its attached EBS volumes?