P
Preston_Romney
In this article
Microsoft Global Network
Default Public Access
Service Endpoints
Private Link
Internet Routing Preference
Azure Services and the solutions you deploy into Azure are connected to the Microsoft global wide-area network also known as the Microsoft Global Network or the Azure Backbone. There are a few different ways to connect to an Azure service from a subnet, depending on your requirements around securing access to these services. Your requirements should dictate which method you choose. There are some common misconceptions around connectivity, and the goal of this article is to provide some clarity around connecting to Azure Services. The three general methods of connectivity are:
Microsoft Global Network
Before we talk about the different connectivity methods, it’s important to understand the network in which Azure Services live. The Microsoft Global Backbone is a network that connects customers to Microsoft cloud services through trillions of requests and offers high availability, capacity, and flexibility. Microsoft uses a strategy to reduce latency and improve quality of service by using direct interconnections, edge nodes, and innovative software to route data as close as possible to customers and their services. By default, all connections to Azure Services are on the Azure Backbone and use what is called cold potato routing. This means that traffic destined to an Azure service will enter the Microsoft Global Network at an edge Point of Presence (POP) closest to the user. Alternatively, return traffic will exit the Microsoft Global Network at the edge POP closest to the user. This ensures that traffic spends most of its time on the Microsoft Global Network enjoying the following benefits:
Default Public Access
Having your Azure service publicly accessible can pose security risks and should be done with caution. Microsoft recommends instead leveraging Private Link for secure and private access to Azure services. However, there are some reasons for which you may need to leave your Azure service publicly accessible:
Default Public Access on the Microsoft Global Network
There exists a common misconception regarding the connectivity to an Azure service through its public IP address, which implies that traffic is compelled to traverse outside the Microsoft Global Network onto the public internet before reconnecting to the Azure service's public IP. This notion is inaccurate.
Upon creating a subnet, Azure establishes a default system route for the address prefix 0.0.0.0/0, setting the next hop to the internet. This route comes into play when there is outbound traffic that doesn't match any other route specified in the subnet's route table and thus exits the Azure backbone for the public internet. However, the Microsoft Global Network is smart enough to recognize public IP addresses affiliated with Azure services and ensure that traffic destined for these addresses remains confined within the Microsoft Global Network. As illustrated in Figure 1, when accessing a public Azure service like storage, the traffic stays on the Microsoft Global Network.
Figure 1 - Public access via Microsoft Global Network
Default Public Access Which Leaves the Microsoft Global Network
When you create a User Defined Route (UDR) within your subnet to override the default system route for the 0.0.0.0/0 prefix, as is typically done when using a Network Virtual Appliance (NVA), any traffic bound for unknown prefixes will be first routed to the NVA rather than being directed to the public internet. Overriding this system route also causes traffic destined for public Azure services to exit the Microsoft Global Network and traverse the public internet. The exception to this is when using Service Endpoints, which I will address further below. Figure 2 demonstrates traffic to a public Azure service such as storage after overriding the default system route.
Figure 2 - Public access via UDR
Service Endpoints
Employing Service Endpoints provides the capability to limit access to your public Azure service exclusively to designated Virtual Networks and specified IP addresses and ranges. These IP addresses and ranges may extend beyond the boundaries of the Microsoft Global Network.
Once Service Endpoints are enabled, the Azure service retains its public IP address, and data traffic stays within the Microsoft Global Network as it does with default public access. Although Service Endpoints offer enhanced security compared to the default public access method, Microsoft strongly advises the utilization of Private Link as the preferred option.
Service Endpoints on the Microsoft Global Network
By enabling Service Endpoints, you guarantee that traffic directed to your public Azure service remains confined within the Microsoft Global Network, even when you override the default system route 0.0.0.0/0. This distinction is exclusive to Service Endpoints, as overriding the default system route results in all other traffic to public Azure services leaving the Microsoft Global Network. As illustrated in Figure 3, you can observe how Service Endpoints maintain the traffic within the Microsoft Global Network, even in cases of overriding the default system route.
Figure 3 - Accessing public Azure services using Service Endpoints and UDR
Private Link
Leveraging Private Link enables you to connect with Azure services through a private IP address confined within your subnet via Private Endpoints. Moreover, you have the option to grant access to your Azure service for customers or partners by authorizing Private Endpoints in their respective subnets.
After enabling Private Link and its corresponding Private Endpoint, you can disable public access to the Azure service, effectively facilitating all communication through a private network. Nevertheless, there may be instances where it is preferable to maintain public access, such as during gradual migration processes or to support legacy integrations.
Private Link on the Microsoft Global Network
Just like default public access and Service Endpoints, traffic directed to Azure services via Private Link stays within the confines of the Microsoft Global Network. When it comes to Private Link traffic, overriding the 0.0.0.0/0 system route has no effect, as Private Endpoints exclusively employ Private IP addresses.
Figure 4 – Accessing an Azure service via Private Link
Internet Routing Preference
Several Azure services offer flexibility to modify how public traffic is routed via the Microsoft Global Network. As previously mentioned, the default routing approach is referred to as "cold potato," where traffic enters and exits the Microsoft Global Network at points of presence (POPs) closest to the client.
However, certain Azure services provide the option to associate the public IP with the routing preference "internet" instead of "Microsoft Global Network." When this setting is activated, the routing behavior for the public Azure service shifts to a "hot potato" approach, wherein traffic enters and exits the Microsoft Global Network at the nearest point to the Azure service itself. This results in traffic spending more time on the public internet and less time on the Azure backbone. Changing this routing preference does not impact traffic within the Microsoft Global Network. For example, traffic from a subnet to a public Azure service which is using the “internet” routing choice will still remain on the Azure backbone.
By choosing this routing option, you can make a trade-off between performance and cost, as data egress charges are reduced when using the "internet" routing choice. Additionally, this adjustment aligns with the default routing behavior of other cloud providers, which also use the "hot potato" approach.
Continue reading...
Microsoft Global Network
Default Public Access
Service Endpoints
Private Link
Internet Routing Preference
Azure Services and the solutions you deploy into Azure are connected to the Microsoft global wide-area network also known as the Microsoft Global Network or the Azure Backbone. There are a few different ways to connect to an Azure service from a subnet, depending on your requirements around securing access to these services. Your requirements should dictate which method you choose. There are some common misconceptions around connectivity, and the goal of this article is to provide some clarity around connecting to Azure Services. The three general methods of connectivity are:
- Default Public Access
- Service Endpoints
- Private Link
Microsoft Global Network
Before we talk about the different connectivity methods, it’s important to understand the network in which Azure Services live. The Microsoft Global Backbone is a network that connects customers to Microsoft cloud services through trillions of requests and offers high availability, capacity, and flexibility. Microsoft uses a strategy to reduce latency and improve quality of service by using direct interconnections, edge nodes, and innovative software to route data as close as possible to customers and their services. By default, all connections to Azure Services are on the Azure Backbone and use what is called cold potato routing. This means that traffic destined to an Azure service will enter the Microsoft Global Network at an edge Point of Presence (POP) closest to the user. Alternatively, return traffic will exit the Microsoft Global Network at the edge POP closest to the user. This ensures that traffic spends most of its time on the Microsoft Global Network enjoying the following benefits:
- Network Performance and Reliability: Microsoft enhances routes through which data traverse its worldwide network. This results in reduced latency, jitter, and packet loss, as well as enhanced throughput. Through direct interconnections, you get a higher quality of service compared to transit links, thanks to fewer intermediate stops, fewer involved parties, and superior network pathways.
- Data protection: The Microsoft global network ensures that customer data is encrypted and secured when it travels between datacenters and regions. This is done on the network hardware itself providing line rate encryption with no increase to latency.
- Scale: The Microsoft global network relies on software-defined networking (SDN) to centrally control and optimize the network infrastructure and traffic. This requires sophisticated software systems that can handle the enormous volume and complexity of data on the network. It also requires constant monitoring and updating to ensure network performance and reliability.
Default Public Access
Having your Azure service publicly accessible can pose security risks and should be done with caution. Microsoft recommends instead leveraging Private Link for secure and private access to Azure services. However, there are some reasons for which you may need to leave your Azure service publicly accessible:
- Legacy applications: If you have legacy applications that can’t be modified to use Private Link or Service Endpoints, you might need to connect to the resource over its public IP address until a migration can take place.
- Third-party applications: If you’re using a third-party application that doesn’t support Private Link or Service Endpoints, you might need to connect to the resource over its public IP address.
- Ease of access: Making your Azure service publicly accessible can make it easier for your customers to access it without requiring them to use a VPN or setting up a Private Endpoint.
Default Public Access on the Microsoft Global Network
There exists a common misconception regarding the connectivity to an Azure service through its public IP address, which implies that traffic is compelled to traverse outside the Microsoft Global Network onto the public internet before reconnecting to the Azure service's public IP. This notion is inaccurate.
Upon creating a subnet, Azure establishes a default system route for the address prefix 0.0.0.0/0, setting the next hop to the internet. This route comes into play when there is outbound traffic that doesn't match any other route specified in the subnet's route table and thus exits the Azure backbone for the public internet. However, the Microsoft Global Network is smart enough to recognize public IP addresses affiliated with Azure services and ensure that traffic destined for these addresses remains confined within the Microsoft Global Network. As illustrated in Figure 1, when accessing a public Azure service like storage, the traffic stays on the Microsoft Global Network.
Figure 1 - Public access via Microsoft Global Network
Default Public Access Which Leaves the Microsoft Global Network
When you create a User Defined Route (UDR) within your subnet to override the default system route for the 0.0.0.0/0 prefix, as is typically done when using a Network Virtual Appliance (NVA), any traffic bound for unknown prefixes will be first routed to the NVA rather than being directed to the public internet. Overriding this system route also causes traffic destined for public Azure services to exit the Microsoft Global Network and traverse the public internet. The exception to this is when using Service Endpoints, which I will address further below. Figure 2 demonstrates traffic to a public Azure service such as storage after overriding the default system route.
Figure 2 - Public access via UDR
Service Endpoints
Employing Service Endpoints provides the capability to limit access to your public Azure service exclusively to designated Virtual Networks and specified IP addresses and ranges. These IP addresses and ranges may extend beyond the boundaries of the Microsoft Global Network.
Once Service Endpoints are enabled, the Azure service retains its public IP address, and data traffic stays within the Microsoft Global Network as it does with default public access. Although Service Endpoints offer enhanced security compared to the default public access method, Microsoft strongly advises the utilization of Private Link as the preferred option.
Service Endpoints on the Microsoft Global Network
By enabling Service Endpoints, you guarantee that traffic directed to your public Azure service remains confined within the Microsoft Global Network, even when you override the default system route 0.0.0.0/0. This distinction is exclusive to Service Endpoints, as overriding the default system route results in all other traffic to public Azure services leaving the Microsoft Global Network. As illustrated in Figure 3, you can observe how Service Endpoints maintain the traffic within the Microsoft Global Network, even in cases of overriding the default system route.
Figure 3 - Accessing public Azure services using Service Endpoints and UDR
Private Link
Leveraging Private Link enables you to connect with Azure services through a private IP address confined within your subnet via Private Endpoints. Moreover, you have the option to grant access to your Azure service for customers or partners by authorizing Private Endpoints in their respective subnets.
After enabling Private Link and its corresponding Private Endpoint, you can disable public access to the Azure service, effectively facilitating all communication through a private network. Nevertheless, there may be instances where it is preferable to maintain public access, such as during gradual migration processes or to support legacy integrations.
Private Link on the Microsoft Global Network
Just like default public access and Service Endpoints, traffic directed to Azure services via Private Link stays within the confines of the Microsoft Global Network. When it comes to Private Link traffic, overriding the 0.0.0.0/0 system route has no effect, as Private Endpoints exclusively employ Private IP addresses.
Figure 4 – Accessing an Azure service via Private Link
Internet Routing Preference
Several Azure services offer flexibility to modify how public traffic is routed via the Microsoft Global Network. As previously mentioned, the default routing approach is referred to as "cold potato," where traffic enters and exits the Microsoft Global Network at points of presence (POPs) closest to the client.
However, certain Azure services provide the option to associate the public IP with the routing preference "internet" instead of "Microsoft Global Network." When this setting is activated, the routing behavior for the public Azure service shifts to a "hot potato" approach, wherein traffic enters and exits the Microsoft Global Network at the nearest point to the Azure service itself. This results in traffic spending more time on the public internet and less time on the Azure backbone. Changing this routing preference does not impact traffic within the Microsoft Global Network. For example, traffic from a subnet to a public Azure service which is using the “internet” routing choice will still remain on the Azure backbone.
By choosing this routing option, you can make a trade-off between performance and cost, as data egress charges are reduced when using the "internet" routing choice. Additionally, this adjustment aligns with the default routing behavior of other cloud providers, which also use the "hot potato" approach.
Continue reading...