← All articles

Advanced Cloud Cost Optimization Strategy Teams Overlook

The hidden cost‑saving strategy most cloud teams ignore

If you search for ways to shrink your cloud bill, you’ll find countless guides on right‑sizing, spot instances, and reserved capacity. The tactic that consistently slips under the radar is a tag‑driven, automated idle‑resource cleanup strategy that spans multiple AWS accounts. By combining a disciplined tagging policy, AWS Config rules, and Lambda‑based remediation, you can continuously identify and retire resources that sit idle for longer than a business‑defined threshold—without manual hunting.

Why a tag‑driven, automated cleanup beats ad‑hoc checks

• Visibility at scale – Tags are the native metadata layer in AWS. When every resource carries a CostCenter and Owner tag, you can slice spend by team, project, or environment instantly.
• Policy enforcement – AWS Config can evaluate compliance in real time, flagging resources that violate your idle‑time policy.
• Zero‑touch remediation – A Lambda function can terminate or downsize non‑compliant resources automatically, turning a detection into a cost‑saving action.
• Audit trail – All changes are logged in CloudTrail, giving you a complete history for governance.

Step 1: Establish a strict tagging baseline

1.1 Define the required tag set

Create a tag policy in AWS Organizations that mandates the following keys on every resource type you care about:

• CostCenter – short code for the business unit (e.g., FIN, ENG).
• Owner – IAM user or role responsible for the resource.
• Environment – prod, stage, or dev.
• IdleShutdownAfterDays – integer indicating after how many idle days the resource may be terminated.

1.2 Enforce the policy

1. Open the AWS Organizations console → Policies → Tag policies.
2. Click Create policy, paste the JSON below, and attach it to the root OU or specific OUs.

{
  "tags": {
    "CostCenter": {"required": true},
    "Owner": {"required": true},
    "Environment": {"required": true},
    "IdleShutdownAfterDays": {"required": true, "value": {"type": "numeric", "min": 1, "max": 365}}
  }
}

1.3 Backfill missing tags

Use the AWS CLI to tag existing resources in bulk. Example for EC2 instances across all regions:

aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,Tags]' --output json | \
jq -r '.[] | select(.[] | length==0) | .[0]' | while read id; do
  aws ec2 create-tags --resources $id --tags Key=CostCenter,Value=ENG Key=Owner,Value=team-lead Key=Environment,Value=dev Key=IdleShutdownAfterDays,Value=30
done

Replace the tag values with your organization’s defaults.

Step 2: Detect idle resources with AWS Config

2.1 Choose the resource types to monitor

Common idle culprits include: - EBS volumes (unattached for >30 days) - Elastic IPs (allocated but not associated) - RDS snapshots older than a retention window - Lambda functions with zero invocations for a month - EC2 instances with CPU < 2 % for 7 consecutive days

2.2 Create Config rules

In the AWS Config console, select Rules → Add rule → Custom Lambda rule. Use the following blueprint for an EBS‑idle rule:

import boto3, datetime, os

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    idle_days = int(os.getenv('IDLE_DAYS', '30'))
    cutoff = datetime.datetime.utcnow() - datetime.timedelta(days=idle_days)
    volumes = ec2.describe_volumes(Filters=[{'Name': 'status', 'Values': ['available']}])['Volumes']
    non_compliant = []
    for vol in volumes:
        create_time = vol['CreateTime']
        if create_time < cutoff:
            non_compliant.append(vol['VolumeId'])
    return {'evaluationResults': non_compliant}

Set the environment variable IDLE_DAYS to the value from the IdleShutdownAfterDays tag (you can read the tag via boto3.resource('ec2').Volume(id).tags).

Repeat for other resource types, adjusting the filter logic.

2.3 Enable continuous evaluation

When you add a rule, choose Trigger type = Configuration changes and Periodic = Every 24 hours. This ensures the rule runs daily without missing any newly created idle resources.

Step 3: Automate remediation with Lambda

3.1 Build a generic cleanup function

Create a Lambda function named aws-idle-cleanup with the following permissions: - AWSLambdaBasicExecutionRole - ec2:TerminateInstances - ec2:DeleteVolume - elasticloadbalancing:DeleteLoadBalancer - rds:DeleteDBInstance - lambda:DeleteFunction

import boto3, os, json

def lambda_handler(event, context):
    resource_type = event['detail']['resourceType']
    resource_id = event['detail']['resourceId']
    client_map = {
        'AWS::EC2::Instance': boto3.client('ec2'),
        'AWS::EC2::Volume': boto3.client('ec2'),
        'AWS::EC2::EIP': boto3.client('ec2'),
        'AWS::RDS::DBInstance': boto3.client('rds'),
        'AWS::Lambda::Function': boto3.client('lambda')
    }
    client = client_map.get(resource_type)
    if not client:
        return {'status': 'unsupported'}
    try:
        if resource_type == 'AWS::EC2::Instance':
            client.terminate_instances(InstanceIds=[resource_id])
        elif resource_type == 'AWS::EC2::Volume':
            client.delete_volume(VolumeId=resource_id)
        elif resource_type == 'AWS::EC2::EIP':
            client.release_address(AllocationId=resource_id)
        elif resource_type == 'AWS::RDS::DBInstance':
            client.delete_db_instance(DBInstanceIdentifier=resource_id, SkipFinalSnapshot=True)
        elif resource_type == 'AWS::Lambda::Function':
            client.delete_function(FunctionName=resource_id)
        return {'status': 'deleted'}
    except Exception as e:
        return {'status': 'error', 'message': str(e)}

Deploy the function and note its ARN.

3.2 Wire Config to Lambda

In each Config rule, set Remediation action → AWS Systems Manager Automation → Create a new automation document that invokes the aws-idle-cleanup Lambda with the offending resource ARN.

3.3 Add a safety window

To avoid accidental termination of resources that are truly needed, configure the Lambda to send a Slack notification (via an incoming webhook) 24 hours before deletion. Include an “Approve” button that triggers a Step Functions state machine to cancel the deletion if clicked.

Step 4: Consolidate results across accounts with AWS Organizations

4.1 Enable cross‑account aggregation

In the AWS Config console of the master account, go to Settings → Aggregation → Add aggregator. Choose All accounts in the organization and select the regions you operate in.

4.2 Central dashboard

Create an Amazon QuickSight dataset that pulls from the aggregated Config compliance table. Build a dashboard that shows: - Total number of idle resources per account - Estimated monthly savings (use the pricing API to fetch per‑resource cost) - Trend of compliance over the last 30 days

You can embed this dashboard in an internal portal or share a public link for stakeholders.

Step 5: Quantify the dollar impact with the free AWS waste finder

The free AWS waste finder scans your read‑only AWS environment, lists idle resources, and estimates the monthly cost they generate. Run it once to get a baseline, then compare the baseline to the post‑automation numbers from your QuickSight dashboard. The difference is the direct financial benefit of the strategy.

Comparison of automation approaches

The table helps you decide whether you need the full Lambda remediation pipeline (recommended for most teams) or a lighter‑weight managed rule.

Frequently asked questions

How do I prevent the cleanup Lambda from terminating resources that are temporarily idle?

Add a tag IdleShutdownAfterDays with a value that reflects your tolerance. The Lambda reads this tag and only proceeds if the resource has been idle for at least that many days. You can also whitelist specific resource IDs in an SSM Parameter Store list.

Can this strategy be applied to non‑AWS clouds?

The core concepts—mandatory tagging, continuous compliance evaluation, and automated remediation—are cloud‑agnostic. AWS provides the native services that make implementation straightforward, but you can replicate the workflow in GCP (using Cloud Asset Inventory and Cloud Functions) or Azure (using Azure Policy and Logic Apps) once those integrations become available.

What is the performance impact of running Config rules daily across many accounts?

Config evaluates only the resource types you select, and the evaluation is incremental. In large organizations the daily run typically consumes a few hundred Config rule evaluations, well within the free tier. Monitoring the Config rule evaluation count in the billing console helps you stay within budget.

How do I measure the actual savings after automation?

Export the compliance report from Config (CSV) and join it with the pricing data from the AWS Pricing API. Multiply the number of idle resources by their hourly cost and sum across the month. Compare that figure with the baseline generated by the free AWS waste finder.

Key takeaways

• Enforce a mandatory tag set that includes an idle‑shutdown threshold.
• Use AWS Config rules to detect idle resources based on those tags.
• Deploy a Lambda function that safely terminates or downsizes non‑compliant resources.
• Aggregate compliance data across accounts with AWS Organizations for a unified view.
• Validate dollar impact with the free AWS waste finder and a QuickSight dashboard.
• The approach is fully automated, auditable, and scales with the number of accounts.

Next steps with CloudBudgetMaster

CloudBudgetMaster now scans AWS in read‑only mode, automatically discovers idle and wasted resources, and reports the dollar impact of each. GCP, Azure, and Snowflake support are coming soon. To start seeing hidden waste in your AWS environment, create a free account and let the platform do the heavy lifting.