Routing Access to Azure Services

Azure is part of the Microsoft Global Network. Applications in the Azure environment can receive access from the entire world. This world-wide access creates a dilemma about the routing to the Azure services. We face two options: routing through Microsoft Global Network or through public internet.

Initially only the Storage Accounts had a direct configuration about this routing access. Nowadays, we can configure the routing access in any Public Ip using Standard SKU.

 

This means that any service linked to a Public IP object defined in azure can have its routing preferences configured. This affects most IaaS features, such as virtual machines. However, load balancers and application gateways are also affected and they may be the front-end for PaaS services. Traffic Manager and Azure Front Door are some feature that allow us to manipulate these routing preference in an indirect way.

What the Routing Options mean

The routing options are called Microsoft Routing and Internet Routing. It’s about the way the access will be routed from the user to the Azure service.

When the communication starts on the user machine, the communication is starting outside Microsoft Global Network and will cross some ISPs hardware until it gets to the MS Global Network. How many routers outside Microsoft environment will be routing the packages of this communication?

That’s the difference the routing preference makes:

• Internet Routing will make the package get into the Microsoft Global Network from the closest possible point to the resource. In this way, the package will flow on the public internet most of the way until the destination.

• Microsoft Network will make the package get into the Microsoft Global Network from the closest possible point to the user. In this way, the package will flow inside Microsoft Global Network most of the way until the destination.

The Implications

The security implications are obvious. The most the package flows inside Microsoft Global Network, safer the package is. However, since we are given these options there must be something else to this choice.

There is: The networking price. There is a difference price for network packages that cross Azure regions and continents. This price will make the cost of the cloud higher.

The main question that everyone asks is: How higher?

You can see details about the difference of traffic across regions and continents on this link: https://azure.microsoft.com/en-us/pricing/details/bandwidth/

 

A good way to summarize this link is by highlighting the difference of the traffic from South America to other regions when your service is located in South America. If you move 10 TB every month, it would cost you around us$ 1,200.00 if you are using internet routing but around us$ 1,800.00 if you are using Microsoft routing.

Mind these highlights about this example:

•  South America is the most expensive region in relation to trafic and the one with the biggest difference between Internet and Microsoft routing
• 10 TB is huge amount of data. Consider many ways your application may avoid such huge traffic, like using CDN and other cache features. Most solutions will not reach this amount of traffic.
• The price drops after 10 TB/month

In my humble opinion, the price difference is insignificant to make someone choose internet routing instead of Microsoft routing.

Indirect routing Management

Besides services linked with public Ip and the Azure Storage, we can indirect manage this routing problem by using Azure Front Door or Azure Traffic Manager. These two load balancers are DNS based solutions distributed globally. Wherever the user is in the globe, it will reach the endpoints of these services from the closest Microsoft network endpoint possible. After that, the rules of these load balancers take place and decide what service in our company global virtual network will provide the end user service.

It’s a choice to use or not these load balancers and to distribute or not our services around the globe. If we choose not to, the user packages will need to reach the physical place of our application, whatever region we choose for it. Using these tools, on the other hand, we have the option to redirect the traffic to the application server we provisioned closest to the user.

 

References

https://docs.microsoft.com/en-us/azure/virtual-network/ip-services/routing-preference-overview

The post Routing Access to Azure Services appeared first on Simple Talk.

from Simple Talk https://ift.tt/3GiHpbL
via