Deploying Azure resources to the most isolated capital city in the world - Part 1
Stephen Tulp
May 19, 2025
6 minutes to read
Introduction
Perth, Western Australia, is often regarded as the most isolated capital city in the world due to its significant distance from other major cities. Its just over 2,100 kilometers away from the nearest major city, Adelaide and surrounded by the Indian Ocean to the west and a whole lot of nothing to the east, further emphasising its remote location.
Despite its isolation, Perth is a vibrant city with a strong economy, largely driven by the mining and resources sector and over 2 million people.

One challenge for Perth customers consuming cloud services, has been the latency to an Azure region. For Perth customers, generally one of three (3) Azure regions were used.
Southeast Asia
(Singapore) Used by global customers and early adopters prior to the Australian Azure regions coming online.Australia East
(Sydney) is the de facto standard for most Australian customers due to Availability Zones and a diverse set of services on offer.Australia Southeast
(Melbourne) for customers looking for DR in a multi-region deployment using AustraliaEast as the primary and Southeast as the secondary, or were in fact closer to this region and didn’t require availability zones.
The actual latency to each of the Azure regions from Perth are actually quite similar as seen in the image below from the test using Azure Speed Test that has some great capabilities for understanding distance and latency to each region.

Late last year Microsoft announced it would deploy an Azure Extended Zone
to Perth by mid-2025 and last week public preview access was opened to start testing services and being able to deploy services into the extended location.
What are Azure Extended Zones?
Azure Extended Zones are small extensions of Azure that are strategically placed in metropolitan areas to cater to low latency and data residency requirements. The easiest way to describe it would be an Azure presence that sits between an Azure public region and Azure local within an on-premises environment.

Currently there is only one (1) Azure Extended Zone, which is located in Los Angeles
with Perth
being the second location when it fully comes online and becomes GA.
Use Cases
There are two (2) main use cases addressed with Azure Extended Zones;
- Latency Sensitive Workloads: Workloads that are sensitive to latency and need to be accessed remotely with low latency.
- Data Residency Requirements: Workloads and data that need to stay within a specific geography for various privacy, regulatory, and compliance reasons.
Personally, I don’t see number 2 being that compelling for customers locally and it would make more sense if the data needed to be within the state boundary it’s probably better off staying on-premises.
Availability of Services
Azure services currently focus on core compute, storage, and networking capabilities, with additional services to be added over time. A key differentiator between an Azure region and an Azure Extended Zone is that the Control Plane, (Azure Resource Manager) remains hosted within the Azure region. In contrast, the Data Plane (Compute, Network, Storage services) are deployed at the Extended Zone site.

Available services for Azure Extended Zones include;
-
Compute
- Azure Kubernetes Service*
- Azure Virtual Desktop*
- Virtual Machine Scale Sets
- Virtual machines (general purpose: A, B, D, E, and F series and GPU NVadsA10 v5 series**)
-
Networking
- DDoS (Standard protection)
- ExpressRoute
- Private Link
- Standard Load Balancer
- Standard public IP
- Virtual Network
- Virtual network peering
-
Storage
- Managed disks
- Premium Page Blobs
- Premium Block Blobs
- Premium Files
- Data Lake Storage Gen2
- Hierarchical Namespace
- Change Feed
- Blob Features (SFTP, NFS)
- BCDR
- Azure Site Recovery*
- Azure Backup
- Arc-enabled PaaS
- ContainerApps*
- PostgreSQL*
- ManagedSQL*
(*) While these services are GA in Azure Regions, they are currently in Preview in Azure Extended Zones.
Other things to Note
Based on my research and testing so far, some items I have found.
- There is no default outbound internet access, this secure by design approach aligns with the September 2025 deadline for Default Outbound Access Retirement
- Azure Firewall isn’t currently available, but due for GA. This will be important for the above as control mechanism for ingress and egress.
- There is no support for Reserved Instances and Azure Saving Plans
Onboarding
To get started we need to register the Azure subscription for the Microsoft.EdgeZones
resource provider.

The following command will give a list of all the Azure Extended Zones and their associated metadata.

As we can see there are currently 2 locations, Los Angeles
and Perth
, its important to take note of the HomeLocation as this is the parent Azure region where the control plane services live.

We then register the subscription for the Perth
extended location. We can check to ensure that the status changes from registering
to registered
as this needs to be in place before we can deploy anything.

Conclusion
In part 1 we have delved into understanding what Azure Extended Zones are and some of the unique characteristics to be aware of, next up we will look at deploying a Landing Zone and some services.