Engineering a Multi-Region Azure Platform for a Global SaaS
How we rolled out GPU VM fleets across Australia, the US, and Germany, and put production telemetry behind private endpoints for a global SaaS document platform.
Engineering a Multi-Region Azure Platform for a Global SaaS
When you run a SaaS product with customers spread across three continents, “global” is not a marketing phrase, it is an operational reality. Latency budgets get smaller, telemetry routes get longer, and any workload that depends on specialised hardware (looking at you, GPU instances) suddenly has to be designed for where the hardware actually exists and where the quota actually lives.
Over the past months at SuiteFiles, a document platform serving more than a thousand customers in Australia plus a growing base in Europe and the US, we have been doing exactly that work: lifting a single-region Azure platform into a true multi-region footprint. Australia East stayed as the hub, with West US and Germany West Central added as full peers. Here is what mattered along the way.
GPU Fleets Where the Customers Are
The forcing function was simple: data scraping and inference workloads need GPUs, and round-tripping a request from Sydney to Frankfurt to a GPU sitting in Australia is a non-starter for both latency and cost. We standardised on NCASv3_T4 NVIDIA T4 instances and provisioned one identical GPU fleet per region, three in total, so document processing stays local to the customer.
Two things stand out from that rollout:
- Quota is not a checkbox, it is a project. Quota requests for GPU SKUs vary wildly by region and Azure subscription history. Building the infra without the GPUs is the easy part. Lining up quota approvals so the VMs actually come up is what takes weeks.
- Disk SKU choices compound. Premium SSD v2 with the right IOPS sizing was the difference between scrapers that paged out under load and scrapers that quietly held throughput. We discovered this the slow way; document it for the next region from day one.
Terraform as the Truth, Not the Suggestion
Multi-region only works if the regions look identical. We codified everything in Terraform: networking, NICs, Key Vaults, disks, NSGs, VMs. The first region took weeks of human decisions; the second and third regions took hours and a terraform apply.
A practical note: Key Vault access from outside the VNet was an early footgun. If your runner is not inside the VNet (or your developer is not on a VPN), terraform plan fails on the data sources before anything interesting happens. Plan your runner topology before you plan your infrastructure.
Telemetry Behind Private Endpoints
Observability got the same treatment as workloads. Application Insights and Log Analytics were moved behind Azure Monitor Private Link Scope (AMPLS), with private endpoints in each region. Why bother:
- Compliance. A SaaS that promises customers their telemetry never traverses the public internet now has the network architecture to back that up.
- Data exfiltration boundary. Even an authenticated-but-compromised workload cannot ship logs out to a third-party endpoint, because the only Monitor endpoints reachable from the workload VNet are the private ones.
- Egress savings. At enough volume, removing public-internet egress for telemetry is its own line item.
AMPLS is not trivial. DNS rewriting, scope-mode interactions, and the difference between Ingestion Access Mode and Query Access Mode all bite if you go in blind. Build it once, document it carefully, and copy-paste it into every new region.
Branching for Real Environments
The hidden cost of going multi-region is environment proliferation. Dev, staging, prototype, and production used to be a single-region story; suddenly each environment has three regional flavours and a coordination problem on top.
We codified a branching strategy that maps Git branches to environments cleanly, and we made deployments to non-production regions cheaper than redeploying production. The branching strategy is dull infrastructure work, but it is the thing that lets a small platform team support four environments and three regions without burning out.
What We Took Away
- Multi-region is a quota problem first, an infra problem second. Start the quota conversation before you write a line of Terraform.
- Identical regions only stay identical if the IaC says so. Hand-modifying anything is technical debt that compounds across N regions.
- Telemetry deserves the same private-network rigor as workloads. AMPLS is the right answer if your customers care about where their data goes.
- The platform team’s job in a multi-region world is to make new regions boring. That is what we have been building.
If you are at a SaaS that is getting serious about multi-region, or you are about to rip the band-aid off a single-region setup, we have done the painful version of this story enough times that the second time goes much faster. Get in touch.
Platform, SRE, and AI infrastructure for production systems. Building Horizon, the AI engineering operations platform now running in production across 7 Kubernetes clusters and 10+ tenants.