TL;DR: Os endpoints regionais do Azure Container Registry (ACR) em public preview trazem URLs dedicadas por geo-replica (ex.: myregistry.eastus.geo.azurecr.io), permitindo que equipes de infraestrutura fixem workloads a réplicas específicas, implementem failover client-side e evitem problemas de eventual consistency em pipelines CI/CD. A feature dispensa registro de feature flag e já está disponível nativamente no Azure CLI 2.86.0+ e no portal. Para a maioria dos workloads, o endpoint global com roteamento automático ainda é a melhor escolha; os endpoints regionais são indicados quando se exige previsibilidade de rota ou isolamento por região — algo crucial para empresas brasileiras com clusters em múltiplas regiões Azure.
O que mudou com o anúncio?
A Microsoft liberou em public preview os endpoints regionais para Azure Container Registry (ACR) com geo-replicação. Se você acompanhou a private preview, as principais diferenças são:
- Sem necessidade de registro de feature flag — disponível para todas as assinaturas Azure imediatamente.
- Sem extensão CLI separada — os comandos agora são nativos a partir do Azure CLI 2.86.0+.
- Suporte nativo no portal Azure — tanto na criação quanto em registries existentes.
- Renomeação de flag: O antigo
--region-endpoint-enabled(que controlava a participação de uma réplica no roteamento do endpoint global) foi renomeado para--global-endpoint-routing, para evitar confusão com a nova feature.
Importante: A feature está disponível apenas para registries Premium SKU em todas as regiões públicas da Azure.
O que são endpoints regionais?
São URLs de login dedicadas por geo-replica, seguindo o padrão:
myregistry.eastus.geo.azurecr.iomyregistry.westeurope.geo.azurecr.io
Eles coexistem com o endpoint global (myregistry.azurecr.io), que continua funcionando normalmente com roteamento automático e failover health-aware. A escolha é por workload:
- Endpoint global: para a maioria dos workloads, com failover automático.
- Endpoint regional: quando você precisa de roteamento explícito para uma réplica específica — por exemplo, para garantir que um cluster AKS no Brazil South sempre puxe da réplica local.
Como começar?
Habilitar em um registry existente:
az acr update -n myregistry -g myrg --regional-endpoints enabled
Ver URLs de todos os endpoints:
az acr show-endpoints --name myregistry --resource-group myrg
Casos de uso práticos
Pin de clusters AKS a réplicas locais
Use a URL regional diretamente no deployment manifest:
# East US
image: myregistry.eastus.geo.azurecr.io/myapp:v1
# West Europe
image: myregistry.westeurope.geo.azurecr.io/myapp:v1
CI/CD com consistência
Em pipelines que fazem push e depois pull, fixar o push ao endpoint regional evita race conditions de eventual consistency.
Failover client-side
Você pode implementar sua própria lógica de health check e alternar entre endpoints regionais conforme necessário.
Quando usar cada endpoint?
| Cenário | Ação |
|---|---|
| Workloads comuns | Continue usando o endpoint global com failover automático |
| Pin de AKS | Use URLs regionais nos manifests |
| CI/CD push-then-pull | Fixe push ao endpoint regional |
| Failover client-side | Alterne entre regionais com base em health checks próprios |
| Capacity planning | Distribua carga entre regionais para evitar throttling por réplica |
| Troubleshooting | Mire uma réplica específica para isolar problemas |
O que mudou da private preview para a public preview?
| Private Preview | Public Preview |
|---|---|
| Registro de feature flag necessário | Sem registro |
Extensão CLI separada (acrregionalendpoint) |
Nativo no Azure CLI 2.86.0+ |
| Sem flag de registry | az acr update --regional-endpoints enabled |
--region-endpoint-enabled (confuso) |
Renomeado para --global-endpoint-routing |
| Sem suporte no portal | Suporte nativo no portal |
| Documentação no GitHub | Documentação completa no MS Learn |
Se você estava na private preview
- Remova a extensão CLI:
az extension remove --name acrregionalendpoint - Atualize o Azure CLI para 2.86.0+
- Atualize scripts: substitua
--region-endpoint-enabledpor--global-endpoint-routing
Perguntas Frequentes
-
Preciso desabilitar o endpoint global para usar os regionais?
Não. Os endpoints regionais coexistem com o endpoint global (myregistry.azurecr.io). Você pode escolher por workload: usar o global com failover automático gerenciado pela Azure ou um regional quando precisar de controle explícito sobre a réplica. -
Como os endpoints regionais afetam a consistência de imagens entre réplicas?
Imagens enviadas via endpoint regional ainda são propagadas para todas as outras réplicas sob eventual consistency. Por isso, para cenários de push-then-pull em CI/CD, é recomendado fixar o push a um endpoint regional para evitar race conditions. -
Quais SKUs do ACR suportam endpoints regionais?
A feature está disponível apenas para registries no SKU Premium, em todas as regiões públicas da Azure. Não há suporte para SKUs Basic ou Standard. -
O que mudou no CLI em relação à private preview?
A extensão separada acrregionalendpoint foi removida; os comandos agora são nativos no Azure CLI 2.86.0+. O flag --region-endpoint-enabled foi renomeado para --global-endpoint-routing, e o novo flag --regional-endpoints (no az acr create/update) controla a feature em nível de registry. -
Como usar endpoints regionais com clusters AKS no Brasil?
Basta especificar a URL regional no manifest do deployment, por exemplo, myregistry.brazilsouth.geo.azurecr.io. Isso garante que o cluster sempre puxe da réplica local, reduzindo latência e tráfego cross-region.
Artigo originalmente publicado por Johnson Shi, Zoey Li, Huangli Wu em Azure Updates - Latest from Azure Charts.
