FinOps for Indonesian Cloud Teams: A Practical Cost Optimization Guide

Photo by Unsplash

Photo by Unsplash
As Indonesian enterprises scale their cloud infrastructure, cloud spend often grows faster than revenue — not because engineers are wasteful, but because cloud cost visibility is typically an afterthought. The FinOps Foundation's framework — Inform, Optimize, Operate — provides a structured discipline for bringing engineering, finance, and product teams together to make data-driven spending decisions. This guide focuses on the most common waste patterns observed in Indonesian cloud deployments and provides actionable scripts for immediate cost reduction.
The FinOps Framework defines three iterative phases. Inform: achieving full cloud cost visibility through tagging, showback/chargeback, and anomaly detection. Optimize: identifying and eliminating waste through rightsizing, Reserved Instances, Spot instances, and architectural changes. Operate: embedding FinOps into daily engineering workflows through budgets, alerts, and cost-aware deployment pipelines. Indonesian teams typically skip directly to Optimize, but without the Inform phase, optimization efforts are blind and unsustainable.
The most common waste patterns in Indonesian cloud environments include: over-provisioned EC2/GCE instances running at 5–15% average CPU utilization (typically from initial over-sizing that was never reviewed); forgotten developer and staging environments left running on weekends and holidays (often 30–40% of non-production compute cost); unattached EBS volumes from terminated instances accumulating at $0.08–$0.10/GB-month; NAT Gateway charges from inter-AZ traffic that could be eliminated with VPC endpoint configurations; and S3/GCS cross-region data transfer costs from misrouted replication.
Cost visibility starts with a mandatory tagging strategy enforced via AWS Organizations Service Control Policies (SCPs) or Azure Policy. At minimum, require four tags on every resource: `Environment` (prod/staging/dev), `Team` (owning team slug), `Project` (project or product name), and `CostCenter` (finance cost center code). Resources without mandatory tags should be flagged daily and auto-stopped after 72 hours of non-compliance. A well-implemented tagging strategy typically reveals 20–30% of cloud spend that was previously unattributed.
Enable AWS Cost Anomaly Detection (or GCP Budget Alerts with a 1-day granularity) on every AWS account or GCP project. Set the anomaly threshold at 15–20% week-over-week increase per service. Most cost spikes that would have gone unnoticed for weeks are caught within 24 hours, often saving 5–10x the cost of the monitoring setup itself.
Cloud waste elimination is most effective when automated — manual cost reviews happen quarterly at best, but waste accumulates daily. The scripts below demonstrate how to find unattached EBS volumes (a perennial source of silent waste) and detect cost anomalies week-over-week using AWS Cost Explorer's API. Similar patterns apply to GCP (using gcloud compute disks list --filter='-users:*') and Azure (using az disk list --query "[?diskState=='Unattached']").
The following scripts cover two of the most impactful FinOps automation tasks: listing all unattached EBS volumes in the Jakarta region (ap-southeast-3) with a rough cost estimate, and detecting week-over-week cost anomalies per AWS service. Schedule these scripts to run daily via AWS Lambda or a cron job and send alerts to a Slack channel or PagerDuty when thresholds are exceeded.
# Find all unattached EBS volumes in ap-southeast-3 (Jakarta)
aws ec2 describe-volumes --region ap-southeast-3 --filters Name=status,Values=available --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}' --output table
# Estimate monthly waste (gp3 = ~$0.08/GB-month)
aws ec2 describe-volumes --region ap-southeast-3 --filters Name=status,Values=available --query 'sum(Volumes[*].Size)' --output text | awk '{printf "Unattached EBS waste: $%.2f/month
", $1 * 0.08}'
# -------------------------------------------------------
# Python: AWS Cost Anomaly Detection via Cost Explorer API
# -------------------------------------------------------
import boto3
from datetime import datetime, timedelta
ce = boto3.client('ce', region_name='us-east-1') # Cost Explorer is global
def detect_cost_anomalies(threshold_pct: float = 20.0):
"""Flag services where cost increased > threshold_pct week-over-week."""
end = datetime.utcnow().date()
start = end - timedelta(days=14)
resp = ce.get_cost_and_usage(
TimePeriod={'Start': str(start), 'End': str(end)},
Granularity='WEEKLY',
Metrics=['BlendedCost'],
GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
)
weeks = resp['ResultsByTime']
if len(weeks) < 2:
return []
prev_week = {g['Keys'][0]: float(g['Metrics']['BlendedCost']['Amount'])
for g in weeks[-2]['Groups']}
curr_week = {g['Keys'][0]: float(g['Metrics']['BlendedCost']['Amount'])
for g in weeks[-1]['Groups']}
anomalies = []
for svc, curr in curr_week.items():
prev = prev_week.get(svc, 0)
if prev > 0 and curr > 0:
pct_change = ((curr - prev) / prev) * 100
if pct_change > threshold_pct:
anomalies.append({
'service': svc,
'prev_week_usd': round(prev, 2),
'curr_week_usd': round(curr, 2),
'increase_pct': round(pct_change, 1)
})
return sorted(anomalies, key=lambda x: x['increase_pct'], reverse=True)
for a in detect_cost_anomalies(threshold_pct=25):
print(f"[ALERT] {a['service']}: +{a['increase_pct']}% "
f"(${a['prev_week_usd']} → ${a['curr_week_usd']})")AWS Compute Optimizer and GCP Recommender analyze 14 days of CPU, memory, and network metrics to recommend rightsizing actions. In Indonesian deployments, the most impactful rightsizing opportunities are typically: downsizing initial m5.2xlarge deployments to m5.large or m5.xlarge based on actual utilization; switching database instances from r5.2xlarge to r5.large after load testing proves lower memory requirements; and replacing on-demand i3 storage-optimized instances with gp3 EBS volumes attached to smaller general-purpose instances.
Commitment-based discounts are the highest-ROI FinOps optimization for stable workloads. AWS Reserved Instances (1-year, no upfront) provide approximately 35–40% savings over on-demand; 3-year All Upfront Reserved Instances save up to 62%. AWS Savings Plans are more flexible than RIs and can be applied across instance families. For non-critical batch workloads, Spot instances deliver up to 90% savings but require fault-tolerant architecture to handle 2-minute interruption notices.
Indonesian fintech and e-commerce companies running nightly data processing, ETL, and ML training jobs are ideal candidates for Spot instances. Use AWS EC2 Auto Scaling with mixed instance policy: set 70% On-Demand base capacity and 30% Spot for burst capacity. Use Spot interruption handlers (EC2 Instance Metadata IMDS endpoint at 169.254.169.254/latest/meta-data/spot/termination-time) to gracefully checkpoint work before termination. For Spark/EMR jobs, Spot savings of 60–80% are common with minimal operational complexity.
A common but catastrophic cost-cutting mistake is stopping or terminating production RDS, Cloud SQL, or PostgreSQL instances during off-hours. This causes data loss risk, connection pool resets, and cache warming delays that translate to service degradation for early-morning users. Instead, reduce database cost sustainably by enabling Aurora Serverless v2 for variable workloads, adding read replicas to shift read traffic off the primary, implementing PgBouncer connection pooling to reduce connection overhead, and purchasing Reserved Instance commitments for stable baseline database workloads.
FinOps succeeds when cost awareness is embedded in engineering decisions — not delegated to a separate team reviewing costs monthly. Practical embedding tactics include: adding estimated monthly cost to infrastructure PR descriptions (using Infracost for Terraform), requiring rightsizing review as part of architecture review for any new service, displaying real-time cost dashboards in the engineering team's Slack channel, and including cost efficiency metrics (cost per API request, cost per active user) in quarterly engineering team OKRs.
Many Indonesian data teams store all objects in S3 Standard regardless of access frequency, missing the significant savings available in S3 Intelligent-Tiering, Glacier Instant Retrieval, and Glacier Flexible Retrieval tiers. S3 Intelligent-Tiering automatically moves objects between Frequent Access, Infrequent Access, and Archive tiers based on 30/90/180-day access patterns at no additional API cost. For a typical 50TB data lake accessed irregularly, this can reduce storage costs by 40–60% with zero application changes.
Data transfer costs are frequently the most surprising line item in Indonesian cloud bills, particularly for architectures that were designed for a single AWS region but now span multiple regions or use cross-AZ communication heavily. Use VPC endpoints for S3 and DynamoDB to eliminate NAT Gateway charges for these services. Replace cross-AZ RDS replication traffic with Aurora Global Database for multi-region setups. For outbound internet traffic, consider AWS CloudFront with origin shield in ap-southeast-3 to reduce origin fetch frequency from your application servers.
Schedule non-production environments (dev, staging, QA) to automatically stop at 20:00 WIB and restart at 08:00 WIB on weekdays using AWS Instance Scheduler or a simple Lambda function triggered by EventBridge. For a typical team with 10 dev environments, this 12-hour daily shutdown plus full weekend shutdown reduces non-production compute costs by 65–70% with zero manual effort.
FinOps maturity is measured across three dimensions: cost visibility (what percentage of your cloud spend is tagged and attributable to a team/product), optimization rate (what percentage of your identified waste recommendations have been actioned within 30 days), and unit economics (are you tracking cost per business unit — e.g. cost per transaction, cost per GB stored, cost per MAU). Indonesian companies at FinOps Crawl stage typically achieve 15–25% cost reduction; at Run stage, 30–45% is common within 12 months.
Indonesian engineering culture often treats cloud cost as a finance problem rather than an engineering responsibility. Breaking this pattern requires: (1) making costs visible at the team level (not just company level) via showback dashboards; (2) celebrating cost-saving wins in the same channels as feature launches; (3) including a brief FinOps review in weekly engineering standups; and (4) ensuring engineers understand the business impact of cloud spending — for a startup burning $20K/month on cloud, a 30% reduction directly extends runway.
Key terms in this article include FinOps, Reserved Instance, Rightsizing, and Spot Instance.