How to Reduce AWS Cloud Costs by 40% Using FinOps Principles

Tags: AWS FinOps Cloud Cost Optimization DevOps Platform Engineering

Introduction

Cloud costs have a habit of silently spiraling. You spin up an EC2 instance for a quick test, forget to terminate it, and three months later you're explaining a $4,000 line item to your CTO. Sound familiar?

FinOps — short for Financial Operations — is the practice of bringing financial accountability to the variable spend model of cloud infrastructure. It is not just a set of tools; it is a cultural shift that aligns engineering, finance, and business teams around a single truth: every cloud dollar should deliver measurable value.

In this guide, you will learn how to implement FinOps principles on AWS to systematically reduce your cloud bill by 30–40%, without sacrificing performance or reliability.

What Is FinOps?

FinOps is defined by the FinOps Foundation as "an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology, and business teams to collaborate on data-driven spending decisions."

The FinOps lifecycle has three phases:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   INFORM    │ ──▶ │  OPTIMIZE   │ ──▶ │   OPERATE   │
│             │     │             │     │             │
│ Visibility  │     │ Right-size  │     │ Continuous  │
│ Tagging     │     │ Commitments │     │ Improvement │
│ Allocation  │     │ Waste Elim. │     │ Governance  │
└─────────────┘     └─────────────┘     └─────────────┘

Most teams never get past "Inform" because they lack proper tagging and visibility. Let's fix that first.

Phase 1: Inform — Build Full Cost Visibility

1.1 Tag Everything (Seriously, Everything)

Tagging is the foundation of FinOps. Without tags, you cannot allocate costs to teams, products, or environments.

Implement a mandatory tagging policy using AWS Config and Service Control Policies (SCPs):

# terraform/modules/tagging/main.tf
locals {
  mandatory_tags = {
    Environment = var.environment       # prod | staging | dev
    Team        = var.team              # platform | backend | data
    Project     = var.project           # my-app | cms | analytics
    CostCenter  = var.cost_center       # CC-001 | CC-002
    Owner       = var.owner             # aniket@company.com
    ManagedBy   = "terraform"
  }
}

Tag coverage target: 95%+. Use AWS Cost Explorer's tag coverage report to track this weekly.

1.2 Enable AWS Cost Anomaly Detection

This is free and catches runaway costs before they explode:

aws ce create-anomaly-monitor \
  --anomaly-monitor '{"MonitorName":"AllAWSServices","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}' \
  --region us-east-1

aws ce create-anomaly-subscription \
  --anomaly-subscription '{
    "SubscriptionName": "DailyAnomalyAlert",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/..."],
    "Subscribers": [{"Address": "devops@company.com", "Type": "EMAIL"}],
    "Threshold": 20,
    "Frequency": "DAILY"
  }'

1.3 Set Up AWS Cost and Usage Reports (CUR)

CUR is the most granular billing data AWS provides. Export it to S3 and query with Athena:

-- Find top 10 most expensive resources last month
SELECT
  line_item_resource_id,
  product_product_name,
  SUM(line_item_unblended_cost) AS total_cost
FROM
  my_cur_database.my_cur_table
WHERE
  month = '2025-05'
  AND line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY total_cost DESC
LIMIT 10;

Real-world result: One team discovered a forgotten NAT Gateway costing $1,200/month from a decommissioned VPC using this exact query.

Phase 2: Optimize — Cut the Waste

2.1 Right-Size EC2 Instances

AWS Compute Optimizer analyzes CloudWatch metrics and recommends right-sized instances. Enable it across your organization:

aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

Common patterns that waste money:

2.2 Savings Plans vs Reserved Instances

This is where the largest savings live. AWS offers:

• Compute Savings Plans — 66% off On-Demand, flexible across instance types and regions

• EC2 Instance Savings Plans — 72% off, locked to a specific instance family

• Reserved Instances — Up to 75% off, upfront commitment

Rule of thumb: Commit only to your baseline usage. Cover spikes with On-Demand or Spot.

On-Demand coverage strategy:
├── Baseline (predictable) → Savings Plans (1-year, no upfront)
├── Variable (growth)      → On-Demand
└── Fault-tolerant batch   → Spot Instances (up to 90% off)

2.3 Eliminate Idle and Orphaned Resources

Run this audit monthly. Use AWS Trusted Advisor or build your own scripts:

import boto3

def find_unattached_ebs_volumes(region='ap-south-1'):
    ec2 = boto3.client('ec2', region_name=region)
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )['Volumes']

    orphans = []
    for vol in volumes:
        cost_estimate = (vol['Size'] / 1024) * 0.10 * 730  # gp3 pricing
        orphans.append({
            'VolumeId': vol['VolumeId'],
            'SizeGB': vol['Size'],
            'MonthlyWaste': f"${cost_estimate:.2f}",
            'CreatedAt': str(vol['CreateTime'])
        })

    return orphans

print(find_unattached_ebs_volumes())

Common orphaned resources to audit:

• Unattached EBS volumes (check status: available)

• Unused Elastic IPs ($3.65/month each when unattached)

• Idle NAT Gateways ($32/month + data transfer)

• Forgotten Load Balancers with no targets

• Old AMI snapshots (storage costs accumulate silently)

2.4 Optimize S3 Storage with Intelligent-Tiering

For buckets with unpredictable access patterns, enable S3 Intelligent-Tiering:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket my-production-bucket \
  --id EntireBucket \
  --intelligent-tiering-configuration '{
    "Id": "EntireBucket",
    "Status": "Enabled",
    "Tierings": [
      {"Days": 90, "AccessTier": "ARCHIVE_ACCESS"},
      {"Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS"}
    ]
  }'

Expected savings: 40–68% on storage costs for infrequently accessed data.

2.5 Use Spot Instances for Workloads That Can Tolerate Interruption

Spot Instances are up to 90% cheaper. Good candidates:

• CI/CD build runners

• Data processing pipelines (Spark, EMR)

• ML training jobs

• Non-critical batch workloads

# EC2 Auto Scaling with mixed instance types and Spot
resource "aws_autoscaling_group" "spot_asg" {
  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 1
      on_demand_percentage_above_base_capacity = 20
      spot_allocation_strategy                 = "capacity-optimized"
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
      }
      override {
        instance_type = "m5.large"
      }
      override {
        instance_type = "m5a.large"
      }
      override {
        instance_type = "m4.large"
      }
    }
  }
}

Phase 3: Operate — Build Continuous Governance

3.1 Implement Budget Alerts Per Team

Never let a team exceed their allocation without knowing about it:

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "PlatformTeam-Monthly",
    "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {
      "TagKeyValue": ["user:Team$platform"]
    }
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "platform-lead@company.com"}]
  }]'

3.2 Cost Allocation Dashboard with Grafana + CloudWatch

Build a real-time cost dashboard so engineers see cost impact alongside their deployments:

# Lambda function: push daily costs to CloudWatch custom metrics
import boto3
from datetime import datetime, timedelta

def lambda_handler(event, context):
    ce = boto3.client('ce', region_name='us-east-1')
    cw = boto3.client('cloudwatch', region_name='ap-south-1')

    today = datetime.today().strftime('%Y-%m-%d')
    yesterday = (datetime.today() - timedelta(days=1)).strftime('%Y-%m-%d')

    response = ce.get_cost_and_usage(
        TimePeriod={'Start': yesterday, 'End': today},
        Granularity='DAILY',
        Metrics=['UnblendedCost'],
        GroupBy=[{'Type': 'TAG', 'Key': 'Team'}]
    )

    for group in response['ResultsByTime'][0]['Groups']:
        team = group['Keys'][0].replace('Team$', '')
        cost = float(group['Metrics']['UnblendedCost']['Amount'])
        cw.put_metric_data(
            Namespace='FinOps/TeamCosts',
            MetricData=[{
                'MetricName': 'DailyCost',
                'Dimensions': [{'Name': 'Team', 'Value': team}],
                'Value': cost,
                'Unit': 'None'
            }]
        )

3.3 FinOps Weekly Review Cadence

Operationalize FinOps with a lightweight weekly ritual:

Every Monday — 15 min FinOps standup:
├── Review Cost Anomaly alerts from last week
├── Check Savings Plan utilization (target: >85%)
├── Review top 5 cost drivers vs. previous week
└── Action items assigned to team leads

Every month:
├── Compute Optimizer recommendations reviewed
├── Unused resource audit (EBS, EIPs, snapshots)
├── Reserved Instance / Savings Plan coverage reviewed
└── Tagging compliance report shared with all teams

Results: What 40% Savings Looks Like

Here is a real breakdown of cost reductions achieved by applying these principles to a mid-sized AWS environment ($25,000/month baseline):

Tools Reference

Conclusion

Reducing AWS costs by 40% is not a one-time project — it is an ongoing practice. The teams that succeed at FinOps are not the ones with the most sophisticated tooling, but the ones that make cost visibility a first-class engineering concern.

Start with tagging. Add anomaly detection. Right-size your biggest instances. Commit to Savings Plans for your baseline. Then build the cultural habit of reviewing costs weekly alongside your system metrics.

Your cloud bill is a product metric. Treat it like one.