Application Load Balancer & new actions

 

Application Load Balancer received upgrade last summer as redirect and fixed responses were introduced as new actions.  Therefore, action possibilities contains at the moment Forward, Authenticate (HTTPS listener only), Redirect, and Fixed responses. These two latest actions enable some simplifications to the environment.

Redirect

I find the Redirect very useful and a real word example is HTTP to HTTPS redirect. HTTP requests don’t need to reach the webserver anymore for HTTP -> HTTPS redirect as the magic happens at the load balancer. Apache/NGINX can be configured to listen only one traffic port as all traffic will be routed through that port. For setting HTTP-> HTTPS redirect up at the ALB, it is only required to select HTTP Listener and a new rule; first the Condition (either Path or Host) and then Redirect Action and type 443 in to the console. The result is that all HTTP requests are redirected to HTTPS.

Figure 1. Redirect as a new action.

Fixed responses

The trend is to move some of the activities away from webserver to the load balancer and utilizing a fixed response is one. For example, certain HTTP error codes can be handled on the load balancer level. Clearly some benefits, but I see that the Redirect will be somewhat more widely used.

Even though these new features will make life somewhat easier, there is one feature that still remains on my wish list. Support for the Application controlled session cookies.

 

-Tero

Loadbalancers

As we know, there are two of them (yes, one might say that three but I ignore the classic one here…). Application LB and Network LB. What is the difference and most of all, when one should prefer the former and when the latter. There are good pack of info provided by AWS that we all should be aware of. Yet, I share some of my own findings…

If the internet traffic is proper packets (HTTP/HTTPS), ALB provides such nice tools to control the traffic among various target groups. One can utilize either host or path routing or both. That enables lots of nice ways to route traffic  for example for containers. Also as the ALB operates on HTTP/HTTPS level, one can let it handle the SSL termination. SSL certifications are pretty easy task to handle in AWS, by the way (more about SSL).

The figure 1 below is a snap of the scenario that single ALB routes traffic for two domains . With host based routing it is possible to route traffic to various target groups accordingly.  And of course it is possible to add also path based routing to it.

Figure1. ALB and host based routing

Network LB is on the other hand the preferred one in a scenario that traffic destination must be IP address, not domain. That could be for example SMS messages that your application is receiving / sending through SMS proxy. Or the traffic is not HTTP/HTTPS… Or something else interesting. Well the bottom line is that the NLB works with TCP level not HTTP/HTTPS level. There is a catch, of course. The IP-address is AZ specific, i.e. for example in Ireland Region there can be defined 3 IP addresses; one for each AZ. Furthermore, AZ-specific IP address more or less  connects application to be only one AZ.  That means that multi-AZ designs for HA and DR should require extra effort…

On architecture point of view, the best way is to place LB in public subnets (in all AZs) and webservers in private subnets (figure 2). LBs will use the private IP-addresses of the EC2. Actually all communication inside AWS is between private IPs, so EC2 point of view the traffic comes from LBs private IP address. That might be a problem in some applications as private IP addresses of loadbalancers are not easy to find out.

Figure 2. Private and public subnets

 

-Tero