Week 23: Cost Optimization & FinOps

1. Cost Explorer & Tagging

AWS's Cost Explorer is the starting point for any cost question, and it's only as useful as the tags applied to your resources — group by "Service" and you learn EC2 costs $4,200 last month; group by a team or project tag and you learn which team's EC2 usage that actually is. Every resource created in this course since Week 8 should carry consistent tags for exactly this reason.

provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      team        = "platform"
      environment = var.environment
      managed_by  = "terraform"
      cost_center = "eng-infra"
    }
  }
}

default_tags at the provider level, from Week 9's Terraform, applies these tags to every resource the provider creates without repeating them in every resource block — which matters because a tagging policy that depends on every engineer remembering to add tags manually reliably ends up with gaps. Once tags are consistent, AWS Cost Anomaly Detection can alert automatically when a specific tagged group's spend jumps unexpectedly, the cost equivalent of Week 21's burn-rate alerting.

2. Right-Sizing, Autoscaling & Spot

Right-sizing means matching an instance's actual CPU/memory utilization to what it's provisioned for — AWS Compute Optimizer analyzes real CloudWatch usage and recommends a smaller (or larger) instance type based on observed load, not on the guess made when the resource was first provisioned. A t3.large running at 8% average CPU utilization is very likely over-provisioned; downsizing it to a t3.small can cut its cost by more than half with no functional change.

Autoscaling — the Kubernetes Horizontal Pod Autoscaler from Week 12, or an EC2 Auto Scaling Group — solves a related but distinct problem: instead of provisioning for peak load permanently, capacity tracks actual demand, scaling down (and reducing cost) automatically during low-traffic periods rather than running peak-sized infrastructure around the clock.

resource "aws_eks_node_group" "spot" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "spot-workers"
  capacity_type   = "SPOT"        # up to ~70-90% cheaper than On-Demand
  instance_types  = ["t3.large", "t3a.large", "t3.xlarge"]  # multiple types = better availability

  scaling_config {
    desired_size = 3
    min_size     = 1
    max_size     = 10
  }
}

Spot instances use AWS's spare capacity at a steep discount, with one real trade-off: AWS can reclaim a Spot instance with a two-minute warning if it needs the capacity back. That makes Spot the right fit for stateless, horizontally-scaled workloads that tolerate a Pod being interrupted and rescheduled — exactly what Week 12's readiness probes and multi-replica Deployments already handle gracefully — and the wrong fit for a StatefulSet's database Pod from Week 15, where losing the node mid-write is a much bigger problem.

3. Commitments & the FinOps Team Model

For a workload that genuinely runs continuously — unlike the interruption-tolerant case Spot is built for — Reserved Instances and Savings Plans trade commitment for discount: committing to a 1- or 3-year term (with no-upfront, partial-upfront, or all-upfront payment options) in exchange for up to ~40-60% off On-Demand pricing. A Compute Savings Plan is the more flexible of the two — it applies automatically across EC2, Fargate and Lambda regardless of instance family or region, unlike a Reserved Instance tied to a specific instance type.

FinOps is the organizational practice that makes all of this sustained rather than a one-time cleanup exercise — typically a small cross-functional team (finance, engineering, and often a dedicated FinOps practitioner) that owns cost visibility, sets showback/chargeback reporting per team using the tags from Section 1, and reviews commitment coverage on a recurring cadence rather than only when a bill spikes unexpectedly.

1. Coverage: what % of steady-state compute is covered by
   Savings Plans / Reserved Instances vs. On-Demand?
2. Utilization: are we paying for committed capacity we're
   not actually using?
3. Anomalies: did any tagged team/project's spend jump
   >20% month-over-month, and why?
4. Right-sizing: what does Compute Optimizer recommend this
   month that we haven't acted on yet?
5. Waste: any untagged, orphaned resources (unattached EBS
   volumes, idle load balancers, old snapshots)?

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.