Azure Container Registry - Clarification on Service Endpoint vs Private Endpoint use cases

Question

Azure Container Registry - Clarification on Service Endpoint vs Private Endpoint use cases

Nassim Cherifi 75

Hello,

We would like to clarify the recommended architecture for accessing an Azure Container Registry (ACR) in our environment, specifically regarding the use of a Private Endpoint vs. a Service Endpoint.

Current configuration

We currently have an Azure Container Registry configured with:

A Private Endpoint deployed in a centralized VNet.
The ACR firewall is currently configured with “Enabled from all networks”.
Multiple Azure subscriptions/VNets consume this ACR.
The Private Endpoint is centralized so that all consuming VNets access the registry through this central VNet.
As a result, traffic to the ACR Private Endpoint traverses at least two VNet peerings and an Azure Firewall before reaching the Private Endpoint.
The ACR currently handles approximately 2 TB of traffic per day.

The main consumers of the registry are known, and they are all located within Azure.

We do not currently have any requirement for access to the ACR from outside Azure, such as on-premises environments or another cloud provider.

Our question

We would like Microsoft to clarify the recommended use cases for a Private Endpoint versus a Service Endpoint for this type of architecture.

Given that all our current consumers are Azure VNets and that we do not require access from on-premises or other CSPs, would it be a valid architecture to:

Remove the centralized Private Endpoint.
Enable the appropriate Service Endpoint on the consuming VNets/subnets.
Configure the ACR network access accordingly, restricting access to the required VNets/subnets.

In other words, for this specific use case, would a Service Endpoint be sufficient and potentially more appropriate than maintaining a centralized Private Endpoint?

We are particularly interested in understanding whether there are any functional, security, scalability, or performance considerations that would make a Private Endpoint preferable in this scenario.

Performance consideration

We have occasionally received reports of latency when accessing the ACR.

We do not currently have evidence that the Private Endpoint itself is the cause, but given the current architecture and the approximately 2 TB/day traffic volume, we are wondering whether traffic concentration through a centralized Private Endpoint, combined with the additional VNet peering and Azure Firewall hops, could contribute to latency under certain traffic conditions.

Could you please clarify:

Whether Microsoft recommends centralizing an ACR Private Endpoint when it is consumed by multiple VNets/subscriptions.
Whether using Service Endpoints directly from the consuming VNets would be a recommended alternative in our scenario.
Whether there are any specific limitations or features that we would lose by moving from Private Endpoint to Service Endpoint.
Whether the approximately 2 TB/day traffic volume should influence the choice between these two approaches.

We would appreciate your guidance on the recommended architecture and the relevant use cases for each option.

Thank you.

0 comments

2 answers

Your answer

Answer 1

Welcome to Microsoft Q&A,

@Nassim Cherifi I hope you are doing well,

Yes, a Service Endpoint can be a valid option for your scenario if the consumers are supported Azure VMs or AKS clusters and your ACR is Premium. Service endpoints restrict access to the ACR public endpoint to selected VNets/subnets. However, Microsoft recommends Private Endpoints instead of Service Endpoints in most network scenarios.

The main considerations are:

Private Endpoint: provides private IP connectivity and allows you to disable public network access. It is also suitable if private access from on-premises through VPN/ExpressRoute is required.

Service Endpoint: keeps the ACR public endpoint but restricts access to selected VNets/subnets. It is currently Preview, requires Premium, and supports only Azure VM and AKS hosts.

ACR doesn't support configuring both Private Link and Service Endpoint access from the same VNet.

Microsoft does not document a performance advantage based on traffic volume such as 2 TB/day, so I wouldn't attribute the reported latency to the centralized Private Endpoint without network measurements.

Given your architecture, Service Endpoints could technically fit, but I would evaluate the Preview limitations and the additional peering/Firewall path before replacing the existing Private Endpoint.

References:

https://learn.microsoft.com/en-us/azure/container-registry/container-registry-vnet

https://learn.microsoft.com/en-us/azure/container-registry/container-registry-private-link

https://learn.microsoft.com/en-us/azure/container-registry/container-registry-skus

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

Answer 2

For this scenario, a service endpoint is a valid option, but the documented recommendation is to use private endpoints in most network scenarios.

Key documented differences:

Microsoft recommendation
- Azure Container Registry recommends private endpoints instead of service endpoints in most network scenarios.
- ACR does not support having both configured from a virtual network at the same time. If moving to service endpoints, private link access from VNets must be removed accordingly.
When private endpoints are preferable
- Private endpoints provide access to ACR over private IP addresses inside the VNet.
- They also support private access from on-premises through ExpressRoute, private peering, or VPN gateway.
- If public network access is disabled, private endpoints allow the registry and its dedicated data endpoints to be reachable only through the private endpoint.
- Private endpoints are described as the most secure way to control network access from clients in a virtual network.
When service endpoints can fit
- Service endpoints secure the registry’s public IP address so that only selected VNets/subnets can access it over the Azure backbone.
- For an Azure-only consumer base where access is limited to known VNets/subnets, this model can fit the stated requirement.
- Service endpoints for ACR are available only on the Premium SKU.
- Each Premium registry supports a maximum of 100 virtual network rules.
Functional limitations if moving to service endpoints
- Service endpoints for ACR are currently preview.
- Only an AKS cluster or Azure VM can be used as a host to access ACR by using a service endpoint. Other Azure services, including Azure Container Instances, aren’t supported.
- Service endpoints for ACR can’t be configured in the Azure portal.
- Service endpoints aren’t supported in Azure US Government or Azure operated by 21Vianet.
Functional considerations if staying with private endpoints
- If public network access is disabled and private endpoints are used, some functionality changes:
  - Certain trusted services require enabling a bypass setting.
  - Azure DevOps Services can’t access the registry once public network access is disabled.
  - Private endpoints aren’t supported with agents managed by Azure DevOps; a self-hosted agent with network line of sight is required.
  - Repositories and tags can’t be listed from outside the virtual network by Azure portal, Azure CLI, or other tools.
Scale limits
- Private endpoints: maximum 200 private endpoints per Premium registry.
- Service endpoints: maximum 100 virtual network rules per Premium registry.

For the proposed architecture change:

Yes, using service endpoints directly from the consuming VNets/subnets is supported for ACR if the consumers are compatible hosts and the registry is Premium.
Yes, removing the centralized private endpoint and restricting ACR to the required VNets/subnets through service endpoint rules is consistent with the documented service-endpoint model.
No, private link and service endpoint access should not be kept together for the same VNet-based access path.

For the centralization question:

The documentation supports creating private endpoints in VNets and describes subnet/IP planning, but it does not state that centralizing one ACR private endpoint for many VNets is a recommended architecture.
The documentation also does not provide performance guidance tied to traffic volume such as 2 TB/day, VNet peering count, or Azure Firewall traversal.
Because of that, no documented conclusion can be made here that the private endpoint itself, or the centralized topology, is the cause of latency.

Practical decision based on the documented guidance:

Choose private endpoints when the priority is strongest network isolation, private IP-based access, or future need for private access from on-premises/VPN/ExpressRoute.
Choose service endpoints when Azure-only consumers on supported hosts need access through selected VNets/subnets and the preview limitations are acceptable.

In this specific case, the strongest documented reason to keep private endpoints is security and private IP-based access. The strongest documented reason to consider service endpoints is that the consumers are Azure VNets only and service endpoints can restrict access to selected VNets/subnets over the Azure backbone. The documentation does not establish a performance advantage for either option in the described 2 TB/day topology.

References: