We’re excited to release some exciting enhancements to help our clients scale and protect workloads in the cloud.
Need a load balancer that’s more responsive and accessible across zones to handle volatile traffic and have confidence that your applications will scale to the demands of your customers? We’ve got the solution.
Wish you could do end-to-end encryption of your workloads? Your wait is over.
Need to connect to a load balancer over the internet? We have you covered.
Looking for a load balancer that makes smarter load balancing decisions and applies optimizations and changes to the content (such as compression and encryption)? You are good to go!
At IBM Cloud, we’ve taken stock of our clients’ wishes, needs, and wants. Today, we are proud to announce that IBM Cloud Load Balancer has released the following enhancements to help our clients scale and protect workloads in the cloud:
- Multi-Zone Region (MZR) availability
- Backend encryption
- Public-to-public load balancer
- Layer7 Routing
Now supporting Multi-Zone Regions (MZR)
A region is a geographically and physically separate group of one or more availability zones with independent electrical and network infrastructures isolated from other regions. Regions are designed to remove shared single points of failure with other regions and guarantee low inter-zone latency within the region. There are currently six MZR’s supported by IBM Cloud Load Balancer spread over North America, Europe, Asia, and Australia.
An availability zone is a logically and physically isolated location within an IBM Cloud Region with independent power, cooling, and network infrastructures isolated from other zones to strengthen fault tolerance by avoiding single points of failure between zones, while also guaranteeing high bandwidth and low inter-zone latency within a region. There are three availability zones per MZR.
IBM Cloud Load Balancer now supports the creation of load balancer resources in different zones of a region provided that the load balancer is created in a data center that is part of an MZR and the account has VLAN spanning or VRF enabled.
With this feature, the load balancer resource is deployed in multiple availability zones. For example, if you create a load balancer in the dal10 data center, your load balancer resources will be created in two of the three availability zones (dal10, dal12, and dal13) of the US-south region.
Even if there is some outage affecting an entire zone, your application will continue to function without any issue since the load balancer instances are distributed across different zones of the same region, thereby increasing the reliability and availability of your application on IBM Cloud. With MZR enabled, the appliances will be balanced across different zones even when the load balancer scales up and down based on the volume of incoming traffic.
IBM Cloud Load Balancer with backend encryption feature provides end-to-end security. With this feature, customers can configure HTTPS backends with HTTS frontend listener configurations. Prior to this capability, customers had to choose HTTP backend with HTTPS frontend, which left backend traffic unencrypted. Customers desiring end-to-end security had to choose the TCP protocol to terminate SSL directly on the backend servers. With backend encryption, customers can choose to terminate SSL at the load balancer (with a valid certificate providing authentication), and re-encrypt backend traffic by selecting HTTPS for their backend protocol.
Public-to-public load balancer
IBM Cloud Load Balancer can now be ordered as public-to-public. Initially, IBM Cloud only offered two types of load balancers: Public-to-private and private-to-private. This meant that the target backend servers had to be on the private network.
Now, we have introduced a new flavor of load balancer: Public-to-public. This is a public-facing load balancer, which means that clients can connect to the load balancer over the internet. The load balancer then connects to the backend servers via their public IP addresses.
IBM Cloud Load Balancer now supports all Layer7 routing configurations for HTTP and HTTPS protocols. These include the creation of the following:
- Backend pools, including specific backend servers that are targeted to receive traffic filtered by Layer7 properties. Backend servers can belong to multiple pools, so a single load balancer can serve multiple applications that run on the same set of backend servers.
- Policies—actions that can be performed on requests like redirect to a particular pool of backend servers, redirect to a URL, or reject.
- Rules for each policy to determine which requests to apply the policy. Examples include requests with a particular value of header, cookie, URL path, hostname or file type. The comparison performed to evaluate the rule can be
REGEX, which means you don’t need to know the exact value for comparison, but rather just a part of the value is sufficient to match the required parameter and perform Layer7 routing based on it.
Ready to get started?
Are you already a customer? Stay up to date on these new capabilities and learn more in our documentation.