← All articles

Advanced Cloud Cost Optimization Strategy Teams Miss

Why traditional cost‑cutting methods leave money on the table

Most engineering and platform teams start their FinOps journey by looking at obvious levers – right‑sizing EC2, deleting unattached EBS volumes, or switching to Spot instances. Those actions are valuable, but they address static waste. What they often miss is dynamic spend that spikes unexpectedly, such as a runaway data‑transfer job, a mis‑configured backup that writes petabytes to S3, or a newly launched instance that never shuts down. Because these events are irregular, they slip through manual reviews and can inflate the monthly bill by thousands of dollars before anyone notices.

Detecting and correcting such anomalies in real time requires a different mindset: treat cost as a signal that can be monitored, alerted on, and automatically remediated. The tactic described below combines native AWS services – Budgets, CloudWatch Events, Lambda, and tagging – into a closed‑loop system that catches abnormal spend the moment it happens and takes corrective action without human intervention.

The overlooked tactic: automated cost‑anomaly detection and remediation

At its core, the strategy is simple: set a budget that defines normal spend, trigger an alert when spend deviates, and let a Lambda function enforce a predefined remediation (for example, stop or terminate the offending resource, apply a cheaper instance type, or adjust a lifecycle policy). The loop runs continuously, so the moment an unexpected cost appears, the system reacts.

Key benefits:

• Immediate financial impact – a runaway process can be stopped before it consumes large amounts of resources.
• Reduced manual toil – no need to scan dashboards daily.
• Audit trail – every remediation is logged in CloudTrail, satisfying compliance requirements.
• Scalable across accounts – the same Lambda can operate on dozens of accounts via cross‑account roles.

Below is a practical, step‑by‑step guide to building this pipeline on AWS.

1. Create a cost budget that captures normal spend

AWS Budgets lets you define a monetary threshold and receive alerts via SNS when actual spend exceeds the threshold. Follow these steps:

1. Open the AWS Billing console → Budgets → Create budget.
2. Choose Cost budget and click Set budget details.
3. Name the budget (e.g., Prod‑Monthly‑Spend‑Limit).
4. Set Period to Monthly and Budgeted amount to the amount you consider normal for the account.
5. Under Alert threshold, add a threshold at 80% (warning) and 100% (critical). Choose Alert type = Actual spend.
6. For Notification channel, create a new SNS topic (e.g., aws-cost-anomaly) and subscribe your email or Slack webhook.
7. Click Create budget.

The budget now publishes a message to the SNS topic whenever spend crosses the defined percentages.

2. Wire the SNS topic to a CloudWatch Event rule

AWS Budgets sends notifications to SNS, but we need a CloudWatch Event (now called EventBridge) rule that captures the SNS message and triggers a Lambda function.

aws events put-rule \
  --name "CostAnomalyRule" \
  --event-pattern '{"source":["aws.budgets"],"detail-type":["Budget Alert"],"detail":{"budgetName":["Prod‑Monthly‑Spend‑Limit"]}}' \
  --region us-east-1

Next, add the SNS topic as a target:

aws events put-targets \
  --rule "CostAnomalyRule" \
  --targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:CostAnomalyRemediator"

Make sure the Lambda execution role has events.amazonaws.com permission to invoke it.

3. Build the remediation Lambda function

The Lambda function receives the budget‑alert payload, extracts the account ID and budget name, then decides which resources to act on. A common first‑step remediation is to stop all running EC2 instances that lack a CostCenter tag – a sign they may be test or orphan resources.

3.1. Sample Python code (Python 3.9)

import json, boto3, os

ec2 = boto3.client('ec2')
cloudwatch = boto3.client('cloudwatch')

def lambda_handler(event, context):
    # Extract budget details
    detail = event.get('detail', {})
    budget_name = detail.get('budgetName')
    account_id = detail.get('accountId')
    # Log for audit
    print(f"Budget {budget_name} triggered in account {account_id}")

    # Find running instances without CostCenter tag
    filters = [
        {'Name': 'instance-state-name', 'Values': ['running']},
        {'Name': 'tag-key', 'Values': ['CostCenter']},
    ]
    # First get all running instances
    all_running = ec2.describe_instances(Filters=[{'Name': 'instance-state-name','Values':['running']}])
    to_stop = []
    for reservation in all_running['Reservations']:
        for instance in reservation['Instances']:
            tags = {t['Key']: t['Value'] for t in instance.get('Tags', [])}
            if 'CostCenter' not in tags:
                to_stop.append(instance['InstanceId'])

    if to_stop:
        print(f"Stopping instances: {to_stop}")
        ec2.stop_instances(InstanceIds=to_stop)
        # Emit a custom CloudWatch metric for visibility
        cloudwatch.put_metric_data(
            Namespace='CostAnomalyRemediation',
            MetricData=[{
                'MetricName': 'InstancesStopped',
                'Value': len(to_stop),
                'Unit': 'Count'
            }]
        )
    else:
        print('No untagged running instances found')
    return {'statusCode': 200, 'body': json.dumps('Remediation complete')}

3.2. Deploy the function

aws lambda create-function \
  --function-name CostAnomalyRemediator \
  --runtime python3.9 \
  --role arn:aws:iam::123456789012:role/CostAnomalyLambdaRole \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip \
  --region us-east-1

Add the following inline policy to the role so the function can stop instances and publish metrics:

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": ["ec2:StopInstances", "ec2:DescribeInstances"], "Resource": "*"},
    {"Effect": "Allow", "Action": ["cloudwatch:PutMetricData"], "Resource": "*"}
  ]
}

4. Enforce tagging discipline to reduce false positives

Automated remediation works best when resources are consistently tagged. Implement a Tag Enforcement Policy using AWS Organizations Service Control Policies (SCP) or AWS Config Rules.

• Config Rule: required-tags – checks that every EC2, RDS, and S3 resource has a CostCenter tag.
• SCP: deny ec2:RunInstances unless the request includes aws:TagKeys containing CostCenter.

CLI example for the Config rule:

aws configservice put-config-rule \
  --config-rule-name "required-tags" \
  --source '{"Owner":"AWS","SourceIdentifier":"REQUIRED_TAGS"}' \
  --input-parameters '{"tag1Key":"CostCenter"}' \
  --scope '{"ComplianceResourceTypes":["AWS::EC2::Instance","AWS::S3::Bucket"]}'

When a resource violates the rule, Config will flag it, and the next budget‑alert cycle will automatically stop it if it contributes to abnormal spend.

5. Measure impact and iterate

After the pipeline is live, track its effectiveness with two custom CloudWatch metrics:

Create a dashboard that shows spend before vs. after remediation. Use the AWS Cost Explorer API to pull daily spend and compare against a baseline.

aws ce get-cost-and-usage \
  --time-period Start=$(date -d '-30 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

If the AnomalyAlerts metric stays high, refine the budget thresholds or add more granular budgets (e.g., per‑service budgets for S3 and Data Transfer). Continuous improvement is part of the strategy.

6. Manual vs. automated cost‑anomaly handling

Frequently asked questions

How does this differ from AWS Cost Anomaly Detection?

AWS Cost Anomaly Detection (part of Cost Explorer) surfaces statistical outliers but does not automatically remediate them. The strategy here adds an action layer – a Lambda that stops or modifies the offending resource – turning a signal into a fix.

Can I use this approach for multiple AWS accounts?

Yes. Deploy the Lambda in a central monitoring account and grant it sts:AssumeRole permissions on each member account. The EventBridge rule can be set to listen to budget alerts from all linked accounts by omitting the budgetName filter or using a wildcard.

What if the remediation accidentally stops a production workload?

Start with a dry‑run mode. Add a flag (e.g., DRY_RUN=true in Lambda environment variables) that only logs the instances it would stop. Once confidence is built, flip the flag off. You can also whitelist critical instance IDs via a DynamoDB table that the Lambda checks before acting.

Do I need to write custom code for every service?

Not necessarily. The sample Lambda focuses on EC2, but you can extend it with additional if blocks for RDS (rds:stop-db-instance), Redshift (redshift:pause-cluster), or even scale down ECS services. The pattern remains the same: identify the resource, verify tags, and invoke the appropriate AWS SDK call.

Key takeaways

• Traditional FinOps checks catch static waste; dynamic anomalies require real‑time monitoring.
• Combine AWS Budgets, SNS, EventBridge, and Lambda to build a closed‑loop remediation pipeline.
• Enforce consistent tagging (e.g., CostCenter) to reduce false positives and improve automation accuracy.
• Track custom CloudWatch metrics (AnomalyAlerts, InstancesStopped) to quantify impact.
• Start with a dry‑run, iterate thresholds, and expand the Lambda to cover more services over time.
• Use the free AWS waste finder to surface existing idle resources before you enable the automated pipeline.
• When you’re ready to scale the solution across teams, create a free account and let CloudBudgetMaster surface the dollar impact of idle and wasted resources today; GCP, Azure and Snowflake support are coming soon.