Are you currently experiencing an attack?

Are you currently experiencing an attack?

Cloud load balancing, Part 2

In a modern-day cloud deployment, load balancers do more than merely distribute traffic to backend instances. Additional roles such as protecting workloads from cyberattacks, SSL offloading, custom messages, URL redirection, etc., all provide additional security and better control over how traffic flows in the cloud environment.

In Cloud Load Balancing, Part 1, we explored how AWS and GCP load balancers offer these capabilities. Now in this second part, we’ll examine the load balancing capabilities offered by Azure. We will also discuss how modern cloud load balancers can help to manage the ever-evolving cyber-threat landscape.

Azure: What It Offers

Azure offers load balancing at Layer 4 and Layer 7, along with DNS-based traffic redirection. While Layer 4 load balancers focus on the distribution of TCP and UDP traffic, Layer 7 load balancers are designed to deliver Application Delivery Controller (ADC) capabilities for your workloads. These can be integrated with AKS, thus acting as ingress controllers to expose microservices to the internet.

Similar to the load balancers provided by AWS and GCP, Azure’s load balancers are also highly available by design and can be used to distribute traffic to resources across multiple Azure regions. When used with VM scale sets, load balancers support the autoscaling capability provided by the Azure platform based on various performance metrics.

The platform offers three types of load balancers: Azure Load Balancer, Azure Application Gateway, and Azure Traffic Manager.

Azure Load Balancer

Azure Load Balancer operates at Layer 4 and can be deployed with an internet-facing IP (external load balancer) or with a private IP (internal load balancer). It can be used to redirect traffic to backend VM pools or VM scale sets, and it’s recommended for non-HTTP(S) load balancing that’s highly available and low-latency.

For applications that might have ingress traffic in the range of millions/second, the Azure load balancer would be beneficial and can be deployed with either a public or private endpoint. Let’s consider an N- tier architecture in Azure with internet traffic terminating on NVAs and then flowing to a web tier, business tier, and backend DB tier. It’s recommended to use a public load balancer to distribute internet traffic to NVAs in the DMZ. Private load balancers, on the other hand, can be used in other non-internet facing tiers, such as web, business, and data tiers, as they only accept traffic from connected subnets.

There are two load balancer SKUs available: Basic and Standard. Standard is recommended for all new workloads, as it supports advanced capabilities, including support for availability zones, an increased count of backend pools, and assured SLAs. For example, where basic load balancers can support a maximum of 100 instances in the backend, standard load balancers can support up to 1,000 instances.

Additionally, standard load balancers can have a combination of VMs in a network, VMs in scale sets, and VMs in availability sets. In basic load balancers, customers are limited to any one of these options. Standard load balancers are recommended for highly available application deployments, since they can be scaled across three availability zones with an assured SLA of 99.99%, whereas availability zones are not supported in basic load balancers.

Azure Application Gateway

Azure Application Gateway operates at Layer 7. It provides web-application firewall capabilities along with load balancing, and can redistribute traffic based on HTTP request attributes, such as URI path and host headers. The SSL termination capability of Azure’s application gateway can be leveraged to encrypt/decrypt traffic, thereby relieving the backend from this additional overhead.

The service supports autoscaling and zone redundancy for an application’s scalability and availability requirements. Multiple-site hosting allows customers to use the same application gateway to host up to 100 websites without any performance impact. Additional features supported by application gateway include HTTP to HTTPS redirection, session affinity, WebSockets, HTTP header rewrites, HTTP2, and custom error pages.

The Web Application Firewall feature of Azure Application Gateway is based on Open Web Application Security Project (OWASP) rule sets. It helps to protect backend applications from many malicious attacks, such as SQL injection, remote file inclusion, cross-site scripting, and command injection. The WAF can operate either in detection mode or prevention mode. Detection mode will simply monitor and log threats but will not block them. Prevention mode, on the other hand, will block malicious requests.

Azure Traffic Manager

Azure Traffic Manager provides DNS-based load balancing, which redirects clients to resources in the backend pool based on the configured traffic-routing mechanism. It is a best-fit solution for distributed architectures where services are distributed across multiple Azure regions, often for business continuity and disaster recovery (DR) purposes. The endpoints that are part of a traffic-manager backend pool can be hosted in Azure, another cloud service provider platform, or even on-premises.

Traffic Manager supports the following routing mechanisms: Priority, Weighted, Performance, Geographic, MultiValue, and Subnet. The Priority method uses one endpoint as primary and the remaining endpoints as backups in case the primary is not available. The Weighted method is used if you want to prioritize traffic distribution across multiple endpoints based on the weights assigned to them. Performance-based routing redirects customers to the nearest endpoint with minimal network latency. The Geographic routing method uses the geographic location of a client’s DNS query to redirect traffic to backend endpoints. The MultiValue method provides IPv4/IPv6 service endpoint addresses as a response to queries reaching the Traffic Manager. Lastly, the Subnet-based routing method redirects traffic to specific backend instances that are mapped to the IP-address range of the end user.

Addressing Security Challenges of Cloud-Native Deployments

Because load balancers are often the entry point of internet traffic, they also become the entry point for hackers trying to infiltrate the network or inject malicious code. Load balancing in its traditional sense is not enough for the refined and unique threat vectors that are present today. You need advanced security measures, like real-time traffic analysis that can implement machine learning intelligence and protect against organized attacks such as DDoS.

Cloud services follow a layered approach for security, and load balancers play a key role in securing the perimeter for your workloads, especially at the application layer. For non-HTTP(S) traffic, this layer of security should be reinforced into the network load-balancing services. For example, in Azure this could be as simple as restricting traffic to load balancers using NSG or implementing advanced threat-management capabilities by integrating Azure Web Application Firewall.

All Layer 7 load-balancing services delivered by the leading cloud service providers have some inherent threat-detection and mitigation capabilities. For instance, Azure Application Gateway has an integrated WAF capability out of the box to protect workloads from common web-based attacks.

Although these native cloud services are useful, they do not provide (nor are they meant to provide) comprehensive security. For example, in an AWS deployment, it is helpful to place an AWS WAF in front of the AWS application load balancer. But AWS WAF (even when combined with AWS Shield) lacks some important capabilities, so it should be augmented with an additional solution. Similarly, in a GCP deployment, Google Cloud Armor can be converted into a full security solution. As for Azure, the Application Gateway WAF includes the Core Rule Set (CRS) from the Open Web Application Security Project (OWASP). These are useful, but they do not provide full coverage in today’s threat environment. To achieve this, it is best to add a cloud security platform such as Reblaze, which integrates seamlessly with Microsoft Azure or AWS WAF and provides turn-key protection.

Specialized Load-Balanced WAF Solutions for Cloud Environments

Along with application workloads, the modern threat environment requires that security workloads are load-balanced too. DDoS attacks and other threats require an autoscaling WAF that can remain performant even when scrubbing massive volumetric assaults. To achieve this, the security solution must run natively on the top-tier cloud platforms, being fully integrated with the platforms’ load-balancing capabilities. For full protection, it must include a next-generation WAF, DDoS protection, bot management (ideally based on UEBA: user and entity behavioral analytics), API security, and more.

Summary

Load balancers have outgrown their initial job description of distributing traffic and ensuring high availability. Today, they also play key roles in securing workloads.

In this short article series, we explored the capabilities offered by the native cloud load-balancing solutions and their best-fit use cases. We also discussed the desired characteristics of a WAF solution for added security of your environments. Whether you use Azure, AWS, GCP, or a hybrid approach, this information can help you select the best solution for your cloud architecture.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.