FinOps for Indonesian Cloud Teams: A Practical Cost Optimization Guide

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: Inform, Optimize, Operate

The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximizes the business value of technology through collaboration between engineering, finance, and business teams. Its framework runs in three iterative phases. Inform: full cost visibility through tagging, showback/chargeback, and anomaly detection. Optimize: removing waste through rightsizing, commitment discounts, Spot capacity, and architectural changes. Operate: embedding FinOps in daily engineering through budgets, alerts, and cost-aware deployment pipelines. Teams often jump straight to Optimize, but without the Inform phase, optimization is blind and does not last.

Common Cloud Waste in Indonesian Deployments

The waste patterns that show up most often are: EC2 or Compute Engine instances sized at launch and never reviewed against actual utilization; developer and staging environments left running through nights, weekends, and holidays; EBS volumes left unattached after their instances were terminated, which AWS keeps billing until they are deleted; NAT Gateway charges, billed per hour and per GB processed, for traffic to S3 or DynamoDB that a gateway VPC endpoint would carry at no additional charge, or for traffic that crosses Availability Zones to reach a NAT Gateway in another zone; and S3/GCS cross-region data transfer from misrouted replication.

Setting Up Cloud Cost Visibility with Tagging Strategy

Cost visibility starts with a mandatory tagging strategy. 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). On AWS, Organizations tag policies standardize tag keys and values but do not evaluate untagged resources, so pair them with service control policies that deny create actions missing a required aws:RequestTag key; on Azure, the built-in Require a tag on resources policy does the same job. Flag noncompliant resources daily and stop them after a grace period such as 72 hours. For the billing data itself, the FinOps Foundation's FOCUS specification (version 1.4 as of 17 October 2026) normalizes cost and usage data across providers, and AWS Data Exports can deliver it in a FOCUS 1.0 format.

Finding and Eliminating Cloud Waste

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']").

AWS CLI and Python Scripts for Cost Analysis

The following scripts cover two of the most impactful FinOps automation tasks: listing all unattached EBS volumes in the Jakarta Region (ap-southeast-3, an opt-in Region that must be enabled on the account first) with a cost estimate from the rate you copy off the EBS pricing page, and detecting week-over-week cost changes per AWS service from Cost Explorer's daily data. Schedule them 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, an opt-in Region)
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: set GB_MONTH_USD to the gp3 per-GB-month rate for
# Asia Pacific (Jakarta) on the Amazon EBS pricing page (other types differ)
GB_MONTH_USD=0.00
aws ec2 describe-volumes \
  --region ap-southeast-3 \
  --filters Name=status,Values=available \
  --query 'sum(Volumes[*].Size)' \
  --output text | awk -v rate="$GB_MONTH_USD" '{printf "Unattached EBS waste: $%.2f/month\n", $1 * rate}'

# -------------------------------------------------------
# Python: AWS Cost Anomaly Detection via Cost Explorer API
# -------------------------------------------------------
import boto3
from collections import defaultdict
from datetime import datetime, timedelta, timezone

ce = boto3.client('ce', region_name='us-east-1')  # Cost Explorer API endpoint

def detect_cost_anomalies(threshold_pct: float = 20.0):
    """Flag services whose cost rose > threshold_pct: last 7 days vs the 7 before."""
    end    = datetime.now(timezone.utc).date()  # End is exclusive: up to yesterday
    start  = end - timedelta(days=14)
    cutoff = str(end - timedelta(days=7))

    # Granularity accepts DAILY, MONTHLY or HOURLY (there is no WEEKLY),
    # so sum 14 daily rows into two 7-day windows, following pagination.
    prev_week, curr_week = defaultdict(float), defaultdict(float)
    kwargs = dict(
        TimePeriod={'Start': str(start), 'End': str(end)},
        Granularity='DAILY',
        Metrics=['BlendedCost'],
        GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
    )
    while True:
        resp = ce.get_cost_and_usage(**kwargs)
        for day in resp['ResultsByTime']:
            week = curr_week if day['TimePeriod']['Start'] >= cutoff else prev_week
            for g in day['Groups']:
                week[g['Keys'][0]] += float(g['Metrics']['BlendedCost']['Amount'])
        if 'NextPageToken' not in resp:
            break
        kwargs['NextPageToken'] = resp['NextPageToken']

    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']})")

Rightsizing EC2 and GCE Instances

AWS Compute Optimizer analyzes 14 days of CloudWatch utilization metrics by default (up to 93 days with its paid enhanced infrastructure metrics), and Google Cloud's machine type recommendations use the previous 8 days of Cloud Monitoring data. Typical rightsizing moves look like these: downsizing an m5.2xlarge chosen at launch to m5.large or m5.xlarge once utilization data supports it; moving a database from r5.2xlarge to r5.large after load testing proves lower memory needs; and replacing storage-optimized i3 instances with smaller general-purpose instances on gp3 EBS volumes when the workload does not need local NVMe storage.

Reserved Instances, Spot, and Commitment Discounts

Commitment-based discounts are the highest-return FinOps optimization for stable workloads. As listed on AWS's pricing pages on 17 October 2026, Standard Reserved Instances and EC2 Instance Savings Plans offer up to 72% off On-Demand, while Compute Savings Plans offer up to 66% but apply across instance family, size, operating system, tenancy, and Region, and also cover Fargate and Lambda. AWS now recommends Savings Plans over Reserved Instances for EC2. For non-critical batch workloads, Spot Instances run at up to 90% off but can be reclaimed with a two-minute interruption notice, so they need fault-tolerant architecture.

Spot Instance Architecture for Indonesian Batch Workloads

Nightly data processing, ETL, and ML training jobs at Indonesian fintech and e-commerce companies are good candidates for Spot Instances. In an EC2 Auto Scaling group with a mixed instances policy, set OnDemandBaseCapacity to the capacity that must always run, then use OnDemandPercentageAboveBaseCapacity to split the rest, for example 70% On-Demand and 30% Spot. Watch for interruptions through the EC2 Spot Instance Interruption Warning event in EventBridge or by polling the IMDS path latest/meta-data/spot/instance-action every 5 seconds (AWS keeps spot/termination-time only for backward compatibility), and checkpoint work before the instance stops.

Embedding FinOps into the Engineering Workflow

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.

S3 Intelligent-Tiering for Indonesian Data Lakes

Many data teams store every object in S3 Standard regardless of how often it is read. S3 Intelligent-Tiering moves objects to its Infrequent Access tier after 30 consecutive days without access and to Archive Instant Access after 90 days, while the optional Archive Access and Deep Archive Access tiers take objects untouched for 90 and 180 days or more. There are no retrieval charges, but there is a small monthly monitoring and automation charge per object, and objects under 128 KB are never tiered. AWS lists savings of up to 40% for the Infrequent Access tier and up to 68% for Archive Instant Access (as listed on 17 October 2026), with no application changes.

Network and Data Transfer Cost Optimization

Data transfer is frequently the most surprising line in a cloud bill, particularly for architectures designed for one AWS Region that now span several or talk heavily across Availability Zones. Use gateway VPC endpoints for S3 and DynamoDB, which carry no additional charge, to keep that traffic off the NAT Gateway, and keep chatty services in the same Availability Zone as the resources they call, or give each zone its own NAT Gateway. Replication between zones for RDS Multi-AZ deployments is free, so spend the effort on application traffic instead. For outbound internet traffic, CloudFront reduces origin fetches; Origin Shield is not offered in the Jakarta Region, so choose the Origin Shield Region with the lowest latency to your origin.

Measuring FinOps Maturity and ROI

The FinOps Foundation assesses maturity per capability as Crawl, Walk, or Run, and warns that reaching Run everywhere is not the goal; business value decides how far to mature each one. Three practical measures show progress: cost visibility (what percentage of cloud spend is tagged and attributable to a team or product), optimization rate (what percentage of identified waste recommendations are actioned within 30 days), and unit economics (cost per business unit, such as cost per transaction, per GB stored, or per monthly active user). How much any company saves depends on its starting point, so track these measures against your own baseline rather than a quoted industry figure.

Building a FinOps Culture in Indonesian Tech Teams

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.

Related Articles

• Infrastructure as Code with Terraform
• Kubernetes Deployment Strategies: Blue-Green, Canary, and Rolling Updates