The good load-balancer to choose and the way to do it with Terraform
Recently I have confronted myself with the need of using a static IP with load-balancers. The reason was to be able to whitelist IP addresses in firewalls. By making some researches, I have discovered that ELBv1 does not support this feature. ELBs manage IP addresses behind the scene you have no control over it.
The first step was to migrate to a network load-balancer (NLB). In the first section, we’re going to inspect its characteristics. Then we put in place a small Terraform project to assigned reserved public IP to an NLB.
Network Load Balancer
At first view, the NLB looks like ELBv1 and offers a single endpoint to the clients. But, it uses target group and listener concepts to manage backend and frontend :
- Listeners wait for connection requests from clients following the defined protocol and port. It forwards the client requests to a configured target group.
- Target groups request the targets that can be EC2 instances for example. A target can belong to several target groups. When defining a target you have to configure the protocol and the destination port. The target group also manages the health check of targets.
The AWS documentation lists the benefits of using an NLB. You can check it out here. NLB focuses on network level and has some limitations :
- You cannot attach security groups to it. If you want to do it, you can attach them to the autoscaling group used by your target.
- The attached security groups expect only CIDR blocks
- Your security groups need to allow the NLB network interfaces for the health check.
The data sources are all in the same file and execute these actions :
- Retrieve availability zones of the current region
- Retrieve Ubuntu 20.04 AMI
- Prepare shell script to install Apache server
The content of the shell script :
sudo apt-get update -y
sudo apt-get install -y apache2
sudo systemctl start apache2
sudo systemctl enable apache2
echo "<h1>Deployed via Terraform</h1>" | sudo tee /var/www/html/index.html
Redundant variables are centralized into
variables.tf. We’ll use one availability zone from the previous data source:
network.tf we define a VPC, a public subnet, an internet gateway, and a route table:
security-groups.tf defines a security group with a rule that authorizes HTTP traffic from everywhere. There will be no issue with the health check of the target group.
We define a launch configuration that :
- Uses the Ubuntu AMI from the previous data source
- Embeds the security group to expose HTTP traffic. As mentioned before this is not possible to add it directly to the NLB resource.
- Handle user-data to install and configure the Apache webserver at boot
- Have a
create_before_destroyflag enabled in the lifecycle block to avoid conflicts in case of launch-configuration recreation
Network load balancer
The AWS EIP is reserved before the creation of the NLB because it has an implicit dependency. The EIP is mapped to the public subnet located in
us-east-1a. You can map as many subnet and EIP you want using a
dynamic block and iterate over the values.
A target group is configured to look for TCP/80 inside the VPC. It has also a health check to ensure all is fine. A listener is configured to forward incoming traffic from the NLB on TCP/80 to the target group :
The security group is registered inside the autoscaling group and uses the launch-configuration to initiate EC2 instance :
Deploy the stack
Init and deploy the stack :
$ terraform init
$ terraform apply
Check AWS web console
In “EC2 > Network & Security > Elastic IPs” we can see the public IP allocated to
In “EC2 > Load-Balancing > Load-Balancers” we can ensure the NLB with the previous EIP mapped on the public subnet in
us-east-1a availability zone :
We open a browser page to http://188.8.131.52 and we have the page configure in the user-data :