Cost Optimization (FinOps)

TL;DR

• Cost allocation tagging is foundational; without it, root-cause cost investigation is impossible.
• Cost Explorer is passive (requires active review); Budgets with anomaly detection is proactive (pushes alerts).
• Savings Plans are flexible across instance families/sizes/services; Reserved Instances are tied to specific attributes and offer slightly deeper discounts.
• Commitment sizing: use stable historical baseline, not growth projections; multi-year commitments don’t shrink if architecture changes.
• Compute Optimizer automates right-sizing analysis across fleets; identifies over-provisioned instances consistently.
• Spot Instances are the biggest cost lever for interruption-tolerant workloads; many teams leave this unused.

Core Concepts

Cost Allocation Tagging: The Foundation

Without consistent tagging, cost visibility is impossible. A finance stakeholder asking “why did the bill jump 20%” gets answered “the entire account bill increased 20%,” which is useless for accountability.

Standard tags: team, environment (dev/staging/prod), project, cost-center, owner.

Enforcement: Tagging is voluntary unless enforced. Teams default to not tagging. Use SCP (Service Control Policies) to require tags on resource creation, or tag policies to enforce specific tag keys and values.

Example finding: A build system is consuming $10K/month unexpectedly. With tagging, you identify it’s the “dev-environment” “ci-cd-team” project. Without tagging, the cost is unattributed and goes unexamined.

Cost Explorer vs. Budgets

Cost Explorer: Historical and forecasted spend, broken down by service, tag, region, etc. Requires active review. A cost regression sitting in Cost Explorer unreviewed for weeks is a real failure mode.

Budgets with anomaly detection: Proactive alerts when spend deviates from expected patterns. Example: a runaway instance increases spend by 50% in a day. Anomaly detection alerts within hours. Cost Explorer wouldn’t surface the anomaly until someone reviews the dashboard.

Mature FinOps: Cost Explorer + Budgets. Budgets catch anomalies early. Cost Explorer provides detailed investigation.

Savings Plans vs. Reserved Instances

Reserved Instances (RIs): Purchase a specific instance type/size/region for 1 or 3 years. Slightly deeper discount (~40% for 3 years) than Savings Plans. Tied to specific attributes; if instance type changes, RI doesn’t apply.

Savings Plans: Purchase compute capacity (not instance type) for 1 or 3 years. Applies across instance families, sizes, and even across EC2/Fargate/Lambda within the commitment. More flexible (~30-40% discount).

Trade-off: RIs offer slightly deeper discounts for a stable, well-known instance type. Savings Plans offer flexibility when workload shape varies over time.

Sizing discipline: Both should be sized conservatively against stable historical baseline (e.g., lowest month’s usage), not aggressively against a growth projection. A commitment sized at “peak usage” or “projected future usage” wastes money if architecture changes.

Example mistake: Team commits to a 3-year Savings Plan based on current usage of 100 compute-units. Architecture changes 8 months later; usage drops to 50 units. Team is still paying for 100 units. Cost: ~$4K/month wasted for the remaining 28 months.

Compute Optimizer: Automated Right-Sizing

Compute Optimizer uses ML to analyze historical utilization data (CPU, memory, network) across EC2, Lambda, and RDS instances. It generates right-sizing recommendations with projected cost/performance impact.

Example: An instance has been right-sized as t3.2xlarge but consistently runs at 10% CPU. Compute Optimizer recommends downsizing to t3.medium, reducing cost by 80% with no performance impact.

Benefit: Automation. Analyzing 1000 instances manually is untenable. Compute Optimizer handles it.

Limitation: Only provides recommendations. Requires review and action. An unimplemented recommendation is wasted analysis.

Spot Instances: Biggest Cost Lever

Spot Instances are available at up to 90% discount vs. On-Demand pricing. The trade-off: AWS can terminate a Spot Instance with 2-minute notice when capacity is needed elsewhere.

When to use: Interruption-tolerant workloads (batch jobs, distributed data processing, analytics). Not suitable for interactive applications or databases (unless replicated).

Cost impact: Switching a batch job from On-Demand to Spot can reduce its compute cost by 70-80%. This is the biggest lever for cost optimization, and many teams leave it unused.

Risk: Teams assume Spot is “unreliable” without evaluating actual interruption patterns. For many workloads, interruptions are rare, and the cost savings exceed the operational complexity.

Comparison Table

Command/Configuration Reference

Enforce Cost Allocation Tagging via SCP

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "rds:CreateDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Environment": "true"
        }
      }
    }
  ]
}

Create Budget with Anomaly Detection

aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

Budget JSON:

{
  "BudgetName": "anomaly-detection-budget",
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "AutoAdjustData": {
    "AutoAdjustType": "ANOMALY",
    "HistoricalOptions": {
      "BudgetAdjustmentPeriod": 3
    }
  }
}

Retrieve Compute Optimizer Recommendations

aws compute-optimizer get-ec2-instance-recommendations \
  --account-ids 123456789012 \
  --finding-reason-codes Underutilized

Common Pitfalls

Interview Questions

• A finance stakeholder wants to know why the AWS bill grew 20% last month, and your team can’t answer beyond the total account bill. What’s broken, and how do you fix it? — Tests understanding of cost allocation tagging as the foundational gap for accountability.

• Walk me through the trade-off between Savings Plans and Reserved Instances for a workload with stable, predictable instance type. — Tests understanding of flexibility (Savings Plans) vs. discount depth (RIs) trade-off.

• Your team committed to a 3-year Compute Savings Plan at 100 units, and 8 months later, architecture changes halve the usage to 50 units. What happened, and how would you avoid this? — Tests understanding of commitment risk and conservative sizing discipline.

• A batch processing job currently runs on On-Demand EC2 and costs $500/month. How would you approach reducing that cost, and what are the risks? — Tests understanding of Spot Instances as the biggest lever, and operational considerations for interruption tolerance.