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

SSL Termination

Application loadbalancers are handy tools to handle SSL termination. It is not a huge task for webservers but still, if one can let AWS to do the job, why not?

Basically, it means that LB will have HTTP and HTTPS listeners but it routes traffic to target groups as HTTP. Target groups should be in private subnets and inbound rules in target groups’ security groups should allow traffic only from LB’s security group.

Figure1. Loadbalancer in public subnets and EC2 instances in private subnets

SSL-termination task begins with SSL-certification generation. With AWS that task is easy, especially when premium DNS service Route53 is used. During LB creation, select (add) HTTPS listener, pick all your AZs with public subnets, and then moving forward to SSL & ACM. Click “Request a new certificate from ACM”.

Figure2. Configuring HTTPS for ALB

On ACM screen, write your domain name (don’t forget to add *.domain).

Figure3. Request a certificate

On Step 2, select DNS validation, and then Review -> Confirm&Request.

Figure4. DNS validation during the new certification request process 

On Validation phase, just click on Create record in Route 53, and voila, you will have SSL certification for your domain. You will find a new Record set (CNAME) in your domain’s hosted zone. The SSL-certification is added to ACM and you don’t have to remember to renew the certification. Life becomes a bit easier.

Figure5. Validation phase

Now when you go back to LB creation, refresh the Certification name list and you should find the brand new certification on the list. Select that and move forward selecting Security groups and target groups.

Now your ALB is listening HTTP (80) and HTTPS (443) and routing traffic to target group with HTTP (80 and 443) and target group don’t have to take care of SSL termination.  The final touch will be on webservers. Then Rewrite rules & Rewrite conditions should be defined for Apache or NGINX to make sure that they are on the same page (accepting HTTP).

For example something like (Apache):

<VirtualHost *:80>
...
ReWriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
...
</VirtualHost>

-Tero