<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1554224155-6726b3ff858f?w=1200&amp;q=80"><h2 id="finops-2026-engineering-your-way-out-of-cloud-cost-chaos">FinOps 2026: Engineering Your Way Out of Cloud Cost Chaos</h2>Cloud costs are the new technical debt. They accumulate silently, resist easy attribution, and explode at the worst moments. And as AI inference workloads, GPU clusters, and multi-cloud deployments become standard, the bill is getting harder to manage.FinOps — the practice of bringing financial accountability to cloud spending — has matured from a CFO concern into a core engineering discipline. This post is for the engineers who own it.<img src="https://images.unsplash.com/photo-1554224155-6726b3ff858f?w=900&amp;q=80" alt="Cloud Cost Management"> Photo by <a href="https://unsplash.com/@thoughtcatalog">Thought Catalog</a> on Unsplash<hr><h2 id="why-cloud-costs-are-an-engineering-problem">Why Cloud Costs Are an Engineering Problem</h2>Finance can see the bill. Only engineering can actually do something about it.Reducing cloud spend by 30-40% — which is realistic for most organizations — requires:<ul><li>Architectural decisions (rightsizing, Spot instances, caching layers)</li><li>Code changes (inefficient queries, redundant API calls, uncompressed data)</li><li>Tooling changes (CI/CD resource profiles, test environment policies)</li><li>Tagging discipline (who owns what)</li></ul>None of these live in a spreadsheet. They live in your codebase and infrastructure.<hr><h2 id="the-visibility-problem">The Visibility Problem</h2>You can’t optimize what you can’t see. The first challenge is attribution: which team, service, or feature is responsible for which cost?<h3 id="tagging-strategy-the-foundation">Tagging Strategy: The Foundation</h3>Without consistent tagging, cost allocation is guesswork. A workable tagging schema:<div><pre><code># Terraform module defaults
locals {
 required_tags = {
 "cost:team" = var.team_name # e.g., "platform", "checkout", "ml-infra"
 "cost:service" = var.service_name # e.g., "recommendation-engine"
 "cost:environment" = var.environment # "prod", "staging", "dev"
 "cost:owner" = var.owner_email # for escalation
 }
}

resource "aws_instance" "app" {
 # ... config ...
 tags = merge(local.required_tags, var.additional_tags)
}
</code></pre></div>Enforce this in CI. Terraform plans that lack required tags should fail:<div><pre><code># conftest.py (pytest + checkov)
def test_all_resources_have_required_tags(terraform_plan):
 required_tags = {"cost:team", "cost:service", "cost:environment", "cost:owner"}
 
 for resource in terraform_plan.resources:
 if resource.type in TAGGABLE_RESOURCES:
 missing = required_tags - set(resource.tags.keys())
 assert not missing, (
 f"{resource.address} missing tags: {missing}"
 )
</code></pre></div><h3 id="cost-allocation-in-kubernetes">Cost Allocation in Kubernetes</h3>Kubernetes is particularly opaque for cost attribution. A single node runs pods from multiple teams. Tools that help:OpenCost (CNCF project) allocates cluster costs by namespace, label, or deployment:<div><pre><code># Install OpenCost
helm install opencost opencost/opencost \
 --namespace opencost \
 --set opencost.exporter.defaultClusterId=prod-us-east-1

# Query allocation by namespace
curl "http://opencost:9090/allocation/compute?window=7d&amp;aggregate=namespace"
</code></pre></div>Kubecost provides similar functionality with a polished UI and alerting, but carries licensing costs at scale.A practical approach: export OpenCost data to your data warehouse hourly, join it with your service catalog, and surface per-team cost in engineering dashboards.<hr><h2 id="the-big-wins-where-to-look-first">The Big Wins: Where to Look First</h2>Before optimizing anything, benchmark your current spend against these common waste categories:<h3 id="1-oversized-instances-typically-20-35-of-compute-spend">1. Oversized Instances (Typically 20-35% of Compute Spend)</h3>Most workloads are oversized. The typical pattern: developers provision m5.xlarge “just to be safe,” the workload uses 15% CPU on average, and nobody reviews it.<div><pre><code># AWS: Find instances with &lt;20% average CPU utilization over 14 days
aws cloudwatch get-metric-statistics \
 --namespace AWS/EC2 \
 --metric-name CPUUtilization \
 --period 1209600 \
 --statistics Average \
 --dimensions Name=InstanceId,Value=i-XXXXXXXX

# Or use AWS Compute Optimizer for bulk recommendations
aws compute-optimizer get-ec2-instance-recommendations \
 --filters name=Finding,values=Overprovisioned \
 --query 'instanceRecommendations[*].{Id:instanceArn,Type:currentInstanceType,Saving:savingsOpportunity.estimatedMonthlySavings.value}'
</code></pre></div>Action: Schedule monthly rightsizing reviews. Automate the analysis, require human approval for changes.<h3 id="2-idle-and-orphaned-resources-typically-8-15-of-total">2. Idle and Orphaned Resources (Typically 8-15% of Total)</h3>Stopped instances with attached EBS volumes. Load balancers with no targets. Elastic IPs not attached to anything. Snapshots from decommissioned instances.<div><pre><code># Find unattached EBS volumes
aws ec2 describe-volumes \
 --filters Name=status,Values=available \
 --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Age:CreateTime}' \
 --output table

# Find Elastic IPs not associated with any instance
aws ec2 describe-addresses \
 --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocId:AllocationId}'
</code></pre></div>Run these queries weekly, export to a tracking sheet, and assign cleanup ownership to teams by tag.<h3 id="3-data-transfer-costs-often-invisible-until-huge">3. Data Transfer Costs (Often Invisible Until Huge)</h3>Cross-AZ data transfer is free within VPC for many services but charged for others. Egress to the internet is consistently expensive. CDN offload is usually high ROI.Key questions:<ul><li>Are your microservices in the same AZ? Cross-AZ calls add cost and latency.</li><li>Is your CDN cache hit rate above 80%? If not, you’re paying full egress for cacheable content.</li><li>Are you sending logs/telemetry to a region different from where they’re generated?</li></ul><div><pre><code># Detect cross-region data transfer in your architecture
# Query your VPC flow logs in Athena
SELECT 
 srcaddr, dstaddr,
 SUM(bytes) as total_bytes,
 COUNT(*) as flow_count
FROM vpc_flow_logs
WHERE 
 -- Identify cross-region flows by IP range
 NOT (srcaddr LIKE '10.%' AND dstaddr LIKE '10.%')
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 50;
</code></pre></div><hr><h2 id="kubernetes-cost-optimization">Kubernetes Cost Optimization</h2><h3 id="vertical-pod-autoscaler-vpa">Vertical Pod Autoscaler (VPA)</h3>Most Kubernetes deployments have manually tuned resource requests that are wrong:<div><pre><code>apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
 name: recommendation-service-vpa
spec:
 targetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: recommendation-service
 updatePolicy:
 updateMode: "Auto" # or "Off" for recommendations only
 resourcePolicy:
 containerPolicies:
 - containerName: "app"
 minAllowed:
 cpu: 100m
 memory: 128Mi
 maxAllowed:
 cpu: 2000m
 memory: 4Gi
</code></pre></div>Run VPA in <code>Off</code> mode first to get recommendations without disruption, then gradually move to <code>Auto</code> for non-critical workloads.<h3 id="spotpreemptible-instances-for-batch-workloads">Spot/Preemptible Instances for Batch Workloads</h3>For ML training, batch processing, and CI runners — Spot instances are 60-80% cheaper:<div><pre><code># Karpenter NodePool for Spot
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
 name: batch-spot
spec:
 template:
 spec:
 requirements:
 - key: "karpenter.sh/capacity-type"
 operator: In
 values: ["spot"]
 - key: "node.kubernetes.io/instance-type"
 operator: In
 values: ["m5.2xlarge", "m5a.2xlarge", "m4.2xlarge"] # Multiple types = better availability
 limits:
 cpu: 1000
 disruption:
 consolidationPolicy: WhenEmpty
 consolidateAfter: 30s
</code></pre></div>Label batch jobs to target this pool:<div><pre><code>nodeSelector:
 karpenter.sh/capacity-type: spot
</code></pre></div><hr><h2 id="engineering-the-finops-culture">Engineering the FinOps Culture</h2>Technical tooling is necessary but not sufficient. The cultural patterns that work:<h3 id="per-team-cost-dashboards">Per-Team Cost Dashboards</h3>Every team should see their own cloud spend, updated daily. Not “here’s a request to finance,” but a dashboard in Grafana or Datadog that lives next to uptime and latency.When engineers see the cost impact of their deployment decisions in real time, behavior changes. This is the highest-leverage FinOps investment.<h3 id="unit-economics-in-code-review">Unit Economics in Code Review</h3>Add cost-per-unit metrics to your performance benchmarks. Not just “this API call takes 50ms” but “this API call costs $0.00003, and we make 10M/day.”<div><pre><code># In your benchmark suite
def test_recommendation_endpoint_cost(benchmark):
 result = benchmark(call_recommendation_api, user_id="test-123")
 
 # Assuming $0.0000015 per Lambda invocation + $0.000001 per GB-second
 estimated_cost_per_call = calculate_lambda_cost(
 duration_ms=benchmark.stats["mean"] * 1000,
 memory_mb=256,
 invocations=1
 )
 
 # Fail if unit cost exceeds budget
 assert estimated_cost_per_call &lt; 0.0001, (
 f"Cost per call ${estimated_cost_per_call:.6f} exceeds budget $0.0001"
 )
</code></pre></div><h3 id="finops-champions-not-finance-police">FinOps Champions, Not Finance Police</h3>The teams that succeed at FinOps have engineers who own cost as a first-class metric — not a finance team auditing engineers. Designate a FinOps champion per team who attends a monthly cost review and has explicit authority to push back on wasteful architecture decisions.<hr><h2 id="aiml-workload-costs-the-new-frontier">AI/ML Workload Costs: The New Frontier</h2>GPU instances are expensive. LLM API calls add up fast. A few patterns that matter specifically for AI workloads:Batch inference over real-time when latency allows: Real-time inference on a GPU instance runs 24/7. Batch inference can use Spot instances and run only when there’s work.Model caching and request deduplication: LLM APIs charge per token. If the same prompt is sent repeatedly (RAG system with common queries), a cache layer pays for itself quickly.Quantization: A quantized model (int8/int4) runs 2-4x cheaper with acceptable accuracy loss for many tasks. Evaluate before assuming you need fp16.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=900&amp;q=80" alt="Data Center"> Photo by <a href="https://unsplash.com/@tvick">Taylor Vick</a> on Unsplash<hr><h2 id="quick-wins-checklist">Quick Wins Checklist</h2><ul><li>Enable AWS Compute Optimizer / GCP Recommender — it pays for itself</li><li>Schedule dev/staging environments to shut down nights and weekends</li><li>Set up billing alerts at 80% and 100% of monthly budget</li><li>Audit S3 storage classes — move infrequent access to IA/Glacier</li><li>Enable S3 Intelligent-Tiering for objects &gt; 128KB with unknown access patterns</li><li>Review NAT Gateway costs — often the biggest surprise</li><li>Audit Reserved Instance coverage — 40-60% RI coverage is usually optimal</li><li>Enable Savings Plans for compute-heavy workloads</li></ul><hr>FinOps isn’t about cutting corners — it’s about making deliberate decisions with full visibility into their cost. The teams that nail this aren’t just saving money; they’re building a competitive advantage in infrastructure efficiency.What’s your biggest cloud cost mystery right now? The answer is usually in the data transfer charges. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

FinOps 2026: Engineering Your Way Out of Cloud Cost Chaos
Cloud costs are the new technical debt. They accumulate silently, resist easy attribution, and explode at the worst moments. And as AI inference workloads, GPU clusters, and multi-cloud deployments become standard, the bill is getting harder to manage.
FinOps — the practice of bringing financial accountability to cloud spending — has matured from a CFO concern into a core engineering discipline. This post is for the engineers who own it.
Photo by Thought Catalog on Unsplash
Why Cloud Costs Are an Engineering Problem
Finance can see the bill. Only engineering can actually do something about it.
Reducing cloud spend by 30-40% — which is realistic for most organizations — requires:
Architectural decisions (rightsizing, Spot instances, caching layers)
Code changes (inefficient queries, redundant API calls, uncompressed data)
Tooling changes (CI/CD resource profiles, test environment policies)
Tagging discipline (who owns what)
None of these live in a spreadsheet. They live in your codebase and infrastructure.
The Visibility Problem
You can’t optimize what you can’t see. The first challenge is attribution: which team, service, or feature is responsible for which cost?
Tagging Strategy: The Foundation
Without consistent tagging, cost allocation is guesswork. A workable tagging schema:
# Terraform module defaults
locals {
 required_tags = {
 "cost:team" = var.team_name # e.g., "platform", "checkout", "ml-infra"
 "cost:service" = var.service_name # e.g., "recommendation-engine"
 "cost:environment" = var.environment # "prod", "staging", "dev"
 "cost:owner" = var.owner_email # for escalation
 }
}
resource "aws_instance" "app" {
 # ... config ...
 tags = merge(local.required_tags, var.additional_tags)
}
Enforce this in CI. Terraform plans that lack required tags should fail:
# conftest.py (pytest + checkov)
def test_all_resources_have_required_tags(terraform_plan):
 required_tags = {"cost:team", "cost:service", "cost:environment", "cost:owner"}
 
 for resource in terraform_plan.resources:
 if resource.type in TAGGABLE_RESOURCES:
 missing = required_tags - set(resource.tags.keys())
 assert not missing, (
 f"{resource.address} missing tags: {missing}"
 )
Cost Allocation in Kubernetes
Kubernetes is particularly opaque for cost attribution. A single node runs pods from multiple teams. Tools that help:
OpenCost (CNCF project) allocates cluster costs by namespace, label, or deployment:
# Install OpenCost
helm install opencost opencost/opencost \
 --namespace opencost \
 --set opencost.exporter.defaultClusterId=prod-us-east-1
# Query allocation by namespace
curl "http://opencost:9090/allocation/compute?window=7d&aggregate=namespace"
Kubecost provides similar functionality with a polished UI and alerting, but carries licensing costs at scale.
A practical approach: export OpenCost data to your data warehouse hourly, join it with your service catalog, and surface per-team cost in engineering dashboards.
The Big Wins: Where to Look First
Before optimizing anything, benchmark your current spend against these common waste categories:
1. Oversized Instances (Typically 20-35% of Compute Spend)
Most workloads are oversized. The typical pattern: developers provision m5.xlarge “just to be safe,” the workload uses 15% CPU on average, and nobody reviews it.
# AWS: Find instances with <20% average CPU utilization over 14 days
aws cloudwatch get-metric-statistics \
 --namespace AWS/EC2 \
 --metric-name CPUUtilization \
 --period 1209600 \
 --statistics Average \
 --dimensions Name=InstanceId,Value=i-XXXXXXXX
# Or use AWS Compute Optimizer for bulk recommendations
aws compute-optimizer get-ec2-instance-recommendations \
 --filters name=Finding,values=Overprovisioned \
 --query 'instanceRecommendations[*].{Id:instanceArn,Type:currentInstanceType,Saving:savingsOpportunity.estimatedMonthlySavings.value}'
Action: Schedule monthly rightsizing reviews. Automate the analysis, require human approval for changes.
2. Idle and Orphaned Resources (Typically 8-15% of Total)
Stopped instances with attached EBS volumes. Load balancers with no targets. Elastic IPs not attached to anything. Snapshots from decommissioned instances.
# Find unattached EBS volumes
aws ec2 describe-volumes \
 --filters Name=status,Values=available \
 --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Age:CreateTime}' \
 --output table
# Find Elastic IPs not associated with any instance
aws ec2 describe-addresses \
 --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocId:AllocationId}'
Run these queries weekly, export to a tracking sheet, and assign cleanup ownership to teams by tag.
3. Data Transfer Costs (Often Invisible Until Huge)
Cross-AZ data transfer is free within VPC for many services but charged for others. Egress to the internet is consistently expensive. CDN offload is usually high ROI.
Key questions:
Are your microservices in the same AZ? Cross-AZ calls add cost and latency.
Is your CDN cache hit rate above 80%? If not, you’re paying full egress for cacheable content.
Are you sending logs/telemetry to a region different from where they’re generated?
# Detect cross-region data transfer in your architecture
# Query your VPC flow logs in Athena
SELECT 
 srcaddr, dstaddr,
 SUM(bytes) as total_bytes,
 COUNT(*) as flow_count
FROM vpc_flow_logs
WHERE 
 -- Identify cross-region flows by IP range
 NOT (srcaddr LIKE '10.%' AND dstaddr LIKE '10.%')
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 50;
Kubernetes Cost Optimization
Vertical Pod Autoscaler (VPA)
Most Kubernetes deployments have manually tuned resource requests that are wrong:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
 name: recommendation-service-vpa
spec:
 targetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: recommendation-service
 updatePolicy:
 updateMode: "Auto" # or "Off" for recommendations only
 resourcePolicy:
 containerPolicies:
 - containerName: "app"
 minAllowed:
 cpu: 100m
 memory: 128Mi
 maxAllowed:
 cpu: 2000m
 memory: 4Gi
Run VPA in Off mode first to get recommendations without disruption, then gradually move to Auto for non-critical workloads.
Spot/Preemptible Instances for Batch Workloads
For ML training, batch processing, and CI runners — Spot instances are 60-80% cheaper:
# Karpenter NodePool for Spot
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
 name: batch-spot
spec:
 template:
 spec:
 requirements:
 - key: "karpenter.sh/capacity-type"
 operator: In
 values: ["spot"]
 - key: "node.kubernetes.io/instance-type"
 operator: In
 values: ["m5.2xlarge", "m5a.2xlarge", "m4.2xlarge"] # Multiple types = better availability
 limits:
 cpu: 1000
 disruption:
 consolidationPolicy: WhenEmpty
 consolidateAfter: 30s
Label batch jobs to target this pool:
nodeSelector:
 karpenter.sh/capacity-type: spot
Engineering the FinOps Culture
Technical tooling is necessary but not sufficient. The cultural patterns that work:
Per-Team Cost Dashboards
Every team should see their own cloud spend, updated daily. Not “here’s a request to finance,” but a dashboard in Grafana or Datadog that lives next to uptime and latency.
When engineers see the cost impact of their deployment decisions in real time, behavior changes. This is the highest-leverage FinOps investment.
Unit Economics in Code Review
Add cost-per-unit metrics to your performance benchmarks. Not just “this API call takes 50ms” but “this API call costs $0.00003, and we make 10M/day.”
# In your benchmark suite
def test_recommendation_endpoint_cost(benchmark):
 result = benchmark(call_recommendation_api, user_id="test-123")
 
 # Assuming $0.0000015 per Lambda invocation + $0.000001 per GB-second
 estimated_cost_per_call = calculate_lambda_cost(
 duration_ms=benchmark.stats["mean"] * 1000,
 memory_mb=256,
 invocations=1
 )
 
 # Fail if unit cost exceeds budget
 assert estimated_cost_per_call < 0.0001, (
 f"Cost per call ${estimated_cost_per_call:.6f} exceeds budget $0.0001"
 )
FinOps Champions, Not Finance Police
The teams that succeed at FinOps have engineers who own cost as a first-class metric — not a finance team auditing engineers. Designate a FinOps champion per team who attends a monthly cost review and has explicit authority to push back on wasteful architecture decisions.
AI/ML Workload Costs: The New Frontier
GPU instances are expensive. LLM API calls add up fast. A few patterns that matter specifically for AI workloads:
Batch inference over real-time when latency allows: Real-time inference on a GPU instance runs 24/7. Batch inference can use Spot instances and run only when there’s work.
Model caching and request deduplication: LLM APIs charge per token. If the same prompt is sent repeatedly (RAG system with common queries), a cache layer pays for itself quickly.
Quantization: A quantized model (int8/int4) runs 2-4x cheaper with acceptable accuracy loss for many tasks. Evaluate before assuming you need fp16.
Photo by Taylor Vick on Unsplash
Quick Wins Checklist
Enable AWS Compute Optimizer / GCP Recommender — it pays for itself
Schedule dev/staging environments to shut down nights and weekends
Set up billing alerts at 80% and 100% of monthly budget
Audit S3 storage classes — move infrequent access to IA/Glacier
Enable S3 Intelligent-Tiering for objects > 128KB with unknown access patterns
Review NAT Gateway costs — often the biggest surprise
Audit Reserved Instance coverage — 40-60% RI coverage is usually optimal
Enable Savings Plans for compute-heavy workloads
FinOps isn’t about cutting corners — it’s about making deliberate decisions with full visibility into their cost. The teams that nail this aren’t just saving money; they’re building a competitive advantage in infrastructure efficiency.
What’s your biggest cloud cost mystery right now? The answer is usually in the data transfer charges.

FinOps 2026: Engineering Your Way Out of Cloud Cost Chaos

댓글