← All articles

Advanced Cloud Cost Optimization Strategy Teams Miss

How to unlock hidden savings with an advanced cloud cost optimization strategy

Most engineers and founders think they have trimmed the cloud bill by right‑sizing instances, buying Savings Plans, and deleting obvious orphaned volumes. The reality is that a systematic, tag‑driven re‑evaluation of idle resources uncovers far more waste. This post walks you through the exact steps, CLI commands, and AWS services needed to implement that strategy today.

Why traditional cost‑saving tactics leave money on the table

Traditional checklists focus on obvious items: - Unattached EBS volumes - Unused Elastic IPs - Over‑provisioned EC2 instances These items are easy to spot, so teams spend time on them. However, three hidden cost categories are routinely missed: 1. Long‑lived but under‑utilized resources – an RDS instance running at 5 % CPU for months. 2. Resources that become idle after a deployment – a Lambda function version that never receives traffic. 3. Mis‑tagged or untagged assets – cost allocation tags that are missing, making it impossible to attribute spend to a team. When you ignore these, you sacrifice up to 20 % of potential savings without any extra infrastructure changes.

The overlooked strategy: periodic idle‑resource re‑evaluation

The core of the strategy is a scheduled, automated audit that surfaces any resource whose utilization falls below a defined threshold for a configurable window (e.g., 30 days). The audit then tags the resource for review or automatically schedules termination.

Identify idle resources across services

Use the following AWS CLI commands to pull utilization metrics for common services:

# EC2 CPU utilization (average over 30 days)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --statistics Average \
  --period 86400 \
  --start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0

# RDS DBInstance CPU utilization
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --statistics Average \
  --period 86400 \
  --start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --dimensions Name=DBInstanceIdentifier,Value=mydbinstance

# Lambda invocations (zero invocations means idle)
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Invocations \
  --statistics Sum \
  --period 86400 \
  --start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --dimensions Name=FunctionName,Value=my-function

Collect the output into a CSV, then filter rows where the average is below a threshold you define (e.g., CPU < 10 %).

Automate detection with AWS Config Rules

AWS Config can continuously evaluate resources against custom Lambda‑backed rules. Create a rule that flags any EC2 instance with CPUUtilization < 10 for the past 30 days:

{
  "ConfigRuleName": "idle-ec2-cpu",
  "Source": {
    "Owner": "CUSTOM_LAMBDA",
    "SourceIdentifier": "arn:aws:lambda:us-east-1:123456789012:function:IdleEc2Evaluator"
  },
  "InputParameters": {
    "cpuThreshold": "10",
    "days": "30"
  },
  "MaximumExecutionFrequency": "TwentyFour_Hours"
}

Deploy the Lambda function using the AWS SAM template provided in the free AWS waste finder tool. The rule will place non‑compliant resources into a Config Non‑compliant list that you can query via:

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name idle-ec2-cpu

Use cost allocation tags to prioritize remediation

Tagging lets you assign a dollar value to each idle resource. Follow this tagging convention: - CostCenter=Finance - Owner=team@example.com - IdleSince=2024-07-01 Apply tags in bulk with the CLI:

aws ec2 create-tags \
  --resources i-0123456789abcdef0 i-0fedcba9876543210 \
  --tags Key=IdleSince,Value=$(date -u +%Y-%m-%d)

Once tagged, you can generate a cost report with Cost Explorer:

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

The output shows the exact dollar impact of idle assets, ready for a FinOps review.

Implementing a tag‑driven lifecycle policy

After you have identified idle resources, enforce a lifecycle that either shuts them down or deletes them after a grace period.

Tagging standards

1. Create a tagging policy in AWS Organizations → Tag Policies.
2. Require the IdleSince tag on all compute resources.
3. Enforce the policy with aws organizations enable-policy-type.

Lifecycle policies for storage and databases

• EBS snapshots: Use the aws ec2 create-snapshot command with --description "IdleSince=$(date -u +%Y-%m-%d)". Then add a Data Lifecycle Manager (DLM) rule that deletes snapshots older than 90 days.
• RDS automated backups: Set BackupRetentionPeriod to 7 for instances flagged as idle, then schedule a Lambda to call modify-db-instance after the grace period.

aws rds modify-db-instance \
  --db-instance-identifier mydbinstance \
  --backup-retention-period 7 \
  --apply-immediately

• S3 objects: Apply an S3 Object Lifecycle configuration that transitions objects with the IdleSince tag to Glacier after 30 days and expires after 365 days.

{
  "Rules": [{
    "ID": "IdleObjectRule",
    "Filter": {"Tag": {"Key": "IdleSince", "Value": "2024-07-01"}},
    "Status": "Enabled",
    "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}],
    "Expiration": {"Days": 365}
  }]
}

Leveraging AWS Compute Optimizer and Trusted Advisor together

Both services provide recommendations, but they differ in scope and granularity. Use them side‑by‑side for a complete picture.

Practical workflow: 1. Pull Compute Optimizer recommendations with aws compute-optimizer get-recommendations --service EC2_INSTANCE. 2. Pull Trusted Advisor cost‑optimizing checks with aws support describe-trusted-advisor-check-result. 3. Merge the two JSON outputs, de‑duplicate by resource ID, and feed the result into your idle‑resource pipeline.

Building an automated waste‑finder pipeline with Lambda and Step Functions

A fully automated pipeline removes manual steps and guarantees that every idle resource is evaluated on schedule.

Architecture overview

1. Step Functions state machine triggers daily.
2. Lambda A collects utilization metrics via CloudWatch.
3. Lambda B applies thresholds, tags idle resources, and writes findings to an S3 bucket.
4. Lambda C sends a Slack notification and creates a ticket in your incident system.

Sample Step Functions definition (YAML)

StartAt: CollectMetrics
States:
  CollectMetrics:
    Type: Task
    Resource: arn:aws:lambda:us-east-1:123456789012:function:CollectMetrics
    Next: EvaluateIdle
  EvaluateIdle:
    Type: Task
    Resource: arn:aws:lambda:us-east-1:123456789012:function:EvaluateIdle
    Next: NotifyTeam
  NotifyTeam:
    Type: Task
    Resource: arn:aws:lambda:us-east-1:123456789012:function:NotifyTeam
    End: true

Deploy the state machine with the AWS CLI:

aws stepfunctions create-state-machine \
  --name IdleResourcePipeline \
  --definition file://state-machine.yaml \
  --role-arn arn:aws:iam::123456789012:role/StepFunctionsExecutionRole

The pipeline runs without any write permissions to your production resources, making it safe to test in a read‑only environment.

Integrating findings into your FinOps review cadence

Automation is only valuable if the output reaches the people who control spend.

Weekly dashboards

• Export the S3 findings bucket to Amazon QuickSight.
• Build a dashboard with three tiles: Idle Compute, Idle Storage, Projected Savings.
• Schedule an email snapshot to the finance mailing list every Monday.

Alerting thresholds

Create a CloudWatch alarm that fires when projected monthly waste exceeds 5 % of total spend:

aws cloudwatch put-metric-alarm \
  --alarm-name "HighIdleWaste" \
  --metric-name "ProjectedIdleCost" \
  --namespace "Custom/FinOps" \
  --statistic Sum \
  --period 86400 \
  --threshold $(aws ce get-cost-and-usage --time-period Start=$(date -d '-30 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) --metrics UnblendedCost --query "ResultsByTime[0].Total.UnblendedCost.Amount" --output text) \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:FinOpsAlerts

When the alarm triggers, the same Slack webhook used by the pipeline can push a concise summary to the #finops channel.

Frequently asked questions

How often should I run the idle‑resource audit?

Running the audit daily catches resources that become idle shortly after a deployment. For smaller teams, a weekly cadence may be sufficient, but the Step Functions pipeline can be scheduled at any interval you prefer.

Does tagging alone reduce costs?

Tagging does not directly reduce spend, but it enables precise cost attribution and automated lifecycle policies. Without tags, you cannot reliably calculate the dollar impact of idle assets.

Can I use this strategy for services beyond EC2, RDS, and Lambda?

Yes. The same pattern applies to DynamoDB tables, Elasticache clusters, and even API Gateway stages. Replace the CloudWatch metric names and dimensions in the CLI snippets to match the target service.

Will the automation interfere with production workloads?

The pipeline runs in read‑only mode and only adds tags or creates notifications. No resources are stopped or terminated without explicit human approval, so production stability is preserved.

Key takeaways

• Traditional checklists miss long‑lived, under‑utilized resources that still generate spend.
• A periodic, automated audit that tags idle assets reveals the true dollar impact.
• Combine AWS Config Rules, Compute Optimizer, and Trusted Advisor for comprehensive coverage.
• Deploy a Lambda‑Step Functions pipeline to run the audit without manual effort.
• Feed the findings into weekly dashboards and alerting to keep FinOps stakeholders informed.

CloudBudgetMaster automates this advanced strategy. It scans AWS accounts in read‑only mode today, identifies idle and wasted resources, and reports the exact dollar impact. Support for GCP, Azure, and Snowflake is coming soon. To try the detection yourself, use our free AWS waste finder and then create a free account to see the full report.