Skip to content
MANIFESTO

Why Southeast Asia Enterprises Keep Overpaying for Multi-Cloud — And

Why Southeast Asia Enterprises Keep Overpaying for Multi-Cloud — And the Engineering Fixes That Actually Work Walk into a mid-size enterprise in Singapore or Jakarta...

MAY 21, 2026 5 MIN READ
Why Southeast Asia Enterprises Keep Overpaying for Multi-Cloud — And
RADICAL · BRUTALISM · KINETIC · DESIGN · RADICAL · BRUTALISM · KINETIC · DESIGN · RADICAL · BRUTALISM · KINETIC · DESIGN · RADICAL · BRUTALISM · KINETIC · DESIGN ·

Why Southeast Asia Enterprises Keep Overpaying for Multi-Cloud — And the Engineering Fixes That Actually Work

A vibrant collection of international flags in a cityscape setting, symbolizing global unity.
Photo by Th2city Santana on Pexels

Walk into a mid-size enterprise in Singapore or Jakarta and ask their cloud team how their monthly AWS bill compares to last quarter's. You will get one of two answers: either a vague "roughly the same" or a panicked look that means they have not looked at the cost dashboard in three weeks. For CTOs and IT directors across Southeast Asia managing multi-cloud estates across AWS, GCP, and Azure, cloud cost governance has quietly become one of the most unmanaged parts of the infrastructure stack.

The problem is not that tools do not exist. AWS Cost Explorer, GCP Billing Account alerts, and Azure Cost Management all provide adequate surface-level visibility. The problem is what those tools miss: the hidden cost patterns that emerge when enterprises run services across multiple clouds simultaneously — patterns that do not show up on any single vendor's dashboard, but show up clearly on your CFO's budget report every quarter.

This is the multi-cloud cost gap. It is costing SEA enterprises an estimated 25-40% more than a well-governed single-cloud deployment, and it is almost entirely preventable.

The Glue-and-EMR Problem Nobody Talks About

The most instructive example of multi-cloud cost opacity comes from a case study that reset our own internal ETL cost model. A regional e-commerce platform in Southeast Asia ran 1.3 million daily active users across Singapore, Malaysia, Indonesia, Thailand, the Philippines, Vietnam, and processed roughly 2.3 terabytes of incremental order and behavioral data every night through a self-managed Apache Airflow setup on EC2, with EMR clusters spinning up for processing windows.

Their migration brief was operationally driven. The Airflow setup required dedicated SRE attention for cluster management, job dependency handling, and on-call response when EMR clusters failed to start within the service-level objective window. AWS Glue's promise was straightforward: managed Spark execution, built-in job scheduling, automatic resource provisioning. The migration was operationally successful. The cost model was not what anyone expected.

Here is the actual number that matters: the old EMR-based setup cost roughly $2,300 per month for cluster time plus $470 for Airflow infrastructure and SRE time amortisation. Glue's billing for equivalent processing came to $4,700 per month — over double. The reason is structural: Glue's per-DPU-hour pricing assumes consistent utilisation. Nightly ETL workloads have peak processing hours and idle stretches. Under EMR's spin-up-spin-down model, that means pay only for active cluster time. Under Glue's job-level pricing, the cost includes Glue's own orchestration overhead. The idle stretches cost money in the new architecture that were effectively free in the old one.

This is the spin-down model problem. It is not unique to Glue versus EMR. It is a pattern that repeats across every cloud service where reserved capacity, on-demand billing, and serverless pricing models interact. Understanding which workloads should be reserved, which should be serverless, and which should spin down to zero when idle is the first discipline of multi-cloud cost engineering — and it is the discipline most SEA enterprises have not systematically built.

The Three Hidden Cost Layers in Your Multi-Cloud Bill

In our work with enterprise clients across Southeast Asia, we consistently encounter three cost layers that do not appear in any vendor's native billing interface. These are the layers where the real budget bleed happens.

Cross-cloud data transfer is your largest silent expense. When you run a workload on AWS in Singapore and need to read from a dataset stored in GCP's asia-southeast1 region, every gigabyte that crosses the public internet between providers incurs egress charges from both sides. For a mid-size e-commerce or cloud gaming operation moving terabytes per day, cross-cloud egress can represent 15-25% of total monthly spend. Native tools from each vendor measure internal traffic only. Measuring cross-vendor traffic requires a unified cost governance layer that most enterprises do not build until after they have already overspent for a year.

Idle capacity compounds quietly during off-peak hours. Southeast Asian enterprises running global services often maintain reserve capacity for peak traffic windows that occur at different times in different markets. A Manila-headquartered operation with a Singapore CDN node and Jakarta compute instances may have reserve capacity sitting idle for 14-16 hours per day in each region. At AWS Lambda pricing, idle Lambda concurrency is not a cost — but idle RDS read replicas, reserved EC2 instances, and pre-warmed GCP Cloud Run instances all carry costs that do not register as urgent until the monthly invoice arrives.

License and API call costs do not scale linearly. A fintech customer running microservices on Oracle Cloud Infrastructure, AWS, and a small Azure footprint discovered that their combined API Gateway call volumes across three providers were generating per-call charges that had grown 180% in 18 months without a corresponding growth in business volume. The reason: each team had independently adopted their cloud's native API Gateway without a unified routing layer. The consolidation project recovered 40% of that incremental spend in the first month.

Close-up view of modern rack-mounted server units in a data center.
Photo by panumas nikhomkhai on Pexels

The Malaysian Fintech Migration That Changed How We Think About Identity Cost

The compliance angle in multi-cloud cost engineering is often underestimated — until a regulatory examination lands and forces a rethink. A Malaysian fintech operating regional retail banking integrations migrated from Auth0 to AWS Cognito over 11 weeks in 2024. The stated goal was compliance simplification: Bank Negara Malaysia's updated cloud outsourcing examination had produced a question about the segregation between their authentication vendor and their infrastructure vendor. Consolidating to Cognito would simplify the audit trail to a single cloud relationship.

What the post-migration analysis revealed was more complex. The compliance simplification was real — BNM's follow-up examination accepted the single-vendor audit trail without reservation. But the operational cost was higher than projected: the Lambda Triggers the team built to match Auth0's advanced fraud detection patterns required custom development and produced edge-case failures under burst load that were not caught until production. CloudWatch Logs surfaced the issue three weeks post-migration. The root cause — a Pre-Sign-up trigger occasionally timing out under burst load, causing legitimate registrations to fail — took 47 minutes from alert to fix.

The total cost of the migration, including the Lambda development work, the extended user import validation period (23 working days), and the post-incident remediation, exceeded the annual Auth0 licensing fee. The long-term TCO advantage only materialises over 18-24 months. For enterprises evaluating identity provider consolidation purely on licensing cost, this case study is a necessary correction.

Engineering Controls That Close the Multi-Cloud Cost Gap

The fixes are not abstract. They are engineering decisions that any competent cloud team can implement, and they follow a consistent logic: make cost visible at the point of decision, not after the invoice arrives.

Implement a unified cost governance layer that aggregates billing data from all cloud providers into a single view. AWS Cost Explorer, Azure Cost Management, and GCP Cost Table can all export to BigQuery or an equivalent analytics backend. The goal is not a prettier dashboard — it is cross-cloud visibility that lets your team see data transfer costs, idle capacity, and API call volumes as they actually occur across providers, not as each vendor independently reports them.

Adopt a FinOps tagging discipline across all three clouds before you scale. Every resource — EC2 instance, S3 bucket, RDS replica, GCP Compute Engine VM, Azure Virtual Machine — should carry project code, environment, owner, and cost centre tags. Without consistent tagging, cost allocation by business unit or project is guesswork, and guesswork is where budget authority dissolves.

Right-size compute with evidence, not habit. Run AWS Cost Explorer's rightsizing recommendations alongside GCP's recommender and Azure's Advisor recommendations weekly. In multi-cloud environments, right-sizing is not a one-time project — it is a continuous practice because workloads change and reservation commitments do not. Commit to annual reservation reviews and match reserved capacity to stable baseline workloads while keeping variable workloads on on-demand or spot pricing.

For regulated industries — financial services, healthcare, gaming platforms with real-money components — factor compliance cost into the infrastructure decision, not after it. The Malaysian fintech case study is representative: the identity provider consolidation had genuine compliance merit, but the migration cost was not modelled with full operational scope. When you build the TCO model, include the Lambda development costs, the extended validation periods, and the post-migration incident risk. The compliance benefit is real — budget for the full cost of achieving it.

Close-up of wooden Scrabble tiles spelling SECURITY, symbolizing cybersecurity and protection.
Photo by Markus Winkler on Pexels

FAQ

How do I get a unified cost view across AWS, Azure, and GCP?
Aggregate billing exports from each provider into a central analytics platform — BigQuery, a dedicated FinOps SaaS tool, or a custom dashboard. Each provider offers a billing export API. Tag every resource consistently across all three clouds so cost allocation by project and business unit is accurate rather than estimated.

Is serverless always cheaper for variable workloads?
Not necessarily. The Glue versus EMR example illustrates the case clearly: serverless per-unit pricing assumes consistent utilisation. For workloads with pronounced idle periods — batch ETL, overnight processing, event-driven jobs with irregular triggers — a properly configured spin-down model using reserved capacity or spot instances often costs less than serverless equivalents. Model both architectures before committing.

What is a realistic RTO and RPO for a multi-cloud disaster recovery setup?
With same-city active-active architecture and real-time database replication, typical RPO approaches zero and RTO stays under 30 minutes. Cross-region DR with automated failover adds latency and cost but provides protection against regional outages. Tier your workloads by criticality and apply matching DR architecture rather than applying a single DR standard to all services.

How does Agilewing handle multi-cloud cost governance for enterprise clients?
Our managed services include 7×24 monitoring, a dedicated technical account manager, and continuous cost governance across your full multi-cloud estate. We aggregate billing data from all providers, run weekly right-sizing reviews, and flag cross-cloud data transfer anomalies before they become budget surprises. Response time for cost-related incidents is under 15 minutes.

Team of hackers with Guy Fawkes masks coding in a dark room with computers.
Photo by Tima Miroshnichenko on Pexels

The enterprises that have solved multi-cloud cost governance share a common trait: they treated cost engineering as a first-class engineering discipline, not a finance department problem to be delegated back to the infrastructure team. The tools are available. The patterns are understood. The gap between enterprises that manage it and enterprises that absorb it is a decision, not a technical constraint.

Agilewing helps cross-border e-commerce, cloud gaming, NEV automakers, smart manufacturing, and SaaS companies across Singapore, Jakarta, and Manila build multi-cloud infrastructure that is secure, compliant, and cost-optimised from day one. Our APN Security-accredited delivery team brings deep AWS, GCP, Azure, and Oracle Cloud expertise and covers GDPR, PCI-DSS, PDPA, MLPS 2.0, CCPA, and cross-border compliance requirements across every engagement.

If your multi-cloud bill does not have a clear owner, it is already out of control.

END TRANSMISSION

Agilewing · RADICAL ARCHIVE · ISSUE 001