Following a deep dive into Azure endpoints, I found it interesting that there is a misconception about the primary uses (and any secondary uses) of Azure Private Endpoints. They seem to be used when a Service Endpoint is perfectly suitable (and free) to use. I have lightly written this up as a reminder for me in future and if it's helpful to anyone else.
The following is broken up between Public, Private and Service endpoints. I'll try and capture the primary use case for each, the pros and cons and anything further of interest. As this topic is vast, there are bound to be a few things not covered, but I shall intend to keep this topic updated as and when its helpful to do so.
https://www.youtube.com/watch?v=4v-9zGHxVeI
Traffic is routed over the internet, using public IP endpoints.
When to use Public Endpoints:
When secure but public, internet routing isn't an issue for either direct to Storage accounts or via VNET components.
Pros
1. Simple solution
2. Storage account options to control networking connection type (TLS version) and source access via Firewalls and virtual networks (public internet, VNETs)
3. No additional costs
Cons
1. Traffic routed over public internet (if this is an issue)
Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. You can think of this as a new virtual network card on the PaaS component (e.g. Storage account), which is then assigned to the VNET/Subnet. This addresses the main exam question of accessing an Azure PaaS component DIRECTLY via Express Route or Site-To-Site VPN and not having to target the public IP endpoint. A service endpoint doesn't solve this problem.
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview
When to use Private Endpoints:
When non-public internet access is required to an Azure PaaS component via express route or S2S VPN. Other uses are possible, but a standard Service Endpoint should be considered as a Private Endpoint is likely overkill for a non-express route or S2S VPN use case.
Pros
1. Private address used
2. No public internet traffic or public IP is present
3. Optional data exfiltration, locking private access directly to the storage account instance, preventing communications with other instances
Cons
1. Dependant on the scenario, the setup can be significantly more involved than service endpoints*
2. Charges per hour, inbound traffic and outbound traffic
3. NSG is not supported on private endpoints
4. Targets a specific use case
5. Each storage account (and type) needs its own private endpoint
*It's important to correctly configure your DNS settings to resolve the private endpoint IP address to the fully qualified domain name (FQDN) of the connection string. Existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This configuration must be overridden to connect using your private endpoint.
See https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
Virtual network rule(s) can secure the Azure service resources to your virtual network. The rule addition provides improved security by fully removing public internet access to resources and allowing traffic only from your virtual network.
When the service endpoint is enabled for storage accounts, the identity of the virtual network will be made available to the storage account(s). All source IPs from the
VNET/Subnet(s) will be private IPs.
When the VM connects to the storage account, the storage account knows which virtual network and subnet the request has come from. The VM IP visible to the storage account will be the private IP address and not the public IP. The VM still believes it is connecting to the storage account's public IP, but the traffic never leaves the Azure backbone. i.e. private IP is used
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
https://www.youtube.com/watch?v=q8s-zmHighs
When to use Service Endpoint:
When restricted or non-public internet access is required to an Azure PaaS component from an existing VNET
Pros
1. Simple set-up
a.create service endpoint on VNET/Subnet(s)
b.Limit storage account network access to the same VNET/subnet(s)
2. No additional costs
3. Public address continued to be used, although Azure routing uses internal backbone*
4. No public internet traffic, by configuring PaaS service firewall rules
Cons
1. Public address exists, although unusable
2. Any existing public IP firewall rules will need to be reconfigured
*Please note that no changes are required to the requesting PaaS component as this continues to use the public endpoint FQDN. Azure returns the private IP rather than the public IP, knowing that a service endpoint is in use.