Optimizing Costs

Cost Optimization

Purpose

Cloud cost optimization transforms uncontrolled spending into strategic resource allocation through the FinOps lifecycle: Inform, Optimize, and Operate. This skill provides decision frameworks for commitment-based discounts (Reserved Instances, Savings Plans), right-sizing strategies, Kubernetes cost management, and automated cost governance across multi-cloud environments.

When to Use This Skill

Invoke cost-optimization when:

• Reducing cloud spend by 15-40% through systematic optimization
• Implementing cost visibility dashboards and allocation tracking
• Establishing budget alerts and anomaly detection
• Optimizing Kubernetes resource requests and cluster efficiency
• Managing Reserved Instances, Savings Plans, or Committed Use Discounts
• Automating idle resource cleanup and right-sizing recommendations
• Setting up showback/chargeback models for internal teams
• Preventing cost overruns through CI/CD cost estimation (Infracost)
• Responding to finance team requests for cloud cost reduction

FinOps Principles

The FinOps Lifecycle

┌─────────────────────────────────────────────────────┐
│  INFORM → OPTIMIZE → OPERATE (continuous loop)      │
│    ↓         ↓           ↓                          │
│ Visibility  Action   Automation                     │
└─────────────────────────────────────────────────────┘

Inform Phase: Establish cost visibility

• Enable cost allocation tags (Owner, Project, Environment)
• Deploy real-time cost dashboards for engineering teams
• Integrate cloud billing data (AWS CUR, Azure Consumption API, GCP BigQuery)
• Set up Kubernetes cost monitoring (Kubecost, OpenCost)

Optimize Phase: Take action on cost drivers

• Purchase commitment-based discounts (40-72% savings)
• Right-size over-provisioned resources (target 60-80% utilization)
• Implement spot/preemptible instances for fault-tolerant workloads
• Clean up idle resources (unattached volumes, old snapshots)

Operate Phase: Automate and govern

• Budget alerts with cascading notifications (50%, 75%, 90%, 100%)
• Automated cleanup scripts for idle resources
• CI/CD cost estimation to prevent surprise increases
• Continuous monitoring with anomaly detection

Core FinOps Principles

1. Collaboration: Cross-functional teams (finance, engineering, operations, product) 2. Accountability: Teams own the cost of their services 3. Transparency: All costs visible and understandable to stakeholders 4. Optimization: Continuous improvement of cost efficiency

For detailed FinOps maturity models and organizational structures, see references/finops-foundations.md.

Cost Optimization Strategies

1. Commitment-Based Discounts

Reserved Instances (RIs): 40-72% discount for 1-3 year commitments

• Standard RI: Instance type locked, highest discount (60% for 3-year)
• Convertible RI: Flexible instance types, moderate discount (54% for 3-year)
• Use for: Databases (RDS, ElastiCache), stable production EC2 workloads

Savings Plans: Flexible compute commitments

• Compute Savings Plans: Applies to EC2, Fargate, Lambda (54% discount for 3-year)
• EC2 Instance Savings Plans: Tied to instance family (66% discount for 3-year)
• Use for: Workloads that change instance types or regions

GCP Committed Use Discounts (CUDs): 25-70% discount

• Resource-based CUDs: Commit to vCPU, memory, GPUs
• Spend-based CUDs: Commit to dollar amount (flexible)
• Sustained Use Discounts: Automatic 20-30% discount for sustained usage (no commitment)

Decision Framework:

Reserve when:
├─ Workload is production-critical (24/7 uptime required)
├─ Usage is predictable (stable baseline over 6+ months)
├─ Architecture is stable (unlikely to change instance types)
└─ Financial commitment acceptable (1-3 year lock-in)

Use On-Demand when:
├─ Development/testing environments
├─ Unpredictable spiky workloads
├─ Short-term projects (<6 months)
└─ Evaluating new instance types

For detailed commitment strategies and RI coverage analysis, see references/commitment-strategies.md.

2. Spot and Preemptible Instances

Discount: 70-90% off on-demand pricing (interruptible with 2-minute warning)

Use Spot For: CI/CD workers, batch jobs, ML training (with checkpointing), Kubernetes workers, data analytics Avoid Spot For: Stateful databases, real-time services, long-running jobs without checkpointing

Best Practices:

• Diversify instance types and spread across Availability Zones
• Implement graceful shutdown handlers
• Auto-fallback to on-demand when capacity unavailable
• Kubernetes: Mix 70% spot + 30% on-demand nodes with taints/tolerations

3. Right-Sizing Strategies

Target Utilization: 60-80% average (leave headroom for spikes)

Compute Right-Sizing:

• Analyze actual CPU/memory utilization over 30+ days
• Downsize instances with <40% average utilization
• Consolidate underutilized workloads
• Switch instance families (compute-optimized vs. memory-optimized)

Database Right-Sizing:

• Analyze connection pool usage (max connections vs. allocated)
• Downgrade storage IOPS if utilization <50%
• Evaluate read replica necessity (can caching replace it?)
• Consider serverless options (Aurora Serverless, Azure SQL Serverless)

Kubernetes Right-Sizing:

• Set requests = average usage (not peak)
• Set limits = 2-3x requests (allow bursting)
• Use Vertical Pod Autoscaler (VPA) for automated recommendations
• Identify pods with 0% CPU usage (candidates for consolidation)

Storage Right-Sizing:

• Delete unattached volumes (EBS, Azure Disks, GCP Persistent Disks)
• Delete old snapshots (>90 days, retention policy not required)
• Implement lifecycle policies (S3 Intelligent-Tiering, Azure Blob Lifecycle)
• Compress/deduplicate data

Right-Sizing Tools:

• AWS Compute Optimizer: ML-based EC2, Lambda, EBS recommendations
• Azure Advisor: VM rightsizing, reserved instance advice
• GCP Recommender: VM, disk, commitment recommendations
• VPA (Vertical Pod Autoscaler): Automated container resource requests

4. Kubernetes Cost Management

Resource Requests and Limits:

# Set requests = average usage (enables efficient bin-packing)
resources:
  requests:
    cpu: 500m        # 0.5 CPU cores (average usage)
    memory: 1Gi      # 1 GiB memory (average usage)
  limits:
    cpu: 1500m       # 1.5 CPU cores (3x requests, allows bursting)
    memory: 3Gi      # 3 GiB memory (3x requests)

Namespace Quotas: Prevent runaway resource consumption

• ResourceQuota: Limit total CPU/memory per namespace
• LimitRange: Default/max requests per pod
• PriorityClass: Ensure critical pods get resources

Cluster Autoscaling:

• Scale down idle nodes to reduce costs
• Scale-to-zero for dev clusters during off-hours
• Use multiple node pools (spot + on-demand mix)
• Set max node limits to prevent overspend

Cost Visibility:

• Deploy Kubecost or OpenCost for namespace-level cost tracking
• Allocate costs by labels (team, project, environment)
• Track idle cost (cluster capacity not allocated to workloads)
• Generate showback/chargeback reports

For detailed Kubernetes cost optimization patterns, see references/kubernetes-cost-optimization.md.

Cost Visibility and Monitoring

Tagging for Cost Allocation

Required Tags:

• Owner or Team - Responsible team/department
• Project or Application - Business unit or application name
• Environment - prod, staging, dev, test
• CostCenter - Finance cost center code

Enable Cost Allocation Tags:

• AWS: Activate tags in Cost Allocation Tags console
• Azure: Apply tags via Azure Policy enforcement
• GCP: Use labels on all resources, export to BigQuery

For comprehensive tagging strategies, see references/tagging-for-cost-allocation.md.

Monitoring and Dashboards

Native Cloud Tools:

• AWS Cost Explorer: Analyze spending patterns, forecast costs
• Azure Cost Management + Billing: Budget tracking, cost analysis
• GCP Cloud Billing: BigQuery export for custom analysis

Third-Party Platforms:

• Kubecost: Kubernetes cost visibility and optimization
• CloudZero: Unit cost economics, anomaly detection
• CloudHealth: Multi-cloud cost management
• Infracost: Terraform cost estimation in CI/CD

Key Metrics to Track:

• Total monthly cloud spend (trend over time)
• Cost per service/team/project (allocation accuracy)
• Unit cost metrics (cost per customer, cost per transaction)
• Reserved Instance/Savings Plan utilization (target >95%)
• Idle resource waste (target <5% of total spend)
• Budget variance (forecasted vs. actual)

Budget Alerts and Anomaly Detection

Cascading Budget Alerts:

50% of budget  → Email to team lead (informational)
75% of budget  → Email + Slack to team (warning)
90% of budget  → Email + Slack + PagerDuty (urgent)
100% of budget → Automated shutdown (non-prod only) or escalation

Anomaly Detection: Alert on unexpected cost spikes

• >20% cost increase week-over-week
• >$500 unexpected daily cost spike
• New resource types (unusual spend patterns)

Budget Granularity:

• Organization-level (total cloud spend)
• Department-level (engineering, data, marketing)
• Project-level (per application/service)
• Environment-level (prod vs. dev/staging)

Decision Frameworks

Framework 1: Commitment Discount Decision Tree

Should we purchase Reserved Instances / Savings Plans?

STEP 1: Analyze Historical Usage (6-12 months)
├─ Identify steady-state baseline (minimum usage)
├─ Exclude spiky/seasonal workloads
└─ Calculate: (baseline usage) / (total usage) = commitment %

STEP 2: Choose Commitment Type
├─ RESERVED INSTANCES
│   ├─ Pros: Highest discount (up to 72%)
│   ├─ Cons: Instance type locked (unless convertible)
│   └─ Use for: Databases, stable production workloads
│
├─ SAVINGS PLANS
│   ├─ Pros: Flexible (across instance types, regions)
│   ├─ Cons: Slightly lower discount than RI
│   └─ Use for: Compute workloads, Lambda, Fargate
│
└─ COMMITTED USE DISCOUNTS (GCP)
    ├─ Resource-based: vCPU/memory commitments
    └─ Spend-based: Dollar amount commitments

STEP 3: Determine Commitment Period
├─ 1-year commitment
│   ├─ Lower discount (40-50%)
│   └─ Less risk if architecture changes
│
└─ 3-year commitment
    ├─ Higher discount (60-72%)
    └─ Only for mature, stable workloads

STEP 4: Monitor and Optimize
├─ Target >95% RI/Savings Plan utilization
├─ Sell unused RIs on AWS Reserved Instance Marketplace
└─ Adjust commitments quarterly based on usage trends

Framework 2: Right-Sizing Priority Matrix

Cost Impact vs. Effort:

High Impact, Low Effort (DO FIRST):

• Idle resources (100% waste): Stopped instances, unattached volumes, old snapshots
• Unused NAT Gateways ($32/month each)
• Over-provisioned databases (<20% CPU for 30 days)
• Kubernetes pods with no resource requests set

High Impact, Medium Effort (DO SECOND):

• Over-provisioned compute (<40% CPU/memory for 30 days)
• Lambda functions with max memory >2x used memory
• Storage optimization (S3 Intelligent-Tiering, gp3 vs. gp2)

Low Impact, High Effort (DO LAST):

• Application code optimization (requires profiling, refactoring)
• Architecture redesign (serverless migration, multi-region optimization)

Weekly Optimization Routine: 1. Delete idle resources (automated script) 2. Review top 10 cost drivers (manual analysis) 3. Right-size 3-5 instances/week (incremental approach) 4. Monitor impact (cost trend over 4 weeks)

Framework 3: Spot vs. On-Demand Decision

Should this workload use Spot/Preemptible instances?

├─ Is the workload fault-tolerant?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
├─ Is the workload stateless (or has checkpointing)?
│   ├─ NO → Use On-Demand (data loss risk)
│   └─ YES → Continue
│
├─ Can the workload handle interruptions gracefully?
│   ├─ NO → Use On-Demand
│   └─ YES → Continue
│
└─ Workload Type Assessment:
    ├─ Batch Jobs / CI/CD → ✅ Use Spot (70-90% savings)
    ├─ ML Training → ✅ Use Spot (with checkpointing)
    ├─ Kubernetes Workers → ✅ Use Spot (mixed with on-demand)
    ├─ Production API Servers → ⚠️ Mixed fleet (70% spot, 30% on-demand)
    ├─ Databases → ❌ Use On-Demand (or Reserved)
    └─ Real-time Services → ❌ Use On-Demand (or Reserved)

Tool Selection Guide

By Platform

By Use Case

For detailed tool comparisons and selection criteria, see references/tools-comparison.md.

Cloud-Specific Tactics

AWS Optimization Tactics

1. Enable Cost & Usage Reports (CUR): Export detailed billing to S3 2. Use AWS Compute Optimizer: ML-based EC2 rightsizing recommendations 3. Implement Savings Plans: More flexible than Reserved Instances 4. S3 Intelligent-Tiering: Automatic storage class optimization 5. Lambda Right-Sizing: Adjust memory allocation (CPU scales proportionally) 6. EBS gp3 Migration: 20% cheaper than gp2 with same performance

Azure Optimization Tactics

1. Enable Azure Advisor: VM rightsizing and reserved instance recommendations 2. Azure Hybrid Benefit: Bring Windows Server licenses for discounts 3. Dev/Test Pricing: Reduced rates for non-production workloads 4. Azure Spot VMs: Up to 90% discount for interruptible workloads 5. Storage Lifecycle Management: Auto-tier blobs to cool/archive tiers

GCP Optimization Tactics

1. Export Billing to BigQuery: Custom cost analysis with SQL 2. Sustained Use Discounts: Automatic 20-30% discount (no commitment) 3. Committed Use Discounts: 52-70% savings for 3-year commitments 4. Preemptible VMs: Up to 91% discount for batch workloads 5. GCP Recommender: Idle VM detection and rightsizing advice

For cloud-specific deep dives, see references/cloud-specific-tactics.md.

Implementation Checklist

Phase 1: Establish Visibility (Week 1-2)

• [ ] Enable cost allocation tags (Owner, Project, Environment)
• [ ] Activate cost allocation tags in cloud billing console
• [ ] Deploy Kubecost for Kubernetes cost visibility (if using K8s)
• [ ] Create cost dashboards (Grafana, CloudWatch, Azure Monitor, GCP)
• [ ] Set up weekly cost reports (emailed to team leads)

Phase 2: Set Up Governance (Week 2-3)

• [ ] Create budget alerts (50%, 75%, 90%, 100% thresholds)
• [ ] Enable anomaly detection (>20% WoW increase)
• [ ] Implement tagging policy enforcement (Azure Policy, AWS Config, GCP Org Policy)
• [ ] Establish showback reports (cost by team/project)
• [ ] Document cost ownership (who owns which services)

Phase 3: Quick Wins (Week 3-4)

• [ ] Delete idle resources (unattached volumes, old snapshots)
• [ ] Stop/terminate unused development instances
• [ ] Right-size top 10 over-provisioned instances (<40% utilization)
• [ ] Implement S3 Intelligent-Tiering or lifecycle policies
• [ ] Evaluate Reserved Instance/Savings Plan coverage

Phase 4: Commitment Discounts (Month 2)

• [ ] Analyze 6-12 months usage history
• [ ] Calculate baseline usage for commitment sizing
• [ ] Purchase Reserved Instances for databases
• [ ] Purchase Savings Plans for compute workloads
• [ ] Monitor RI/SP utilization (target >95%)

Phase 5: Automation (Month 2-3)

• [ ] Deploy automated cleanup scripts (weekly schedule)
• [ ] Integrate Infracost into CI/CD pipelines
• [ ] Implement auto-shutdown for dev/test environments (off-hours)
• [ ] Enable Vertical Pod Autoscaler (VPA) for K8s rightsizing
• [ ] Set up Spot instance automation (Spot.io, CAST AI, or native)

Phase 6: Continuous Optimization (Ongoing)

• [ ] Weekly cost reviews with engineering teams
• [ ] Monthly optimization sprints (top cost drivers)
• [ ] Quarterly commitment adjustments (RI/SP coverage)
• [ ] Annual FinOps maturity assessment

Common Pitfalls

Pitfall 1: No Cost Visibility

❌ Problem: Finance team sees cloud bill at end of month, surprises everywhere ✅ Solution: Deploy real-time cost dashboards, daily Slack reports to engineering teams

Pitfall 2: Reserved Instance Underutilization

❌ Problem: Purchased 100 RIs, only using 60 (40% wasted commitment) ✅ Solution: Monitor RI utilization weekly (target >95%), sell unused RIs on marketplace

Pitfall 3: Missing Kubernetes Resource Requests

❌ Problem: Pods with no requests set → inefficient bin-packing → wasted nodes ✅ Solution: Use VPA to auto-generate recommendations, enforce via admission control

Pitfall 4: Idle Resources Not Cleaned Up

❌ Problem: 50 stopped EC2 instances (still paying for EBS), 200 unattached volumes ✅ Solution: Weekly automated cleanup of idle resources >7 days old

Pitfall 5: No Budget Alerts

❌ Problem: Accidentally left test cluster running, $10K bill surprise ✅ Solution: Budget alerts at 50%, 75%, 90%, 100% with Slack/PagerDuty notifications

Related Skills

• resource-tagging: Cost allocation tags enable showback/chargeback models
• kubernetes-operations: K8s rightsizing, VPA, cluster autoscaling for cost optimization
• infrastructure-as-code: Infracost for Terraform cost estimation and policy-as-code
• aws-patterns: AWS-specific cost optimization tactics (EC2, RDS, S3, Lambda)
• gcp-patterns: GCP-specific optimizations (Compute Engine, BigQuery, Cloud Storage)
• azure-patterns: Azure-specific optimizations (VMs, Storage, App Service, Functions)
• platform-engineering: Internal FinOps platforms and self-service cost dashboards
• disaster-recovery: Balance cost vs. RTO/RPO (warm standby vs. cold standby)

Examples

See examples/ directory for:

• terraform/: AWS, Azure, GCP cost optimization infrastructure (budgets, alerts)
• kubernetes/: Kubecost deployment, resource quotas, VPA configurations
• ci-cd/: Infracost GitHub Actions, cost approval workflows
• dashboards/: Grafana cost dashboards, CloudWatch alarms

Scripts

See scripts/ directory for:

• cleanup_idle_resources.py: Automated AWS/Azure/GCP idle resource cleanup
• ri_coverage_report.py: Reserved Instance coverage analysis
• cost_allocation_report.py: Generate showback/chargeback reports
• spot_savings_calculator.py: Estimate savings from spot instances
• k8s_rightsizing_audit.py: Find K8s pods with missing resource requests

Key Takeaways

1. FinOps is a Culture: Collaboration between finance, engineering, and operations 2. Visibility First: Can't optimize what can't measure (tags + dashboards mandatory) 3. Commitment = Savings: Reserved Instances/Savings Plans provide 40-72% discounts 4. Right-Size Continuously: Target 60-80% utilization (leave headroom for spikes) 5. Automate Cleanup: Idle resources are 100% waste (weekly automated deletion) 6. Kubernetes Costs Hidden: Use Kubecost/OpenCost for namespace-level visibility 7. Shift-Left Cost Awareness: Infracost in CI/CD prevents surprise cost increases 8. Budget Alerts Prevent Overspend: Cascading notifications at 50%, 75%, 90%, 100% 9. Spot for Fault-Tolerant Workloads: 70-90% discount (CI/CD, batch jobs, ML training) 10. Unit Cost Metrics Drive Value: Track cost per customer, cost per transaction

Cloud-Specific Cost Optimization Tactics

Quick reference for AWS, Azure, and GCP cost optimization tactics beyond the universal strategies covered in SKILL.md.

Table of Contents

1. AWS Optimization Tactics 2. Azure Optimization Tactics 3. GCP Optimization Tactics 4. Multi-Cloud Cost Comparison

---

AWS Optimization Tactics

Compute

EC2 Compute Optimizer: ML-based rightsizing recommendations

aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0

Savings Plans: More flexible than Reserved Instances

• Compute Savings Plans: Apply to EC2, Fargate, Lambda
• EC2 Instance Savings Plans: Apply within instance family

Graviton Instances: 40% better price/performance

• Migrate x86 workloads to ARM-based Graviton2/Graviton3 instances
• Example: m6g.xlarge (Graviton) vs m5.xlarge (x86) = 20% cost savings

Storage

S3 Intelligent-Tiering: Automatic cost optimization

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

EBS gp3 Migration: 20% cheaper than gp2

# Modify volume type from gp2 to gp3
aws ec2 modify-volume \
  --volume-id vol-1234567890abcdef0 \
  --volume-type gp3

S3 Lifecycle Policies:

<LifecycleConfiguration>
  <Rule>
    <Filter><Prefix>logs/</Prefix></Filter>
    <Status>Enabled</Status>
    <Transition>
      <Days>30</Days>
      <StorageClass>STANDARD_IA</StorageClass>
    </Transition>
    <Transition>
      <Days>90</Days>
      <StorageClass>GLACIER</StorageClass>
    </Transition>
    <Expiration><Days>365</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

Lambda

Right-Size Memory: CPU scales proportionally with memory

• Over-provisioned memory = wasted cost
• Under-provisioned memory = longer execution time (higher cost)
• Use AWS Lambda Power Tuning to find optimal memory allocation

Provisioned Concurrency: Avoid if possible ($0.015/GB-hour)

• Use only for latency-sensitive workloads
• Consider Application Auto Scaling for Provisioned Concurrency

Networking

NAT Gateway Optimization: $0.045/hour = $32.85/month each

• Use single NAT Gateway per AZ (not per subnet)
• Consider NAT instances for low-traffic workloads (cheaper)
• VPC Endpoints for AWS services (avoid NAT Gateway data transfer)

CloudFront for Static Content: Reduce data transfer costs

• S3 data transfer: $0.09/GB (egress)
• CloudFront: $0.085/GB (first 10 TB)

Database

RDS Reserved Instances: 60-72% discount

• Purchase for production databases (24/7 uptime)
• Use Aurora Serverless v2 for variable workloads

DynamoDB On-Demand vs. Provisioned:

On-Demand: $1.25/million writes, $0.25/million reads
Provisioned: $0.00065/WCU/hour, $0.00013/RCU/hour

Break-even: ~350 WCU or 1,750 RCU continuous usage
Use On-Demand for: Unpredictable traffic, new workloads
Use Provisioned for: Predictable traffic, cost optimization

---

Azure Optimization Tactics

Compute

Azure Hybrid Benefit: Bring Windows Server licenses

• Savings: Up to 85% on Windows VMs
• Eligibility: Windows Server licenses with Software Assurance
• Stack with Reserved VM Instances for maximum savings

Azure Spot VMs: Up to 90% discount

az vm create \
  --resource-group myResourceGroup \
  --name mySpotVM \
  --priority Spot \
  --max-price 0.05 \
  --eviction-policy Deallocate

Dev/Test Pricing: 20-40% discount for non-production

• Requires Visual Studio subscription
• Applies to VMs, App Service, SQL Database

B-Series Burstable VMs: 30-60% cheaper for low-utilization workloads

• Accumulates CPU credits during idle time
• Bursts to 100% CPU when needed
• Ideal for: Web servers, dev/test, small databases

Storage

Azure Blob Lifecycle Management:

{
  "rules": [{
    "name": "archive-old-logs",
    "type": "Lifecycle",
    "definition": {
      "actions": {
        "baseBlob": {
          "tierToCool": { "daysAfterModificationGreaterThan": 30 },
          "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
          "delete": { "daysAfterModificationGreaterThan": 365 }
        }
      }
    }
  }]
}

Managed Disk Optimization:

• Premium SSD: $0.135/GB/month (high IOPS)
• Standard SSD: $0.075/GB/month (moderate IOPS, 44% cheaper)
• Standard HDD: $0.045/GB/month (low IOPS, 67% cheaper)

Database

Azure SQL Database Serverless: Pay per use

• Autopause during inactivity (no compute charges)
• Auto-resume on connection
• Ideal for: Dev/test, intermittent workloads

Hyperscale Tier: Separate compute and storage pricing

• Scale compute independently of storage
• Pay only for storage used (no pre-provisioning)

Networking

Azure Front Door vs. Application Gateway:

• Application Gateway: Regional load balancer ($0.025/hour)
• Front Door: Global load balancer with CDN ($0.36/hour)
• Use Application Gateway if traffic is regional (cheaper)

---

GCP Optimization Tactics

Compute

Sustained Use Discounts: Automatic 20-30% discount

• No commitment required
• Applied automatically for VMs running >25% of month
• Stacks with Committed Use Discounts

Committed Use Discounts: 52-70% savings

gcloud compute commitments create my-commitment \
  --plan=36-month \
  --resources=vcpu=100,memory=400GB \
  --region=us-central1

Preemptible VMs: Up to 91% discount

gcloud compute instances create preemptible-instance \
  --preemptible \
  --zone=us-central1-a \
  --machine-type=n1-standard-4

E2 Instances: 30% cheaper than N1 instances

• Same performance for most workloads
• Automatically uses cost-optimized CPU platform

Storage

Cloud Storage Autoclass: Automatic tier management

gcloud storage buckets update gs://mybucket \
  --autoclass

Tiers:

• Standard: $0.020/GB/month (hot data)
• Nearline: $0.010/GB/month (accessed <1/month)
• Coldline: $0.004/GB/month (accessed <1/quarter)
• Archive: $0.0012/GB/month (accessed <1/year)

Lifecycle Management:

lifecycle:
  rule:
  - action:
      type: SetStorageClass
      storageClass: NEARLINE
    condition:
      age: 30
  - action:
      type: Delete
    condition:
      age: 365

BigQuery

Flat-Rate Pricing: Predictable costs for heavy usage

• On-Demand: $5/TB scanned
• Flat-Rate: $10,000/month for 500 slots (100 TB/month break-even)

Query Cost Optimization:

-- Bad: Full table scan
SELECT * FROM bigquery-public-data.usa_names.usa_1910_current;

-- Good: Partition pruning
SELECT * FROM bigquery-public-data.usa_names.usa_1910_current
WHERE year BETWEEN 2000 AND 2010;

-- Good: Column selection
SELECT name, year FROM bigquery-public-data.usa_names.usa_1910_current;

Clustering and Partitioning: Reduce scanned data

CREATE TABLE mydataset.mytable (
  transaction_id STRING,
  transaction_date DATE,
  amount NUMERIC
)
PARTITION BY transaction_date
CLUSTER BY transaction_id;

Networking

Cloud CDN: Reduce egress costs

• Standard egress: $0.12/GB
• Cloud CDN: $0.08/GB (33% cheaper)
• Cache static content at edge locations

Private Google Access: Avoid NAT Gateway costs

• Access Google APIs from private VMs without external IP
• No NAT Gateway charges ($0.045/hour saved)

---

Multi-Cloud Cost Comparison

Compute (General Purpose, 4 vCPU, 16 GB RAM)

Storage (Object Storage, Standard Tier)

Database (Managed PostgreSQL, 4 vCPU, 16 GB RAM)

Commitment-Based Discount Strategies

Table of Contents

1. Overview 2. AWS Commitment Options 3. Azure Commitment Options 4. GCP Commitment Options 5. Commitment Strategy Framework 6. Monitoring and Optimization 7. Common Mistakes

---

Overview

Commitment-based discounts are the single largest cost optimization opportunity in cloud computing, offering 40-72% savings compared to on-demand pricing. However, commitments require careful planning to avoid waste.

Key Principles

1. Commit to Baseline, Not Peak: Reserve only for steady-state usage 2. Start Conservative: Better to under-commit and expand than over-commit and waste 3. Monitor Utilization: Target >95% utilization of commitments 4. Review Quarterly: Usage patterns change, adjust commitments accordingly 5. Mix Strategies: Combine reserved, savings plans, spot, and on-demand

---

AWS Commitment Options

Reserved Instances (RIs)

Reserved Instances provide the highest discounts but are locked to specific instance attributes.

RI Types

Standard Reserved Instances:

• Discount: Up to 72% off on-demand (3-year, all upfront)
• Flexibility: None (locked to instance type, region, OS, tenancy)
• Use Case: Stable, predictable workloads with no architecture changes expected
• Best For: Production databases (RDS, ElastiCache), long-running EC2 instances

Convertible Reserved Instances:

• Discount: Up to 54% off on-demand (3-year, all upfront)
• Flexibility: Can exchange for different instance types, regions, OS
• Use Case: Production workloads where instance type might change
• Best For: Applications that may need upsizing/downsizing

Scheduled Reserved Instances:

• Discount: 5-10% off on-demand
• Flexibility: Reserved for specific time windows (e.g., 9am-5pm weekdays)
• Use Case: Predictable recurring workloads (batch jobs, business hours apps)
• Best For: Non-24/7 production workloads

RI Payment Options

Recommendation: All upfront for 3-year if cash flow allows (maximum savings).

RI Scopes

Regional RIs:

• Apply to any Availability Zone in the region
• Instance size flexibility within same instance family
• Example: m5.xlarge RI can cover 2x m5.large or 4x m5.medium

Zonal RIs:

• Locked to specific Availability Zone
• Provides capacity reservation (guaranteed availability)
• No instance size flexibility
• Use Case: Capacity-constrained AZs

---

AWS Savings Plans

Savings Plans offer more flexibility than Reserved Instances with slightly lower discounts.

Compute Savings Plans

Coverage:

• EC2 (any instance type, region, OS, tenancy)
• AWS Fargate
• AWS Lambda

Discount: Up to 66% off on-demand (3-year)

Flexibility: Maximum (applies across all compute services)

Commitment: Hourly spend amount (e.g., $10/hour)

Use Case: Dynamic workloads that change instance types or regions

Example:

Commit to $10/hour for 1 year:
- Covers EC2 m5.2xlarge in us-east-1 (current usage)
- Automatically applies if you switch to c5.4xlarge in eu-west-1
- Also covers Lambda and Fargate usage

EC2 Instance Savings Plans

Coverage:

• EC2 instances within a specific instance family (e.g., m5)
• Any size, OS, tenancy within that family
• Any region

Discount: Up to 72% off on-demand (3-year)

Flexibility: Medium (locked to instance family, but flexible on size/region/OS)

Commitment: Hourly spend amount (e.g., $10/hour on m5 instances)

Use Case: Workloads committed to instance family but may change sizes

Savings Plan Term Options

---

Reserved Instances vs. Savings Plans Decision Matrix

---

Azure Commitment Options

Azure Reserved VM Instances

Discount: Up to 72% off pay-as-you-go (3-year)

Coverage:

• Virtual Machines (Linux and Windows)
• Azure Dedicated Host
• Azure App Service
• Azure SQL Database
• Azure Cosmos DB
• Azure Synapse Analytics

Flexibility:

• Instance Size Flexibility: Reservation applies to VM sizes in same series
• Scope Options: Shared (subscription), single resource group, management group

Payment Options:

• Upfront: Pay entire amount upfront (maximum discount)
• Monthly: Pay monthly installments (slightly lower discount)

Example:

Purchase: D4s_v3 VM reservation (4 vCPUs, 16 GB RAM) for 3 years
Discount: 72% off pay-as-you-go
Flexibility: Can apply to D2s_v3, D4s_v3, or D8s_v3 (same series)

Azure Hybrid Benefit

Discount: Bring existing Windows Server licenses to Azure (up to 85% savings)

Eligibility:

• Windows Server licenses with Software Assurance
• SQL Server licenses with Software Assurance

Use Case: Enterprises with existing Microsoft licensing agreements

Combination: Stack with Reserved Instances for even greater savings

Azure Savings Plans for Compute

Discount: Up to 65% off pay-as-you-go (3-year)

Coverage:

• Virtual Machines
• Dedicated Hosts
• Container Instances
• Premium Functions

Commitment: Hourly spend amount (e.g., $5/hour)

Flexibility: Applies across VM sizes, regions, operating systems

---

Azure Dev/Test Pricing

Discount: Reduced rates for non-production workloads (no minimum commitment)

Eligibility:

• Visual Studio subscribers
• Development/testing workloads only

Savings: 20-40% off standard pricing

Use Case: Dev, QA, staging environments

---

GCP Commitment Options

Committed Use Discounts (CUDs)

Google Cloud offers two types of committed use discounts:

Resource-Based CUDs

Commitment: Specific resources (vCPU, memory, GPUs)

Discount: Up to 57% off on-demand (3-year)

Flexibility: Applies to any machine type using those resources

Use Case: Predictable compute usage with flexible machine types

Example:

Commit to: 100 vCPUs + 400 GB memory for 1 year
Discount: 37% off on-demand
Applies to: n1-standard-4 (4 vCPU, 15 GB), n2-standard-8 (8 vCPU, 32 GB), etc.

Spend-Based CUDs

Commitment: Dollar amount per hour (e.g., $10/hour)

Discount: Up to 52% off on-demand (3-year)

Flexibility: Maximum (applies to any compute usage)

Use Case: Variable workloads with unpredictable resource needs

Example:

Commit to: $10/hour for 3 years
Discount: 52% off on-demand
Applies to: All Compute Engine, GKE, Cloud SQL usage

Sustained Use Discounts (Automatic)

Discount: 20-30% off on-demand (automatic, no commitment required)

How it Works: Automatically applied for VMs running >25% of the month

Calculation: Incremental discount increases with usage (up to 30% at 100% usage)

Use Case: No action needed, automatic savings for sustained workloads

Example:

VM runs 100% of month: 30% discount applied automatically
VM runs 50% of month: 15% discount applied automatically

Preemptible VMs

Discount: Up to 91% off on-demand

Availability: Can be terminated with 30-second warning

Use Case: Fault-tolerant workloads (batch jobs, CI/CD, ML training)

Limitations: Maximum 24-hour runtime (VM automatically terminated)

---

Commitment Strategy Framework

Step 1: Analyze Historical Usage (6-12 Months)

Goal: Identify baseline usage (steady-state, not peak)

Analysis:

1. Export 12 months of compute usage data
2. Identify minimum daily usage (baseline floor)
3. Calculate average usage (typical steady state)
4. Identify peak usage (exclude from commitment sizing)

Example:
├── Minimum daily usage: 100 vCPUs
├── Average usage: 150 vCPUs
├── Peak usage: 250 vCPUs
└── Commitment size: 100-120 vCPUs (baseline + 20% growth buffer)

Tools:

• AWS Cost Explorer: "Reserved Instance Recommendations"
• Azure Cost Management: "Reservation Recommendations"
• GCP Billing: "Commitment Recommendations"

Step 2: Segment Workloads

Categorize workloads by commitment suitability:

Step 3: Calculate Commitment Size

Conservative Sizing Formula:

Commitment Size = MIN(6-month average, 12-month minimum) × 0.85

Example:
├── 6-month average: 150 vCPUs
├── 12-month minimum: 100 vCPUs
├── MIN(150, 100) = 100 vCPUs
└── 100 × 0.85 = 85 vCPUs (commit to 85 vCPUs)

Rationale: 15% buffer to avoid underutilization

Step 4: Choose Commitment Term

1-Year vs. 3-Year Decision Matrix:

Recommendation:

• 3-Year: Mature, stable production databases and core infrastructure
• 1-Year: Applications in growth phase, new workloads, uncertain future

Step 5: Payment Option Selection

All Upfront vs. No Upfront:

ROI Calculation:

3-year EC2 m5.2xlarge RI (us-east-1):
├── On-demand cost: $0.384/hour × 8,760 hours/year × 3 years = $10,097
├── RI all upfront: $6,063 (40% discount)
├── RI no upfront: $7,152 (29% discount)
└── Savings: $4,034 (all upfront) vs. $2,945 (no upfront)

Extra $1,089 savings with all upfront payment.

---

Monitoring and Optimization

Track Utilization (Target >95%)

AWS:

aws ce get-reservation-utilization \
  --time-period Start=2025-12-01,End=2025-12-31 \
  --granularity MONTHLY

Azure:

az consumption reservation summary list \
  --reservation-order-id <order-id> \
  --grain daily

GCP:

gcloud billing accounts cud-analysis get \
  --billing-account=<account-id> \
  --start-date=2025-12-01 \
  --end-date=2025-12-31

Quarterly Review Checklist

• [ ] Check RI/SP/CUD utilization (target >95%)
• [ ] Identify underutilized commitments (utilization <90%)
• [ ] Analyze new commitment opportunities (growing workloads)
• [ ] Review expiring commitments (renew or let expire)
• [ ] Adjust commitment sizes based on usage trends
• [ ] Sell unused RIs on marketplace (AWS only)

Unused Commitment Actions

Underutilized (<90% usage): 1. Modify instance family: Exchange Convertible RI for different type 2. Sell on marketplace: AWS Reserved Instance Marketplace 3. Repurpose: Move commitment to different workload 4. Accept loss: If no alternatives, let expire at end of term

Over-committed (running out of capacity): 1. Purchase additional commitments: Top up with new RI/SP/CUD 2. Use spot for overflow: Spot instances for peak traffic 3. Optimize existing: Right-size to fit within commitments

---

Common Mistakes

Mistake 1: Over-Committing

❌ Problem: Purchased 3-year RIs for 200 vCPUs, usage dropped to 120 vCPUs 💰 Cost: Paying for 80 unused vCPUs ($10K/year wasted)

✅ Solution:

• Start with 1-year commitments for new workloads
• Commit to 80-85% of baseline (not average or peak)
• Review and expand commitments quarterly

Mistake 2: Wrong Commitment Type

❌ Problem: Purchased Standard RIs for microservices that change instance types monthly 💰 Cost: RIs unused because workload migrated to different instance type

✅ Solution:

• Use Savings Plans for variable workloads (not RIs)
• Reserve Standard RIs for stable workloads only (databases)

Mistake 3: Ignoring Regional Differences

❌ Problem: Purchased RIs in us-east-1, workload migrated to eu-west-1 💰 Cost: RIs unused, paying full on-demand in new region

✅ Solution:

• Purchase Compute Savings Plans (region-flexible)
• Or use Convertible RIs (can change region via exchange)

Mistake 4: Not Monitoring Utilization

❌ Problem: RI utilization at 65%, wasting 35% of commitment 💰 Cost: $50K/year commitment, $17.5K wasted

✅ Solution:

• Weekly utilization reports (automated alerts)
• Quarterly commitment reviews
• Reallocate or sell unused commitments

Mistake 5: All Upfront Without Cash Flow

❌ Problem: Purchased $500K all-upfront RIs, caused cash flow crunch 💰 Cost: Opportunity cost of capital tied up

✅ Solution:

• Use no upfront or partial upfront if cash flow constrained
• Balance discount savings vs. cash flow needs

---

Commitment Strategy Examples

Example 1: E-Commerce Platform

Workload:

• Production RDS PostgreSQL: 24/7 uptime, db.r5.4xlarge
• Web servers: Variable traffic (50-200 m5.large instances)
• Background jobs: Batch processing (10-30 c5.2xlarge instances)

Commitment Strategy:

1. RDS Database:
   ├── Purchase: db.r5.4xlarge Standard RI (3-year, all upfront)
   ├── Discount: 72% off on-demand
   └── Savings: $25,000/year

2. Web Servers:
   ├── Purchase: Compute Savings Plan (1-year, $5/hour)
   ├── Covers: Baseline 50 m5.large instances
   ├── Discount: 40% off on-demand
   └── Overflow: On-demand for traffic spikes

3. Batch Jobs:
   ├── Purchase: No commitment (use Spot instances)
   ├── Discount: 70-80% off on-demand via Spot
   └── Fallback: On-demand if Spot unavailable

Example 2: SaaS Startup

Workload:

• Kubernetes cluster: 100-150 vCPUs (growing)
• PostgreSQL RDS: db.r5.xlarge (stable)
• Redis ElastiCache: cache.r5.large (stable)

Commitment Strategy:

1. Kubernetes (GKE):
   ├── Purchase: Spend-based CUD (1-year, $3/hour)
   ├── Covers: 100 vCPU baseline
   ├── Growth: Add commitments quarterly as usage grows
   └── Discount: 37% off on-demand

2. RDS + ElastiCache:
   ├── Purchase: Standard RIs (1-year, no upfront)
   ├── Reason: Startup cash flow constrained
   └── Discount: 40% off on-demand

Example 3: Enterprise Multi-Cloud

Workload:

• AWS: 500 EC2 instances (mix of types)
• Azure: 200 VMs (Windows + Linux)
• GCP: 300 VMs (Compute Engine)

Commitment Strategy:

1. AWS:
   ├── Compute Savings Plans: $50/hour (covers 60% of usage)
   ├── Standard RIs: RDS, ElastiCache databases
   └── Spot: Batch workloads (30% of compute)

2. Azure:
   ├── Reserved VM Instances: $30/hour (covers 50% of usage)
   ├── Azure Hybrid Benefit: Windows VMs (bring licenses)
   └── Dev/Test Pricing: Non-prod environments

3. GCP:
   ├── Spend-based CUDs: $20/hour (covers 55% of usage)
   ├── Sustained Use Discounts: Automatic (no action needed)
   └── Preemptible VMs: 40% of workloads

---

Commitment ROI Calculator

Formula:

Annual Savings = (On-Demand Cost - Commitment Cost) × Hours per Year

ROI % = (Annual Savings / Upfront Investment) × 100

Payback Period (months) = Upfront Investment / (Annual Savings / 12)

Example:

Workload: 10x m5.2xlarge instances (24/7)
On-Demand Cost: $0.384/hour × 10 instances × 8,760 hours = $33,638/year
Standard RI (3-year, all upfront): $20,210 total ($6,737/year)
Annual Savings: $33,638 - $6,737 = $26,901/year (80% reduction)
ROI: $26,901 / $20,210 = 133% over 3 years
Payback: $20,210 / ($26,901/12) = 9 months

FinOps Foundations

Table of Contents

1. FinOps Principles 2. FinOps Maturity Model 3. FinOps Team Structure 4. FinOps Practices 5. Measuring FinOps Success

---

FinOps Principles

FinOps (Financial Operations) is a cultural practice that brings financial accountability to cloud spending through collaboration between finance, engineering, and operations teams.

Core Principles (FinOps Foundation)

1. Teams Need to Collaborate

Cloud spend is everyone's responsibility:

• Finance: Budget planning, forecasting, variance analysis
• Engineering: Architectural decisions, resource optimization
• Operations: Monitoring, automation, cost-efficient infrastructure
• Product: Feature prioritization, cost vs. value tradeoffs
• Executive Leadership: Strategic cloud investment decisions

Cross-functional FinOps team:

• FinOps Lead (cross-functional coordinator)
• Cloud Financial Analyst (cost analysis, reporting)
• Cloud Architect (technical optimization advice)
• Automation Engineer (tooling, guardrails)
• Finance Partner (budgeting, forecasting)

2. Everyone Takes Ownership

Decentralized cost accountability:

• Engineering teams own the cost of their services
• Product teams understand cost impact of feature decisions
• Each team has a monthly cloud budget
• Cost metrics integrated into engineering dashboards
• Quarterly cost reviews with team leads

Ownership Model:

Service Team → Owns cost of their microservices
Platform Team → Owns shared infrastructure (K8s, networking)
Data Team → Owns data processing and storage costs
Finance → Owns budget allocation and variance tracking

3. A Centralized Team Drives FinOps

While teams own their costs, a centralized FinOps team provides:

• Cost visibility tools: Dashboards, reporting, tagging enforcement
• Best practices: Optimization playbooks, architecture guidance
• Automation: Budget alerts, idle resource cleanup, rightsizing recommendations
• Education: FinOps training programs, cost-awareness campaigns
• Governance: Tagging policies, budget controls, approval workflows

4. Reports Should Be Accessible and Timely

Real-time cost visibility (not monthly reports):

• Daily cost reports via Slack/email
• Live dashboards accessible to all engineers
• Cost data at service/namespace/project granularity
• Anomaly alerts within minutes (not days)
• API access for custom integrations

5. Decisions Are Driven by Business Value

Cost optimization must balance efficiency with business impact:

• Unit cost metrics: Cost per customer, cost per transaction, cost per request
• Cost vs. revenue: What's the ROI of this infrastructure spend?
• Opportunity cost: What else could we do with these resources?
• Trade-offs: Performance vs. cost, availability vs. cost

Example: Spending $10K/month on caching to save $50K/month in compute is good ROI.

6. Take Advantage of the Variable Cost Model

Cloud's flexibility enables optimization:

• Right-size dynamically: Scale resources up/down as needed
• Shut down when idle: Dev/test environments off-hours
• Commitment flexibility: Mix reserved, savings plans, spot, on-demand
• Rapid iteration: Test optimizations quickly, roll back if needed

---

FinOps Maturity Model

Organizations progress through three maturity levels as they adopt FinOps practices.

Crawl (Reactive Cost Management)

Characteristics:

• Manual cost reporting (monthly spreadsheets)
• Limited cost visibility (finance sees bill, engineering doesn't)
• No tagging or allocation (unclear who owns what)
• Reactive optimization (respond to bill shock)
• No budget controls or alerts
• Ad-hoc cost reviews (when finance complains)

Tools:

• Native cloud billing consoles (AWS Cost Explorer, Azure Cost Management)
• Manual tagging of critical resources
• Spreadsheets for cost tracking

Cost Savings Potential: 5-10% reduction

Duration: 1-3 months (establish basic visibility)

---

Walk (Proactive Cost Management)

Characteristics:

• Automated cost dashboards (daily updates)
• Comprehensive tagging (80%+ resource coverage)
• Showback reports (teams see their costs)
• Proactive optimization (weekly cost reviews)
• Budget alerts and guardrails
• Scheduled cost reviews (monthly with stakeholders)
• Reserved Instance/Savings Plan management

Tools:

• Third-party cost platforms (Kubecost, CloudHealth, CloudZero)
• Automated tagging enforcement (Azure Policy, AWS Config)
• Budget alerts with Slack/email integration
• CI/CD cost estimation (Infracost)

Cost Savings Potential: 15-25% reduction

Duration: 3-6 months (build optimization muscle)

---

Run (Predictive Cost Management)

Characteristics:

• Real-time cost visibility (engineers see costs in dashboards)
• Chargeback models (teams billed for their usage)
• AI-driven optimization (automated rightsizing, anomaly detection)
• Continuous cost culture (cost is an engineering metric)
• Proactive forecasting (predict costs 3-6 months out)
• Automated governance (policy-as-code, auto-remediation)
• Unit cost economics (cost per customer tracked and optimized)

Tools:

• Advanced FinOps platforms (CloudZero, Apptio Cloudability)
• AI-powered optimization (nOps, CAST AI, CloudPilot AI)
• Custom FinOps dashboards (Grafana, Looker)
• Policy-as-code (OPA, Cloud Custodian)

Cost Savings Potential: 25-40% reduction

Duration: 6-12 months (embed FinOps culture)

---

FinOps Team Structure

Centralized FinOps Team

FinOps Lead (1 FTE)

• Cross-functional coordination (finance, engineering, ops)
• FinOps strategy and roadmap
• Stakeholder communication
• Executive reporting

Cloud Financial Analyst (1-2 FTE)

• Cost analysis and reporting
• Budget variance tracking
• Showback/chargeback calculations
• Cost forecasting

Cloud Architect (1 FTE, shared with engineering)

• Technical optimization recommendations
• Architecture cost reviews
• Commitment discount strategy (RI/SP sizing)
• Cloud-specific best practices

Automation Engineer (1 FTE, shared with platform team)

• Build cost monitoring dashboards
• Automate idle resource cleanup
• Integrate cost tools (Kubecost, Infracost, CloudHealth)
• Policy-as-code enforcement

Finance Partner (0.5 FTE from finance dept)

• Budget allocation and planning
• Financial forecasting
• Cost attribution models
• Executive budget reviews

Stakeholder Roles

Engineering Teams:

• Own cost of their services (monthly budget accountability)
• Participate in weekly cost reviews
• Implement optimization recommendations
• Design cost-efficient architectures

Finance Department:

• Allocate cloud budgets by department/project
• Track budget variance (planned vs. actual)
• Provide financial forecasts
• Approve large commitments (RI/SP purchases)

Product Management:

• Prioritize features based on cost vs. value
• Balance performance requirements with cost constraints
• Communicate cost implications to customers (if applicable)

Executive Leadership:

• Set strategic cloud investment priorities
• Approve annual cloud budgets
• Review quarterly cost performance
• Champion FinOps culture

---

FinOps Practices

Daily Practices

Morning Cost Standup (5 minutes):

• Review yesterday's spend vs. forecast
• Check for anomalies (unexpected spikes)
• Triage any budget alerts from overnight

Cost Dashboards:

• Engineers check cost metrics in team dashboards
• Platform team monitors cluster efficiency (Kubecost)
• Finance team tracks budget burn rate

Weekly Practices

Team Cost Reviews (30 minutes per team):

• Review past week's spend by service/namespace
• Identify top 3 cost drivers
• Assign optimization actions (rightsizing, cleanup)
• Track progress on previous week's actions

Idle Resource Cleanup (automated + manual review):

• Automated scripts delete unattached volumes, old snapshots
• Manual review of stopped instances >14 days
• Clean up unused load balancers, NAT gateways

Monthly Practices

FinOps All-Hands (1 hour):

• Review month's total spend vs. budget
• Celebrate cost optimization wins (teams that reduced spend)
• Share optimization playbooks (what worked, what didn't)
• Announce new FinOps initiatives

Reserved Instance/Savings Plan Review:

• Check RI/SP utilization (target >95%)
• Analyze new commitment opportunities (growing workloads)
• Sell unused RIs on marketplace (AWS)
• Adjust commitments based on usage trends

Showback/Chargeback Reports:

• Distribute cost reports to team leads (their spend this month)
• Highlight variance from budget (over/under)
• Invoice teams for their usage (if chargeback model)

Quarterly Practices

FinOps Maturity Assessment:

• Review progress on FinOps maturity levels (Crawl → Walk → Run)
• Identify gaps in visibility, optimization, automation
• Set quarterly FinOps goals (e.g., "Achieve 90% tagging coverage")

Budget Planning and Forecasting:

• Forecast next quarter's cloud spend (based on trends)
• Allocate budgets to teams/projects
• Plan large investments (new projects, migrations)

Commitment Strategy Review:

• Review RI/SP portfolio (what's expiring, what to renew)
• Optimize commitment mix (3-year vs. 1-year, RI vs. SP)
• Plan for architecture changes (impact on commitments)

Annual Practices

FinOps Strategy and Roadmap:

• Set annual cost optimization goals (e.g., "Reduce cloud spend by 20%")
• Define FinOps investments (tools, headcount, training)
• Align FinOps strategy with business strategy

Cloud Provider Negotiations:

• Negotiate enterprise discount agreements (AWS EDP, Azure EA, GCP CUD)
• Review commitment levels (spend-based discounts)
• Evaluate multi-cloud strategy (optimize across providers)

---

Measuring FinOps Success

Cost Efficiency Metrics

Total Cloud Spend:

• Trend over time (month-over-month, year-over-year)
• Cost per business unit/team/project
• Cost variance from budget (planned vs. actual)

Unit Cost Metrics:

• Cost per customer
• Cost per transaction
• Cost per API request
• Cost per active user
• Cost per GB stored/processed

Savings Metrics:

• Total savings from optimizations ($ saved this quarter)
• Savings from commitment discounts (RI/SP vs. on-demand)
• Savings from spot instances (vs. on-demand)
• Savings from rightsizing (before vs. after)

Operational Metrics

Tagging Coverage:

• % of resources with required tags (target: >90%)
• % of costs allocated to teams/projects (target: >95%)

Budget Accuracy:

• Forecast accuracy (predicted vs. actual spend)
• % of teams within budget (target: >80%)
• Budget variance (% over/under budget)

Commitment Utilization:

• Reserved Instance utilization (target: >95%)
• Savings Plan utilization (target: >95%)
• Spot instance adoption rate (% of eligible workloads on spot)

Idle Resource Waste:

• % of spend on idle resources (target: <5%)
• Number of idle resources (unattached volumes, stopped instances)
• Time to remediation (how fast are idle resources cleaned up)

FinOps Maturity Metrics

Visibility:

• % of teams with access to cost dashboards
• Frequency of cost reports (daily, weekly, monthly)
• Cost data granularity (service-level vs. account-level)

Optimization:

• Number of optimization actions per quarter
• Average time to implement optimizations
• % of optimization recommendations acted upon

Automation:

• % of cost governance automated (tagging, budgets, cleanup)
• % of rightsizing recommendations auto-applied
• Cost anomaly detection accuracy (true positives vs. false positives)

Culture:

• % of engineers aware of their service costs
• % of teams with monthly cost goals
• % of architecture reviews that include cost analysis

---

FinOps KPIs Dashboard Example

┌─────────────────────────────────────────────────────────┐
│              FinOps Health Dashboard                    │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  COST EFFICIENCY                                         │
│  ├── Total Monthly Spend: $125,000 (↓8% vs. last month)│
│  ├── Unit Cost per Customer: $2.35 (↓12% vs. Q3)       │
│  ├── Budget Variance: +2% (within target)              │
│  └── Total Savings This Quarter: $37,000               │
│                                                          │
│  COMMITMENT OPTIMIZATION                                 │
│  ├── RI Utilization: 97% (✅ target >95%)               │
│  ├── Savings Plan Utilization: 94% (⚠️ target >95%)    │
│  ├── Spot Adoption: 35% of eligible workloads (🎯 40%) │
│  └── On-Demand Cost: 45% (🎯 <40% via commitments)     │
│                                                          │
│  VISIBILITY & GOVERNANCE                                 │
│  ├── Tagging Coverage: 92% (✅ target >90%)             │
│  ├── Cost Allocation: 96% (✅ target >95%)              │
│  ├── Teams Within Budget: 14/16 (88%)                  │
│  └── Idle Resource Waste: 3% ($3,750) (✅ target <5%)  │
│                                                          │
│  FINOPS MATURITY                                         │
│  ├── Current Level: Walk (Proactive)                    │
│  ├── Next Milestone: Automated chargeback (Q1 2026)    │
│  └── Cost Culture Score: 7.5/10 (engineer survey)      │
│                                                          │
└─────────────────────────────────────────────────────────┘

---

Getting Started with FinOps

Step 1: Establish Executive Sponsorship

• Get buy-in from CFO, CTO, VP Engineering
• Define FinOps goals (e.g., "Reduce cloud spend by 20% in 6 months")
• Allocate budget for FinOps tools and headcount

Step 2: Form FinOps Team

• Hire/assign FinOps Lead
• Identify Cloud Financial Analyst (from finance team)
• Partner with Cloud Architect (from engineering)
• Engage Finance Partner

Step 3: Implement Tagging Strategy

• Define required tags (Owner, Project, Environment, CostCenter)
• Enforce tagging via policy (Azure Policy, AWS Config, GCP Org Policy)
• Backfill tags on existing resources

Step 4: Deploy Cost Visibility Tools

• Enable native cloud billing tools (Cost Explorer, Cost Management)
• Deploy third-party platform (Kubecost for K8s, CloudHealth for multi-cloud)
• Create cost dashboards (Grafana, Looker, or platform-native)
• Set up daily/weekly cost reports

Step 5: Establish Budget Alerts

• Create budgets at organization, department, project, environment levels
• Set up cascading alerts (50%, 75%, 90%, 100%)
• Integrate with Slack/PagerDuty for notifications

Step 6: Quick Wins (First Month)

• Delete idle resources (unattached volumes, old snapshots)
• Stop unused dev/test instances
• Right-size top 10 over-provisioned resources
• Implement lifecycle policies (S3, Azure Blob)

Step 7: Commitment Discounts (Month 2-3)

• Analyze 6-12 months usage history
• Purchase Reserved Instances for databases
• Purchase Savings Plans for compute workloads
• Monitor RI/SP utilization weekly

Step 8: Automation (Month 3-6)

• Automated idle resource cleanup (weekly Lambda/Function)
• Integrate Infracost into CI/CD
• Implement auto-shutdown for dev/test (off-hours)
• Enable VPA for Kubernetes rightsizing

Step 9: Culture and Education (Ongoing)

• Monthly FinOps training for engineers
• Weekly cost reviews with teams
• Cost-aware architecture reviews
• Celebrate cost optimization wins

Step 10: Continuous Improvement (Ongoing)

• Monthly optimization sprints (top cost drivers)
• Quarterly maturity assessments
• Annual FinOps strategy updates

Kubernetes Cost Optimization

Table of Contents

1. Kubernetes Cost Challenges 2. Resource Requests and Limits 3. Namespace Quotas and Limits 4. Cluster Autoscaling 5. Node Pool Strategies 6. Storage Optimization 7. Kubecost Implementation 8. Cost Allocation Best Practices

---

Kubernetes Cost Challenges

Kubernetes abstracts infrastructure, making cost visibility difficult:

Hidden Costs:

• Idle cluster capacity (nodes allocated but not used by pods)
• Over-provisioned pods (requests >> actual usage)
• Missing resource requests (inefficient bin-packing)
• Orphaned resources (PVCs, LoadBalancers after workload deletion)
• Multi-tenant cost allocation (which team owns what?)

Cost Drivers:

Total Cluster Cost = Node Costs + Storage Costs + Network Costs + Control Plane

Node Costs = (Number of nodes) × (Instance type cost) × (Uptime hours)
Storage Costs = PV provisioning + Snapshot storage
Network Costs = LoadBalancers + Data transfer + Ingress controllers

Visibility Problem: Traditional cloud billing shows node costs, but not:

• Cost per namespace
• Cost per deployment
• Cost per team/project
• Idle vs. utilized capacity

Solution: Kubecost or OpenCost for Kubernetes-native cost visibility.

---

Resource Requests and Limits

The Problem

Missing Requests:

# BAD: No resource requests
spec:
  containers:
  - name: app
    image: myapp:latest
    # No resources defined

Impact:

• Kubernetes scheduler cannot bin-pack efficiently
• Pods may be scheduled on oversized nodes (wasted capacity)
• No cost allocation possible (Kubecost can't attribute costs)

Over-Provisioned Requests:

# BAD: Requests >> actual usage
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: 4          # App uses 0.5 CPU average
        memory: 16Gi    # App uses 2 GiB average

Impact:

• 8x over-provisioning ($1,000/month pod costs $125/month to run)
• Forces cluster to scale up unnecessarily
• Wastes node capacity (other pods can't schedule)

The Solution

Right-Sized Requests:

# GOOD: Requests match average usage
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: 500m        # 0.5 CPU (average usage)
        memory: 2Gi      # 2 GiB (average usage)
      limits:
        cpu: 1500m       # 1.5 CPU (3x requests, allows bursting)
        memory: 6Gi      # 6 GiB (3x requests)

Guidelines:

• Requests = Average usage (measured over 7-30 days)
• Limits = 2-3x requests (allow bursting, prevent noisy neighbors)
• Never set requests > limits (Kubernetes will reject)
• CPU limits optional (throttling can cause latency)
• Memory limits required (OOM kills without limits)

Measuring Actual Usage

kubectl top:

# Current CPU/memory usage per pod
kubectl top pods -n production --containers

# Average over time (requires metrics-server)
kubectl top pods -n production --containers --use-protocol-buffers

Prometheus queries:

# Average CPU usage per container (7 days)
avg_over_time(
  container_cpu_usage_seconds_total{namespace="production"}[7d]
)

# Average memory usage per container (7 days)
avg_over_time(
  container_memory_working_set_bytes{namespace="production"}[7d]
)

Kubecost recommendations:

• Navigate to "Savings" > "Right-size your container requests"
• Kubecost analyzes actual usage and suggests optimal requests/limits

Vertical Pod Autoscaler (VPA)

Automate resource request recommendations:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: "Auto"  # or "Recreate" or "Initial"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 256Mi
      maxAllowed:
        cpu: 2
        memory: 8Gi
      controlledResources: ["cpu", "memory"]

Update Modes:

• Auto: VPA updates pods automatically (recreates pods)
• Recreate: VPA updates pods on eviction/restart
• Initial: VPA sets requests only on pod creation
• Off: VPA generates recommendations only (manual review)

Recommendation: Start with "Off" mode, review recommendations, then enable "Auto" for non-critical workloads.

---

Namespace Quotas and Limits

Prevent runaway resource consumption:

ResourceQuota

Limit total resources per namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "100"         # Max 100 CPU cores requested
    requests.memory: 200Gi      # Max 200 GiB memory requested
    limits.cpu: "200"           # Max 200 CPU cores limit
    limits.memory: 400Gi        # Max 400 GiB memory limit
    persistentvolumeclaims: "10" # Max 10 PVCs
    services.loadbalancers: "2"  # Max 2 LoadBalancers
    pods: "50"                   # Max 50 pods

Enforcement:

• Kubernetes rejects pod creation if quota exceeded
• Prevents single team from consuming entire cluster
• Allocates costs predictably (quota = budget)

LimitRange

Set default and max requests/limits per pod:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-backend
spec:
  limits:
  - max:
      cpu: "4"
      memory: 16Gi
    min:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m        # Default limit if not specified
      memory: 1Gi
    defaultRequest:
      cpu: 250m        # Default request if not specified
      memory: 512Mi
    type: Container

Benefits:

• Prevents pods without requests (defaults applied)
• Prevents oversized pods (max enforcement)
• Ensures minimum resources (prevents starvation)

PriorityClass

Ensure critical workloads get resources:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-priority
value: 1000000  # Higher = more important
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "Critical production workloads"

Usage in Pod:

spec:
  priorityClassName: critical-priority
  containers:
  - name: app
    image: myapp:latest

Cost Impact:

• Low-priority pods evicted first during node pressure
• Critical workloads guaranteed resources (may increase costs if cluster scales)

---

Cluster Autoscaling

Cluster Autoscaler

Automatically add/remove nodes based on pod scheduling:

# GKE example (AWS/Azure similar)
gcloud container clusters update my-cluster \
  --enable-autoscaling \
  --min-nodes=3 \
  --max-nodes=20 \
  --zone=us-central1-a

How it Works:

1. Pod scheduled → No node capacity → Scale up (add node)
2. Node idle >10 minutes → Scale down (remove node)
3. Max nodes limit → Prevents overspend

Scale-Down Constraints:

# Prevent scale-down of specific nodes
kubectl annotate node node-1 \
  cluster-autoscaler.kubernetes.io/scale-down-disabled=true

# Allow eviction for scale-down
kubectl annotate pod myapp \
  cluster-autoscaler.kubernetes.io/safe-to-evict=true

Cost Savings:

• Dev clusters: Scale to 0 during off-hours (nights/weekends)
• Staging: Scale down 50-75% during off-hours
• Production: Scale down to baseline (3-5 nodes minimum)

Scale-to-Zero Strategies

CronJob to scale down:

# Scale down dev cluster at 6 PM
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-down-dev
spec:
  schedule: "0 18 * * 1-5"  # 6 PM weekdays
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: kubectl
            image: bitnami/kubectl:latest
            command:
            - kubectl
            - scale
            - deployment
            - --all
            - --replicas=0
            - -n
            - development

Scale up at 8 AM:

schedule: "0 8 * * 1-5"  # 8 AM weekdays
command: kubectl scale deployment --all --replicas=3 -n development

Savings: 60% reduction in dev/test costs (14 hours/day × 5 days/week saved).

---

Node Pool Strategies

Mixed Node Pools (Spot + On-Demand)

Pattern:

├── Critical node pool (on-demand)
│   ├── 3-5 baseline nodes (always running)
│   ├── Hosts: Stateful workloads, databases, critical services
│   └── Taint: node-type=on-demand:NoSchedule
│
└── Burstable node pool (spot/preemptible)
    ├── 0-20 nodes (autoscale to zero)
    ├── Hosts: Stateless workloads, batch jobs, web servers
    ├── Taint: node-type=spot:NoSchedule
    └── Discount: 70-90% vs. on-demand

Toleration for Spot Nodes:

spec:
  tolerations:
  - key: node-type
    operator: Equal
    value: spot
    effect: NoSchedule
  nodeSelector:
    node-type: spot

Benefits:

• 70% cost reduction on burst workloads
• Critical workloads protected on on-demand nodes
• Graceful handling of spot interruptions (30-second warning)

Pod Disruption Budgets (PDB)

Ensure availability during node scale-down:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2  # Always keep 2 pods running
  selector:
    matchLabels:
      app: myapp

Use Cases:

• Prevent all pods evicted during node scale-down
• Ensure availability during voluntary disruptions (upgrades, spot interruptions)

---

Storage Optimization

Persistent Volume Cleanup

Problem: Orphaned PVCs after workload deletion

# Find unattached PVCs
kubectl get pvc --all-namespaces | grep Released

# Delete PVC and associated PV
kubectl delete pvc <pvc-name> -n <namespace>

Automation:

# Delete PVCs released >7 days ago
kubectl get pvc -A -o json | \
  jq -r '.items[] | select(.status.phase=="Released") |
    select((.metadata.creationTimestamp | fromdateiso8601) < (now - 604800)) |
    "\(.metadata.namespace) \(.metadata.name)"' | \
  xargs -n2 kubectl delete pvc -n

StorageClass Cost Optimization

Use appropriate storage tiers:

# Expensive: High-performance SSD
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io2  # $0.125/GB/month + $0.065/IOPS

# Cost-effective: General purpose SSD
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3  # $0.08/GB/month (37% cheaper)

Reclaim Policy:

reclaimPolicy: Delete  # Auto-delete PV when PVC deleted (prevent orphaned volumes)

---

Kubecost Implementation

Installation

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update

helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set kubecostToken="<your-token>" \
  --set prometheus.server.persistentVolume.size=100Gi

Configuration

# kubecost-values.yaml
kubecostProductConfigs:
  cloudIntegrationSecret: cloud-integration  # AWS/Azure/GCP billing data

  labelMappingConfigs:
    enabled: true
    owner_label: "team"
    product_label: "product"
    department_label: "department"
    environment_label: "environment"

# Multi-cluster aggregation
kubecostAggregator:
  enabled: true

# Budget alerts
notifications:
  alertConfigs:
    enabled: true
    globalSlackWebhookUrl: ${SLACK_WEBHOOK}
    alerts:
      - type: budget
        threshold: 1000  # USD per day
        window: 1d
        aggregation: namespace
        filter: environment=prod

Cost Allocation Queries

Namespace cost breakdown:

curl http://kubecost:9090/model/allocation \
  -d window=7d \
  -d aggregate=namespace

Team cost allocation:

curl http://kubecost:9090/model/allocation \
  -d window=month \
  -d aggregate=label:team

Idle cost analysis:

curl http://kubecost:9090/model/allocation \
  -d window=7d \
  -d idle=separate

---

Cost Allocation Best Practices

Label Strategy

Required labels:

metadata:
  labels:
    team: backend            # Owning team
    product: api             # Product/service
    environment: production  # Environment
    cost-center: engineering # Finance cost center

Enforcement (OPA/Gatekeeper):

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: RequireLabels
metadata:
  name: require-cost-labels
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment", "StatefulSet"]
  parameters:
    labels:
      - key: team
      - key: product
      - key: environment

Showback vs. Chargeback

Showback (informational):

• Teams see their costs (no actual billing)
• Monthly cost reports via email/Slack
• Cost awareness without financial consequences

Chargeback (actual billing):

• Teams charged for their usage
• Costs deducted from team budgets
• Financial accountability (reduces waste)

Implementation:

1. Start with Showback (3-6 months)
2. Establish baseline costs per team
3. Set budgets based on historical usage
4. Transition to Chargeback (financial accountability)

Cost Attribution Models

Idle Cost Distribution:

Option 1: Proportional (distribute idle cost by usage)
  ├── Team A uses 40% of cluster → pays 40% of idle cost
  └── Team B uses 60% of cluster → pays 60% of idle cost

Option 2: Share equally
  ├── Team A pays 50% of idle cost
  └── Team B pays 50% of idle cost

Option 3: Allocate to platform team
  └── Platform team pays 100% of idle cost (incentive to optimize)

Recommendation: Proportional distribution (fairest allocation).

Tagging for Cost Allocation

Effective tagging is the foundation of cost visibility and accountability. Without proper tags, costs cannot be allocated to teams, projects, or environments.

Table of Contents

1. Required Tags 2. Cloud-Specific Tag Activation 3. Tagging Enforcement 4. Tagging Automation 5. Tagging Audit and Backfill 6. Cost Allocation Reports 7. Showback and Chargeback 8. Tag Naming Conventions 9. Tagging Compliance Checklist

---

Required Tags

Minimum Tagging Strategy

Every cloud resource must have these four tags:

Recommended Additional Tags

---

Cloud-Specific Tag Activation

AWS: Cost Allocation Tags

Activate tags in billing console:

# Enable cost allocation tag
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=Environment,Status=Active \
  --cost-allocation-tags-status TagKey=Project,Status=Active

Tags take 24 hours to appear in Cost Explorer after activation.

User-Defined vs. AWS-Generated Tags:

• User-Defined: Custom tags added to resources
• AWS-Generated: Automatic tags (aws:createdBy, aws:cloudformation:stack-name)

Azure: Tags and Resource Policies

Apply tags via Azure Policy:

{
  "policyRule": {
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.Compute/virtualMachines"},
        {"field": "tags['Environment']", "exists": "false"}
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

View costs by tag:

az consumption usage list \
  --start-date 2025-12-01 \
  --end-date 2025-12-31 \
  --query "[?tags.Environment=='prod']"

GCP: Labels (Not Tags)

GCP uses "labels" instead of "tags":

# Add labels to instance
gcloud compute instances add-labels my-instance \
  --labels=environment=prod,team=backend,project=api

Export billing data to BigQuery with labels:

SELECT
  labels.key,
  labels.value,
  SUM(cost) as total_cost
FROM `project.dataset.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
WHERE labels.key = 'environment'
GROUP BY labels.key, labels.value
ORDER BY total_cost DESC;

---

Tagging Enforcement

AWS Config Rule

Require tags on EC2 instances:

{
  "ConfigRuleName": "required-tags",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "REQUIRED_TAGS"
  },
  "Scope": {
    "ComplianceResourceTypes": [
      "AWS::EC2::Instance",
      "AWS::RDS::DBInstance",
      "AWS::S3::Bucket"
    ]
  },
  "InputParameters": "{\"tag1Key\":\"Environment\",\"tag2Key\":\"Owner\",\"tag3Key\":\"Project\"}"
}

Azure Policy

Deny resources without required tags:

{
  "properties": {
    "displayName": "Require tags on resources",
    "mode": "All",
    "policyRule": {
      "if": {
        "anyOf": [
          {"field": "tags['Environment']", "exists": "false"},
          {"field": "tags['Owner']", "exists": "false"},
          {"field": "tags['Project']", "exists": "false"}
        ]
      },
      "then": {"effect": "deny"}
    }
  }
}

GCP Organization Policies

Require labels on Compute Engine instances:

constraint: constraints/compute.requireLabels
listPolicy:
  allowedValues:
    - "environment"
    - "team"
    - "project"

---

Tagging Automation

Terraform: Enforce tags via default_tags

AWS Provider:

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      ManagedBy   = "Terraform"
      Environment = var.environment
      Project     = var.project_name
      Owner       = var.team_name
    }
  }
}

# All resources automatically inherit default tags
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  # Additional tags (merged with default_tags)
  tags = {
    Name = "web-server-1"
  }
}

AWS Lambda: Auto-Tag Resources

import boto3

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    """
    Auto-tag EC2 instances on creation.
    Triggered by CloudWatch Events (EC2 instance state change).
    """
    instance_id = event['detail']['instance-id']

    # Extract tags from instance metadata or environment
    tags = [
        {'Key': 'AutoTagged', 'Value': 'true'},
        {'Key': 'CreatedBy', 'Value': event['detail']['userIdentity']['principalId']},
        {'Key': 'CreatedAt', 'Value': event['time']}
    ]

    ec2.create_tags(Resources=[instance_id], Tags=tags)

    return {'statusCode': 200, 'body': f'Tagged {instance_id}'}

---

Tagging Audit and Backfill

Find Untagged Resources (AWS)

# EC2 instances without required tags
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?!not_null(Tags[?Key==`Environment`])].[InstanceId]' \
  --output text

# RDS instances without tags
aws rds describe-db-instances \
  --query 'DBInstances[?length(TagList)==`0`].[DBInstanceIdentifier]' \
  --output text

Backfill Tags on Existing Resources

# Tag all untagged EC2 instances
for instance in $(aws ec2 describe-instances --query 'Reservations[].Instances[?!not_null(Tags[?Key==`Environment`])].[InstanceId]' --output text); do
  aws ec2 create-tags \
    --resources $instance \
    --tags Key=Environment,Value=unknown Key=Owner,Value=platform-team
done

---

Cost Allocation Reports

AWS Cost and Usage Report (CUR)

Enable CUR with tag columns:

aws cur put-report-definition \
  --report-definition '{
    "ReportName": "cost-usage-report",
    "TimeUnit": "DAILY",
    "Format": "Parquet",
    "Compression": "Parquet",
    "S3Bucket": "my-cur-bucket",
    "S3Prefix": "reports/",
    "S3Region": "us-east-1",
    "AdditionalSchemaElements": ["RESOURCES"],
    "ReportVersioning": "OVERWRITE_REPORT",
    "AdditionalArtifacts": ["ATHENA"]
  }'

Query CUR in Athena:

SELECT
  line_item_resource_id,
  resource_tags_user_environment,
  resource_tags_user_team,
  SUM(line_item_unblended_cost) AS cost
FROM cost_usage_report
WHERE year = '2025' AND month = '12'
GROUP BY 1, 2, 3
ORDER BY cost DESC
LIMIT 100;

Azure Cost Management

Export costs by tag:

az consumption usage list \
  --start-date 2025-12-01 \
  --end-date 2025-12-31 \
  --query "[].{Resource:instanceName, Environment:tags.Environment, Cost:pretaxCost}" \
  --output table

GCP Billing Export

Query BigQuery for cost by label:

SELECT
  ARRAY(
    SELECT value
    FROM UNNEST(labels)
    WHERE key = 'environment'
  )[OFFSET(0)] AS environment,
  ARRAY(
    SELECT value
    FROM UNNEST(labels)
    WHERE key = 'team'
  )[OFFSET(0)] AS team,
  SUM(cost) AS total_cost
FROM `project.dataset.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
WHERE _PARTITIONTIME >= '2025-12-01'
  AND _PARTITIONTIME < '2025-12-31'
GROUP BY environment, team
ORDER BY total_cost DESC;

---

Showback and Chargeback

Showback (Informational)

Monthly cost report by team:

Team: Backend
Environment: Production
Month: December 2025

Service          Cost
--------------   --------
EC2 Instances    $15,234
RDS Databases    $8,456
S3 Storage       $2,123
Data Transfer    $1,890
--------------   --------
Total            $27,703

Automation:

• Weekly Slack messages with team costs
• Monthly email reports to team leads
• Grafana dashboards with cost metrics

Chargeback (Financial Accountability)

Invoice teams for their usage:

Invoice: Backend Team - December 2025
Budget: $25,000
Actual: $27,703
Variance: +$2,703 (10.8% over budget)

Action Required:
- Reduce EC2 instance count by 15%
- Right-size RDS instances (currently <40% utilization)
- Implement S3 lifecycle policies

Implementation: 1. Start with Showback (3-6 months) to establish baseline 2. Set team budgets based on historical usage 3. Transition to Chargeback (actual billing to teams) 4. Monthly budget reviews and variance analysis

---

Tag Naming Conventions

Best Practices

Use PascalCase or kebab-case consistently:

• ✅ Good: Environment, CostCenter, OwnerEmail
• ✅ Good: environment, cost-center, owner-email
• ❌ Bad: ENVIRONMENT, cost_center, Owner-email (inconsistent)

Avoid special characters:

• ✅ Good: team-backend, project-api
• ❌ Bad: team@backend, project/api (special chars cause issues)

Keep values lowercase:

• ✅ Good: environment=prod, owner=backend-team
• ❌ Bad: environment=PROD, owner=Backend_Team (case mismatch)

Use controlled vocabulary:

# Tag value whitelist
Environment:
  - prod
  - staging
  - dev
  - test

Owner:
  - backend-team
  - frontend-team
  - data-team
  - platform-team

---

Tagging Compliance Checklist

• [ ] Define required tags (Owner, Project, Environment, CostCenter)
• [ ] Activate cost allocation tags in cloud billing console
• [ ] Enforce tagging via policy (AWS Config, Azure Policy, GCP Org Policy)
• [ ] Automate tagging (Terraform default_tags, Lambda auto-tag)
• [ ] Audit untagged resources weekly
• [ ] Backfill tags on existing resources
• [ ] Generate showback reports monthly
• [ ] Transition to chargeback (optional, after 3-6 months)
• [ ] Monitor tag compliance (target >90% coverage)

Cost Optimization Tools Comparison

Comprehensive comparison of cloud cost management tools to help select the right platform for your needs.

Table of Contents

1. Tool Categories 2. Kubernetes Cost Tools 3. Multi-Cloud Cost Platforms 4. Infrastructure-as-Code Cost Tools 5. AWS-Specific Tools 6. Azure-Specific Tools 7. GCP-Specific Tools 8. Automation Tools 9. Tool Selection Framework 10. Cost Comparison 11. Evaluation Checklist

---

Tool Categories

1. Native Cloud Tools: AWS Cost Explorer, Azure Cost Management, GCP Cloud Billing 2. Kubernetes Cost Visibility: Kubecost, OpenCost, CloudPilot AI 3. Multi-Cloud Platforms: CloudHealth, CloudZero, Apptio Cloudability 4. Infrastructure-as-Code Cost: Infracost (Terraform), CloudFormation cost estimation 5. Automation and Optimization: nOps, Spot.io, CAST AI, ParkMyCloud

---

Kubernetes Cost Tools

Recommendation: Start with OpenCost (free), upgrade to Kubecost if showback/chargeback needed.

---

Multi-Cloud Cost Platforms

Feature Comparison

Recommendation:

• CloudHealth: Best for multi-cloud enterprises with mature FinOps practice
• CloudZero: Best for SaaS companies tracking cost per customer (unit economics)
• Cloudability: Best for large enterprises with complex cost allocation needs
• Harness CCM: Best if already using Harness for CI/CD

---

Infrastructure-as-Code Cost Tools

Infracost (Terraform)

Pricing: Free (community), $500+/month (enterprise)

Key Features:

• Terraform cost estimation in CI/CD
• Pull request cost comments
• Cost policies (block PRs if increase >$X)
• Multi-cloud support (AWS, Azure, GCP)

Integration:

# GitHub Actions
- uses: infracost/actions/setup@v2
- run: infracost diff --path . --format json

Use Cases:

• Shift-left cost awareness (developers see costs in PRs)
• Prevent surprise cost increases before deployment
• Cost forecasting for infrastructure changes

AWS CloudFormation Cost Estimation

Pricing: Free (native AWS feature)

Limitations:

• AWS only (no multi-cloud)
• Less accurate than Infracost (no usage-based estimates)
• No CI/CD integration

---

AWS-Specific Tools

---

Azure-Specific Tools

---

GCP-Specific Tools

---

Automation Tools

---

Tool Selection Framework

By Organization Size

Startup (<50 resources):

• Native cloud tools (AWS Cost Explorer, Azure Cost Management, GCP Billing)
• Infracost (if using Terraform)
• OpenCost (if using Kubernetes)

Mid-Market (50-500 resources):

• Kubecost (Kubernetes)
• Infracost (Terraform)
• CloudHealth or Harness CCM (multi-cloud)

Enterprise (500+ resources):

• CloudHealth or Apptio Cloudability (multi-cloud)
• Kubecost Enterprise (Kubernetes)
• CloudZero (if SaaS with unit economics focus)
• Infracost (CI/CD cost estimation)

By Cloud Provider Mix

Single Cloud (AWS or Azure or GCP):

• Use native tools (Cost Explorer, Cost Management, Cloud Billing)
• Add Kubecost if Kubernetes

Multi-Cloud (2-3 providers):

• CloudHealth, Cloudability, or Harness CCM
• Single pane of glass for all cloud costs

By Use Case

---

Cost Comparison (Annual)

Scenario: 200 resources, 3 Kubernetes clusters, Multi-cloud (AWS + Azure)

Recommendation: Start with native tools + Kubecost + Infracost ($400-500/month), expand to CloudHealth if multi-cloud complexity increases.

---

Evaluation Checklist

When evaluating cost tools, assess:

• [ ] Cloud Coverage: Supports all clouds used (AWS, Azure, GCP, K8s)?
• [ ] Cost Allocation: Supports tags, labels, showback, chargeback?
• [ ] Budget Alerts: Cascading notifications, automated actions?
• [ ] Anomaly Detection: AI-powered cost spike detection?
• [ ] Rightsizing Recommendations: Automated or manual?
• [ ] RI/SP Management: Purchase recommendations, utilization tracking?
• [ ] Kubernetes Support: Namespace-level cost allocation, pod-level metrics?
• [ ] CI/CD Integration: Terraform/CloudFormation cost estimation?
• [ ] Custom Dashboards: Build team-specific views?
• [ ] API Access: Integrate cost data into internal tools?
• [ ] Pricing Transparency: Clear pricing model (not hidden fees)?
• [ ] ROI Potential: Tool cost < 5% of expected savings?