Load balancers are an integral part of traffic management in a well-designed cloud architecture; they distribute application traffic across multiple servers, which evens out the load. Highly-available deployments in the cloud rely on load balancers to route traffic only to fully functional and healthy backends.
The basic premise of load balancing is simple: to prevent individual VM instances from becoming overwhelmed with incoming traffic. However, in the cloud era, load balancers have evolved much farther. Along with playing an integral role in the high availability of applications, cloud load balancers are also important when protecting mission-critical applications from security threats and vulnerabilities. For example, Reblaze protects sites, web applications, and APIs on all the top-tier cloud platforms (it offers web security for AWS, web security for GCP, and web security for Azure). To accomplish this, Reblaze uses each platform’s native load-balancing capabilities to scale its resources automatically, so that incoming traffic is always scrubbed quickly and efficiently regardless of its volume.
This two-part series will discuss the different load balancers available on these public cloud platforms. We will also explore their advanced features and security management capabilities, to help you choose the right load-balancing solution in the cloud. Here in Part 1, we’ll start with the load-balancing solutions natively available in AWS and GCP.
The Native Solutions
AWS, Azure, and GCP offer multiple native solutions that meet the advanced load-balancing requirements of modern-day cloud applications. Cloud load balancers are offered as managed services and out of the box, they often have built-in high availability. Some load balancers have additional capabilities like autoscaling, which enables horizontal scaling of resources in the backend based on access patterns. A few load balancers also have integrated remediation capabilities to ensure uninterrupted access to an application.
When integrating a load balancer into a cloud application architecture, it’s important to evaluate the available features offered by each service provider.
AWS elastic load balancers support multiple target backends like Amazon EC2, Amazon container service (ACS), IP addresses, and Lambda functions. These instances can be placed in a single availability zone or multiple availability zones for increased fault tolerance. The load balancers can also be configured as Internet-facing (the default option), or for an internal load balancer that’s restricted to a private IP.
The health checks associated with elastic load balancers can also check availability of services in the backend EC2 instances and forward traffic to healthy instances. The load balancing service in itself is fault-tolerant by default and resilient to failures. It can also be actively integrated with Autoscaling to manage the backend capacity based on traffic inflow.
There are three types of elastic load balancers: Application load balancer, Network load balancer, and Classic load balancer.
Application load balancer: This load balancer operates at Layer 7 (HTTP/HTTPS) and can be integrated with advanced workload architectures using EC2, ACS, IP addresses, and Lambda functions. It supports IP addresses as a target, so it can be used for load-balancing hybrid deployments that use on-premises servers as well. The content-based routing feature helps to redirect traffic based on the requested content:host-based, path-based, HTTP-header, query string parameter-based, etc. For example, customers accessing the application can be redirected to a specific backend based on the URL path while using path-based routing.
Using Server Name Indication (SNI), along with a smart-certificate selection algorithm, helps the load balancer select the right certificate for the session when there are multiple certificates matching the requested domain. And the fixed-response support feature helps to serve custom messages or error codes from the load balancer itself without sending traffic to the targets. For example, custom messages can be used to send a “page under maintenance” notification to customers directly from the load balancer. To meet your compliance and security needs, redirects can also be implemented, e.g., redirecting HTTP requests to HTTPS.
Network load balancer: The Network load balancer operates at Layer 4 (TCP/UDP/TLS) and supports workloads hosted in EC2 instances or containers within a VPC. It can also register targets outside a VPC using an IP address. A Network load balancer is optimized for high-performance scenarios, capable of handling heavy traffic with very minimal latency, and best-suited for handling volatile workloads, e.g., financial transactions that can reach millions of requests per second during business hours. Compared to other load balancers, Network load balancers are unique in that they are automatically configured to use a static frontend IP address.
Additionally, a Network load balancer supports advanced features like TLS offloading, where TLS termination is handled by the load balancer while retaining the IP address of backend instances. SNI mapping can be used to serve multiple websites to customers using a single TLS endpoint as well. To ensure high availability and disaster recovery, Network load balancers can be integrated with Amazon Route 53 so that traffic is routed to a secondary load balancer if the load balancer in the primary load region becomes unavailable. This increases fault tolerance of applications, enables multiple availability zones for the load balancer, and distributes the targets across each of the enabled availability zones.
Classic load balancer: This load balancer targets workloads in EC2-Classic networks, can be used to distribute traffic across Amazon EC2 instances, and can be deployed either at Layer 4 (TCP) or Layer 7 (HTTP/HTTPS). While some Layer 7 features such as SSL offloading, sticky sessions, and X-Forwarded are supported in a classic load balancer, it lacks advanced features like WebSocket support, path-based routing, host-based routing, HTTP2, etc.
Although sticky sessions help redirect traffic to specific EC2 instances by leveraging cookies, it’s recommended to adopt a stateless architecture for applications since it’s more suitable for a load-balanced deployment. Customers can enable cross-zone load balancing to distribute traffic among instances in all availability zones.
Google Cloud provides a range of load-balancing services that can be used to distribute traffic at Layer 4 and Layer 7 to VM instances, containers, storage, etc., in the backend. Load balancing can be done for TCP/UDP, HTTP/HTTPS, and SSL traffic.
While using Layer 7 load balancers, the backend resources can either be regional or global. Load balancers in a GCP platform come with built-in intelligence to autoscale the backend when the backend resources are at maximum capacity. It also supports options like Pass through/direct connect load balancing and Proxy-based load balancing. Based on the OSI layer they operate on, the GCP load balancers can be broadly classified as HTTP(S) load balancers and Network load balancers.
HTTP(S) load balancers: These operate at Layer 7 and can be used to distribute both HTTP and HTTPS traffic to virtual machines as well as Google Kubernetes Engine (GKE) nodes in the backend. They are generally classified as internal and external load balancers.
An internal load balancer is based on the open-source Envoy Proxy and can be accessed at a private IP only by resources in the same region as the Google cloud VPC network. The backend services should also be deployed in the same region as the internal load balancer.
Conversely, an external load balancer has a public IP-based endpoint and can be used for tiers of applications that can be exposed to the internet.
HTTP(S) uses a URL map to redirect traffic based on Layer 7 HTTP headers. Behind the scenes, the incoming traffic terminates on an HTTP/HTTPS target proxy which routes the traffic to the backend based on the defined URL map. Health checks are configured to ensure that the traffic is forwarded to a healthy backend.
The load balancers also support HTTPS/HTTP/2 protocols with fine-grained control over the SSL policies that can be used for negotiating with HTTPS clients. The HTTPS load balancer supports SSL offloading, and the client SSL session will be terminated at the load balancer. A signed SSL certificate is mandatory for HTTPS load balancers and can be managed either by the customer or Google.
Network load balancers: These load balancers operate at Layer 4 and support TCP and UDP protocols based on load balancing. It should be noted that a single load balancer can support either TCP or UDP protocols but not both. It is also restricted to redirecting traffic to backends in the same region.
TCP/UDP-based load balancers use a direct server return approach, where the backend VMs send the response directly to clients instead of sending it through the load balancer. The source-machine IP is retained in the packet that passes through the load balancer and the destination IP will be that of the load balancer. So, the backend VMs should have local routes configured to accept such network packets. Since a network load balancer does not have SSL-offloading capability, it is not well-suited for scenarios that use encrypted traffic.
The load balancers offered by AWS and GCP are very similar in terms of capabilities and features, even though the technologies used to enable them are proprietary. In Part 2 of this series, we’ll continue this discussion by exploring load-balancing services in Azure.
We’ll also discuss the key security considerations while integrating load balancers into your cloud architectures.