Category Archives: Networking

Maximize the performance of Azure Stack HCI: discover the best configurations for networking

Hyperconverged infrastructure (HCI) are increasingly popular as they allow you to simplify the management of the IT environment, reduce costs and scale easily when needed. Azure Stack HCI is the Microsoft solution that allows you to create a hyper-converged infrastructure for the execution of workloads in an on-premises environment and which provides a strategic connection to various Azure services to modernize your IT infrastructure. Properly configuring Azure Stack HCI networking is critical to ensuring security, application reliability and performance. In this article, the fundamentals of configuring Azure Stack HCI networking are explored, learning more about available networking options and best practices for networking design and configuration.

There are different network models that you can take as a reference to design, deploy and configure Azure Stack HCI. The following paragraphs show the main aspects to consider in order to direct the possible implementation choices at the network level.

Number of nodes that make up the Azure Stack HCI cluster

A single Azure Stack HCI cluster can consist of a single node and can scale up to 16 nodes.

If the cluster consists of a single server at the physical level it is recommended to provide the following network components, also shown in the image:

  • single TOR switch (L2 or L3) for north-south traffic;
  • two-four teamed network ports to handle management and computational traffic connected to the switch;

Furthermore, optionally it is possible to provide the following components:

  • two RDMA NIC, useful if you plan to add a second server to the cluster to scale your setup;
  • a BMC card for remote management of the environment.

Figure 1 – Network architecture for an Azure Stack HCI cluster consisting of a single server

If your Azure Stack HCI cluster consists of two or more nodes you need to investigate the following parameters.

Need for Top-Of-Rack switches (TOR) and its level of redundancy

For Azure Stack HCI clusters consisting of two or more nodes, in production environment, the presence of two TOR switches is strongly recommended, so that we can tolerate communication disruptions regarding north-south traffic, in case of failure or maintenance of the single physical switch.

If the Azure Stack HCI cluster is made up of two nodes, you can avoid providing a switch connectivity for storage traffic.

Two-node configuration without TOR switch for storage communication

In an Azure Stack HCI cluster that consists of only two nodes, to reduce switch costs, perhaps going to use switches already in possession, storage RDMA NICs can be connected in full-mesh mode.

In certain scenarios, which include for example branch office, or laboratories, the following network model can be adopted which provides for a single TOR switch. By applying this pattern, you get cluster-wide fault tolerance, and is suitable if interruptions in north-south connectivity can be tolerated when the single physical switch fails or requires maintenance.

Figure 2 – Network architecture for an Azure Stack HCI cluster consisting of two servers, without storage switches and with a single TOR switch

Although the SDN services L3 are fully supported for this scheme, routing services such as BGP will need to be configured on the firewall device that sits on top of the TOR switch, if this does not support L3 services.

If you want to obtain greater fault tolerance for all network components, the following architecture can be provided, which provides two redundant TOR switches:

Figure 3 – Network architecture for an Azure Stack HCI cluster consisting of two servers, without storage switches and redundant TOR switches

The SDN services L3 are fully supported by this scheme. Routing services such as BGP can be configured directly on TOR switches if they support L3 services. Features related to network security do not require additional configuration for the firewall device, since they are implemented at the virtual network adapter level.

At the physical level, it is recommended to provide the following network components for each server:

  • two-four teamed network ports, to handle management and computational traffic, connected to the TOR switches;
  • two RDMA NICs in a full-mesh configuration for east-west traffic for storage. Each cluster node must have a redundant connection to the other cluster node;
  • as optional, a BMC card for remote management of the environment.

In both cases the following connectivities are required:

Networks Management and computational Storage BMC
Network speed At least 1 GBps,

10 GBps recommended

At least 10 GBps Tbd
Type of interface RJ45, SFP+ or SFP28 SFP+ or SFP28 RJ45
Ports and aggregation Twofour ports in teaming Two standalone ports One port

Two or more node configuration using TOR switches also for storage communication

When you expect an Azure Stack HCI cluster composed of more than two nodes or if you don't want to preclude the possibility of being able to easily add more nodes to the cluster, it is also necessary to merge the traffic concerning the storage from the TOR switches. In these scenarios, a configuration can be envisaged where dedicated network cards are maintained for storage traffic (non-converged), as shown in the following picture:

Figure 4 – Network architecture for an Azure Stack HCI cluster consisting of two or more servers, redundant TOR switches also used for storage traffic and non-converged configuration

At the physical level, it is recommended to provide the following network components for each server:

  • two teamed NICs to handle management and computational traffic. Each NIC is connected to a different TOR switch;
  • two RDMA NICs in standalone configuration. Each NIC is connected to a different TOR switch. SMB multi-channel functionality ensures path aggregation and fault tolerance;
  • as optional, a BMC card for remote management of the environment.

These are the connections provided:

Networks Management and computational Storage BMC
Network speed At least 1 GBps,

10 GBps recommended

At least 10 GBps Tbd
Type of interface RJ45, SFP+ or SFP28 SFP+ or SFP28 RJ45
Ports and aggregation Two ports in teaming Two standalone ports One port

Another possibility to consider is a "fully-converged" configuration of the network cards, as shown in the following image:

Figure 5 – Network architecture for an Azure Stack HCI cluster consisting of two or more servers, redundant TOR switches also used for storage traffic and fully-converged configuration

The latter solution is preferable when:

  • bandwidth requirements for north-south traffic do not require dedicated cards;
  • the physical ports of the switches are a small number;
  • you want to keep the costs of the solution low.

At the physical level, it is recommended to provide the following network components for each server:

  • two teamed RDMA NICs for traffic management, computational and storage. Each NIC is connected to a different TOR switch. SMB multi-channel functionality ensures path aggregation and fault tolerance;
  • as optional, a BMC card for remote management of the environment.

These are the connections provided:

Networks Management, computational and storage BMC
Network speed At least 10 GBps Tbd
Type of interface SFP+ or SFP28 RJ45
Ports and aggregation Two ports in teaming One port

SDN L3 services are fully supported by both of the above models. Routing services such as BGP can be configured directly on TOR switches if they support L3 services. Features related to network security do not require additional configuration for the firewall device, since they are implemented at the virtual network adapter level.

Type of traffic that must pass through the TOR switches

To choose the most suitable TOR switches it is necessary to evaluate the network traffic that will flow from these network devices, which can be divided into:

  • management traffic;
  • computational traffic (generated by the workloads hosted by the cluster), which can be divided into two categories:
    • standard traffic;
    • SDN traffic;
  • storage traffic.

Microsoft has recently changed its approach to this. In fact,, TOR switches are no longer required to meet every network requirement regarding various features, regardless of the type of traffic for which the switch is used. This allows you to have physical switches supported according to the type of traffic they carry and allows you to choose from a greater number of network devices at a lower cost, but always of quality.

In this document lists the required industry standards for specific network switch roles used in Azure Stack HCI implementations. These standards help ensure reliable communication between nodes in Azure Stack HCI clusters. In this section instead, the switch models supported by the various vendors are shown, based on the type of traffic expected.

Conclusions

Properly configuring Azure Stack HCI networking is critical to ensuring that hyper-converged infrastructure runs smoothly, ensuring security, optimum performance and reliability. This article covered the basics of configuring Azure Stack HCI networking, analyzing the available network options. The advice is to always carefully plan the networking aspects of Azure Stack HCI, choosing the most appropriate network option for your business needs and following implementation best practices.

The importance of a modern approach to networking and effective network governance in the cloud era

Networking is one of the pillars in the IT world, because it supports the infrastructure, allows the exchange of all the data necessary for the business, both inside and outside the company, and enables the creation and adoption of new solutions. You can easily understand how networking is a delicate area, complex and constantly evolving. However, what we are witnessing in many companies is the obstinacy to a traditional approach to networking that is now limiting and not very effective. This article lists the main challenges of a traditional approach to networking in the modern era and gives some suggestions for adopting a different approach and for structuring effective network governance.

The challenges of traditional networking in the modern era

Going into the merits of the main challenges that customers face every day in the networking field we find:

  • an increase in complexity and management effort: the rapid proliferation of cloud environments, of mobile devices and the IoT has effectively eroded the boundaries of modern networks, making them more difficult to manage and more vulnerable;
  • expansion of the attack surface: in this regard, the question to which it is advisable to be able to answer is «how is it possible to guarantee effective network protection without interfering with the growth and fluctuations of workloads in cloud and multi-cloud environments?»;
  • fragmented and inconsistent visibility and integration between local data centers and cloud environments: adding isolated monofunctional network products to deal with communication problems increases the complexity, IT staff costs and workload;
  • changes in branch office connectivity: the trend of corporate realities, geographically distributed, sees the replacement of expensive MPLS connections with more affordable direct Internet connections, but which do not always allow to reach the same levels of quality and performance.

All of this translates into specific critical points that I have encountered with our customers over time:

  • High costs and a lot of complexity
  • Many network solution vendors with poor integration
  • Too many alerts with slow and manual responses
  • Lack of properly trained internal IT personnel

Adopting a modern approach to networking

In the light of these considerations, it becomes essential to adopt a modern approach to networking able to better face all these challenges, going to reduce complexity and improve efficiency. Identify and implement network architectures designed for digital transformation must occur through:

  • A networking based on security which guarantees and speeds up the network and user experience.
  • A dynamic and transversal management of any environment to secure and control on-premises infrastructure and applications, in hybrid environments and public clouds.
  • Integrated solutions to connect the components of the entire network infrastructure, helping organizations adapt to a changing and increasingly challenging environment.
  • A monitored and controlled ecosystem to detect and respond to malfunctions, to security threats and to optimize operations, lightening the workload on staff.

How to structure networking governance

In the context of IT governance, it certainly deserves a dedicated chapter network governance which must contemplate a set of processes through which it is possible to guarantee an organization a effective and efficient use of IT resources in the networking field, in order to achieve their goals.

Network governance must also include the application of:

  • controls that help the company mitigate risk and create “guardrails”
  • measurements to check for potential problems

The main disciplines that emerge in the Network Governance are:

  • Compliance and security baseline
  • Vulnerability management
  • Identity management and access control
  • Acceleration, control and consistency in the deployment and change processes of network solutions
  • Optimization and efficiency of wired and wireless networks

Importantly, all of this needs to be done for IT resources in scope networking in any environment, both on-premise and in cloud and multi-cloud realities with a structured approach, consolidated and holistic.

Microsoft, also in this area, offers different tools and solutions that allow you to face the challenge of network governance in the Azure environment, to which it is necessary to support experience to implement consolidated and reliable processes.

Conclusions

In recent years, the adoption of hybrid architectures has attracted considerable interest from many companies, attracted by the possibilities offered and the benefits. In order to best create these environments and promote innovation, it is also essential to adapt the approach to the use of network resources and extend the governance processes of the IT environment to the networking area.

How to strengthen network protection with Defender for Cloud

In the networking field, Microsoft Azure provides a series of solutions, native to the platform, which allow to obtain a high degree of security if they are adopted in the appropriate way. An important added value to refine and strengthen the security posture of the network is given by Microsoft Defender for Cloud, as it allows you to contemplate, through specific features, also certain aspects of networking. This article explores how Microsoft Defender for Cloud lets you verify, achieve and maintain an Azure networking best practice configuration.

Defender for Cloud overview

The Microsoft Defender for Cloud solution provides a set of features that cover two important pillars of security for modern architectures that adopt cloud components: Cloud Security Posture Management (CSPM) e Cloud workload protection (CWP).

Figure 1– The pillars of security covered by Microsoft Defender for Cloud

Within Cloud Security Posture Management (CSPM) Defender for Cloud can provide the following features:

  • Visibility: to assess the current security situation.
  • Hardening Guide: to be able to improve security efficiently and effectively.

Thanks to a continuous assessment, Defender for Cloud is able to continuously discover new resources that are distributed and evaluate if they are configured according to security best practices. If not,, assets are flagged and you get a priority list of recommendations on what to fix to improve their security. This process occurs specifically also for network resources and the recommendations focus on various networking solutions such as: next generation firewall, Network Security Group e JIT VM access. A complete list of recommendations and related corrective actions, Defender for Cloud recommended for the network, you can consult it in this document.

Figure 2 - Examples of networking recommendations

As regards the scope Cloud Workload Protection (CWP), Defender for Cloud delivers security alerts based onMicrosoft Threat Intelligence. Furthermore, includes a wide range of advanced and intelligent protections for workloads, provided through specific Microsoft Defender plans for the different types of resources present in the subscriptions and in hybrid and multi-cloud environments.

Defender for Cloud specific networking features

What about networking, Defender for Cloud in addition to making a continuous assessment of resources and generating any recommendations, includes other specific features:

Figure 3 - Microsoft Defender for Cloud networking features

Adaptive network hardening

Network Security Groups (NSG) are the main tool to control network traffic in Azure, through which, through deny and permit rules, it is possible to filter the communications between different workloads attested on the Azure virtual networks. However, there may be situations in which the actual network traffic that crosses an NSG corresponds only to a subset of the rules that have been defined within the NSG itself. In these cases, to further improve the security posture it is possible to refine the rules present in the NSG, based on actual network traffic patterns. The functionality of adaptive network hardening of Defender for Cloud verifies just that and generates recommendations to further strengthen the rules present in the NSG. To achieve this result, a machine learning algorithm is used that takes into account the actual network traffic, of the present configuration, threat intelligence and other indicators of compromise.

Figure 4 - Recommendations relating to the adaptive network hardening functionality

Network Map

To continuously monitor the security status of the network, Defender for Cloud provides an interactive map that allows you to graphically view the network topology, including tips and recommendations for hardening network resources. Furthermore, using the map you can check the connections between virtual machines and subnets, until evaluating if each node is configured correctly from the point of view of the network. By checking how the nodes are connected, you can more easily identify and block unwanted connections that could potentially make it easier for an attacker to attack your network. For more information on this feature, you can consult the Microsoft's official documentation.

Figure 5 - Defender for Cloud generated network map

In order to take advantage of these specific features it is necessary to license the plan Defender for Servers Plan 2.

Conclusions

A winning strategy in Azure networking, capable of also supporting the Zero Trust model, it can be obtained by applying a mix-and-match of the different network security services to have protection on multiple levels. At the same time, it is very useful to be able to rely on the features of Defender for Cloud, also to contemplate the aspects related to networking, that through continuous assessment and in-depth visibility allow to obtain environments configured according to best practices even over time.

Azure Networking: security services for a Zero Trust approach

There are more and more companies that, in order to sustain the pace dictated by digital transformation and for other specific reasons, undertake a path of adopting cloud solutions and migrating their workloads to the cloud. To ensure that the resources in the cloud environment are secure, it is necessary to adopt a new security model that adapts more effectively to the complexity of the modern environment, contemplating hybrid environments and protecting applications and data no matter where they reside. This article describes some of the key Azure networking security services that help organizations adopt the Zero Trust model, an integrated and proactive approach to security to be applied on different fronts.

The Zero Trust framework developed by Microsoft is based on the following three principles to protect assets:

  • Verify explicitly. Always authenticate and authorize, taking into consideration different aspects such as: the user identity, location, the status of the device, the service or workload, data classification and anomalies.
  • Use least privileged access. Restrict user access through: “just-in-time” access (JIT) and “just-enough-access” (JEA), risk-based adaptive policies and data protection.
  • Assume breach. Minimize exposure and segment accesses by defining granular perimeters. Use end-to-end encryption and scan for: gain visibility, detect threats and improve defenses.

The Zero Trust approach assumes a violation and accepts the reality that bad guys can be anywhere. For this reason, this model recommends checking all access attempts, restrict user access (JIT and JEA) and strengthen asset protection. However, it is important to associate checks on network communications with all these practices, going to segmenting the network into smaller areas and then checking what traffic can flow between them. An approach where network firewalls are implemented exclusively on the perimeter networks, filtering traffic between trusted and untrusted zones becomes limiting for this model. Instead, it is recommended to filter the traffic also between internal networks, hosts and applications.

There are several networking related security services in Azure, described in the following paragraphs, that allow you to filter and control network communications in a granular way, thus supporting the Zero Trust model.

Network Security Group (NSG)

The Network Security Groups (NSG) are the main tool to control network traffic in Azure. Through the rules of deny and permit you can filter communications between different workloads on an Azure virtual network. Furthermore, you can apply filters on communications with systems that reside on-premises, connected to the Azure VNet, or for communications to and from Internet. Network Security Groups (NSG) can be applied on a specific subnet of a Azure VNet or directly on the individual network adapters of Azure virtual machines. NSGs may contain rules with Service Tags, that allow you to group with predefined categories of IP addresses, including those assigned to specific Azure services (ex. AzureMonitor, Appservice, Storage, etc.).

The rules of the Network Security Groups can also be referenced Application Security Groups (ASG). These are groups that contain network adapters of virtual machines on Azure. ASGs allow you to group multiple servers with mnemonic names, useful in particular for dynamic workloads. The Application Security Groups therefore allow you to no longer have to manage the IP addresses of Azure virtual machines in the NSG rules, as long as these IPs are related to VMs attested on the same VNet.

Although there is the option to enable firewall solutions at the guest OS level, Azure NSGs can guarantee protection even if the virtual machine in Azure is compromised. In fact,, an attacker who gains access to the virtual machine and elevates its privileges may be able to disable the firewall on the host. In NSG, being implemented outside the virtual machine, they provide strong guarantees against attacks on the firewalling system on board virtual machines.

Figure 1 - Graphical display of network traffic segregation via NSG

Azure Firewall

Azure Firewall is a network security service, managed and cloud-based, able to protect the resources attested on the Azure Virtual Networks and to centrally govern the related network flows. Furthermore, it has inherent features of high availability and scalability.

Azure Firewall Premium guarantees all the features present in the Azure Firewall Standard tier and in addition adds the following features typical of a next generation firewall.

Figure 2 - Overview of Azure Firewall Premium features

The best practices dictated by the Zero Trust model are to always encrypt data in transit to obtain end-to-end encryption. However, from an operational point of view, often there is a need for greater visibility to apply additional security services to unencrypted data. With the features of Azure Firewall Premium all this is possible. In fact,, the Premium version allows you to obtain an additional level of protection from security threats, through features such as TLS Inspection and IDPS that guarantee greater control of network traffic in order to intercept and block the spread of malware and viruses. For more details regarding the features of Azure Firewall Premium you can consult this article.

DDoS protection

The Zero Trust model aims to authenticate and authorize any component residing on the network. Nevertheless, any system capable of receiving network packets is vulnerable to DDoS attacks, even those that use a Zero Trust architecture. Consequently, It is imperative that any Zero Trust implementation also adopts a DDoS protection solution.

In Azure, DDoS protection is available in two different tiers: Basic oppure Standard.

The protection Basic is enabled by default in the Azure platform, which constantly monitors traffic and applies mitigations to the most common network attacks in real time. This tier provides the same level of protection adopted and tested by Microsoft's online services and is active for Azure Public IP addresses (Pv4 and IPv6). No configuration is required for the Basic tier.

Typology Azure DDoS Protection Standard provides additional mitigation features over the Basic tier, that are specifically optimized for resources located in Azure virtual networks. The protection policies are self-configured and are optimized by carrying out specific monitoring of network traffic and applying machine learning algorithms, that allow you to profile your application in the most appropriate and flexible way by studying the traffic generated. When the thresholds set in the DDoS policy are exceeded, the DDoS mitigation process is automatically started, which is suspended when it falls below the established traffic thresholds. These policies are applied to all Azure public IPs associated with the resources present in the virtual networks, like: virtual machines, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway and Azure Service Fabric instances.

Azure Firewall Manager

The security model Zero Trust directs us to adopt an approach related to micro-segmentation and the definition of granular perimeters in its network architecture. To facilitate this approach, you can use Azure Firewall Manager, a tool that, providing a single centralized control panel, is able to simplify the configuration and management of network security policies, which often need to be deployed across multiple Azure Firewall instances. In addition to the management of Azure Firewall policies, Azure Firewall Manager allows you to associate a DDoS protection plan to virtual networks.

Furthermore, Azure Firewall Manager allows you to use SECaaS offerings (Security as a Service) third parties to protect users' Internet access.

Synergies and recommendations for the use of the various protection services

In order to obtain effective network protection, some recommendations are given that are recommended to be taken into consideration for the use of the various security components related to Azure networking:

  • Network Security Groups (NSG) and the Azure Firewall are complementary and using them together you get a high degree of defense. The NSGs are recommended to use them to filter traffic between resources residing within a VNet, while the Azure Firewall is useful for providing network and application protection between different Virtual Networks.
  • To increase the security of Azure PaaS services, it is recommended to use Private link, which can be used in conjunction with Azure Firewall to consolidate and centralize access logs.
  • In case you want to make a protected application publication (HTTP/S in inbound) it is advisable to use the Web Application Firewall present in Azure Application Delivery solutions, then placing it alongside Azure Firewall. Web Application Firewall (WAF), provides protection from common vulnerabilities and attacks, such as X-Site Scripting and SQL Injection attacks.
  • Azure Firewall can also be supported by third-party WAF / DDoS solutions.
  • In addition to Azure Firewall, it is possible to evaluate the adoption of Network Virtual Appliances (NVA's) provided by third-party vendors and available in the Azure marketplace.

All these protection services, suitably configured in a Hub-Spoke network topology allow you to perform a segregation of network traffic, achieving a high level of control and security.

Figure 3 - Example of a Hub-Spoke architecture with the various security services

Furthermore, providing for integration with Azure security services, such as Microsoft Defender for Cloud, Microsoft Sentinel and Azure Log Analytics, it is possible to further optimize the management of security postures and the protection of workloads.

Conclusions

The security model defined Zero trust by analysts at Forrester Research is now an imperative for the protection of their environments. Azure provides a wide range of services that allow you to achieve high levels of security, acting on different fronts to support this model. To face this process of adopting the Zero Trust model, a winning strategy in Azure networking can be obtained by applying a mix-and-match of the different network security services to have protection on multiple levels.

Azure Networking: how to extend an on-premises network to Azure with private connectivity

When you decide to undertake a strategy based on a hybrid cloud, that combines on-premises IT resources with public cloud resources and services, it is advisable to carefully consider how to connect your local network with the virtual networks present in the public cloud. In Azure one option is to use ExpressRoute, a private and dedicated connection that takes place through a third-party connectivity provider. This article describes possible network architectures with ExpressRoute, together with a series of precautions to be taken into consideration for a successful deployment.

Very often a Site-to-site VPN is used to establish connectivity between the on-premise resources and the resources in Azure environment attested on the Virtual Networks. This type of connectivity is ideal for the following use cases:

  • Development environments, test, laboratories, but also production workloads where the resources located in the Azure environment do not use the connectivity to the on-premises environment intensively and strategically and vice versa.
  • When you have an acceptable tolerance for bandwidth and speed in the hybrid connection.

There are some use cases, however, where ExpressRoute should be configured, according to Microsoft best practices, to ensure bidirectional connectivity between the on-premise network and virtual networks (vNet) of Azure of the customer. In fact,, ExpressRoute is suitable for the following use cases:

  • If high speed requirements are to be met, connection with low latency and high availability / resilience.
  • In the presence of mission-critical workloads that use hybrid connectivity.

What is ExpressRoute?

Thanks to ExpressRoute it is possible to activate a dedicated private connection, provided by a third party connectivity provider, to extend the on-premises network to Azure. ExpressRoute connections do not go through the public internet. In this way they can offer a higher level of security, greater reliability, faster speeds and consistent latencies than traditional internet connections.

Figure 1 - ExpressRoute logic diagram

ExpressRoute connections enable access to the following services:

  • Microsoft Azure services (scenario covered in this article).
  • Services of Microsoft 365. Microsoft 365 it has been designed to be accessed securely and reliably over the Internet. For this reason it is recommended that you use ExpressRoute with Microsoft 365 only in certain scenarios, as described in this Microsoft article.

It is possible to create an ExpressRoute connection between the local network and the Microsoft cloud via four different modes:

Figure 2 - ExpressRoute connectivity models

Connectivity providers can offer one or more connectivity models and you can choose the most appropriate model for your connectivity needs.

Reference architectures

The following reference architecture shows how you can connect your on-premises network to virtual networks in Azure, using Azure ExpressRoute.

Figure 3 - Reference architecture to extend a local network with ExpressRoute

The architecture will consist of the following components.

  • On-premises corporate network (“On-premises network” in the schema). This is the Customer's private local network.
  • Local Edge Routers. These are the routers that connect the local network to the circuit managed by the provider.
  • ExpressRoute Circuit. It is a circuit layer 2 or layer 3, provided by the connectivity provider, which joins the local network to Azure via edge router. The circuit uses the hardware infrastructure managed by the connectivity provider.
  • Edge router Microsoft. These are routers in an active-active high availability configuration. These routers allow the connectivity provider to connect their circuits directly to the data center.
  • Virtual network gateway (ExpressRoute). The ExpressRoute virtual network gateway enables the virtual network (VNet) Azure to connect to the ExpressRoute circuit used for connectivity with the local network.
  • Azure virtual networks (VNet). Virtual networks residing in an Azure region.

In the architecture described above, ExpressRoute will be used as the primary connectivity channel to connect the on-premises network to Azure.

Furthermore, it is possible to use a site-to-site VPN connection as a source of backup connectivity to improve connectivity resilience. In this case, the reference architecture will be the following:

Figure 4 - Reference architecture to use both ExpressRoute and a site-to-site VPN connection

In this scenario they are expected, in addition to the architectural components described above, the following components:

  • Appliance VPN on-premises. A device or service that provides external connectivity to the local network. The VPN appliance can be a hardware device or a supported software solution for connecting to Azure.
  • Virtual network gateway (VPN). The VPN virtual network gateway allows the virtual network to connect to the VPN appliance present in the local network.
  • VPN connection. The connection has properties that specify the type of connection (IPSec) and the key shared with the local VPN appliance to encrypt the traffic.

How to monitor ExpressRoute

To allow you to monitor network resources in the presence of ExpressRoute connectivity, you can use the Azure Monitor platform tool, through which you can check availability, performance, the use and operation of this connectivity.

A screenshot of the solution is shown as an example.

Figure 5 – ExpressRoute circuit monitor via Azure Monitor

This solution will provide a detailed topology mapping of all ExpressRoute components (peering, connections, gateway) in relation to each other. The detailed network information for ExpressRoute will include a dashboard through which the metrics can be consulted, the actual speed, any drop of network packets and gateway metrics.

As an example, a dashboard screen showing the total throughput of inbound and outbound traffic for the ExpressRoute circuit is shown (expressed in bits / second). Furthermore, you can view the throughput for individual connections.

Figure 6 - Metrics relating to the Throughput of ExpressRoute connections

For more details you can refer to the Microsoft official documentation on how to make the ExpressRoute monitor.

Security Considerations

Microsoft in the security baselines for ExpressRoute, refer to the Azure Security Benchmark version 1.0, the Azure-specific set of guidelines created by Microsoft, provides several indications that are recommended to be followed. Among the main ones that should be adopted we find:

  • Definition and implementation of standard security configurations for Azure ExpressRoute using Azure Policy.
  • Use of tags for Azure ExpressRoute components in order to provide metadata and a logical and structured organization of resources.
  • Locking to prevent accidental deletion or unwanted modification of Azure components related to ExpressRoute configuration.
  • Using Azure Platform Tools to Monitor Network Resource Configurations and Detect Network Resource Changes of ExpressRoute Connections. Creating Alerts in Azure Monitor to be generated when changes are made to critical resources.
  • Configure centralized collection of Activity Logs for ExpressRoute components.

Conclusions

ExpressRoute offers a fast and reliable connection to Azure with bandwidths that can reach up to 100 Gbps. It is therefore an ideal option for specific scenarios such as periodic data migration, replication for business continuity purposes, the disaster recovery, and the activation of high availability strategies. Thanks to ExpressRoute's fast speed and low latency times, Azure will feel like a natural extension of your data centers. In this way, it is possible to take advantage of the scalability and innovation of the public cloud without compromising in terms of network performance.

Next-Generation Firewall functionality with Azure Firewall Premium

The adoption of an effective Azure environment protection strategy is essential and also requires a careful assessment of the features provided by the firewall solution you intend to use. Azure Firewall has been available for some time, Microsoft's managed and fully integrated public cloud service, that allows you to secure the resources present on the Virtual Networks of Azure. In specific business realities, particularly sensitive to security and requiring a high level of regulation, advanced features typical of a next generation firewall are required. For this reason, Microsoft has released Azure Firewall Premium, the firewall-as-a-service solution (FWaaS) which guarantees several advanced features to better protect Azure environments. This article explores the features of Azure Firewall Premium.

Azure Firewall is a network security service, managed and cloud-based, able to protect the resources attested on the Azure Virtual Networks and to centrally govern the related network flows. Furthermore, it has inherent features of high availability and scalability.

The Premium version allows you to get an additional level of protection from security threats, through features such as TLS Inspection and IDPS that guarantee greater control of network traffic in order to intercept and block the spread of malware and viruses. The features of TLS Inspection and IDPS require more performance, reason why Azure Firewall Premium, compared to the Standard tier, uses more powerful SKUs for its instances and is able to guarantee high levels of performance. Like the Standard SKU, Premium SKU can scale up to 30 Gbps and integrates with availability zones to guarantee a service level agreement (SLA) equal to 99,99 %. Azure Firewall got ICSA Labs certification, in addition, the Premium version complies with the PCI DSS security standard (Payment Card Industry Data Security Standard).

The functionality of Azure Firewall Premium

The new features of Azure Firewall Premium are configurable only through Firewall Policy. Firewall rules in "classic" mode continue to be supported and can only be used to configure the Standard version of Azure Firewall. Firewall Policies can be managed independently or with Azure Firewall Manager.

Azure Firewall Premium guarantees all the features present in the Azure Firewall Standard tier and in addition adds the following features typical of a next generation firewall.

Figure 1 - Azure Firewall Premium overview

The following chapters describe the new features introduced in Azure Firewall Premium.

TLS inspection

The standard security technology that allows you to establish an encrypted connection between a client and a server is the Transport Layer Security (TLS), formerly known as Secure Sockets Layer (SSL). This standard ensures that all data passing between clients and the server remains private and encrypted. Azure Firewall Premium is able to intercept and inspect TLS connections. To do this, a complete decryption of network communications is performed, the necessary security checks are performed and the traffic to be sent to the destination is re-encrypted.

The Azure Firewall Premium TLS Inspection solution is ideal for the following use cases:

  • Outbound TLS termination.

Figure 2 - Azure Firewall TLS Inspection for outbound traffic

  • TLS termination between spoke virtual networks (east-west).
  • Inbound TLS termination with Application Gateway. Azure Firewall communication flows can be deployed behind an Application Gateway. By adopting this configuration, incoming Web traffic passes both through the WAF of the Application Gateway and through the Azure Firewall. WAF provides Web application-level security, while Azure Firewall acts as a central control and logging point to inspect traffic between the Application Gateway and back-end servers. The Azure Firewall can in fact de-encrypt the traffic received from the Application Gateway for further inspection and encrypt it again before forwarding it to the destination Web server. For more details on this use case you can consult this Microsoft's document.

Figure 3 – Implementation of the Application Gateway before Azure Firewall

To enable TLS Inspection in Azure Firewall Premium it is advisable to use a certificate present in an Azure Key Vault. Azure Firewall is accessed to the key vault to retrieve certificates using a managed identity. For more information about using certificates, for this Azure Firewall Premium feature, you can see the Microsoft's official documentation.

These use cases allow customers to adopt a zero trust model and implement end-to-end network segmentation.

IDPS

An Intrusion Detection and Prevention System (IDPS) allows you to monitor network activities to detect malicious activities, record information about these activities, report them and, optionally, try to block them. Azure Firewall Premium provides signature-based IDPS and is able to enable attack detection by searching for specific patterns, as sequences of bytes in network traffic or known malicious instruction sequences used by malware. IDPS signatures are automatically managed and continuously updated.

This capability works for all ports and protocols, but despite some detections they can also run with encrypted traffic, enabling TLS Inspection is important to make the best use of the IDPS.

Figure 4 – IDPS mode

Filtering URL

URL filtering allows you to filter outbound access to specific URLs, and not just for certain FQDNs. In fact, the Azure Firewall FQDN filtering capability is extended to consider an entire URL. For example,, www.microsoft.com/a/b instead of just www.microsoft.com. This feature is also effective for encrypted traffic if TLS Inspection is enabled.

Filtering URL can also be used in conjunction with Web categorization to extend a particular category by explicitly adding multiple URLs, or to allow/deny access to URLs within your organization's intranet.

Figure 5 – URL filtering in application rules

Web categorization

Web categorization in Azure Firewall policies allows you to allow or deny users access to the Internet based on specific categories, for example, social networks, search engines, gambling, etc.

This feature can be used as a target type in the application rules in both Standard and Premium Azure Firewall SKUs. The main difference is that the Premium SKU allows you to achieve a higher level of optimization, classifying traffic by full URL, using the functionality of TLS Inspection, while the standard SKU classifies traffic only by FQDN. This function allows you to have visibility and control in the use of an organization's Internet traffic and is ideal for controlling web browsing for Azure Virtual Desktop clients.

Figure 6 – Web categorization in an access rule

The transition from version Standard to version Premium

For those who use the Azure Firewall Standard SKU and need to upgrade to the Premium SKU, they can migrate using the following steps.

  • First thing, in case they are not already in use, Azure Firewall Policy must be adopted. To do this, it is possible to transform the Azure Firewall rules (Classic) existing:

Figure 7 - Migration of classic rules to Azure Firewall Policy

  • Create a new Azure Firewall Premium by associating it with the existing Azure Firewall Policy:

Figure 8 - Creation of a new Azure Firewall Premium by associating an existing Azure Policy

Note: an important aspect to consider when migrating is maintaining the IP address or IP addresses assigned to Azure Firewall.

The cost of Azure Firewall Premium

Same as for the Standard SKU, the prices of Azure Firewall Premium are given both by the deployment, both from data processing. The cost for deployment is higher than 40% compared to Azure Firewall Standard, while the costs for data processing are the same as for Azure Firewall Standard. For more details on costs please visit the Microsoft's official page.

Conclusions

The adoption of a firewall solution to better protect and segregate network flows is now an obligatory choice to ensure effective protection and management of the network infrastructure in Azure environments. For companies with advanced control and security needs, they can use the Azure Firewall Premium SKU to expand the set of features available. Azure Firewall Premium can compete, in terms of functionality, with Network Virtual Appliances (NVA's) provided by well-known third-party vendors, for which, however, more articulated configurations are required and generally higher costs are expected.

Secure network architecture design for Azure Kubernetes Service (AKS)

The trend in adopting applications based on microservices requires the use of state-of-the-art solutions capable of managing a large number of containers and the ways in which these interact in application with each other, as Azure Kubernetes Service (AKS). As part of the design of Azure Kubernetes Service architectures (AKS) there are several elements that need to be evaluated to obtain an appropriate network topology that can ensure maximum efficiency and security. This article outlines the main points to consider, accompanied by some proposals, to make informed choices when designing network architectures for AKS.

What is Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) is the fully managed Azure service that allows the activation of a Kubernetes cluster, ideal for simplifying the deployment and management of microservices-based architectures. Thanks to the features offered by AKS it is possible to scale automatically according to the use, use controls to ensure the integrity of the services, implement load balancing policies and manage secrets. In microservices-based architectures, it is also common to adopt the Azure Container Registry that allows you to create, store and manage container images and artifacts in a private registry. The use of this managed service is integrated with the container development and deployment pipelines.

Figure 1 - Azure Kubernetes Service architecture example (AKS)

The network topology

In the network architecture of type Hub and Spoke, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. TheSpoke are virtual networks running the peering with the Hub and can be used to isolate workloads.

Figure 2 - Hub and Spoke network topology

This network topology is also recommended for AKS architectures as it can offer several advantages, including:

  • Environmental segregation to more easily enforce governance policies and gain greater control. This topology also supports the concept of "landing zones" by contemplating the separation of duties.
  • Minimizing the direct exposure of Azure resources to the public network (Internet).
  • Possibility of contemplating workloads attested on different Azure subscriptions, becoming a natural choice in these scenarios.
  • Ability to easily extend the architecture to accommodate new features or new workloads, simply by adding additional spoke virtual networks.
  • Ability to centralize Azure services shared by multiple workloads in a single location (attested on different VNet), such as DNS servers and any virtual network appliances. It also reduces the VPN Gateways to provide connectivity to the on-premises environment, resulting in savings on Azure costs and simplification of the architecture.

Figure 3 - Hub and Spoke network topology for AKS

Hub Virtual Network

In the Hub network it is possible to evaluate the adoption of the following services:

  • VPN or ExpressRoute Gateway: necessary to provide connectivity to the on-premises environment.
  • Firewall Solutions, necessary in case you want to control the traffic from your AKS environment, as pods or cluster nodes, outgoing to external services. In this context, the choice can fall between:
    • Azure Firewall, the firewall-as-a-service solution (FWaaS) which allows to secure the resources present in the Virtual Networks and to govern the related network flows.
    • Network Virtual Appliances (NVA's) provided by third party vendors. Such solutions are numerous and can offer advanced functionality, but typically the configuration of these solutions is more complex and the cost tends to be higher than the solution provided by the Azure platform. A comparison between the new Azure Firewall and third-party virtual appliances can be found in this article.
  • Azure Bastion, the PaaS service that offers secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal.

Spoke Virtual Network

The AKS cluster is placed in the Spoke network together with other resources closely related to its operation. Spoke VNet is split into different subnets to accommodate the following components:

  • The two groups of nodes (node pools) in AKS:
    • AKS System Node pool: the pool of system nodes that host the pods needed to run the core services of the cluster.
    • AKS User Node pool: the pool of user nodes that run the application workloads and the ingress controller.

For multi-tenant application environments or for workloads with advanced needs, it may be necessary to implement isolation mechanisms of node pools that require the presence of different subnets.

  • AKS Internal Load Balancer: the balancer to route and distribute inbound traffic for Kubernetes resources. In this case the component is used Azure Load Balancer, which enables Layer-4 load balancing for all TCP and UDP protocols, ensuring high performance and very low latencies.
  • Azure Application Gateway: it is a service managed by the azure platform, with inherent features of high availability and scalability. The Application Gateway is a application load balancer (OSI layer 7) for web traffic, that allows you to govern HTTP and HTTPS applications traffic (URL path, host based, round robin, session affinity, redirection). The Application Gateway is able to centrally manage certificates for application publishing, using SSL and SSL offload policy when necessary. The Application Gateway may have assigned a private IP address or a public IP address, if the application must be republished in Internet. In particular in the latter case, it is recommended to turn onWeb Application Firewall (WAF), that provides application protection, based on rulesOWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.

Thanks to the adoption of Azure Private Link you can bring Azure services to a virtual network and map them with a private endpoint. In this way, all traffic is routed through the private endpoint, keeping it on the Microsoft global network. The data does not pass ever on the Internet, this reduces exposure to threats and helps to meet the compliance standards.

Figure 4 - Overview of Azure Private Link

In AKS environments theAzure Private Link they are usually created in the Spoke virtual network subnets for Azure Container Registry and Azure KeyVault.

Below is a diagram with the incoming and outgoing network flows for an AKS environment, which also includes the presence of Azure Firewall to control outgoing traffic.

Figure 5 - Example of network flows in a typical AKS architecture

Management traffic

In order to allow the management of the environment, such as creating new resources or carrying out activities to scale the cluster environment, it is advisable to provide access to the Kubernetes API. Good practice is apply network filters to authorize this access in a timely manner.

Private AKS cluster

In case you want to implement a totally private AKS environment, where no Internet service is exposed, it is possible to adopt a AKS cluster in "private" mode.

Conclusions

The increasing demand for microservices-based application architectures that useAzure Kubernetes Service (AKS) requires you to locate and build network architectures designed to be secure, flexible and with a high level of integration. All this must take place through a modern approach able to fully exploit the potential offered in the field of networking by Azure.

Azure Networking: comparison between the new Azure Firewall and third-party virtual appliances

Securing network architectures is an aspect of fundamental importance even when adopting the public cloud and becoming mandatory to adopt a firewall solution to better protect and segregate network flows. The availability of Azure Firewall Premium was recently announced, Microsoft's next generation firewall with interesting features that can be useful in highly security-sensitive environments and that require a high level of regulation. This article reports the characteristics of this new solution and a comparison is made with the Network Virtual Appliances (NVA's) of third-party vendors, to evaluate the choice of an appropriate "Firewall Strategy".

New features in Azure Firewall Premium

Azure Firewall is the firewall-as-a-service solution (FWaaS) present in Microsoft's public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows.

Figure 1 – Azure Firewall Premium Overview

Azure Firewall Premium uses Firewall Policy, a global resource that is used to centrally manage firewalls by using Azure Firewall Manager. All new features can only be configured through Firewall Policy.

The following chapters describe the new features introduced in Azure Firewall Premium.

TLS inspection

The standard security technology that allows you to establish an encrypted connection between a client and a server is the Transport Layer Security (TLS), formerly known as Secure Sockets Layer (SSL). This standard ensures that all data passing between clients and the server remains private and encrypted. Azure Firewall Premium is able to intercept and inspect TLS connections. To do this, a complete decryption of network communications is performed, the necessary security checks are performed and the traffic to be sent to the destination is re-encrypted.

The Azure Firewall Premium TLS Inspection solution is ideal for the following use cases:

  • Outbound TLS termination.

Figure 2 – Azure Firewall TLS Inspection for Outbound Traffic

  • TLS termination between spoke virtual networks (east-west).
  • Inbound TLS termination with Application Gateway. Azure Firewall communication flows can be deployed behind an Application Gateway. By adopting this configuration, incoming Web traffic passes both through the WAF of the Application Gateway and through the Azure Firewall. WAF provides Web application-level security, while Azure Firewall acts as a central control and logging point to inspect traffic between the Application Gateway and back-end servers. The Azure Firewall can in fact de-encrypt the traffic received from the Application Gateway for further inspection and encrypt it again before forwarding it to the destination Web server. For more details on this use case you can consult this Microsoft's document.

Figure 3 – Implementation of the Application Gateway before Azure Firewall

To enable TLS Inspection in Azure Firewall Premium it is advisable to use a certificate present in an Azure Key Vault. Azure Firewall is accessed to the key vault to retrieve certificates using a managed identity. For more information about using certificates, for this Azure Firewall Premium feature, you can see the Microsoft's official documentation.

These use cases allow customers to adopt a zero trust model and implement end-to-end network segmentation.

IDPS

An Intrusion Detection and Prevention System (IDPS) allows you to monitor network activities to detect malicious activities, record information about these activities, report them and, optionally, try to block them. Azure Firewall Premium provides signature-based IDPS and is able to enable attack detection by searching for specific patterns, as sequences of bytes in network traffic or known malicious instruction sequences used by malware. IDPS signatures are automatically managed and continuously updated.

This capability works for all ports and protocols, but despite some detections they can also run with encrypted traffic, enabling TLS Inspection is important to make the best use of the IDPS.

Figure 4 – IDPS mode

Filtering URL

URL filtering allows you to filter outbound access to specific URLs, and not just for certain FQDNs. In fact, the Azure Firewall FQDN filtering capability is extended to consider an entire URL. For example,, www.microsoft.com/a/b instead of just www.microsoft.com. This feature is also effective for encrypted traffic if TLS Inspection is enabled.

Filtering URL can also be used in conjunction with Web categorization to extend a particular category by explicitly adding multiple URLs, or to allow/deny access to URLs within your organization's intranet.

Figure 5 – URL filtering in application rules

Web categorization

Web categorization in Azure Firewall policies allows you to allow or deny users access to the Internet based on specific categories, for example, social networks, search engines, gambling, etc.

This feature can be used as a target type in the application rules in both Standard and Premium Azure Firewall SKUs. The main difference is that the Premium SKU allows you to achieve a higher level of optimization, classifying traffic by full URL, using the functionality of TLS Inspection, while the standard SKU classifies traffic only by FQDN. This feature allows you to have visibility and control in the use of an organization's Internet traffic and is ideal for controlling Internet browsing for Windows Virtual Desktop clients.

Figure 6 – Web categorization in an access rule

Azure Firewall Premium vs Network Virtual Appliances (NVA's) of third party

The Network Virtual Appliances (NVA's) provided by third-party vendors and available in the Azure marketplace are numerous and can offer advanced features. Typically the configuration of these solutions is more articulated and the cost tends to be higher than the solutions provided by the Azure platform.

The gap between Azure Firewall features, thanks to Premium features, and the third party NVAs is now greatly reduced.

There is a high-level comparison between Azure Firewall Premium and NVAs:

Figure 7 – Azure Firewall Premium vs NVAs Feature Comparison

The Azure Firewall feature set is therefore suitable for most customers and provides some key benefits being a cloud-native managed service, for example:

  • Integration with DevOps templates and other Azure artifacts (ex. Tags, diagnostic settings).
  • High availability is integrated into the service and no specific configurations or additional components are required to make it effective. This is definitely an element that distinguishes it compared to third-party solutions that, for the configuration of Network Virtual Appliance (NVA) in HA, typically require the configuration of additional load balancers.
  • Azure Firewall allows you to scale easily to adapt to any change of network streams.
  • No maintenance activity required.
  • Significant TCO savings for most customers. In fact,, for NVAs it is appropriate to consider:
    • Computational costs (at least two virtual machines for HA)
    • Licensing costs
    • Costs for standard load balancers (interior and exterior)
    • Maintenance costs
    • Support costs

However, it is appropriate to specify that for some customers, third-party solutions are more suitable as they allow for continuity in the user experience compared to solutions already active in the on-premises environment.

Conclusions

With the release of the Premium SKU Azure Firewall becomes a next generation firewall fully integrated into the Azure fabric, that provides very interesting features, to the point of making it the ideal choice for customers with advanced control and security needs of their Azure networking.

How to monitor, diagnose problems and gain insights into networking with Azure tools

Network architectures in the public cloud have peculiarities and introduce concepts that substantially differentiate them from traditional ones in the on-premises environment. However, one aspect that unites them is certainly the need to monitor them, constantly checking performance and health status. To do all this effectively, contemplating the intrinsic particularities of the public cloud and hybrid network architectures, it is advisable to have effective tools. This article reports the characteristics of the platform service Azure Network Watcher, that provides a suite of tools to monitor, diagnose and view network resource metrics and logs.

Network Watcher is designed to monitor and check network infrastructure health, even in hybrid environments, specifically for IaaS components (Infrastructure-as-a-Service) attested on Azure virtual networks. Network Watcher does not provide tools to monitor the PaaS infrastructure (Platform-as-a-Service) or to carry out the analysis of web components.

Network Watcher is a regional service, zone-resilient and fully managed. The enabling of the component now occurs by default for each Azure subscription that contains virtual networks. Network Watcher resources are placed by default in the resource group, hidden and created automatically, called NetworkWatcherRG.

The tools included in Azure Network Watcher can be divided into three categories based on the features offered: Monitoring, Diagnostics and Logging

Monitoring tools

Topology view

In particularly complex network architectures it may be useful to identify which resources are attested on a specific virtual network and how they relate to each other. With this tool, you can view directly in the Azure portal a visual diagram of the components on a specific virtual network and the relationships between the various resources.

Figure 1 – Example of a Topology view

Connection Monitor

Connection Monitor was recently revised and in version 2.0 allows you to monitor end-to-end connections both in Azure environments and in the presence of hybrid network architectures.

Among the main strengths of this new solution we find:

  • Unified and intuitive monitor experience for both fully Azure-based environments and hybrid environments.
  • Connectivity monitor, also cross-region, and verify network latencies to endpoints.
  • High probing frequencies that allow to obtain greater visibility on network performance.
  • More immediate alerts to report abnormal conditions in the presence of hybrid network architectures.
  • Ability to perform connectivity checks based on protocols HTTP , TCP, and ICMP.
  • Support for saving data to Azure Monitor metrics and Log Analytics workspaces.

Figure 2 – Connection Monitor Tool Overview

To make Connection Monitor able to recognize Azure VMs as sources for monitor activities, Network Watcher Agent virtual machine extension must be installed on them.

Network Performance Monitor

Network Performance Monitor is now an integral part of Connection Monitor and therefore included in Azure Network Watcher. The solution requires the presence of the Azure Monitor agent and, thanks to the use of synthetic transactions, provides the ability to monitor network parameters in hybrid network architectures, to get performance information, like packet loss and latency. Furthermore, this solution makes it easy to locate the source of a problem in a specific network segment or by identifying a particular device. The solution, tracking retransmission packets and roundtrip time, is able to return a graph of easy and immediate interpretation. Furthermore, allows you to check the performance between the on-premises and Azure environment, even if you have expressroute connectivity.

Diagnostic Tools

IP Flow Verify

Under certain circumstances, it can happen that a virtual machine is unable to communicate with other resources, because of the security rules present. This feature allows you to specify a source and destination IPv4 address, a port, a protocol (TCP or UDP) and the direction of traffic (inbound or outbound). IP Flow Verify verifies the communication and informs if the connection is successful or not. If the connection fails, is indicated which security rule denied the communication, so you can solve the problem.

Next Hop

This tool helps to verify network traffic routes and allows you to detect any routing problems. The Next Hop functionality allows you to specify a source and destination IPv4 address and to verify their communication.

Connection Troubleshoot

This tool allows you to check connectivity and latency between a virtual machine and another network resource on a one-time basis, which can be another virtual machine, an FQDN, a URI or IPv4 address. The test returns information similar to that returned when using Connection Monitor, but the connection check happens at a certain time, instead of making a monitor over time as is the case with Connection Monitor.

Packet Capture

With this tool, you can versatilely capture network traffic on an Azure virtual machine, applying any advanced filtering options and setting time and size limits. Capture can be stored in Azure Storage, on the VM disk or in both locations. Captured network traffic can then be analyzed with several standard analysis tools, such as Wireshark.

VPN Troubleshoot

This tool performs various diagnostic checks on VPN gateways and their connections, useful for solving problems.

The Packet Capture and Connection Troubleshoot features require the presence of the extension Network Watcher on the VMs, as reported for Connection Monitor.

Logging tools

NSG Flow Logs

In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (VNet) it uses the Network Security Group (NSG), containing a list of access rules. NSGs are usually applied to subnets (recommended) or directly to the network interfaces connected to the virtual machines. Azure platform uses NSG flow logs to maintain visibility of network traffic in and out of Network Security Groups.

Traffic Analytics

Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Figure 3 – Data flow of Traffic Analytics

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.

Figure 4 – Virtual Network in Traffic Analytics

The cost of Network Watcher is detailed in the Microsoft's official page and it depends on the use that is made of the various tools included in the solution.

Conclusions

As the complexity of Azure network architectures increases and in hybrid environments, it is useful to have particularly effective and easy-to-use tools to be able to carry out the monitor. Azure provides several tools integrated into the platform that in addition to the monitor allow you to diagnose problems of different kinds and obtain an overall visibility of your network resources in a simple and intuitive way.

Azure Application delivery: which load balancing service to choose?

The transition to cloud solutions to deliver applications is a trend that is proceeding at a very fast pace and ensuring an access fast, secure and reliable to such applications is a challenging task that must be directed by adopting the right solutions. Microsoft Azure provides a wide range of services to ensure optimal application delivery, but in assessing which load-balancing solution to adopt there are several aspects to consider. This article wants to clarify what you should consider to adopt the most suitable Azure solution in this area.

The need to distribute workloads over multiple computing resources may be due to the need to optimize the use of resources, maximize throughput, minimize response times and avoid overloading every single resource. Furthermore, it can also be aimed at improving application availability by sharing a workload between redundant computing resources.

Azure load balancing services

To provide Azure load-balancing services we find the following components.

Azure Load Balancer and cross-region Azure Load Balancer: these are components that enable Layer-4 load balancing for all TCP and UDP protocols, ensuring high performance and very low latencies. Azure Load Balancer is a component zone-redundant, therefore provides high availability among availability zones.

Figure 1 – Azure Load Balancer and cross-region Azure Load Balancer overview

Azure Application Gateway: it is a service managed by the azure platform, with inherent features of high availability and scalability. The Application Gateway is a application load balancer (OSI layer 7) for web traffic, that allows you to govern HTTP and HTTPS applications traffic (URL path, host based, round robin, session affinity, redirection). The Application Gateway is able to centrally manage certificates for application publishing, using SSL and SSL offload policy when necessary. The Application Gateway may have assigned a private IP address or a public IP address, if the application must be republished in Internet. In particular, in the latter case, it is recommended to turn onWeb Application Firewall (WAF), that provides application protection, based on rulesOWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.

Figure 2 – Azure Application Gateway Overview

Front Door: is an application delivery network that provides global load balancing and site accelleration service for web applications. It offers Layer-7 functionality for application publishing such as SSL offload, path-based routing, fast failover, caching, in order to improve the performance and high availability of applications.

Figure 3 – Azure Front Door Overview

Traffic Manager: is a DNS-based load balancer that enables optimal distribution of traffic to services deployed in different Azure regions, while providing high availability and responsiveness. Are available different routing methods to determine which endpoint to direct traffic to. Based on DNS, failover may not be immediate due to common challenges related to DNS caching and systems not meeting DNS TTLs.

Figure 4 – Azure Traffic Manager Overview (performance traffic-routing method)

Things to consider when choosing Azure load balancing services

Each service has its own characteristics and to choose the most appropriate one it is good to make a classification with respect to the following aspects.

Load-balancing services: global vs regional

  • Global load-balancing: are used to distribute traffic to globally distributed backends across multiple regions, which can be deployed in cloud or hybrid environments. Fall into this category Azure Traffic Manager, Azure Front Door and the cross-region Azure Load Balancer.
  • Regional load-balancing: they allow you to distribute traffic to virtual machines connected to a specific virtual network or to endpoints in a specific region. This category includes Azure Load Balancer and the Azure Application Gateway.

Type of traffic: HTTP(S) vs non-HTTP(S)

Another important differentiating factor in the choice of the load-balancing solution to be adopted is the type of traffic that must be managed:

  • HTTP(S): the adoption of Layer-7 load-balancing services that accept only HTTP traffic is recommended(S). They are suitable for this type of traffic Azure Front Door and Azure Application Gateway. Typically they are used for web applications or other endpoints HTTP (S) and include features such as: SSL offload, web application firewall, path-based load balancing, and session affinity.
  • Non-HTTP(S): the use of load-balancing services is required that allow to contemplate the traffic non-HTTP (S), like Azure Traffic Manager, cross-region Azure Load Balancer and Azure Load Balancer.

In the evaluation of the Azure load-balancing service to be adopted, it is also appropriate to include considerations regarding the following aspects:

To facilitate the choice of the load-balancing solution, the following flow chart can be used as a starting point, which directs the choice on a series of key aspects:

Figure 5 – Flowchart for choosing azure load-balancing solution

Note: This flowchart does not cover the cross-region Azure Load Balancer as at the moment (11/2020) are in preview.

This flow chart is a great starting point for your evaluations, but since each application has unique requirements it is good to carry out a specific more detailed analysis.

If the application consists of multiple workloads, it is appropriate to evaluate each of these separately, as it may be necessary to adopt one or more load balancing solutions.

The various load load-balancing services can be used in combination with each other to ensure reliable and secure application access to the services provided in environments IaaS, PaaS or on-premises.

Figure 6 – Possible example of how to combine the various Azure load-balancing services

Conclusions

Thanks to a wide range of global and regional services, Azure is able to guarantee performance, security and high availability in application access. In order to establish the architecture that best meets your needs, there are several elements to evaluate, but the right combination of Azure Application Delivery solutions can deliver significant value to IT organizations, ensuring a distribution that is fast, secure and reliable for applications and user data.