Amazon AWS Amazon New Layer 7 Application Load Balancer

eva2000 · Aug 16, 2016

Amazon AWS announced that their existing Layer 4 Elastic Load Balancer has a new featured offering, Layer 7 based Application Load Balancing New – AWS Application Load Balancer | AWS Blog including the much needed HTTP/2 support !

On the Level
Per the well-known OSI model, load balancers generally run at Layer 4 (transport) or Layer 7 (application).

A Layer 4 load balancer works at the network protocol level and does not look inside of the actual network packets, remaining unaware of the specifics of HTTP and HTTPS. In other words, it balances the load without necessarily knowing a whole lot about it.

A Layer 7 load balancer is more sophisticated and more powerful. It inspects packets, has access to HTTP and HTTPS headers, and (armed with more information) can do a more intelligent job of spreading the load out to the target.

Application Load Balancing for AWS

Today we are launching a new Application Load Balancer option for ELB. This option runs at Layer 7 and supports a number of advanced features. The original option (now called a Classic Load Balancer) is still available to you and continues to offer Layer 4 and Layer 7 functionality.

Application Load Balancers support content-based routing, and supports applications that run in containers. They support a pair of industry-standard protocols (WebSocket and HTTP/2) and also provide additional visibility into the health of the target instances and containers. Web sites and mobile apps, running in containers or on EC2 instances, will benefit from the use of Application Load Balancers.

Let’s take a closer look at each of these features and then create a new Application Load Balancer of our very own!

Content-Based Routing
An Application Load Balancer has access to HTTP headers and allows you to route requests to different backend services accordingly. For example, you might want to send requests that include /api in the URL path to one group of servers (we call these target groups) and requests that include /mobile to another. Routing requests in this fashion allows you to build applications that are composed of multiple microservices that can run and be scaled independently.

As you will see in a moment, each Application Load Balancer allows you to define up to 10 URL-based rules to route requests to target groups. Over time, we plan to give you access to other routing methods.

Support for Container-Based Applications
Many AWS customers are packaging up their microservices into containers and hosting them on Amazon EC2 Container Service. This allows a single EC2 instance to run one or more services, but can present some interesting challenges for traditional load balancing with respect to port mapping and health checks.

The Application Load Balancer understands and supports container-based applications. It allows one instance to host several containers that listen on multiple ports behind the same target group and also performs fine-grained, port-level health checks

Better Metrics
Application Load Balancers can perform and report on health checks on a per-port basis. The health checks can specify a range of acceptable HTTP responses, and are accompanied by detailed error codes.

As a byproduct of the content-based routing, you also have the opportunity to collect metrics on each of your microservices. This is a really nice side-effect that each of the microservices can be running in its own target group, on a specific set of EC2 instances. This increased visibility will allow you to do a better job of scaling up and down in response to the load on individual services.

The Application Load Balancer provides several new CloudWatch metrics including overall traffic (in GB), number of active connections, and the connection rate per hour.

Support for Additional Protocols & Workloads
The Application Load Balancer supports two additional protocols: WebSocket and HTTP/2.

WebSocket allows you to set up long-standing TCP connections between your client and your server. This is a more efficient alternative to the old-school method which involved HTTP connections that were held open with a “heartbeat” for very long periods of time. WebSocket is great for mobile devices and can be used to deliver stock quotes, sports scores, and other dynamic data while minimizing power consumption. ALB provides native support for WebSocket via the ws:// and wss:// protocols.

HTTP/2 is a significant enhancement of the original HTTP 1.1 protocol. The newer protocol feature supports multiplexed requests across a single connection. This reduces network traffic, as does the binary nature of the protocol.

The Application Load Balancer is designed to handle streaming, real-time, and WebSocket workloads in an optimized fashion. Instead of buffering requests and responses, it handles them in streaming fashion. This reduces latency and increases the perceived performance of your application.
Click to expand...

eva2000 · Aug 16, 2016

Curious about pricing AWS | Elastic Load Balancing | Application Load Balancer Pricing seems it's based on regions and ranges from:

$0.0225 per Application Load Balancer-hour (or partial hour) + $0.008 per LCU-hour (or partial hour)

$0.0243 per Application Load Balancer-hour (or partial hour) + $0.008 per LCU-hour (or partial hour)

$0.0252 per Application Load Balancer-hour (or partial hour) + $0.008 per LCU-hour (or partial hour)

LCU Details
An LCU measures the dimensions on which the Application Load Balancer processes your traffic (averaged over an hour). The three dimensions measured are:

Number of new connections: Measures newly established connections per second.

Number of active connections: Measures number of active connections per minute.

Bandwidth: Measures the amount of traffic processed by the load balancer in Mbps.

You are charged only on the dimension with the highest usage. An LCU contains:

Up to 25 new connections per second.

Up to 3,000 active connections per minute.

Up to 2.22 Mbps

Click to expand...

Pricing Example
Let’s assume your application receives 1 new connection per second, each lasting 2 minutes and consuming 300 KB in bandwidth. We calculate your monthly Application Load Balancer costs using pricing in the US-East-1 Region as follows:

New connections (per second): each LCU provides up to 25 new connections per second (averaged over the hour). Since your application receives 1 new connection per second, this translates to 0.04 LCUs (1 connection per second / 25 connections per second);

Active connections (per minute): each LCU provides up to 3,000 active connections per minute. Your application receives 1 new connection per second, each lasting 2 minutes. This translates to 120 active connections per minute, or 0.04 LCUs (120 active connections / 3,000 active connections);

Bandwidth (Mbps): each LCU provides 2.22 Mbps averaged over the hour. Since your application transfers 300 KB in bandwidth per connection, that is 2.4 Mbps or 1.08 LCUs (2.4 Mbps / 2.22 Mbps).

Using these values, the hourly bill is calculated by taking the maximum LCUs consumed across the three dimensions. In this example, the bandwidth dimension (1.08 LCUs) is greater than both the new connections (0.04 LCUs) and active connections (0.04 LCUs), resulting in a total charge of $0.008 per hour (1.08 LCUs * $0.008 per LCU) or $6.19 per month ($0.0086 * 24 hours * 30 days).

Adding the hourly charge of $0.0225, the total Application Load Balancer costs are:

$0.03 per hour ($0.0225 hourly charge + $0.0086 LCU charge); or

$22.39 per month ($0.0311 * 24 hours * 30 days).

Click to expand...

Ouch that is kind of expensive for 1 new connection per second lasting 2 minutes and 300KB bandwidth = $22.39/month ! Better off using Nginx as load balancer at TCP or Application level or using Haproxy

eva2000 · Aug 16, 2016

lol Nginx folks already responded to Amazon AWS Application Load Balancer announcement at Choosing the Right Load Balancer on Amazon: AWS Application Load Balancer vs. NGINX Plus - NGINX

Anyone running highly available, scalable applications on Amazon Web Services (AWS) now can choose between load balancing with NGINX or NGINX Plus; AWS Elastic Load Balancer, now called Classic Load Balancer; and the new Application Load Balancer, described by Amazon as an option for Elastic Load Balancing.

The new option is described in a blog post and product documentation. In this post, we will review the new features in Amazon Load Balancer, then compare its pricing and features to open source NGINX and NGINX Plus. We will also describe the role of Classic Load Balancer with respect to these alternatives.

Note: See our previous blog post for a direct comparison of NGINX Plus and AWS Classic Load Balancer, as well as information on using them together.
Click to expand...

ALB is a significant update for AWS users who have struggled with ELB’s limited feature set, and it goes some way towards addressing the requirements of sophisticated users who need to be able to secure, optimize and control the traffic to their web applications. However, it does fall short of the capabilities of dedicated reverse proxies (such as NGINX) and load balancers (such as NGINX Plus).

A Better Approach to Control Traffic on AWS
Rather than using Amazon ALB, users can deploy open source NGINX or NGINX Plus on AWS to control and load balance traffic. They may wish to deploy Amazon Classic Load Balancer as a front-end to achieve high availability across multiple availability zones.
Click to expand...

side by side compare

Log in / Register

Forums

Join the community today

Amazon AWS Amazon New Layer 7 Application Load Balancer

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Join the community today

Amazon AWS Amazon New Layer 7 Application Load Balancer

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.