Introduction

Cloud spend has become the second-largest operating expense for most software companies after headcount. In 2026, FinOps (Financial Operations) has evolved from a finance team concern into a core engineering discipline—and the teams that treat it seriously are reclaiming 30–50% of their cloud bills through systematic engineering work, not just procurement negotiations.

This post is a technical FinOps guide for engineers: the specific tactics, tools, and architectural patterns that consistently deliver cost savings across AWS, GCP, and Azure. We’ll go beyond “right-size your instances” platitudes into actionable engineering changes.

Photo by Markus Spiske on Unsplash

The Cost Visibility Problem

You can’t optimize what you can’t see. Most cloud cost problems stem from:

1. No per-service cost attribution — “cloud costs” is one line item
2. No cost alerting — surprises at month end
3. No chargeback/showback — teams don’t feel the cost of their choices

Setting Up Cost Attribution

The foundation is tagging everything. A minimal tagging strategy:

# Terraform - enforce tags via tag_policies or Sentinel
variable "required_tags" {
  type = object({
    service     = string
    environment = string
    team        = string
    cost_center = string
  })
}

resource "aws_instance" "app" {
  # ... instance config ...
  
  tags = merge(var.required_tags, {
    Name = "${var.required_tags.service}-${var.required_tags.environment}"
  })
}

Implement tag enforcement with:

• AWS: Service Control Policies (SCPs) + AWS Config rules
• GCP: Organization Policies + label constraints
• Azure: Azure Policy with deny effect on untagged resources

Cost Dashboards That Engineers Actually Use

The FinOps tools landscape in 2026:

OpenCost deserves special mention—it’s the CNCF-incubating project for Kubernetes cost attribution that breaks down costs by namespace, deployment, and pod.

# Install OpenCost on your cluster
helm install opencost opencost/opencost -n opencost --create-namespace

# Query cost by namespace
curl http://localhost:9003/allocation/compute?window=7d&aggregate=namespace

The Big 5 Cost Optimization Levers

Lever 1: Compute Right-Sizing (Typically 25–35% savings)

Most teams over-provision compute by 2–3x. The engineering fix is automated right-sizing with guardrails:

# Example: AWS Cost Explorer + Lambda for automated right-sizing recommendations
import boto3
from datetime import datetime, timedelta

def get_rightsizing_recommendations():
    ce = boto3.client('cost-explorer')
    
    response = ce.get_rightsizing_recommendation(
        Service='AmazonEC2',
        Configuration={
            'RecommendationTarget': 'CROSS_INSTANCE_FAMILY',
            'BenefitsConsidered': True
        }
    )
    
    recommendations = []
    for rec in response['RightsizingRecommendations']:
        current = rec['CurrentInstance']
        target = rec['RightsizingType']
        
        if rec['RightsizingType'] == 'Modify':
            savings = rec['ModifyRecommendationDetail']['TargetInstances'][0]\
                        ['EstimatedMonthlySavings']
            recommendations.append({
                'instance_id': current['ResourceId'],
                'current_type': current['InstanceType'],
                'recommended_type': rec['ModifyRecommendationDetail']\
                                      ['TargetInstances'][0]['InstanceType'],
                'monthly_savings': float(savings['Value'])
            })
    
    return sorted(recommendations, key=lambda x: x['monthly_savings'], reverse=True)

For Kubernetes specifically, use VPA (Vertical Pod Autoscaler) in recommendation mode:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-service-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-service
  updatePolicy:
    updateMode: "Off"  # Recommendation only — don't auto-update in prod
  resourcePolicy:
    containerPolicies:
    - containerName: my-service
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Check VPA recommendations weekly and apply them after review.

Lever 2: Spot/Preemptible Instances (Typically 60–80% compute savings)

Spot instances are the highest-ROI optimization for stateless workloads. The engineering pattern in 2026:

# EKS Node Group with mixed instance strategy
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production
  region: us-east-1
nodeGroups:
  # Stable on-demand for critical workloads
  - name: critical-on-demand
    instanceType: m6i.xlarge
    desiredCapacity: 2
    minSize: 2
    maxSize: 4
    labels:
      lifecycle: on-demand
      tier: critical
      
  # Spot for everything else (80% of workloads)
  - name: general-spot
    instancesDistribution:
      instanceTypes: ["m6i.2xlarge", "m6a.2xlarge", "m5.2xlarge", "m5a.2xlarge"]
      onDemandPercentageAboveBaseCapacity: 0
      spotAllocationStrategy: price-capacity-optimized
    desiredCapacity: 10
    minSize: 0
    maxSize: 50
    labels:
      lifecycle: spot

Node selectors and tolerations direct workloads to the appropriate pool:

# Critical services: on-demand only
spec:
  nodeSelector:
    lifecycle: on-demand
  
# Background jobs: spot only
spec:
  tolerations:
  - key: "spot"
    operator: "Exists"
    effect: "NoSchedule"
  nodeSelector:
    lifecycle: spot

Key insight: Use Karpenter instead of managed node groups in 2026. Karpenter provisions nodes on-demand with optimized instance selection and consolidates underutilized nodes automatically.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: kubernetes.io/arch
        operator: In
        values: ["arm64", "amd64"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s  # Aggressive consolidation
  limits:
    cpu: 1000
    memory: 1000Gi

Lever 3: Storage Tiering (Typically 15–25% savings)

Storage costs are often overlooked. Key patterns:

S3 Intelligent Tiering (set and forget):

import boto3

s3 = boto3.client('s3')

# Apply intelligent tiering to all objects in a bucket
s3.put_bucket_intelligent_tiering_configuration(
    Bucket='my-data-bucket',
    Id='entire-bucket',
    IntelligentTieringConfiguration={
        'Id': 'entire-bucket',
        'Status': 'Enabled',
        'Tierings': [
            {
                'Days': 90,
                'AccessTier': 'ARCHIVE_ACCESS'
            },
            {
                'Days': 180,
                'AccessTier': 'DEEP_ARCHIVE_ACCESS'
            }
        ]
    }
)

EBS/Persistent Volume right-sizing:

# Find oversized PVs in Kubernetes
kubectl get pv -o json | jq '.items[] | 
  select(.spec.capacity.storage | gsub("Gi"; "") | tonumber > 100) |
  {name: .metadata.name, size: .spec.capacity.storage, 
   claim: .spec.claimRef.name}'

Lever 4: Data Transfer Costs (Typically 10–20% savings)

Data egress is often invisible in cost attribution but significant at scale.

The most common culprits:

• Services in different AZs making synchronous calls to each other
• Prometheus metrics being scraped cross-AZ
• Logs being shipped to a different region’s S3

Architectural fix — AZ affinity:

# Keep pod communication within the same AZ
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-service
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: topology.kubernetes.io/zone
              labelSelector:
                matchLabels:
                  app: my-service-dependency  # Co-locate with its dependencies

Lever 5: Idle Resource Elimination (Typically 5–15% savings)

Every organization has zombie resources. Automate their detection:

#!/bin/bash
# Find idle EC2 instances (< 5% CPU for 2 weeks)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 1209600 \
  --statistics Average \
  --query 'Datapoints[0].Average'

Cloud Custodian (open source) is the best tool for automated policy enforcement:

# cloud-custodian policy: notify on idle instances, terminate after 30 days
policies:
  - name: idle-ec2-notify
    resource: ec2
    filters:
      - type: metrics
        name: CPUUtilization
        days: 14
        period: 86400
        value: 5
        op: less-than
      - "tag:Environment": "non-production"
    actions:
      - type: notify
        template: default
        subject: "Idle EC2 instance detected"
        to: ["team-infra@company.com"]
      - type: tag
        key: "idle-since"
        value: "{now}"
        
  - name: idle-ec2-terminate
    resource: ec2
    filters:
      - "tag:idle-since": present
      - type: value
        key: "tag:idle-since"
        op: greater-than
        value_type: age
        value: 30  # days
    actions:
      - terminate

Putting It Together: The FinOps Engineering Workflow

Week 1: Visibility
├── Implement tagging policy
├── Set up cost dashboards per team/service
└── Configure anomaly alerts (>20% week-over-week increase)

Week 2-4: Quick Wins
├── Enable S3 Intelligent Tiering on all buckets
├── Delete unattached EBS volumes and unused snapshots
├── Terminate/downsize idle non-production environments
└── Move dev/staging to spot instances

Month 2: Structural Changes
├── Deploy Karpenter (or equivalent)
├── Configure spot pools for stateless workloads
├── Implement VPA for Kubernetes right-sizing
└── Add AZ affinity for high-traffic service pairs

Quarter 2: Unit Economics
├── Instrument cost-per-request metrics
├── Set team budgets with automatic alerts
└── Add Infracost to CI/CD (pre-deploy cost estimates)

The Cultural Component

Technology is 50% of FinOps. Culture is the other 50%.

What works:

• Monthly cost reviews in team retrospectives
• Cost visibility on team dashboards (next to latency and error rates)
• “Cost champion” rotating role within engineering teams
• Celebrating savings as much as new features

What doesn’t work:

• Mandating savings without giving engineers the tools and time
• Finance-driven mandates without engineering buy-in
• Reactive cost cuts (panic when bill arrives) vs proactive culture

Conclusion

A 40% cloud cost reduction is achievable in 6 months with systematic engineering work. The highest-ROI actions in order:

1. Right-size compute (do this first—low risk, high reward)
2. Move to spot/preemptible for stateless workloads
3. Implement Karpenter or equivalent node consolidation
4. Enable storage tiering everywhere
5. Eliminate idle resources with automated policy enforcement
6. Fix data transfer hotspots

The teams that win at FinOps in 2026 treat cloud costs as a product metric, not an accounting problem. Build cost visibility into your engineering culture, and the optimizations follow naturally.

References:

• FinOps Foundation
• OpenCost Project
• Karpenter Documentation
• Cloud Custodian
• Infracost

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)