Load Balancing AWS Auto Scaling Groups with NGINX Plus

One of the most beneficial features of the cloud is the ability to automatically scale the number of computing instances. With AWS Auto Scaling, you can change the number of EC2 instances in an Auto Scaling group, either manually or automatically, based on schedule or demand. Auto Scaling helps reduce cost by adjusting the number of instances to the right number for the current workload. Additionally, Auto Scaling restarts failed instances, which adds resilience to your applications.

There are three main reasons to choose NGINX Plus as a replacement or an addition to the built‑in AWS cloud load balancers:

NGINX Plus provides multiple advanced features that ELB and ALB lack.

The pricing model for the AWS load balancers (especially ALB) is complex, making it hard to predict costs. NGINX Plus pricing is straightforward, whether you purchase the NGINX Plus subscription directly from us or run prebuilt NGINX Plus instances from the AWS Marketplace, which are billed at a set hourly rate.

NGINX Plus doesn’t tie you to platform‑specific APIs, allowing you to reuse the load balancing configuration across multiple cloud platforms.

To see how NGINX Plus compares to (and works together with) the AWS built‑in solutions, read our blog posts on ELB and ALB.

In this blog post we show two methods of configuring NGINX Plus to load balance Auto Scaling groups, and explain when it makes sense to use each method:

After reading this blog post you will be ready to deploy NGINX Plus on AWS to provide advanced load balancing for Auto Scaling groups.

The Sample AWS Auto Scaling Environment

We’re using a sample application environment to illustrate the two methods for using NGINX Plus to load balance Auto Scaling groups. Our backend web application consists of two services – Backend One and Backend Two – each exposed on port 80. For each service there is an Auto Scaling group of multiple application instances. The load balancer routes client requests to the appropriate backend based on the request URI:

Requests for /backend‑one go to Backend One.

Requests for /backend‑two go to Backend Two.

When we scale the application Auto Scaling groups (either automatically or manually), the load balancer configuration must be updated to reflect the new number of application instances. The built‑in AWS load balancers do this automatically. For NGINX Plus, we need to propagate scaling events to the configuration with one of the methods mentioned above (NGINX Plus in front of ELB, or NGINX Plus with the integration software).

Another way to update the NGINX Plus configuration in response to scaling events is with an external service registry. NGINX Plus supports integration with service discovery systems that provide a DNS interface, such as Consul. In this blog post we focus on solutions that do not rely on using external systems and that are easy to set up and use.

Using NGINX Plus in Front of ELB

If you are already using Auto Scaling groups and ELB, the easiest way to bring some of the advanced features of NGINX Plus to your application is to place NGINX Plus in front of the ELB cloud load balancers, as shown in the diagram:

In this case NGINX Plus acts as a proxy/load balancer for one or more ELBs. Using its advanced routing capabilities, NGINX Plus forwards requests to the appropriate ELB based on the request URI. The ELB then passes the request to one of the instances in the Auto Scaling group. In this configuration, ELB provides the support for scaling.

The resolver directive defines the DNS server that NGINX Plus uses to resolve the DNS names of the internal ELB instances. Here it is the IP address of the AWS DNS server.

We create two upstream blocks, one for each Auto Scaling group corresponding to our services, Backend One and Backend Two. We identify the Auto Scaling group by the DNS name of the ELB that load balances traffic to it.

Using the resolve parameter, we tell NGINX Plus to periodically re‑resolve the name – the frequency is set by the valid parameter to the resolver directive discussed in the previous bullet. Here we set it to 10 seconds because the IP addresses of ELB are subject to frequent change.

The zone directive allocates memory (here up to 64 KB) for storing the resolved IP addresses.

We define a virtual server that listens on port 80. The location blocks tell NGINX Plus to pass requests for /backend‑one to the ELB for the Backend One Auto Scaling group and requests for /backend‑two to the ELB for the Backend Two Auto Scaling group.

As you can see, this method is easy to set up and use, especially if you are already using ELB. However, there are several drawbacks:

Limited load‑balancing options. Because NGINX Plus passes requests to ELB, not to the backend instances directly, it is the ELB that is doing load balancing. For this reason, you cannot take advantage of NGINX Plus’ more sophisticated load‑balancing algorithms and session‑persistence options.

Redundancy. NGINX Plus can do load balancing, so ELB is redundant – we’re using it only because it is natively integrated with Auto Scaling.

Limited protocol support. Unlike NGINX Plus, ELB does not support WebSocket and UDP.

The next method does not rely on ELB and consequently does not have those disadvantages.

Using NGINX Plus with the Integration Software

With this method, you install additional integration software along with NGINX Plus. The software (nginx-asg-sync) constantly monitors Auto Scaling groups. When it sees that a scaling event has happened, it adds or removes backend instances from the NGINX Plus configuration. As shown, nginx-asg-sync learns about changes to Auto Scaling groups via the AWS Auto Scaling API.

The instructions assume that the Auto Scaling groups for the backends already exist. They also assume that NGINX Plus is running on an Amazon Linux AMI.

Step 1 – Set Up Access to the AWS API

Communication with the Auto Scaling API is authenticated, so you must provide credentials for nginx-asg-sync. AWS uses IAM roles to handle credentials, so you need to create a role for the NGINX Plus instance before launching it. For step‑by‑step instructions, see IAM Roles for Amazon EC2 in the AWS documentation.

Create an IAM role and attach the predefined AmazonEC2ReadOnlyAccess policy to it. This policy allows read‑only access to EC2 APIs.

When you launch the NGINX Plus instance, add this IAM role to the instance.

Step 2 – Install the Integration Software

To install the integration software, download the package for your operating system from the nginx-asg-sync GitHub repository, and install it on the instance where NGINX Plus is running.

For Amazon Linux, CentOS, and RHEL:

$ sudo rpm -i package-name.rpm

For Ubuntu:

$ sudo dpkg -i package-name.deb

For complete installation instructions, see the documentation on GitHub.

As in the ELB example, we declare two upstream groups – backend‑one and backend‑two, which correspond to our Auto Scaling groups. Here, however, we do not add any servers to the upstream groups, because the servers will be added by nginx‑aws‑sync. The state directive names the file where the dynamically configurable list of servers is stored, enabling it to persist across restarts of NGINX Plus.

We define a virtual server that listens on port 80. In contrast to the ELB example, NGINX Plus passes requests for /backend‑onedirectly to the instances of the Backend One group, and requests for /backend‑two directly to the instances of the Backend Two group.

We define a second virtual server listening on port 8080 and configure the NGINX Plus APIs on it:

The on‑the‑fly API is available at 127.0.0.1:8080/upstream_conf

The status API is available at 127.0.0.1:8080/status

Step 4 – Configure the Integration Software

The integration software is configured in the file aws.yaml in the /etc/nginx folder. For our application, we define the following configuration:

Testing Load Balancing and Scaling

In the steps above, we configured NGINX Plus to load balance Auto Scaling groups for our application. Now we can test it. NGINX Plus distributes requests with the /backend‑one URI to the instances of the Backend One group, and requests with the /backend‑two URI to the instances of the Backend Two group.

We can see how NGINX Plus picks up new instances when we scale our Auto Scaling groups. First, we access the live activity monitoring dashboard, accessible at /status.html on port 8080 of the NGINX Plus instance. On the Upstream tab we see the instances in our Auto Scaling groups:

Now, we scale up the Backend One group from three to five instances by changing the capacity of the Auto Scaling group. After the new instances are launched, nginx-asg-sync adds them to the NGINX Plus configuration. Soon enough the new instances appear on the dashboard:

Making NGINX Plus Highly Available

So far, we have launched only one instance of NGINX Plus. However, for high availability, we recommend creating an Auto Scaling group for NGINX Plus itself and use ELB in front of the NGINX Plus instances. Alternatively to ELB, you can use Route 53 to route traffic to NGINX Plus instances. The diagram of our deployment with ELB looks like this:

Choosing The Right Method

So, which method of configuring NGINX Plus to load balance Auto Scaling groups is better for you? The table briefly compares the two:

NGINX Plus in Front of ELB

NGINX Plus with the Integration Software

Advantages

Simple configuration and no installation of additional software.

Full benefits of all NGINX Plus features, without any limitations imposed by the ELB method.

Disadvantages

Limits the number of NGINX Plus features you can use, including supported protocols. Increases cost of the deployment as well as latency.

Requires installation and configuration of the integration software.

Summary

Use this method if its disadvantages are acceptable.

Use this method to take full advantage of NGINX Plus’ capabilities.

Summary

AWS Auto Scaling provides the benefit of adjusting the number of application instances to the level of demand. NGINX Plus provides advanced load‑balancing features that can be used in conjunction with AWS Auto Scaling groups.

Have a Cookie? :)

Our site uses cookies to provide functionality and performance as well as for social media and advertising purposes. Social media and advertising cookies of third parties are used to offer you social media functionalities and personalized ads for NGINX content and offers. To get more information about these cookies and how we process personal data, check our Privacy Policy. Do you accept the use of cookies and the processing of personal data involved?

Your Cookie Settings

Site functionality and performance

These cookies are required for NGINX site functionality and are therefore always enabled. These include cookies that allow you to be remembered as you explore the NGINX site, help make the shopping cart and checkout process possible as well as assist in security issues and conforming to regulations. To use the NGINX website, you have to consent to these cookies and the processing of personal data according to the NGINX website terms of use and privacy policy.

Social media and advertising

Social media cookies offer the possibility to connect you to your social networks and share content from our website through social media. Advertising cookies (of third parties) collect information to help better tailor NGINX advertising to your interests, both within and beyond NGINX websites. De-selecting these cookies may result in seeing advertising that is not as relevant to you or you not being able to link effectively with Facebook, Twitter, or other social networks and/or not allowing you to share content on social media.