In this article we will talk about the most important services that help us to create a better network over Azure infrastructure. I assume that you already know the base concepts of cloud.
The 3 services that are falling in this category are:
We will take each service separately and talk more about each of them.
Traffic Manager allows us to distribute traffic to different endpoints. Endpoints can be on different datacenters. From some perspectives, we can look at Traffic Manager like a Load Balancer at global level. In this way, we can deploy a solution to multiple datacenters and redirect traffic based on user location.
Traffic Manager checks the endpoint status at a specific time interval. If 4 times in a row the endpoint is down, the endpoint will be marked as down and traffic will not be redirected to that endpoint anymore. Users that already know about that endpoint will still try to connect to that endpoint until the DNS cache expires (DNS TTL).
Used only as DNS Resolver
Traffic Manager is used only to resolve the endpoint address. Once the endpoint is resolved, the request will go directly to the endpoint and will not pass through traffic manager.
Traffic Manager DNS Name
Each Traffic Manager instance will have its own DNS name. We will register this DNS in behind our real DNS if we want to redirect traffic from our site (www.foo.com) through Traffic Manger.
Configuration Tools
We can configure it using Power Shell, REST API or Management Portal. All the features are available from each tool.
DNS TTL
We can specify how long the name of the DNS that is resolved by Traffic Manager will be cached by our clients.
Load Balancing Method
There are 3 types of load balancing supported in this moment:
Endpoints Weight
Each endpoint can have a specific weight that will be used by Traffic Manager for traffic distribution. Bigger values means that that endpoint can receive more traffic. It is used by Round Robin load balancing methods (this can be configured only from PowerShell or REST API).
Custom monitor endpoint
Traffic Manager allows us to specify what endpoint to monitor. We can use HTTP/HTTPS endpoints. We can also specify a custom port and path. For all endpoints, the same monitor endpoint will be used.
Profiles
A Traffic Manager profile represents all the configuration for a specific node.
Nested Profiles
Traffic Manager allows us to specify another traffic endpoint. In this way, we can define complex failover profiles and we can manage different load balancing rules.
Real DNS
Traffic Manager can be used by your own domain DNS. Your DNS needs to point to Traffic Manager DNS.
Endpoints location
All endpoints need to be from the same subscription. You cannot use it with external endpoints.
Redirect user based on location
Users will be redirected to the closest endpoint. In this way clients can reach the endpoint that is in the best shape and the closest to them.
Automatic Failover
Traffic Manager is able to automatically switch to another endpoint when the original one is down.
Test new deployments
We can very easily add endpoints with different configuration or different version of our application and check the behavior of them (testing the surface with new features).
Reduce Application Downtime
Traffic Manager allows us to switch automatically to a healthy endpoint if the original one is down.
Distribute traffic on multiple locations
Being able to register multiple endpoints from different datacenters, the traffic will be distributed to the closest endpoint (based on response time or other configuration – depending on what load balancing method we selected).
Not all Azure Services Supported
You cannot include in Traffic Manager services like Service Bus, SQL Azure or Storage. In general you don’t want to do something like this.
External Endpoints are not supported
You are not allowed to monitor external endpoints (from on-premises or from other Azure Subscriptions)
Monitor Configuration
You don’t have access to monitor configuration. Clients cannot set up how often the health of endpoints is checked.
Next, you can find 3 use cases where I would use Traffic Manager.
Web Sites deployed in multiple data centers
If you have a web site that is deployed in multiple data centers, the load balancing of traffic can be made easily by using Traffic Manager. If the load of a web site increases or is down, the traffic will be redirected automatically to another endpoint.
Uniform load distribution
When you have a system that is distributed in different data centers and you have a custom rule to specify if an endpoint can accept new clients or not, you can use Traffic Manager with success. You should implement the url path that is used to check the endpoint health to return a HTTP error code different from 200 OK if the current endpoint cannot accept new clients anymore.
Web sites failover
You can use traffic manager only as a failover mechanism for your web sites and configure the last failover endpoint from Traffic Manager to return only a simple HTTP page. In this way, even if your system is down, clients will be able to see something ‘nice’.
Pros
Cons
When you calculate the cost of using Traffic Manager in your system you should take into account:
Express Routes is a private connection between your network (on-premises) and Azure Data Centers. When using this feature, you have a direct connection with Azure Data Centers, which is not shared with other users.
Because of this, a connection like this is not only fast but it is also extremely secure. All traffic from clients that use this feature is split in two ‘channels’. One channel is used for traffic that hits Azure public services and the second one for traffic that hits Azure Compute resources. For each of these channels (Direct Layer 3 and Layer 3), there are different speeds that are guaranteed.
Express Routes is a private connection between your network (on-premises) and Azure Data Centers. When using this feature, you have a direct connection with Azure Data Centers, which is not shared with other users. Because of this, a connection like this is not only fast but it is also extremely secure. All traffic from clients that use this feature is split in two ‘channels’. One channel is used for traffic that hits Azure public services and the second one for traffic that hits Azure Compute resources. For each of these channels (Direct Layer 3 and Layer 3), there are different speeds that are guaranteed.
Not over public Internet
Connections that are made over Express Route are going over a private connection that is not connected to the ‘known internet’.
More secure
Data that are sent over the wire are more secure because the connection is over a private wire that cannot be accessed by public users.
Faster speed
The speeds that are offered over this connection are higher and the bandwidth is dedicated to you.
Lower latency
The direct connection between you and Azure data center reduces the latency that normally exists between two endpoints.
Bandwidth Available
There are different options of bandwidth that are available from 10 Mbps and goes to 10 Gbsp.
Connection Redundancy
Yes, we even have connection redundancy. Layer 3 Connectivity (over Network Service Providers) can have a redundant connection (Active connection).
Easy migration from S2S and P2S
If you already use Site to Site or Point to Site and want to migrate to Express Route you will discover that migration can be made very easily.
Virtual networks
All virtual networks that are connected to the same Express Route can talk with each other. You will be able to connect virtual networks from different subscriptions as long as all of them are connected to the same express route.
All Virtual Networks connected to the same Express Route are part from the same routing domain and are not isolated between them. If you need isolation between them, than you will need to create different express routes for each of them.
Number of routes
In this moment there is a limit up to 4.000 routes for public peering and 3.000 routes for private peering.
S2S or P2S cannot be used in combination with Express Route.
You cannot use both methods to connect to Azure infrastructure. If you use Express Route, you will not be able to use S2S or P2S for the same connection.
Multiple Providers
Each Express Route can be associated with only one provider. Because of this, you cannot associate the same Express Route with multiple providers.
VLANs to Azure Express Route
Layer 2 connectivity extensions to Azure are not supported.
Below you can find 4 use cases when Express Route can be used with success:
Video Streaming
When you are using Azure Media Services for video streaming, you will want to be able to stream live content to Azure Media Services all the time. In this case you need a stable connection between your studios and Azure Data Centers. Express Route can be a good option for you.
Monitor and Support
If your infrastructure and services are on Azure, than you will need at monitor and support phase an Express Connection between you and Azure. Support team needs to be able to access your Azure services in a fast and reliable way.
Data Storage
When you are using Azure Storage or SQL Azure to store your data, you will also want a low latency and fast connection between your data and your on-premises infrastructure. Express Routes can be a solution for this problem.
Bank data privacy
If you are a bank and need a secure connection between on-premises sites and your Azure services, Express Route can be a very good solution. Using it, you will have a secure connection that cannot be accessed from internet.
Pros
Cons
The pricing is based on outbound traffic. A part of outbound is free, included in subscription. Exceeding it, you will be charged with a small rate per GB. The included data transfer traffic may differ based on Exchange provider port speed that you prefer to use.
A Virtual Network is a ‘private’ network that you can define over Azure infrastructure. In each Virtual Network users have the ability to add Azure services and VM that they want and need.
Only VMs and Azure services from the same Virtual Network can see each other. By default, external resources cannot access resources from Virtual Network. Of course, users have the ability to configure a Virtual Network to be accessed from the outside world (if needed).
We can imagine a Virtual Network as a private network that we create at home or at work. We can add to it any resources, allocate specific IPs and subnet masks, open different ports for external access and so on. It is a network inside a network, if we could say this. Many times I refer to it as a Private Network, because you can add resources to it and limit access of external resources to it.
It isolates resources from public access
Using Virtual Networks you can create your own private corner in Azure, where only you have access to it. All your resources are isolated from the rest of Azure.
3 type of models
In general, there are 3 types of configuration used with Virtual Networks:
Cross-Premises Connection
In use cases when you need to connect your on-premises solution to Azure resources, than Virtual Network is a must and you need to think about it from the first moment.
Resource Name Resolution
Once you integrate your network with a Virtual Network you can access your resources directly by their DNS name (for example Virtual Machine name).
Automatic integration scripts
When you create a Virtual Network, Azure can generate your custom scripts that need to be run by IT on your on-premises network. Using these scripts, the two networks can become one network without additional configuration.
Custom IP range and Subnet Mask
When creating a Virtual Network you have the ability to set a custom IP range and subnet mask. You can create your own configuration based on your own needs and network requirements.
Persistent Private IP Address
In the Virtual Network resources will have a static IP that doesn’t change in time. For example, a VM will have the same IP and it will not change. On top of this, you can assign a specific IP to your resources by hand from your Virtual Network IP range.
Azure Resources Supported
At the moment, only Virtual Machines and PaaS resources can be added to a Virtual Network. Resources like Service Bus cannot be added to a Virtual Network (yet).
Tools that can be used
For setup and configuration we have two tools that can be used:
Subnet Masks Limitation
You can define the number of subnets, as long as they don’t overlap. The same rules are applicable for any network (from on-premises or cloud).
IP Type and Ranges
Virtual Network allows us to use any kind of IP, from public IP Address to any kind of IP ranges.
Type of Network
Virtual Network is a Layer 3 network that is responsible for package forwarding and routing.
Supported Protocols
There are 3 types of protocols that are supported in this moment:
VPNs
VPN connections are supported (RRAS – Remote Access servers and Windows Server 2012 Routing).
Linux Support
All Linux distribution that are supported on Azure can be used in a Virtual Network.
You cannot move resources to a Virtual Network once they were created
Once a resource like a Virtual Machine was created and deployed, you cannot move it to a Virtual Network. This is happening because network information is acquired during deployment. Of course, you can redeploy your machine, but a short downtime will appear.
VPN is limited only to Windows OS
You can use VPN only for Windows OS (W7,W8, Windows Server 2008 R2 64b, Windows Server 2012)
It cannot be used with all Azure Services
At the moment, only Virtual Machines and PaaS resources can be added to a Virtual Network. Other types of services cannot be added to a Virtual Network.
Cross Region
A virtual region can be defined only in one region. If you want to create a cross region network you need to create multiple Virtual Networks and connect them.
Network Size
The smallest subnet network that is supported is /29 and the largest is a /8.
VLANs cannot be added
Because Virtual Network is a Layer 3 network, there is no support for VLANs (that operate at Layer 2).
Tracert
This network diagnostic tool cannot be used in a Virtual Network.
IPv6
At the moment there is no support of IPv6.
Broadcast
At the moment there is no support for packages broadcast.
Multicast
At the moment there is no support for multicast.
IP-in-IP encapsulated packets
At the moment this is not supported.
Generic Routing Encapsulation (GRE)
At the moment this is not supported.
SQL DB
At the moment SQL DBs cannot be used in combination with Virtual Networks.
Applicable Use Cases
Below you can find 4 use cases when I would use Virtual Network:
To isolate an application that contains multiple resources (like VM)
In this case you would like all your resources to be part of the same network and to be isolated from the external world.
To scale your on-premises resources
When you need more computing power resources (VMs) and you want to scale your on-premises resources in a secure and simple way, Virtual Network can create the secure environment to do something like this.
Hybrid Solutions
When your solution is hosted on-premises and also on cloud, Virtual Network can be used with success to unify the system and resources.
To connect to Azure VM in a secure way
If you want to access VM in a secure and reliable way from your own networks, than Virtual Network is a must.
Pros
Cons
When you calculate how much Virtual Networks would cost, you should take into consideration the fallowing components:
In this article, we have discovered different ways of managing the network layer for our applications that are hosted on Microsoft Azure. Based on your needs, you should take into account these services.
by Ovidiu Mățan
