This deployment guide explains how to configure global server load balancing (GSLB) of traffic for web domains hosted in Amazon Web Services (AWS) Elastic Compute Cloud (EC2). For high availability and improved performance, you set up multiple backend servers (web servers, application servers, or both) for a domain in two or more AWS regions. Within each region, NGINX Plus load balances traffic across the backend servers.

The AWS Domain Name System (DNS) service, Amazon Route 53, performs global server load balancing by responding to a DNS query from a client with the DNS record for the region that is closest to the client and hosts the domain. For best performance and predictable failover between regions, “closeness” is measured in terms of network latency rather than the actual geographic location of the client.

For your convenience, the Appendix provides instructions for creating EC2 instances with NGINX and NGINX Plus installed as required for the tutorial in this guide:

About NGINX Plus

NGINX Plus is the commercially supported version of the open source NGINX software. NGINX Plus is a complete application delivery platform, extending the power of NGINX with a host of enterprise‑ready capabilities that enhance an AWS application server deployment and are instrumental to building web applications at scale:

Topology for Global Load Balancing with Route 53 and NGINX Plus

The setup for global server load balancing (GSLB) in this tutorial combines Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances, Amazon Route 53, NGINX Plus instances, and open source NGINX instances:

Note: Global server load balancing is also sometimes called global load balancing (GLB). The terms are used interchangeably in this guide.

Diagram showing a topology for global server load balancing (GSLB). Eight backend servers, four in each of two regions, host the content for a domain. Two NGINX Plus load balancers in each region route traffic to the backend servers. For each client requesting DNS information for the domain, Amazon Route 53 provides the DNS record for the region closest to the client.

Route 53 is a Domain Name System (DNS) service that performs global server load balancing by routing each request to the AWS region closest to the requester’s location. The tutorial uses two regions: US West (Oregon) and US East (N. Virginia).

In each region, two or more NGINX Plus load balancers are deployed in a high‑availability (HA) configuration. In the tutorial, there are two NGINX Plus load balancer instances per region. You can also use the open source NGINX software for this purpose, but it lacks the application health checks that make for more precise error detection. For simplicity, we’ll refer to NGINX Plus load balancers throughout the tutorial, noting when features specific to NGINX Plus are used.

The NGINX Plus instances load balance traffic across web or app servers in their region. The diagram shows four backend servers, but you can deploy as many as needed. In the tutorial, there are two open source NGINX web servers in each region (four total); each one serves a customized static page identifying the server so you can track how load balancing is working.

Health checks are an integral feature of the configuration. Route 53 monitors the health of each NGINX Plus load balancer, marking it as down if a connection attempt times out or the HTTP response code is not 200OK. Similarly, the NGINX Plus load balancer monitors the health of the upstream web servers and propagates those errors to Route 53. If both web servers or both NGINX Plus instances in a region are down, Route 53 fails over to the other region.

Prerequisites and Required AWS Configuration

The instructions assume you have the following:

  • An AWS account.
  • An NGINX Plus subscription, either purchased or a free 30-day trial.
  • Familiarity with NGINX and NGINX Plus configuration syntax. Complete configuration snippets are provided, but not analyzed in detail.

The tutorial uses eight EC2 instances, four in each of two regions. For your convenience, instructions for installing and configuring them are provided in the indicated sections of the Appendix:

  1. Four EC2 instances with elastic IP addresses in each of the two regions Creating AWS EC2 Instances
  2. Open source NGINX on two EC2 instances in each region to act as web servers Setting Up Backend Servers
  3. NGINX Plus on two EC2 instances in each region to act as load balancers Setting Up NGINX Plus Load Balancers

Configuring Global Server Load Balancing

With the required AWS configuration in place, we’re ready to configure Route 53 for global server load balancing.

Complete step‑by‑step instructions are provided in the following sections:

  1. Creating a Hosted Zone
  2. Linking the Domain to EC2 Instances
  3. Configuring Health Checks for Route 53 Failover
  4. Configuring NGINX Plus Application Health Checks

Creating a Hosted Zone

Create a hosted zone, which basically involves designating a domain name to be managed by Route 53. As covered in the instructions, you can either use (transfer) an existing domain name or purchase a new one from Amazon.

Note: When you transfer an existing domain, it can take up to 48 hours for the updated DNS record to propagate. The propagation time is usually much shorter for a new domain.

  1. Log in to the AWS Management Console (console.aws.amazon.com/).
  2. Access the Route 53 dashboard page by clicking Services in the top AWS navigation bar, mousing over Networking in the All AWS Services column and then clicking Route 53.

    Screenshot showing how to access the Amazon Route 53 dashboard to configure global load balancing (GLB) with NGINX Plus

  3. Depending on your history working with Route 53 instances, you might see the Route 53 Dashboard. Navigate to the Registered domains tab, shown here:

    Screenshot showing the Route 53 Registered domains tab during configuration of NGINX GSLB (global server load balancing)

    If you see the Route 53 home page instead, access the Registered domains tab by clicking the  Get started now  button under Domain registration.

    Screenshot showing the Amazon Route 53 homepage for a first-time Route 53 user during configuration of AWS GSLB (global server load balancing) with NGINX Plus

  4. On the Registered domains tab (the first figure in the Step 3), click either the  Register Domain  or  Transfer Domain  button as appropriate and follow the instructions.
  5. When you register or transfer a domain, AWS by default creates a hosted zone for it. To verify that there is a hosted zone for your domain, navigate to the Hosted Zones tab on the Route 53 dashboard. This example shows the domain we registered for the tutorial, nginxroute53.com.

    Screenshot showing a newly registered hosted zone during configuration of Route 53 global load balancing (GLB) with NGINX Plus

    (If no domain is listed, click the  Create Hosted Zone  button. The Create Hosted Zone column opens on the right side of the tab. Type the domain name in the Domain Name field and click the  Create  button at the bottom of the column.)

Now we link the domain to our EC2 instances so that content for the domain can be served from them. We do this by creating Route 53 record sets for the domain. To implement GSLB, in the record sets we specify Latency as the routing policy. This means that in response to a client query for DNS information about a domain, Route 53 sends the DNS records for the region hosting that domain in which servers are responding most quickly to addresses in the client’s IP range.

You can also select Geolocation as the routing policy, but failover might not work as expected. With the Geolocation routing policy, only clients from a specific a continent or country can access the content on a server. If you specify the United States, you also have the option of specifying a state as the “sublocation,” limiting access to users from only that state. In this case, you can also create a generic US location to catch all requests that aren’t sent from a listed sublocation.

We recommend that you choose Geolocation as the routing policy only for particular use cases, for example when you want to customize content for users in different countries – written in the country’s official language with prices in its currency, say. If your goal is to deliver content as quickly as possible, Latency remains the best routing policy.

Create records sets for your domain:

  1. If you’re not already on the Hosted Zones tab of the Route 53 dashboard, navigate to it.
  2. Click on the domain name in the Domain Name row for your hosted zone.

    Screenshot showing how to access the Create Record Set interface for Route 53 hosted zone during configuration of AWS global load balancing (GLB) with NGINX Plus

    The tab changes to display the record sets for the domain.

  3. Click the  Create Record Set  button. The Create Record Set column opens on the right side of the tab, as shown here:

    Screenshot showing Create Record Set interface in Route 53 during configuration of global load balancing (GLB) with NGINX Plus

  4. Fill in the fields in the Create Record Set column:

    • Name – You can leave this field blank, but for the tutorial we are setting the name to www.nginxroute53.com.
    • Type – A – IPv4 address.
    • Alias – No.
    • TTL (Seconds) – 60.

      Note: Reducing TTL from the default of 300 in this way can decrease the time that it takes for Route 53 to fail over when both NGINX Plus load balancers in the region are down, but there is always a delay of about two minutes regardless of the TTL setting. This is a built‑in limitation of Route 53.

    • Value – Elastic IP addresses of the NGINX Plus load balancers in the first region [in the tutorial, US West (Oregon)].
    • Routing Policy – Latency.
  5. A new area opens when you select Latency. Fill in the fields as indicated (see the figure below):

    • Region – Region to which the load balancers belong (in the tutorial, us-west-2).
    • Set ID – Identifier for this group of load balancers (in the tutorial, US West LBs).
    • Associate with Health Check – No.

    When you complete all fields, the tab looks like this:

    Screenshot showing a completed Route 53 record set during configuration of global server load balancing (GSLB) with NGINX Plus

  6. Click the  Create  button.
  7. Repeat Steps 3 through 6 for the load balancers in the other region [in the tutorial, US East (N. Virginia)].

You can now test your website. Insert your domain name into a browser and see that your request is being load balanced between servers based on your location.

Configuring Health Checks for Route 53 Failover

To trigger failover between AWS regions, we next configure health checks in Route 53. Route 53 monitors the NGINX Plus load balancers and fails over to the next closest region if both NGINX Plus load balancers are timing out or returning HTTP status codes other than 200OK. (In the tutorial, failover is to the other region, since there are only two.)

Note: It can take up to three minutes for Route 53 to begin routing traffic to another region. Although the TTL you specify in the record set for a region can slightly affect the amount of time, failover is never instantaneous because of the processing Route 53 must perform.

Diagram showing failover between AWS regions when Amazon Route 53 is configured for global load balancing (GLB) with NGINX Plus

We create health checks both for each NGINX Plus load balancer individually and for the load balancers in each region as a pair. Then we update the record sets created in the previous section to refer to the health checks.

Configure Route 53 health checks for individual load balancers:

  1. Navigate to the Health checks tab on the Route 53 dashboard.

    Screenshot of Amazon Route 53 welcome screen seen by first-time user of Route 53 during configuration of global server load balancing (GSLB) with NGINX Plus

  2. Click the  Create health check  button. The Configure health check form opens.

    Screenshot of Amazon Route 53 interface for configuring health checks, during configuration of AWS global load balancing (GLB) with NGINX Plus

  3. Specify the following values:

    • Name – Identifier for an NGINX Plus load balancer instance, for example US West LB 1.
    • What to monitor – Endpoint.
    • Specify endpoint by – IP address.
    • IP address – The elastic IP address of the NGINX Plus load balancer.
    • Port – The port advertised to clients for your domain or web service (the default is 80).
  4. Click the  Next  button.
  5. On the Get notified when health check fails screen that opens, set the Create alarm radio button as appropriate.

    Screenshot of Route 53 configuration screen for enabling notifications of failed health checks, during configuration of Route 53 global load balancing (GLB) with NGINX Plus

  6. Click the  Create health check  button.
  7. Repeat Steps 2 through 6 for your other NGINX Plus load balancers (in the tutorial, US West LB 2, US East LB 1, and US East LB 2).

Configure Route 53 health checks for the paired load balancers in each region:

  1. Click the  Create health check  button.
  2. In the Configure health check form that opens, specify the following values:

    • Name – Identifier for the pair of NGINX Plus load balancers in the first region, for example US West LBs.
    • What to monitor – Status of other health checks….
    • Health checks to monitor – The health checks of the two US West load balancers (add them one after the other by clicking in the box and choosing them from the drop‑down menu as shown).

      Screenshot of Amazon Route 53 interface for configuring a health check of combined other health checks, during configuration of global server load balancing (GSLB) with NGINX Plus

    • Report healthy when – at least 1 of 2 selected health checks are healthy.
  3. Click the  Next  button.
  4. On the Get notified when health check fails screen that opens, set the Create alarm radio button as appropriate (see Step 5 above).
  5. Click the  Create health check  button.
  6. Repeat Steps 8 through 12 for the load balancers in the other region [in the tutorial, US East (N. Virginia)].

When you have finished configuring all six health checks, the Health checks tab looks like this:

Screenshot showing six successfully configured health checks in Amazon Route 53, during configuration of NGINX GSLB (global server load balancing)

Modify your records sets to associate them with the newly defined health checks:

  1. Navigate to the Hosted Zones tab.
  2. Click on the domain name in the Domain Name row for your hosted zone.

    Screenshot showing how to access the Create Record Set interface for Route 53 hosted zone during configuration of AWS global load balancing (GLB) with NGINX Plus

    The tab changes to display the record sets for the domain.

  3. Click in the row for the record set for your first region [in the tutorial, US West (Oregon)]. The Edit Record Set column opens on the right side of the tab.

    Screenshot of interface for editing Route 53 record sets during configuration of global server load balancing (GSLB) with NGINX Plus

  4. Change Associate with Health Check to Yes.
  5. In the Health Check to Associate field select the paired health check for your first region (in the tutorial, US West LBs).
  6. Click the  Save Record Set  button.

Configuring NGINX Plus Application Health Checks

When you are using the NGINX Plus load balancer, we recommend that you to configure application health checks of your backend servers. You can configure NGINX Plus to check more than simply whether a server is responding or returning 5xx – for example, checking whether the content returned by the server is correct. When a server fails a health check, NGINX Plus removes it from the load‑balancing rotation until it passes a configured number of consecutive health checks. If all backend servers are down, NGINX Plus sends a 5xx error to Route 53, which triggers a failover to another region.

These instructions assume that you have configured NGINX Plus on two EC2 instances in each region, as instructed in Setting Up NGINX Plus Load Balancers.

They also assume that you have root privileges, and show the base form of each command. If appropriate for your environment, prefix the commands with the sudo command.

  1. Connect to the US West LB 1 instance, following the instructions in Connecting to an Instance.
  2. Change directory to /etc/nginx/conf.d.

    $ cd /etc/nginx/conf.d
  3. Edit the west-lb1.conf file and add the bolded text to set up health checks.

    upstream backend-servers {
    server public‑DNS‑name‑of‑backend1; # Backend 1
    server public‑DNS‑name‑of‑backend2; # Backend 2
    zone backend-servers 64k;
    }

    server {
    location / {
    proxy_pass http://backend-servers;
    }

    location @healthcheck {
    proxy_pass http://backend-servers;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
    health_check uri=/ interval=1s;
    }

    }

  4. Verify the validity of the NGINX configuration and load it.

    $ nginx -t
    $ nginx -s reload
  5. Repeat Steps 1 through 4 for the other three load balancers (US West LB 2, US East LB 1, and US East LB2).

    In Step 3, change the filename as appropriate (west-lb2.conf, east-lb1.conf, and east-lb2.conf). In the east-lb1.conf and east-lb2.conf files, the server directives specify the public DNS names of Backup 3 and Backup 4.

Appendix – Creating and Configuring EC2 Instances

The instructions in this appendix explain how to create and configure the EC2 instances used in the GSLB tutorial:

Creating AWS EC2 Instances

In the GLB tutorial, we are using eight EC2 instances, four in each of two AWS regions. In each region, two instances run NGINX Plus to load balance traffic to the backend (open source NGINX) web servers running on the other two instances. Follow these two subprocedures to create the instances:

Creating and Launching EC2 Instances

  1. Pick two AWS regions to host the EC2 instances in your global server load balancing deployment. In this tutorial, we’re using US West (Oregon) and US East (N. Virginia).
  2. Log in to the AWS Management Console for EC2 (console.aws.amazon.com/ec2/).
  3. Depending on your history working with EC2 instances, you might see the EC2 Dashboard page:

    Screenshot of the AWS EC2 Dashboard used to create instances as a prerequisite to configuring global load balancing (GLB) with NGINX Plus

    If not, access it by clicking  Services  in the top AWS navigation bar, mousing over Compute in the All AWS Services column and then clicking EC2.

    Screenshot showing how to access the EC2 Dashboard to create instances as a prerequisite for configuring AWS global load balancing (GLB) with NGINX Plus

  4. On the EC2 Dashboard, verify that the name of your first AWS region appears on the right side of the top AWS navigation bar (see the first figure in Step 3, which shows the first region for the tutorial,  Oregon ). Switch to the correct region if necessary.
  5. Click the  Launch Instance  button to create a new instance.
  6. On the Step 1 page, click the  Select  button for the Linux distribution of your choice (we’re using Ubuntu Server 14.04 LTS (HVM), SSD Volume Type).

    Screenshot of the interface for choosing an Amazon Machine Image (AMI) while creating an instance as a prerequisite to configuring Route 53 global load balancing (GLB) with NGINX Plus

  7. On the Step 2 page, choose the appropriate instance type. We’re using the t2.micro instance, which is normally selected by default.

    Note: At the time of publication of this guide, AWS gives you 750 hours of free usage per month with this instance type during the first year of your AWS account. Keep in mind, however, that the 8 instances in the tutorial running 24 hours a day use up the 750 hours in just under 4 days.

    Screenshot of the interface for choosing an AWS EC2 instance type as a prerequisite for configuring AWS GSLB (global server load balancing) with NGINX Plus

  8. By default EC2 instances accept only SSH traffic. To allow incoming HTTP and HTTPS traffic:

    1. At the top of the window, click 6. Configure Security Group.

      Screenshot showing how to access the interface for configuring the security group for an AWS EC2 instance as a prerequisite to configuring NGINX GSLB (global server load balancing)

    2. On the Step 6 page, click the  Add Rule  button below the table, then select HTTP in the Type column. We are allowing access to our instances from any IP address (the value in the Source column is Anywhere).
    3. Repeat the previous step for HTTPS.

    When you’re finished, the tab looks like this:

    Screenshot of the interface for configuring the security group for an AWS EC2 instance as a prerequisite to configuring global server load balancing (GSLB) with NGINX Plus

  9. Click the  Review and Launch  button at the bottom of the page.
  10. On the Step 7 page, click the  Launch  button at the bottom.
  11. In the box that pops up, create a new key pair:

    1. Select Create a new key pair from the upper drop‑down menu.

      Screenshot showing how to create a new key pair for an AWS EC2 instance as a prerequisite to configuring global load balancing (GLB) with NGINX Plus

    2. Type a name in the Key pair name field.

      Screenshot of the interface for naming the key pair for a new AWS EC2 instance as a prerequisite to configuring AWS global load balancing (GLB) with NGINX Plus

    3. Click the  Download Key Pair  button.
    4. In your file manager utility, move the downloaded .pem file to a secure location. For the tutorial we’re placing it in the /Desktop/NGINX directory.
    5. Click the  Launch Instances  button.

     

    Note: As you repeat this step when creating additional instances, you have the option of reusing a previously created key. It’s a best practice – and essential in a production environment – to create a separate key for each EC2 instance, so that if a key is compromised only the single associated instance becomes vulnerable.

    If you choose to share keys across instances in a development or test environment, in Step 11a select Choose an existing key pair from the upper drop‑down menu. In Step 11b choose an existing key from the Key pair name drop‑down menu, and check the checkbox below the field. Finish by clicking the  Launch Instances  button.

  12. On the Launch Status page that opens, click the  View Instances  button at the bottom.
  13. Name the new instance US West LB 1:

    1. Click the pencil icon in the Name column.
    2. Type the name in the field and click the check‑mark icon.

    Screenshot showing how to name a new AWS EC2 instance as a prerequisite to configuring Route 53 global load balancing (GLB) with NGINX Plus

  14. Create three more instances in the first region (in the tutorial, Oregon). For each one:

    1. Click the  Launch Instance  button above the list of newly created instances.
    2. Repeat Steps 6 through 13. In Step 13, name the instances US West LB 2, Backend 1, and Backend 2.

  15. Switch to the second region – in the tutorial,  N. Virginia  – by selecting it from the drop‑down menu in the top AWS navigation bar (see Step 4).
  16. Create four instances in the second region by repeating Steps 6 through 13 for each one. For the tutorial, name the instances US East LB 1, US East LB 2, Backend 3, and Backend 4.
  17. Here’s the Instances tab after we create the four instances in the N. Virginia region.

    Screenshot showing newly created EC2 instances in one of two regions, which is a prerequisite to configuring AWS GSLB (global server load balancing) with NGINX Plus

    Configuring Elastic IP Addresses

    By default, AWS assigns a different IP address to an EC2 instance each time you shut it down and spin it back up. Because the NGINX load balancer uses a specific IP address for each backend server, with the default you must modify the NGINX configuration every time you shut down and restart a backend instance. Similarly, you have to modify the Route 53 configuration when you shut down and restart an NGINX instance. To get around this inconvenience, we assign elastic IP addresses to the instances.

    Note: AWS does not charge for elastic IP addresses as long as the associated instance is running. But when you shut down an instance, AWS charges a small amount to maintain the association to an elastic IP address. For details, see the Elastic IP Addresses section on the Amazon EC2 Pricing page.

    Associate an elastic IP address with each EC2 instance:

    1. Navigate to the Elastic IPs tab on the EC2 Dashboard.

      Screenshot of the Elastic IPs tab used during configuration of a new AWS EC2 instance, which is a prerequisite to configuring NGINX GSLB (global server load balancing)

    2. Click the  Allocate New Address  button. In the window that pops up, click the  Yes, Allocate  button and then the  Close  button.

    3. Associate the elastic IP address with an EC2 instance:

      1. Right‑click in the IP address’ row and select  Associate Address  from the drop‑down menu that appears.
      2. In the window that pops up, click in the Instance field and select an instance from the drop‑down menu:

        Screenshot of the interface for associating an AWS EC2 instance with an elastic IP address, which is a prerequisite to configuring AWS global load balancing (GLB) with NGINX Plus

      3. Click the  Associate  button.
    4. Repeat Steps 1 through 3 for the other three EC2 instances in the current AWS region (for the tutorial,  N. Virginia  is still selected in the top AWS navigation bar).
    5. Switch to the other region (for the tutorial,  Oregon ).
    6. Repeat Steps 1 through 3 for each of the four EC2 instances in the other region.

    After you complete Step 6, the list of instances for a region looks like this (the example shows the list for Oregon):

    Screenshot showing the elastic IP addresses assigned to four AWS EC2 instances during configuration of global server load balancing (GSLB) with NGINX Plus

    Proceed to next prerequisite, Setting Up Backend Servers
    Return to main instructions, Configuring Global Server Load Balancing

    Connecting to an Instance

    To complete the instructions for installing and configuring NGINX and NGINX Plus in several other sections of this guide, you need to open a terminal window for each EC2 instance and connect to the instances over SSH.

    1. Navigate to the Instances tab on the EC2 Dashboard if you are not there already.
    2. Screenshot showing newly created EC2 instances in one of two regions, which is a prerequisite to configuring AWS GSLB (global server load balancing) with NGINX Plus

    3. Verify that the name of the appropriate AWS region appears next to your name at the right of the top AWS navigation bar, switching to it if necessary. (For the tutorial, the regions are Oregon and N. Virginia.)
    4. Click in the row for an instance to select it.
    5. Click the  Connect  button above the list of instances. A window like the following pops up.

      Screenshot of the instructions for connecting to an AWS EC2 instance, which is done frequently during configuration of global load balancing (GLB) with NGINX Plus

    6. Follow the instructions in the pop‑up window, which are customized for the selected instance (here, US West LB 1) to provide the name of the key file in the steps and in the sample ssh command.

    Setting Up Backend Servers

    The instructions in this section assume that you have completed the initial set up of global server load balancing by creating EC2 instances as instructed in Creating AWS EC2 Instances and have the EC2 Dashboard open to the Instances tab.

    For the purposes of the tutorial, on our four backend web servers we’re installing the open source NGINX software from the binary distribution at nginx.org.

    Note: The instructions assume that you have root privileges, and show the base form of each command. If appropriate for your environment, prefix the commands with the sudo command.

    Installing NGINX on the Backend Servers

    This section explains how to install open source NGINX on each of the four backend instances in our tutorial. Alternatively you can install a prebuilt NGINX Plus AMI.

    1. Connect to the Backend 1 instance, following the instructions in Connecting to an Instance.
    2. Download the NGINX signing key:

      $ wget http://nginx.org/keys/nginx_signing.key
    3. Change directory to /etc/apt.

      $ cd /etc/apt
    4. Open the sources.list file in your preferred text editor and append the following at the end (these commands are appropriate for our eight instances, which are Ubuntu 14.04 LTS AMIs):

      deb http://nginx.org/packages/ubuntu trusty nginx
      deb-src http://nginx.org/packages/ubuntu trusty nginx
    5. Update the NGINX software:

      $ apt-get update
    6. Install NGINX (type Y at any prompts).

      $ apt-get install nginx
    7. Repeat Steps 1 through 6 for the other three backend instances (Backend 2, Backend 3, and Backend 4).

      Note: To save time, leave the connection to each instance open. You’ll use it again in the next section.

    Configuring NGINX on the Backend Servers

    1. Return to the terminal for Backend 1 and change directory to your root directory. For the tutorial, it is /home/ubuntu.

      $ cd /home/ubuntu
    2. Create a directory called public_html and change directory to it.

      $ mkdir public_html
      $ cd public_html
    3. Using your preferred text editor, create a new file called index.html and add this text to it:

      This is Backend 1
    4. Change directory to /etc/nginx/conf.d.

      $ cd /etc/nginx/conf.d
    5. Rename default.conf to default.conf.bak.

      $ mv default.conf default.conf.bak
    6. Create a new file called backend.conf and add this text to define the docroot for this NGINX web server:

      server {
      root /home/ubuntu/public_html;
      }
    7. Verify the validity of the NGINX configuration and load it.

      $ nginx -t
      $ nginx -s reload
    8. Repeat Steps 1 through 7 on Backend 2, Backend 3, and Backend 4. In Step 3, substitute the appropriate Backend X name in the index.html file.

    Proceed to next prerequisite, Setting Up NGINX Plus Load Balancers
    Return to main instructions, Configuring Global Server Load Balancing

    Setting Up NGINX Plus Load Balancers

    For the purposes of the global server load balancing tutorial, we’re installing NGINX Plus on our four load balancers.

    Note: The instructions assume that you have root privileges, and show the base form of each command. If appropriate for your environment, prefix the commands with the sudo command.

    Installing NGINX Plus on the Load Balancers

    1. If you don’t already have NGINX Plus, sign up for a 30‑day free trial.
    2. NGINX, Inc. provides a key and certificate. Follow the instructions on the website for activating NGINX Plus on a machine (they are accessible via the instructions link on this page):

      Screenshot of the certificate and key for a new subscription of NGINX Plus

    3. To verify that NGINX Plus is installed, run this command:

      $ nginx -t

    Configuring NGINX Plus on the Load Balancers

    1. Connect to the US West LB 1 instance, following the instructions in Connecting to an Instance.
    2. Change directory to /etc/nginx/conf.d.

      $ cd /etc/nginx/conf.d
    3. Rename default.conf to default.conf.bak.

      $ mv default.conf default.conf.bak
    4. Create a new file called west-lb1.conf and add this text to configure load balancing for the two backend servers in the region. The public DNS name of each instance appears on the Instances page of the EC2 Dashboard.

      upstream backend-servers {
      server public‑DNS‑name‑of‑backend1; # Backend 1
      server public‑DNS‑name‑of‑backend2; # Backend 2
      }

      server {
      location / {
      proxy_pass http://backend-servers;
      }
      }

    5. Verify the validity of the NGINX configuration and load it.

      $ nginx -t
      $ nginx -s reload
    6. Repeat Steps 1 through 5 for the US West LB 2 instance. (In Step 4, name the configuration file west-lb2.conf.)
    7. Repeat Steps 1 through 5 for the US East LB 1 and US East LB 2 instances. (In Step 4, name the files east-lb1.conf and east-lb2.conf respectively and use the public DNS names of Backend 3 and Backend 4 in the upstream block.)
    8. To test that the configuration is working correctly, for each NGINX Plus load balancer paste its public DNS name into the address field of your web browser. As you access the load balancer repeatedly, the content of the page alternates between “This is Backend 1” and “This is Backend 2” in your first region, and “This is Backend 3” and “This is Backend 4” in the second region.

    Now that all eight EC2 instances are configured and local load balancing is working correctly, we can set up global server load balancing with Route 53 to route traffic based on the IP address of the requesting client.

    Return to main instructions, Configuring Global Server Load Balancing

    Revision History

    • Version 2 (January 2017) – Clarified information about root permissions; miscellaneous fixes (NGINX Plus Release 11)
    • Version 1 (October 2016) – Initial version (NGINX Plus Release 10)