Part 19: FinOps & Cost Optimization

The Cloud Cost Problem

Cloud spending is growing faster than cloud adoption itself. Gartner estimates worldwide public cloud spending exceeded $720 billion in 2024, with organizations routinely wasting 30-35% of their cloud budgets on idle, oversized, or poorly optimized resources. The promise of cloud — pay only for what you use — has become a cautionary tale for finance teams blindsided by bills that dwarf on-premise costs.

The root causes of cloud overspend are predictable: engineers provision for peak loads and never scale down, development environments run 24/7 when they're used 8 hours a day, zombie resources accumulate without owners, and data transfer charges lurk in the shadows of every architecture diagram. Without deliberate financial governance, cloud costs grow exponentially.

Why Cloud Costs Surprise Everyone

Traditional IT operates on a CapEx model — you buy servers, depreciate them over 3-5 years, and costs are predictable. Cloud flips this to OpEx: costs are variable, granular (per-second billing), and distributed across hundreds of services. Without guardrails, any engineer with API access can spin up resources that cost thousands per hour.

The FinOps Lifecycle

The FinOps Foundation defines a continuous lifecycle of three phases that organizations iterate through as they mature their cloud financial practices:

flowchart LR
    A[Inform] --> B[Optimize]
    B --> C[Operate]
    C --> A

    A:::inform
    B:::optimize
    C:::operate

    classDef inform fill:#e8f4fd,stroke:#16476A,color:#16476A
    classDef optimize fill:#e8fdf4,stroke:#3B9797,color:#132440
    classDef operate fill:#fde8e8,stroke:#BF092F,color:#132440
                            

• Inform: Visibility into where money goes — tagging, allocation, dashboards, anomaly detection
• Optimize: Taking action to reduce waste — right-sizing, reservations, spot, architecture changes
• Operate: Continuous governance — policies, budgets, forecasting, organizational alignment

Understanding Cloud Pricing

Cloud providers offer multiple pricing models designed for different use cases and commitment levels. Understanding these options is the foundation of any cost optimization strategy.

On-Demand (Pay-As-You-Go)

The default pricing model — pay per second/minute/hour with no commitment. Maximum flexibility, maximum cost. Best for unpredictable workloads, development environments, and short-lived resources.

# Check current on-demand pricing for EC2 instances
aws pricing get-products \
  --service-code AmazonEC2 \
  --filters "Type=TERM_MATCH,Field=instanceType,Value=m5.xlarge" \
            "Type=TERM_MATCH,Field=location,Value=US East (N. Virginia)" \
            "Type=TERM_MATCH,Field=operatingSystem,Value=Linux" \
            "Type=TERM_MATCH,Field=tenancy,Value=Shared" \
            "Type=TERM_MATCH,Field=preInstalledSw,Value=NA" \
  --region us-east-1 \
  --output json | jq '.PriceList[0]' | jq -r '.terms.OnDemand | to_entries[0].value.priceDimensions | to_entries[0].value.pricePerUnit.USD'

Reserved, Savings Plans, and Committed Use

Commitment-based discounts trade flexibility for savings of 30-72% compared to on-demand pricing:

Data Transfer: The Hidden Cost Killer

Data transfer costs are the most commonly overlooked expense in cloud architectures. Ingress is usually free, but egress charges accumulate quickly — especially in multi-region or hybrid architectures.

Cost Visibility & Allocation

You can't optimize what you can't see. Cost visibility is the first step in the FinOps lifecycle — understanding exactly where every dollar goes, who's responsible, and whether it's delivering value.

Tagging Strategy: The Foundation of Cost Allocation

Tags are key-value pairs attached to cloud resources that enable cost attribution, automation, and governance. A well-designed tagging strategy is the single most impactful FinOps investment you can make.

# terraform/modules/tagging/variables.tf
# Mandatory tags enforced via Terraform module

variable "mandatory_tags" {
  description = "Tags required on every resource"
  type = object({
    environment  = string  # dev, staging, prod
    team         = string  # engineering, data, platform
    service      = string  # auth-service, payment-api
    cost_center  = string  # CC-1234
    owner        = string  # team-platform@company.com
    managed_by   = string  # terraform, manual, helm
    project      = string  # project-phoenix
  })
}

variable "optional_tags" {
  description = "Optional but recommended tags"
  type = map(string)
  default = {}
}

locals {
  all_tags = merge(
    var.mandatory_tags,
    var.optional_tags,
    {
      created_date = formatdate("YYYY-MM-DD", timestamp())
      terraform    = "true"
    }
  )
}

# terraform/modules/tagging/main.tf
# Tag policy enforcement via AWS Organizations

resource "aws_organizations_policy" "tag_policy" {
  name        = "mandatory-cost-tags"
  description = "Enforce mandatory cost allocation tags"
  type        = "TAG_POLICY"

  content = jsonencode({
    tags = {
      environment = {
        tag_key = { "@@assign" = "environment" }
        tag_value = {
          "@@assign" = ["dev", "staging", "prod", "shared"]
        }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "ec2:volume",
            "rds:db",
            "s3:bucket",
            "lambda:function"
          ]
        }
      }
      cost_center = {
        tag_key = { "@@assign" = "cost_center" }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "rds:db",
            "s3:bucket"
          ]
        }
      }
    }
  })
}

Showback vs Chargeback

Organizations use two models for attributing cloud costs to business units:

# cost-allocation-rules.yaml
# Rules for allocating shared costs across teams

shared_costs:
  kubernetes_cluster:
    method: proportional
    metric: cpu_requests
    services:
      - name: auth-service
        namespace: auth
      - name: payment-api
        namespace: payments
      - name: user-service
        namespace: users

  shared_database:
    method: fixed_percentage
    allocations:
      team-platform: 40%
      team-product: 35%
      team-data: 25%

  networking:
    method: proportional
    metric: egress_bytes
    exclude:
      - shared-vpc-hub  # Allocated to platform team

  observability_stack:
    method: equal_split
    teams: ["platform", "product", "data", "ml"]

Building Cost Dashboards

# Query AWS Cost Explorer for daily costs by service
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-05-14 \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --filter '{
    "Tags": {
      "Key": "environment",
      "Values": ["prod"]
    }
  }' \
  --output json | jq '.ResultsByTime[] | {
    date: .TimePeriod.Start,
    services: [.Groups[] | {service: .Keys[0], cost: .Metrics.UnblendedCost.Amount}]
  }'

Right-Sizing

Right-sizing is the process of matching instance types and sizes to actual workload requirements. Studies consistently show that 40-60% of cloud instances are oversized by at least one size — meaning organizations pay for capacity they never use.

flowchart TD
    A[Collect Metrics
14-30 days] --> B{Peak CPU
> 80%?}
    B -->|Yes| C{Memory
Constrained?}
    B -->|No| D{Peak CPU
> 40%?}
    D -->|Yes| E[Downsize 1 tier]
    D -->|No| F{Steady
Workload?}
    F -->|Yes| G[Downsize 2 tiers +
Consider Reserved]
    F -->|No| H[Consider Spot/
Auto-scaling]
    C -->|Yes| I[Switch to Memory-
Optimized Family]
    C -->|No| J[Current Size
Appropriate]

    style A fill:#e8f4fd,stroke:#16476A
    style E fill:#e8fdf4,stroke:#3B9797
    style G fill:#e8fdf4,stroke:#3B9797
    style H fill:#fde8e8,stroke:#BF092F
                            

Compute Right-Sizing with Cloud Tools

# AWS Compute Optimizer - Get recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --filters "name=Finding,values=OVER_PROVISIONED" \
  --output json | jq '.instanceRecommendations[] | {
    instanceId: .instanceArn | split("/")[1],
    currentType: .currentInstanceType,
    finding: .finding,
    recommendations: [.recommendationOptions[] | {
      type: .instanceType,
      projectedUtilization: .projectedUtilizationMetrics,
      estimatedMonthlySavings: .estimatedMonthlySavings.value,
      savingsCurrency: .estimatedMonthlySavings.currency,
      risk: .performanceRisk
    }]
  }'

# Azure Advisor right-sizing recommendations
az advisor recommendation list \
  --filter "Category eq 'Cost'" \
  --query "[?contains(shortDescription.problem, 'right-size')].{
    resource: resourceMetadata.resourceId,
    impact: impact,
    savings: extendedProperties.annualSavingsAmount,
    currentSku: extendedProperties.currentSku,
    targetSku: extendedProperties.targetSku
  }" \
  --output table

Container Right-Sizing (Kubernetes)

In Kubernetes, right-sizing means setting appropriate CPU and memory requests/limits. Over-requesting wastes cluster capacity; under-requesting causes throttling and OOM kills.

# vpa-recommendation.yaml
# Vertical Pod Autoscaler for automatic right-sizing
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-api-vpa
  namespace: payments
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-api
  updatePolicy:
    updateMode: "Auto"  # Options: Off, Initial, Recreate, Auto
  resourcePolicy:
    containerPolicies:
      - containerName: payment-api
        minAllowed:
          cpu: 100m
          memory: 128Mi
        maxAllowed:
          cpu: 2000m
          memory: 4Gi
        controlledResources: ["cpu", "memory"]
        controlledValues: RequestsAndLimits

# Check VPA recommendations
kubectl get vpa payment-api-vpa -n payments -o jsonpath='{.status.recommendation.containerRecommendations[0]}' | jq '.'

# Example output:
# {
#   "containerName": "payment-api",
#   "lowerBound": { "cpu": "150m", "memory": "256Mi" },
#   "target": { "cpu": "350m", "memory": "512Mi" },
#   "upperBound": { "cpu": "800m", "memory": "1Gi" },
#   "uncappedTarget": { "cpu": "350m", "memory": "512Mi" }
# }

Reserved Instances & Savings Plans

Reservations are the highest-impact cost optimization for stable workloads. If you know a workload will run continuously for 1-3 years, committing to reserved capacity can save 40-72% compared to on-demand pricing.

Commitment Options Comparison

When to Reserve: Decision Framework

flowchart TD
    A[Workload Analysis] --> B{Running
> 70% of time?}
    B -->|No| C{Predictable
Schedule?}
    B -->|Yes| D{Stable for
1+ years?}
    C -->|Yes| E[Scheduled Instances
or Auto-scaling]
    C -->|No| F[On-Demand or
Spot Instances]
    D -->|Yes| G{Know exact
instance type?}
    D -->|No| H[Convertible RI or
Compute Savings Plan]
    G -->|Yes| I[Standard RI or
EC2 Savings Plan]
    G -->|No| H

    style I fill:#e8fdf4,stroke:#3B9797
    style H fill:#e8f4fd,stroke:#16476A
    style E fill:#ffd,stroke:#880
    style F fill:#fde8e8,stroke:#BF092F
                            

# Analyze RI coverage and utilization
aws ce get-reservation-coverage \
  --time-period Start=2026-04-01,End=2026-05-01 \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE \
  --output json | jq '.CoveragesByTime[0].Groups[] | {
    instanceType: .Attributes.instanceType,
    coverageHours: .Coverage.CoverageHours,
    onDemandHours: .Coverage.OnDemandCost,
    coveragePercentage: .Coverage.CoverageHoursPercentage
  }'

# Get RI purchase recommendations
aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --lookback-period-in-days SIXTY_DAYS \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --output json | jq '.Recommendations[0].RecommendationDetails[] | {
    instanceType: .InstanceDetails.EC2InstanceDetails.instanceType,
    region: .InstanceDetails.EC2InstanceDetails.region,
    recommendedCount: .RecommendedNumberOfInstancesToPurchase,
    estimatedMonthlySavings: .EstimatedMonthlySavingsAmount,
    upfrontCost: .UpfrontCost
  }'

Spot & Preemptible Strategies

Spot instances offer the deepest discounts (60-90% off on-demand) by using spare cloud capacity. The trade-off: instances can be reclaimed with as little as 2 minutes notice. Mastering spot requires designing for interruption.

How Spot Pricing Works

Cloud providers have massive pools of unused capacity. Rather than let it idle, they offer it at steep discounts with the caveat that it can be reclaimed when demand for on-demand capacity increases.

Spot-Friendly Workloads

• CI/CD pipelines — builds can retry on interruption
• Batch processing — checkpointed jobs resume from last state
• ML training — distributed training with checkpoints
• Stateless web workers — behind load balancers with health checks
• Data analytics — Spark/EMR with spot-aware scheduling
• Rendering/encoding — parallelizable, fault-tolerant

# terraform/spot-fleet.tf
# Diversified spot fleet with fallback to on-demand

resource "aws_spot_fleet_request" "batch_processing" {
  iam_fleet_role = aws_iam_role.spot_fleet.arn
  target_capacity = 10
  allocation_strategy = "capacityOptimized"
  
  # Terminate instances when fleet is deleted
  terminate_instances_with_expiration = true

  # Instance diversification across types and AZs
  launch_specification {
    instance_type     = "m5.xlarge"
    ami               = data.aws_ami.ubuntu.id
    subnet_id         = aws_subnet.private_a.id
    availability_zone = "us-east-1a"
    
    tags = {
      Name        = "batch-spot-m5xl"
      environment = "prod"
      workload    = "batch-processing"
    }
  }

  launch_specification {
    instance_type     = "m5a.xlarge"
    ami               = data.aws_ami.ubuntu.id
    subnet_id         = aws_subnet.private_b.id
    availability_zone = "us-east-1b"

    tags = {
      Name        = "batch-spot-m5axl"
      environment = "prod"
      workload    = "batch-processing"
    }
  }

  launch_specification {
    instance_type     = "m6i.xlarge"
    ami               = data.aws_ami.ubuntu.id
    subnet_id         = aws_subnet.private_c.id
    availability_zone = "us-east-1c"

    tags = {
      Name        = "batch-spot-m6ixl"
      environment = "prod"
      workload    = "batch-processing"
    }
  }
}

Kubernetes Spot with Karpenter

# karpenter-nodepool.yaml
# Karpenter NodePool with spot priority and on-demand fallback
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-workers
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.xlarge
            - m5.2xlarge
            - m5a.xlarge
            - m5a.2xlarge
            - m6i.xlarge
            - m6i.2xlarge
            - c5.xlarge
            - c5.2xlarge
      nodeClassRef:
        name: default
  limits:
    cpu: "200"
    memory: 800Gi
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h  # 30 days max lifetime

---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: on-demand-critical
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m5.xlarge", "m5.2xlarge"]
      nodeClassRef:
        name: default
      taints:
        - key: workload-type
          value: critical
          effect: NoSchedule
  limits:
    cpu: "50"
    memory: 200Gi

Storage & Network Cost Optimization

Storage and networking account for 20-40% of cloud bills, yet they receive far less optimization attention than compute. Lifecycle policies, intelligent tiering, and architectural choices can dramatically reduce these costs.

Storage Tiering

flowchart TD
    A[New Object Created
Standard/Hot Tier] --> B{Accessed in
last 30 days?}
    B -->|Yes| A
    B -->|No| C[Move to
Infrequent Access]
    C --> D{Accessed in
last 90 days?}
    D -->|Yes| A
    D -->|No| E[Move to
Archive/Glacier]
    E --> F{Retention
expired?}
    F -->|Yes| G[Delete Object]
    F -->|No| E

    style A fill:#e8fdf4,stroke:#3B9797
    style C fill:#ffd,stroke:#880
    style E fill:#e8f4fd,stroke:#16476A
    style G fill:#fde8e8,stroke:#BF092F
                            

# terraform/s3-lifecycle.tf
# S3 lifecycle policy for automatic cost optimization

resource "aws_s3_bucket_lifecycle_configuration" "cost_optimized" {
  bucket = aws_s3_bucket.data_lake.id

  rule {
    id     = "transition-infrequent"
    status = "Enabled"

    filter {
      prefix = "data/"
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER_IR"  # Instant Retrieval
    }

    transition {
      days          = 180
      storage_class = "GLACIER_FLEXIBLE_RETRIEVAL"
    }

    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    expiration {
      days = 2555  # 7 years retention
    }
  }

  rule {
    id     = "cleanup-incomplete-uploads"
    status = "Enabled"

    filter {
      prefix = ""
    }

    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }

  rule {
    id     = "expire-old-versions"
    status = "Enabled"

    filter {
      prefix = ""
    }

    noncurrent_version_transition {
      noncurrent_days = 30
      storage_class   = "GLACIER_IR"
    }

    noncurrent_version_expiration {
      noncurrent_days = 90
    }
  }
}

Data Transfer Optimization

# terraform/vpc-endpoints.tf
# VPC Endpoints eliminate data transfer charges to AWS services

resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids = [aws_route_table.private.id]

  tags = {
    Name        = "s3-gateway-endpoint"
    purpose     = "eliminate-nat-gateway-costs"
    cost_center = var.cost_center
  }
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids = [aws_route_table.private.id]

  tags = {
    Name        = "dynamodb-gateway-endpoint"
    purpose     = "eliminate-nat-gateway-costs"
    cost_center = var.cost_center
  }
}

# Interface endpoints for other services
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.ecr.api"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true

  tags = {
    Name = "ecr-api-endpoint"
  }
}

Cost Automation & Tools

Manual cost optimization doesn't scale. Modern FinOps practices rely on automated tools that estimate costs before deployment, detect anomalies in real-time, and enforce policies continuously.

Infracost: Cost Estimation in CI/CD

Infracost integrates with Terraform to show cost impact of infrastructure changes before they're applied — shifting cost awareness left into the development workflow.

# .github/workflows/infracost.yml
# Infracost integration for PR cost estimation
name: Infracost
on:
  pull_request:
    paths:
      - 'terraform/**'

jobs:
  infracost:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Checkout base branch
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.base.ref }}
          path: base

      - name: Generate Infracost diff
        run: |
          # Generate cost estimate for base branch
          infracost breakdown \
            --path=base/terraform \
            --format=json \
            --out-file=/tmp/infracost-base.json

          # Generate cost estimate for PR branch  
          infracost breakdown \
            --path=terraform \
            --format=json \
            --out-file=/tmp/infracost-pr.json

          # Generate diff
          infracost diff \
            --path=terraform \
            --compare-to=/tmp/infracost-base.json \
            --format=json \
            --out-file=/tmp/infracost-diff.json

      - name: Post PR comment
        uses: infracost/actions/comment@v3
        with:
          path: /tmp/infracost-diff.json
          behavior: update  # Update existing comment
          # Set thresholds for blocking
          # percentage-threshold: 10

Cloud Custodian: Policy-as-Code for Cost

# cloud-custodian/policies/cost-optimization.yml
# Automated cost policies with Cloud Custodian

policies:
  # Stop untagged EC2 instances after 24 hours
  - name: stop-untagged-instances
    resource: ec2
    filters:
      - "tag:cost_center": absent
      - "tag:owner": absent
      - type: instance-age
        days: 1
    actions:
      - type: stop
      - type: notify
        template: untagged-resource
        to:
          - resource-owner
          - finops-team@company.com
        transport:
          type: sns
          topic: arn:aws:sns:us-east-1:123456789:finops-alerts

  # Delete unattached EBS volumes older than 7 days
  - name: delete-unattached-volumes
    resource: ebs
    filters:
      - Attachments: []
      - type: value
        key: CreateTime
        value_type: age
        value: 7
        op: greater-than
    actions:
      - type: snapshot
      - type: delete

  # Right-size underutilized RDS instances
  - name: flag-underutilized-rds
    resource: rds
    filters:
      - type: metrics
        name: CPUUtilization
        statistics: Average
        days: 14
        value: 10
        op: less-than
    actions:
      - type: tag
        tags:
          finops-action: right-size-candidate
          finops-flag-date: "{now}"
      - type: notify
        template: rds-underutilized
        to: [resource-owner]
        transport:
          type: sns
          topic: arn:aws:sns:us-east-1:123456789:finops-alerts

  # Clean up old snapshots (>90 days, no tag)
  - name: cleanup-old-snapshots
    resource: ebs-snapshot
    filters:
      - type: age
        days: 90
        op: greater-than
      - "tag:keep": absent
    actions:
      - type: delete

Cost Management Tools Comparison

# kubecost/values.yaml
# Kubecost Helm configuration for K8s cost allocation
kubecostProductConfigs:
  clusterName: "prod-cluster"
  currencyCode: "USD"
  
  # Cost allocation settings
  sharedNamespaces: "kube-system,monitoring,istio-system"
  sharedOverhead: "250"  # Monthly shared costs in USD
  
  # Efficiency thresholds
  cpuEfficiencyThreshold: 0.65
  memoryEfficiencyThreshold: 0.65

  # Alerts
  alerts:
    - type: budget
      threshold: 10000
      window: monthly
      ownerContact:
        - finops@company.com
    - type: efficiency
      efficiencyThreshold: 0.5
      window: 48h
      ownerContact:
        - platform-team@company.com
    - type: spendChange
      relativeThreshold: 0.2  # 20% increase
      window: 7d
      baselineWindow: 30d
      ownerContact:
        - finops@company.com

Building a FinOps Practice

FinOps is fundamentally a cultural change, not just a tooling exercise. Success requires executive sponsorship, cross-functional collaboration, and a maturity journey that progresses from basic visibility to optimized unit economics.

FinOps Maturity Model

flowchart TD
    A[FinOps Lead / Practitioner] --> B[Engineering Liaison]
    A --> C[Finance Partner]
    A --> D[Executive Sponsor]
    
    B --> E[Platform Team]
    B --> F[Product Engineering]
    B --> G[Data/ML Team]
    
    C --> H[Budget Planning]
    C --> I[Forecasting]
    C --> J[Chargeback Administration]
    
    D --> K[Investment Decisions]
    D --> L[Cross-org Alignment]

    style A fill:#e8fdf4,stroke:#3B9797
    style B fill:#e8f4fd,stroke:#16476A
    style C fill:#ffd,stroke:#880
    style D fill:#fde8e8,stroke:#BF092F
                            

KPIs and Engineering Culture

The metrics you track shape behavior. Move beyond raw spend to unit economics that tie cost to business value:

# finops-kpis.yaml
# Key Performance Indicators for FinOps maturity

kpis:
  # Unit Economics (most important)
  unit_economics:
    - name: cost_per_customer
      formula: "total_cloud_spend / active_customers"
      target: "< $2.50/month"
      cadence: monthly
    - name: cost_per_transaction
      formula: "compute_spend / total_transactions"
      target: "< $0.001"
      cadence: weekly
    - name: cost_per_api_call
      formula: "service_spend / api_calls"
      target: "< $0.0001"
      cadence: daily

  # Efficiency Metrics
  efficiency:
    - name: reservation_coverage
      target: "> 80%"
      cadence: weekly
    - name: reservation_utilization
      target: "> 95%"
      cadence: weekly
    - name: waste_percentage
      formula: "(idle_spend + oversized_spend) / total_spend * 100"
      target: "< 10%"
      cadence: monthly
    - name: spot_adoption_rate
      formula: "spot_spend / (spot_spend + on_demand_spend) * 100"
      target: "> 40% for eligible workloads"
      cadence: monthly

  # Operational Metrics
  operational:
    - name: tagging_compliance
      target: "> 95% of resources tagged"
      cadence: daily
    - name: anomaly_detection_time
      target: "< 4 hours to flag"
      cadence: continuous
    - name: budget_variance
      formula: "abs(actual - forecast) / forecast * 100"
      target: "< 5%"
      cadence: monthly

Cost Optimization Checklist

Prioritize optimizations by effort and impact. Quick wins deliver immediate savings; architectural changes deliver the largest long-term reductions.

# Quick-win script: Find and report waste
#!/bin/bash
# finops-quick-scan.sh - Identify immediate savings opportunities

echo "=== FinOps Quick Scan Report ==="
echo "Date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

# 1. Unattached EBS volumes
echo "--- Unattached EBS Volumes ---"
aws ec2 describe-volumes \
  --filters "Name=status,Values=available" \
  --query "Volumes[].{ID:VolumeId,Size:Size,Created:CreateTime,Type:VolumeType}" \
  --output table

# 2. Unused Elastic IPs
echo ""
echo "--- Unused Elastic IPs ---"
aws ec2 describe-addresses \
  --filters "Name=association-id,Values=" \
  --query "Addresses[].{IP:PublicIp,AllocationId:AllocationId}" \
  --output table

# 3. Old snapshots (>90 days)
echo ""
echo "--- Snapshots Older Than 90 Days ---"
NINETY_DAYS_AGO=$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -v-90d +%Y-%m-%dT%H:%M:%S)
aws ec2 describe-snapshots \
  --owner-ids self \
  --query "Snapshots[?StartTime<='${NINETY_DAYS_AGO}'].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}" \
  --output table

# 4. Stopped instances (still incurring EBS costs)
echo ""
echo "--- Stopped EC2 Instances ---"
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=stopped" \
  --query "Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,Stopped:StateTransitionReason}" \
  --output table

echo ""
echo "=== Scan Complete ==="

Hands-On Exercises

Conclusion & Next Steps

FinOps transforms cloud spending from an unpredictable expense into a strategic lever. The key takeaways from this article:

• FinOps is a continuous lifecycle (Inform → Optimize → Operate), not a one-time project
• Tagging is the foundation — without it, cost allocation and optimization are impossible
• Right-sizing delivers the highest ROI with the least risk for immediate savings
• Reserved Instances and Savings Plans should cover 80% of stable workloads
• Spot instances offer 60-90% savings for fault-tolerant workloads
• Storage lifecycle automation prevents the slow accumulation of unused data costs
• Infracost and Cloud Custodian shift cost awareness left and automate governance
• Unit economics (cost per customer/transaction) are the ultimate FinOps KPI