Azure Malaysia West: One Year Later — Lessons, Gaps, and the Road to Southeast Asia 3

It has been just over a year since Microsoft flipped the switch on the Malaysia West cloud region. For those of us who have been tracking Azure's expansion across Southeast Asia, this was a watershed moment — Microsoft's first hyperscale datacenter region on Malaysian soil, strategically located in Greater Kuala Lumpur, built with three Availability Zones, and backed by a US$2.2 billion investment in Malaysia's cloud and AI infrastructure.

I have spent the past twelve months working with enterprise teams across Malaysia — banks, telcos, oil and gas majors, government agencies — all wrestling with the same fundamental question: What can we actually run in Malaysia West today, and what still has to route elsewhere?

This article is my honest assessment of where things stand. Some of what I found surprised me — including one major AI service gap that almost every draft architecture I review gets wrong. Here is what a year of hands-on work has taught me, and how Malaysian enterprises should be thinking about their Azure strategy as the Johor Bahru region — Southeast Asia 3 — moves from announcement to reality.

The Malaysia West Region: What Is Actually Live

When Malaysia West went generally available in May 2025, Microsoft positioned it as an AI-ready, hyperscale region with full in-country data residency. That much is true. But "full" is a word that deserves scrutiny, and marketing announcements are not architecture inputs. So instead of trusting the launch press release, I verified service availability directly against the Azure resource provider registry. Here is the picture as of this writing.

Verified Available in Malaysia West

The region qualifies as a "recommended" Azure region — three physically independent Availability Zones with low inter-zone latency. The core platform is genuinely broad:

Compute & Application Platform

• Azure Virtual Machines (broad SKU support)
• Azure Kubernetes Service (AKS)
• Azure App Service and Azure Functions
• Azure Container Apps and Azure Container Instances

Data & Storage

• Azure SQL Database
• Azure Database for PostgreSQL Flexible Server
• Azure Database for MySQL Flexible Server
• Azure Cosmos DB
• Azure Cache for Redis (classic and Enterprise tiers)
• Azure Blob Storage and Azure Files
• Azure NetApp Files
• Managed Disks

Networking

• Virtual Networks, Azure Firewall, Application Gateway
• ExpressRoute and VPN Gateway
• Azure Bastion
• DDoS Network Protection (plan creation in-region)

AI & Data Platform

• Azure Machine Learning
• Azure AI Search
• Event Hubs and Service Bus
• Logic Apps and API Management

Security & Identity

• Microsoft Entra ID (global service; Malaysian tenants can anchor data in Malaysia West)
• Azure Key Vault
• Log Analytics workspaces — the foundation Microsoft Sentinel runs on
• Recovery Services vaults (backup and Site Recovery)

This is a solid foundation. If you are running a standard three-tier web application with a SQL backend, containerized microservices on AKS, or machine learning inference on Azure ML, you can deploy it entirely within Malaysian borders today.

What Still Routes to Singapore — The Part Most People Get Wrong

Here is the finding that matters most, and it contradicts what I see in many otherwise-careful architecture documents: Azure OpenAI Service is not available in Malaysia West. The Cognitive Services resource provider — the one Azure OpenAI is built on — does not list Malaysia West among its regions. Any workload that needs GPT models, embeddings, or Azure OpenAI endpoints must route to Southeast Asia (Singapore) or another supported region.

In 2026, that is a significant gap. Most AI-enabled application architectures assume Azure OpenAI is available in the primary region. If you are subject to in-country data residency requirements — and in Malaysia, financial services and government workloads increasingly are — this one gap can force a redesign.

Other verified gaps in Malaysia West:

• Azure AI Bot Service — not available in the region; the provider registry lists only Global, West Europe, West US, and Central India

Worth noting in the other direction: services some teams assume are missing — Azure Cache for Redis and DDoS Network Protection among them — are in fact listed for Malaysia West in the provider registry. Verify rather than assume, in both directions; availability data, not tribal knowledge, should drive your region decision.

The practical implication: if you are building a greenfield application, audit every service dependency against the Azure products-by-region data before you write your Bicep templates. Do not assume availability just because the region exists. You can run this audit yourself in minutes:

# Check whether a specific resource type lists Malaysia West as an available location
az provider show --namespace Microsoft.CognitiveServices \
  --query "resourceTypes[?resourceType=='accounts'].locations" -o json

# Or list everything your subscription has registered
az provider list --query "[?registrationState=='Registered'].namespace" -o table

Latency Benchmarks: What the Numbers Actually Tell You

Latency is the number that matters most for architecture decisions. Microsoft publishes P50 round-trip latency statistics between Azure regions. Here are the official numbers from Malaysia West as published by Microsoft — not estimates:

Malaysia West Inter-Region Latency (Official P50 Round-Trip)

Within Malaysia West

The Malaysia West to Singapore number — roughly 9 ms round-trip on the Azure backbone — is excellent. For most workloads, this means:

• Asynchronous database replication to Singapore works well for DR purposes
• Active-passive failover architectures are straightforward to implement
• Active-active is feasible but requires careful consistency design — the round-trip is small, but application-level eventual consistency must still be engineered in deliberately
• Synchronous writes to Singapore add a real, measurable cost to every transaction — not recommended for latency-sensitive paths

One critical point: these are Azure backbone numbers. Your actual application latency depends on the full path — client to Azure edge, edge to region, inter-service calls within the region, and any internet egress. I recommend every team run their own measurements before committing to an architecture:

# Deploy a small test VM in each region, then measure real connectivity
az network watcher test-connectivity \
  -g rg-mw-test --source-resource vm-mw-test \
  --dest-resource vm-sea-test --dest-port 1433

The Johor Bahru Factor: Southeast Asia 3 Changes the Calculus

On 4 November 2025, Microsoft announced Southeast Asia 3 — a second Azure cloud region to be built in Johor Bahru, Malaysia. This is not just another datacenter announcement. It fundamentally changes the strategic picture for Malaysian enterprises.

What We Know

• Location: Johor Bahru, connected across the Causeway to Singapore's ecosystem and to Microsoft's global Azure backbone — more than 600,000 km of subsea and terrestrial fibre
• Focus: AI transformation and advanced workloads; the region will add to Azure's 70+ global regions
• Timeline: No confirmed GA date yet; construction and community programs are underway
• Sustainability: Backup generators powered by renewable biofuel, and a closed-loop chip-level cooling design that achieves zero-water evaporation — eliminating the need for a continuous fresh water supply
• Community investment: The Skills2Work Datacenter Foundations Program, run with The Asia Foundation and Universiti Teknologi Malaysia, will equip 150 recent graduates with hands-on datacenter training; a separate UNDP Malaysia initiative is training 200 trainers from 20 social enterprises to reach approximately 10,000 community members; and Microsoft is partnering with Belia Prihatin and WWF Malaysia on a three-year mangrove restoration project in Johor

Why This Matters for Architecture Planning

1. The Paired Region Problem, Eventually Solved

Today, Malaysia West has no formal Azure paired region — Microsoft's own reliability documentation lists it under non-paired regions. Southeast Asia (Singapore) is the de facto secondary, but it is not a paired region in Azure's platform sense — meaning you do not get automatic staggered updates or paired-region features for services like geo-redundant storage.

When Southeast Asia 3 goes live, an in-country pairing becomes realistic. That unlocks:

• Formal DR targets with platform-level support
• Staggered platform updates across the pair
• Geo-redundant storage patterns that never leave Malaysian borders

2. Cross-Border Data Residency Implications

Malaysia's PDPA amendments — now in force with mandatory breach notification and Data Protection Officer obligations — tighten cross-border transfer rules. While the PDPA does not mandate data localization for all data types, sector regulators, particularly Bank Negara Malaysia for financial services, lean heavily toward in-country storage.

Having two Malaysian regions means:

• DR within Malaysian borders, without cross-border transfer analysis
• Higher availability for in-country workloads
• A future option for active-active entirely within Malaysia

3. The JB–Singapore Corridor

Johor Bahru's physical proximity to Singapore creates a unique architectural opportunity: workloads distributed across Malaysia West (Kuala Lumpur), Southeast Asia 3 (Johor Bahru), and Southeast Asia (Singapore) — three regions with latencies low enough for most distributed-systems patterns.

Practical Recommendations for Malaysian Enterprises

Based on a year of working with teams deploying to Malaysia West, here is my honest guidance.

1. Start with a Region Audit

Before migrating anything, map every Azure service your current architecture uses against Malaysia West's actual availability. If any dependency is missing — and if your stack includes Azure OpenAI, it is — decide now whether to wait, redesign, or accept the Singapore fallback with its latency and compliance implications.

2. Design for the Paired Region That Does Not Exist Yet

Malaysia West has no formal paired region today. Your DR strategy must be explicitly configured against Southeast Asia (Singapore):

# Create a Recovery Services vault in Southeast Asia as the DR target
az backup vault create \
  --resource-group rg-dr-backup \
  --name rsv-sea-dr \
  --location southeastasia

Azure-to-Azure replication through Site Recovery runs against that same vault. The CLI path exists (az site-recovery protected-item create) but requires fabric, protection container, and policy IDs, so most teams enable replication through the portal, Bicep, or Terraform instead. The important point is not the tooling: do not wait for Southeast Asia 3 to design your DR. Build it now with Singapore, and plan to migrate the DR target to Johor Bahru when it becomes available.

3. Treat Latency as a First-Class Architecture Constraint

Run your own benchmarks. The published numbers are backbone-to-backbone; your real-world latency includes the client path, TLS negotiation, and application-layer processing. If your application requires single-digit-millisecond database response times and you are tempted by cross-region writes, redesign instead: in-region reads, asynchronous replication, and event-driven synchronization.

4. Plan for Southeast Asia 3 Now

The Johor Bahru region announcement is a planning input, not just news. Start documenting which workloads you would move from Singapore DR to in-country DR, and what that change enables — for regulated workloads, keeping all data, primary and DR, within Malaysian borders will likely become a regulatory expectation, not a nice-to-have.

5. Engage Microsoft Early on Service Roadmap

For services not yet in Malaysia West — Azure OpenAI being the big one — engage your Microsoft account team or solution architect. Regional service rollouts are demand-driven, and customer architecture requirements are genuine leverage. If enough Malaysian enterprises signal that Azure OpenAI in Malaysia West is the gating factor for their AI workloads, that changes the roadmap conversation.

Cost Considerations

Malaysia West pricing is generally competitive with Southeast Asia (Singapore), with a few nuances:

• Compute: VM pricing roughly comparable to Southeast Asia, with occasional promotional pricing for new-region adoption
• Storage: Standard and Premium tiers aligned with Southeast Asia
• Cross-region egress: Data transfer from Malaysia West to other regions incurs Azure’s standard inter-region bandwidth charges. As of August 2026, intra-continental APAC inter-region transfer (e.g. Malaysia West ↔ Singapore, Jakarta, Hong Kong, Korea, Japan) is $0.02 per GB; inter-continental (e.g. Malaysia West ↔ Europe or the US) is $0.05 per GB. Internet egress to destinations outside Azure is metered separately and starts at $0.087/GB after the first 100 GB free. Verify the current rates in the Azure Pricing Calculator before you budget a DR architecture that replicates terabytes daily.
• Reserved Instances: Available in Malaysia West. Savings depend on the service and term — for Azure VMs, 1-year reservations typically save around 30–40% and 3-year reservations up to ~65% versus pay-as-you-go. Across the full Azure reservation portfolio, published savings range from about 11% to 72% depending on the service. For Azure SQL and Azure Cache for Redis, the upper end is closer to 30–55%. Use the Azure Pricing Calculator for an exact figure on your specific SKU and region.

# List VM sizes actually available in Malaysia West
# Note: `az vm list-sizes` is deprecated in favor of `az vm list-skus`.
# The query projection below targets the older list-sizes output schema.
az vm list-sizes --location malaysiawest \
  --query "[].{name:name, vCPUs:numberOfCores, memoryMB:memoryInMb}" -o table

My recommendation: start with pay-as-you-go to validate architecture and service availability, then commit to reservations once performance and gaps are confirmed.

Key Takeaways

1. Malaysia West is production-ready for most workloads — compute, databases, storage, networking, Azure ML, and AI Search are all in-region. Verify every dependency against the products-by-region data before committing; the gaps are real and they matter.
2. The big gap is Azure OpenAI. The Cognitive Services provider does not list Malaysia West. Any AI workload built on Azure OpenAI routes to Singapore today — plan for it explicitly, and press Microsoft on the roadmap if in-country AI matters to you.
3. Malaysia West to Singapore latency (~9 ms official P50 round-trip) is excellent for async DR, but design for in-region reads and asynchronous replication rather than synchronous cross-region writes.
4. Malaysia West has no formal paired region. Singapore is the practical DR target, but you must configure replication and failover explicitly. Do not rely on platform-level paired-region features.
5. Southeast Asia 3 (Johor Bahru) changes everything when it lands — in-country DR, a potential paired region, and a KL–JB–Singapore corridor for distributed architectures. Start planning for it now, even though GA is not yet dated.

Law Wen Feng is a Principal Solution Architect based in Malaysia, specializing in Azure infrastructure, cloud strategy, and AI-first architecture for Southeast Asian enterprises. Connect at [wenfeng.my](https://wenfeng.my).