# FinOps for Indonesian Cloud Teams: A Practical Cost Optimization Guide > Cloud bills at Indonesian companies swell with over-provisioned instances, forgotten dev environments and unattached EBS volumes. This guide applies the FinOps Framework's Inform, Optimize and Operate phases with working AWS CLI and Python scripts, cost anomaly alerts, and the Savings Plans, Reserved Instance and Spot choices that suit workloads in the AWS Jakarta Region. URL: https://www.matthewswong.com/en/blog/finops-cloud-cost-optimization-indonesia/ - Author: Matthews Wong (https://www.matthewswong.com/en/about/) - Published: 2026-02-10 - Updated: 2026-10-17 - Category: DevOps 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. > Enable AWS Cost Anomaly Detection on every AWS account, review the cost anomalies dashboard in Google Cloud Billing, and keep budget alerts as a backstop. AWS runs anomaly detection about three times a day on Cost Explorer data that can lag by up to 24 hours, so expect an alert within about a day of the spend, not within minutes. AWS alert thresholds can be absolute or a percentage of an anomaly's total impact; start with a percentage threshold and tighten it once you know your normal alert volume. ## 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. ### 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. > **Never Stop Production Databases to Save Cost** > A common but damaging cost-cutting mistake is stopping or terminating production RDS, Cloud SQL, or PostgreSQL instances during off-hours. Terminating risks data loss, and even a clean stop resets connection pools and leaves caches cold, which early-morning users feel as a slow service. Reduce database cost sustainably instead: use Aurora Serverless v2 for variable workloads, add read replicas to shift read traffic off the primary, use PgBouncer connection pooling to cut connection overhead, and cover the stable baseline with a commitment, either Reserved Instances or the newer Database Savings Plans, which AWS lists at up to 35% off on services including Aurora and RDS (as listed on 17 October 2026). ## 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. ### 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. > Schedule non-production environments (dev, staging, QA) to stop at 20:00 WIB and start at 08:00 WIB on weekdays using Instance Scheduler on AWS or a small Lambda function triggered by EventBridge. Running only 12 hours a day on 5 weekdays is 60 of the week's 168 hours, so stopped instances bill roughly 64% fewer instance-hours with no manual effort. Attached EBS volumes keep billing while the instances are stopped. ## 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. ### 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. ## 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. > **Key takeaway:** For Indonesian cloud teams, FinOps cuts waste in three repeating phases: Inform gives every resource an owner and a tag so the bill can be explained, Optimize removes idle and oversized resources and covers steady usage with Savings Plans or Reserved Instances, and Operate keeps budgets and anomaly alerts in daily engineering work. ## Source links - https://www.finops.org/introduction/what-is-finops/ - https://aws.amazon.com/aws-cost-management/aws-cost-explorer/ - https://cloud.google.com/recommender/docs/recommenders - https://learn.microsoft.com/en-us/azure/advisor/advisor-cost-recommendations - https://www.finops.org/framework/ - https://focus.finops.org/docs/specification/v1-4/ - https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html - https://docs.aws.amazon.com/savingsplans/latest/userguide/plan-types.html - https://aws.amazon.com/ec2/pricing/reserved-instances/ - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html - https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html - https://aws.amazon.com/rds/pricing/ ## FAQ ### Why does the post recommend completing the Inform phase before jumping to Optimize? Without cost visibility through tagging and anomaly detection, optimization is blind: teams cannot tell which resources drive spend or whether a reduction worked. The FinOps Foundation's framework treats Inform, Optimize, and Operate as iterative phases, so visibility comes first and is revisited on every cycle. A mandatory tag set (Environment, Team, Project, CostCenter) is the practical starting point. ### What are the most common sources of cloud waste in Indonesian deployments? The post lists five: instances sized at launch and never reviewed, dev and staging environments left running overnight and on weekends, unattached EBS volumes that AWS keeps billing until they are deleted, NAT Gateway charges for traffic that a gateway VPC endpoint or a same-zone NAT Gateway would avoid, and cross-region transfer from misrouted replication. Each can be found with a script or a cloud provider's recommender. ### How much can scheduling non-production environments to shut down overnight actually save? Running dev environments only from 08:00 to 20:00 WIB on weekdays uses 60 of the week's 168 hours, so stopped instances bill roughly 64% fewer instance-hours. Attached EBS volumes keep billing while instances are stopped, so the saving on the whole environment is somewhat lower. Instance Scheduler on AWS or a Lambda function triggered by EventBridge can automate it. ### What commitment-based discounts does the post recommend, and how much do they save? 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, and Compute Savings Plans up to 66% with flexibility across instance families, Regions, Fargate, and Lambda. AWS recommends Savings Plans over Reserved Instances for EC2. Spot Instances run at up to 90% off but can be reclaimed with a two-minute notice, so they suit only fault-tolerant work. ### Why does the post warn against stopping production databases to save costs? Terminating a production database risks data loss, and even a clean stop resets connection pools and leaves caches cold, so early-morning users get a slow service. The post recommends sustainable alternatives: Aurora Serverless v2 for variable workloads, read replicas, PgBouncer connection pooling, and a commitment for the stable baseline. That commitment can be Reserved Instances or Database Savings Plans, which AWS lists at up to 35% off on services including Aurora and RDS. --- - HTML version: https://www.matthewswong.com/en/blog/finops-cloud-cost-optimization-indonesia/ - Bahasa Indonesia: https://www.matthewswong.com/id/blog/finops-cloud-cost-optimization-indonesia/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json