Azure Container Registry Introduces Regional Endpoints for Geo‑Replicated Registries in Private Preview

Microsoft announced the private preview of regional endpoints for geo‑replicated Azure Container Registries, a Premium SKU feature that provides explicit routing control for container image operations across multiple Azure regions. The capability lets users select a specific replica rather than rely on Azure‑managed routing, which previously directed traffic based on network performance metrics without exposing the underlying replica choice. The announcement appears on the Microsoft Community Hub at https://techcommunity.microsoft.com/t5/s/gxcuf89792/images/bS00NDk2MTg2LTFIY2h0cQ?revision=1.

Previously, geo‑replication in Azure Container Registry created copies of a registry in each selected region, but all client interactions used the global endpoint myregistry.azurecr.io. Azure automatically chose the replica that offered the best network latency for each request. This design reduced the operational overhead for customers but introduced unpredictability when a deployment required a fixed regional affinity or when troubleshooting needed to isolate traffic to a known replica. Detailed guidance on configuring geo‑replication is available in the Azure documentation at https://learn.microsoft.com/azure/container-registry/container-registry-geo-replication.

In the broader cloud container registry market, similar geo‑replication capabilities exist but differ in routing control. Amazon Elastic Container Registry (ECR) supports cross‑region replication through its replication rule API, yet clients still use the global endpoint *.amazonaws.com. AWS does not expose per‑region login URLs, so traffic routing remains managed by AWS. Google Artifact Registry offers multi‑regional storage with a single endpoint, and while it can direct requests to the nearest storage location, it does not provide a dedicated login server for each region. Azure’s new regional endpoint URLs myregistry..geo.azurecr.io fill a gap that other providers have not addressed, giving customers a way to enforce regional affinity without redesigning their application architecture. Pricing for these services can be compared directly: AWS ECR charges $0.10 per GB per month for cross‑region replication at https://aws.amazon.com/ecr/pricing/, while Google Artifact Registry uses regional storage pricing of $0.026 per GB per month at https://cloud.google.com/artifact-registry/pricing. For organizations that operate self‑hosted registries, Harbor provides an alternative at https://goharbor.io/docs/.

Pricing for geo‑replication varies across clouds. Azure Premium tier for Container Registry includes geo‑replication and regional endpoints at a fixed hourly rate per region, with additional costs for data egress when images move between regions. The current SKU pricing is documented at https://learn.microsoft.com/azure/container-registry/container-registry-skus. AWS charges for cross‑region replication based on the amount of data transferred per month, typically $0.10 per GB, and also applies egress fees for pulls from a replica that is not the primary region. Google Artifact Registry uses regional storage pricing, which is $0.026 per GB per month for standard storage in a region, and does not charge extra for replication traffic within the same project. For enterprises that operate Kubernetes clusters in multiple Azure regions, the ability to lock traffic to a co‑located replica can reduce egress costs and improve latency, especially when the Premium SKU already covers the replication infrastructure.

Regional endpoints function as dedicated login servers for each geo‑replica. When a client authenticates against myregistry.eastus.geo.azurecr.io, the request bypasses Azure’s routing engine and is sent directly to the East US replica. The same authentication mechanisms that work with the global endpoint—Microsoft Entra ID, service principals, managed identities, and admin credentials—remain available, so no change is required in credential handling. All subsequent operations, including tag creation, manifest updates, and artifact uploads, target that replica exclusively. The Azure documentation for regional endpoints explains the flow at https://learn.microsoft.com/azure/container-registry/regional-endpoints. Layer blob downloads follow the existing data endpoint pattern: if a registry has a dedicated data endpoint enabled, the blob URL resolves to myregistry.eastus.data.azurecr.io; otherwise it redirects to the Azure storage account *.blob.core.windows.net.

When a registry uses Azure Private Link, enabling regional endpoints creates an additional private IP address allocation for each geo‑replica in the associated virtual networks. For a registry with three geo‑replicas and private endpoints, each VNet receives three extra private IPs, one per regional endpoint. This preserves the firewall‑rule granularity that private endpoints provide while allowing traffic to be confined to a specific region. The same logic applies to dedicated data endpoints, where the blob download URL automatically points to the region‑specific data endpoint, maintaining scoped firewall rules without exposing wildcard storage access. More information on Private Link integration is in the Azure docs at https://learn.microsoft.com/azure/container-registry/container-registry-private-link.

Kubernetes manifests can reference the regional endpoint URL to guarantee that a cluster pulls images from its local replica. An East US AKS deployment can use image: myregistry.eastus.geo.azurecr.io/myapp:v1, while a West Europe deployment uses myregistry.westeurope.geo.azurecr.io/myapp:v1. The same image tag can be stored in multiple replicas, and the manifest ensures the correct replica is used without relying on Azure’s routing heuristics. This pattern simplifies troubleshooting because any network latency issue can be traced to the specific replica rather than to a routing decision. The Azure CLI reference for login to a regional endpoint is at https://learn.microsoft.com/cli/azure/acr.

Adopting regional endpoints requires a few operational steps. First, the subscription must register the RegionalEndpoints feature flag and propagate it to the Microsoft.ContainerRegistry provider. This can be done with Azure CLI commands az feature register and az provider register. Second, the preview extension must be installed to expose the --regional-endpoints flag. After registration, existing Premium registries can enable the feature with az acr update -n myregistry -g myrg --regional-endpoints enabled. New registries can be created with the flag from the start. Migration from other cloud registries involves updating image references in deployment files, adjusting firewall rules to allow the new regional URLs, and testing authentication flows with the same credential types. Because the feature is still in private preview, customers should evaluate it in a non‑production environment before rolling it out widely. The preview extension wheel file is downloadable from https://aka.ms/acr/regionalendpoints/download.

The ability to route traffic to a known replica improves predictability for latency‑sensitive workloads, such as CI/CD pipelines that push images to a registry and then trigger deployments. It also supports custom failover logic where a health check can switch traffic to a secondary region without waiting for Azure’s routing engine to react. From a cost perspective, limiting egress to a co‑located replica can lower data transfer charges, especially for large image sets that move across regions. Compliance teams benefit because the feature makes it easier to enforce data residency policies by ensuring that all operations stay within a specific jurisdiction. Azure’s compliance resources for container registries are available at https://learn.microsoft.com/azure/container-registry/container-registry-compliance.

Microsoft’s regional endpoints represent a concrete step toward giving customers more control over geo‑replicated container registries. While the feature is currently limited to the Premium tier and the Azure public cloud, it aligns with broader trends of explicit routing control in cloud services. Enterprises evaluating multi‑cloud strategies should compare this capability with the routing options offered by AWS ECR and Google Artifact Registry, and consider how the added predictability and cost management can affect their deployment pipelines.

Below is a visual representation of the architecture changes introduced by regional endpoints.