One of the requirements that continuously pop up when you're working on securing your Azure workloads is to remove public access from as many resources, as much as possible. The first crossroads you will find is when you're presented with the option of using service endpoints or private endpoints.
If you're stuck on which is better, don't fret; both options are significant from a security standpoint. If we stop here, the main difference is that service endpoints are configured to allow traffic from a VNET, while private endpoints assign a private IP address to that resource.
This is not a chicken or egg problem; the feature that came first was service endpoints, which resolved many security concerns. In the past, everything you created in Azure was publicly exposed without a solution to block it in any way or form in case of a leaked credential.
So which option is better? Let's first start with the basics and then decide.
Service Endpoints
Service endpoints are a feature for PaaS offerings in Azure that allows you to configure the resource to allow only traffic from a specific VNET(s). This will enable you to eliminate access to the public IP interface from unauthorized endpoints. Service Endpoints are configured on the network blade of the resource where you scope on which VNETS traffic should be allowed.
By enabling this feature, you don't eliminate the public interface of the resource but more like putting a firewall in front of it, which has a deny-all rule except for the configured VNET.
Private Endpoints
Private Endpoints, as Service Endpoints, are a feature for PaaS offering in Azure that allows you to assign a private IP address to a resource; thus "eliminating" the public interface from the resource and allowing you to configure other resources to communicate only privately with it.
Private Endpoints can be used for PaaS and IaaS resources, unlike Service Endpoints. When you create a Private Endpoint, a network interface is made in your virtual network with a private IP address and a Private DNS Zone configured with an entry pointing to that resource. This network interface is then mapped to the resource, which enables the resource to be accessed privately.
Once everything is set up, you can access those PaaS resources from anywhere connected to that VNET.
Which should I choose?
From a security standpoint, both options - Service Endpoints and Private Endpoints - are excellent choices. However, the choice depends on the specific security requirements of the organization. If an organization needs to comply with strict security needs that require rigorous access controls, Private Endpoints are a better solution. Private Endpoints eliminate public access to resources by assigning them a private IP address, ensuring that they can only be accessed from within a specific or peered virtual network.
However, going the Private Endpoint route comes with additional costs and configuration complexity. While configuring Service Endpoints is as simple as specifying the VNET from where traffic should be allowed, Private Endpoint configuration requires the deployment of a NIC, DNS Zone, and Private IP in a specific VNET. This involves ingress and egress costs that could add to a large workload. Therefore, it's essential to consider the cost implications when deciding between Service Endpoints and Private Endpoints.
Besides security and cost implications, Private Endpoints offer advanced architectural possibilities, especially when creating a hub and spoke VNETs. By creating a routable private IP address in a VNET, resources can be accessed from on-premises and peered VNETs. This makes it easier to create complex network architectures that are secure and efficient and, of course, assist with achieving specific compliance certifications.
Based on what I wrote above, I inclined more toward Private Endpoints than Service Endpoints, which is different. I prefer more straightforward solutions and add complexity if the business needs require it.
I generally go with Service Endpoints because it's quite an easy switch to turn on and get instant security benefits. When we need to expand to more complex solutions, we can consider Private Endpoints.
While Private Endpoints provide an additional layer of security and architectural possibilities, they are only sometimes necessary or suitable for some workloads. It's essential to carefully evaluate the security requirements and architecture of the workload before deciding on either solution. In some cases, deploying Private Endpoints may add unnecessary complexity to the architecture, making it harder to manage and troubleshoot.
Now if you have one or the other, why not both? Not all systems require a private IP address, so you can always mix them to make a comprehensive architecture.
The main idea here is that you're not obligated to go forward and plan for everything from starters and identify what is a must at that moment and then expand. This approach allows you to prepare for your security needs incrementally rather than trying to identify and plan for everything from the start.
That being said, both should be used unless a specific requirement should be satisfied. I would start with Service Endpoints and then migrate toward Private Endpoints if needed. It's even easier to add to Terraform configurations, but that's a topic for another time.
Have a good one!
