Azure Subnet

A subnet is defined by a range of IP addresses in CIDR notation, which is used to allocate IP addresses to resources in the subnet. Subnets can be used to group resources together based on their functionality or security requirements, such as placing web servers in one subnet and database servers in another.

Subnet Address Range

In Azure, the address range of a subnet is defined by a CIDR notation which is used to allocate IP addresses to resources in the subnet, and it can be customized to meet specific requirements for grouping resources together and isolating traffic. You can see a deeper explanation on the page referenced below.

Azure Subnet Design

Service Endpoints

Azure Service Endpoints provide a way to extend a virtual network’s private address space and identity to specific Azure services, such as Azure Storage or Azure SQL Database. By using Service Endpoints, you can keep your traffic within the Azure network, which provides a more secure and optimized connection to the service.

By default, if you have a VM in a subnet that needs to communicate with a storage account, the traffic would leave the VM, go over the Internet, and then reach the storage account. This traffic would be vulnerable to interception and data leakage.

However, suppose you enable service endpoints for Azure Storage on the subnet where the VM is located. In that case, the traffic between the VM and the storage account will be routed through a private, optimized path within Azure’s network rather than over the public Internet. This provides additional security for your data and reduces the risk of interception or data leakage.

Enabling service endpoints for Azure Storage can help improve your Azure resources’ performance and security by keeping the traffic within Azure’s network and reducing latency.

Using Service Endpoints can also improve performance and reduce data transfer costs since traffic to the service is optimized and routed over the Azure backbone network instead of the Internet. Additionally, Service Endpoints can be used with network security groups (NSGs) to secure traffic to the service further.

To use Service Endpoints, you must configure them on a subnet in your virtual network. Service Endpoints are available for Azure services, including Azure Storage, Azure SQL Database, Azure Cosmos DB, and many more. You can configure Service Endpoints using the Azure portal, Azure PowerShell, or the Azure CLI.

Service Endpoint Policy

By default, when you enable Service Endpoints on a subnet, it allows traffic to all the resources of the Azure service associated with the endpoint, including all Storage Accounts in that service. However, creating an endpoint policy can restrict the Storage Accounts accessed from the subnet.

For example, you have two Storage Accounts, A and B, associated with the Azure service you’ve enabled Service Endpoints for. You can create an endpoint policy that allows traffic to Storage Account A but denies traffic to Storage Account B from the subnet. This means traffic from the subnet can only access Storage Account A and not Storage Account B.

Endpoint policies give you granular control over the resources accessed from your subnets, which is helpful for security and compliance.

This is an example of what the policy could look like in the Azure portal.

Subnet delegation

Azure subnet delegation is a feature in Microsoft Azure that allows you to delegate a specific subnet within a virtual network to a particular resource type. This delegation grants the service certain privileges and enables it to manage and control resources within that subnet.

By doing this, you can configure a specific subnet to be dedicated to a service, such as Azure Container Instances, Azure Kubernetes Service (AKS), or Azure Databricks, ensuring that the intended service exclusively uses the resources allocated to that subnet.

This provides better control over resource allocation and network traffic management and enhances the security of your Azure environment.

For example, with Azure Container Instances (ACI), you can enhance resource management and network traffic control if you create a dedicated subnet for ACI and delegate it to the Microsoft.ContainerInstance/containerGroups service, which grants ACI the permissions required to manage and control resources within that subnet.

Network Policy For Private Endpoints

The property on an Azure Subnet determines whether network policies are enforced on a private endpoint.

When a private endpoint is created in Azure, it creates a private IP address associated with a network interface. The private endpoint is then linked to a resource such as a storage account, virtual machine, or another service that can be accessed through a private connection.

By default, Azure applies network policies to private endpoints that control inbound and outbound traffic to and from the private endpoint. These policies, described below, can be used to restrict or allow access to specific services or resources in the network.

Allow traffic from all networks: This policy allows traffic to the private endpoint from any network.

Allow traffic to all services: This policy allows traffic to all services on the private endpoint.

Deny traffic from the Internet: This policy blocks all traffic to the private endpoint from the public internet.

You can modify these default policies by creating custom network security groups (NSGs) or by configuring custom routes in your virtual network. For example, if you want to restrict access to the private endpoint to a specific IP address range, you can create a custom NSG with an inbound security rule that allows traffic only from that range. Similarly, suppose you want to route traffic to the private endpoint through a specific network interface. In that case, you can configure custom routes in your virtual network to route traffic to the private endpoint through that interface.

Disabling network policies for private endpoints should be done with caution as it can increase the attack surface and reduce the security of the private endpoint. However, there may be situations where disabling network policies is necessary, such as:

Legacy applications or services that require unrestricted network access: Some legacy applications or services may not be designed to work with network policies and require unrestricted network access. In these cases, you may need to disable network policies to allow the application or service to function correctly.

Testing or troubleshooting: When testing or troubleshooting a private endpoint, you may need to temporarily disable network policies to diagnose connectivity issues or to test specific network configurations.

Connectivity to external networks or services: Private endpoints are designed to provide secure and private connectivity within an Azure virtual network. However, there may be situations where you need to connect to external networks or services that are not part of the virtual network. In these cases, you may need to disable network policies to allow traffic to flow to and from the external network or service.

It’s important to note that disabling network policies should only be done when necessary and for a limited period of time. When disabling network policies, you should carefully evaluate the risks and implement other security measures to compensate for the reduced security of the private endpoint. You should also monitor the private endpoint closely and re-enable network policies as soon as they are no longer required.