Comparisons between Azure Firewall and Traffic Manager.

Introduction: There are competing techniques available from Microsoft Azure all of which allow traffic between the Azure resource to be managed. This article discusses some of those options.

Description: There are two networking technologies to assist with this purpose that we evaluate here. They are Azure Firewall and traffic manager. A firewall is not just a virtual machine or a router, it is also offered as a Firewall-as-a-service. When it is in the form of a virtual machine or a router, it is referred to as a Network Virtual Appliance in the Azure parlance. The ability to deploy an NVA or a router is probably the most flexible way to manage traffic rules at the IP layer simply because it acts as a man-in-the-middle.  The traffic manager offers out-of-box capabilities but it is not the same as what an NVA can provide. This has the flip side that it might be overkill and more advanced than it needs to be. Azure Firewall provides a specialized service in this regard. It is a cloud-native security service that distinguishes it from a traditional NVA by offering its cloud-native security service as a stateful network and application-level service also known as firewall as a service. Firewalls can easily be configured with REST-based APIs.

 

The traffic manager supports six routing methods based on priority, weighted, performance, geographic, multi-value, and subnet. Only one method can be specified at any time. The weighted routing method serves very well for the purpose of simulating zone-down because it can use DNS and weights to divert traffic. The default weight is 1. The higher the weight, the more frequently that endpoint is used.  The status of an endpoint can reflect whether it is downgraded. Within a region, a nested traffic manager profile may be needed. The Internet latency tables will continually change, so assigning a higher weight to a diversion in all cases will help. All traffic managers have health monitoring and automatic failover of endpoints. 

Some services allow the virtual networks to be defined in terms of address range and prefix. By switching the virtual networks, the traffic handled by the service can be diverted.

For example,

            AzureCredentials credentials = SdkContext.AzureCredentialsFactory.FromServicePrincipal(clientId, clientSecret, tenantId, AzureEnvironment.AzureGlobalCloud);

 

            var azure = Azure

                .Configure()

                .WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)

                .Authenticate(credentials)

                .WithSubscription(subscriptionId);

 

            var cosmosClient = new CosmosDBManagementClient(credentials)

            {

                SubscriptionId = subscriptionId

            };

            var cosmosAccounts = await azure.CosmosDBAccounts.ListByResourceGroupAsync(resourceGroupName);

            foreach (var account in cosmosAccounts)

            {

                INetwork virtualNetwork = await azure.Networks.Define(account.Name)

                .WithRegion(account.Region)

                .WithNewResourceGroup(resourceGroupName)

                .WithAddressSpace(subNetRange)

                .DefineSubnet(subNetName)

                .WithAddressPrefix(subNetPrefix)

                .WithAccessFromService(ServiceEndpointType.MicrosoftAzureCosmosDB)

                .Attach()

                .CreateAsync();

               

                await account.Update().WithAutomaticFailoverEnabled(true)

                    .WithVirtualNetworkRule(virtualNetwork.Id, "zonedown", true)

                    .ApplyAsync();

            }