Create your first accelerator

AWS Global Accelerator is a service that uses the AWS global network to optimize the network path from your users to your applications, improving performance. It provides you with static IP addresses that you associate with your accelerator which will act as a fixed entry point to your application endpoints in one or more AWS Regions. We will have a whole lab on AWS Global Accelerator performance.

Reasons you should use AWS Global Accelerator
Types of workloads should you consider using AWS Global Accelerator

In this lab, you will create an accelerator with AWS Global Accelerator and add the Application Load Balancer (ALB) you created in the previous lab as its endpoint.

There are different ways to create an accelerator and add an ALB as its endpoint: Load Balancers Console (Integrated Services tab), Global Accelerator APIs, Global Accelerator console. We will use the latter option.

Here’s what you’ll be doing:

  • Create an accelerator (an accelerator directs traffic to optimal endpoints over the AWS global network to improve the availability and performance of your internet applications)
  • Add listeners (a listener processes inbound connections from clients to the accelerator, based on the port and protocol that you configure)
  • Add an endpoint group (endpoint groups define the different AWS Regions where your application is deployed)
  • Add an endpoint to the endpoint group (an endpoint is an Elastic IP address, Network Load Balancer, or Application Load Balancer that is associated with an endpoint group)
  • Verify the endpoint health
  • Access your application using the accelerator DNS

1. Create and name your accelerator

The first step of this lab is to create and name an accelerator using AWS Global Accelerator console, the accelerator will serve as the entry point for your application.

  1. Log into the AWS Management Console
  2. Open the Amazon Global Accelerator console
  3. Choose Create accelerator and provide a name for your accelerator. In our workshop, we’ve named it AGAWorkshop
  4. Choose Next


2. Configure the accelerator listeners

In order for your AWS Global Accelerator to know where to listen for traffic, we will need to add in a listener for TCP port 80.

  1. Enter the following information:
    • Ports: 80
    • Protocol: TCP
    • Client affinity: None
  2. Click Next
Learn more: AWS Global Accelerator listeners


3. Add an endpoint group to the accelerator

In the previous step, we created a listener, which tells AWS Global Accelerator where it should be listening for traffic. Now we need to tell it where to send the traffic. This is through endpoint groups. Endpoint groups contain one or more registered endpoints to send traffic to and is effectively a container construct for the endpoints.

The number of endpoint groups depends on the number of regions your application is deployed in, currently it’s deployed in a single region (US-WEST-2 - Oregon region for me).

Let’s add an endpoint group, we will also be configuring health checks in this step.

  1. Enter the following information:
    • Traffic Dial: 100 - We will get into traffic dials later in the workshop
  • Configure health checks: Keep the default values
  • Click Next


Learn more: AWS Global Accelerator endpoint groups and health checks

4. Add an endpoint (your ALB) to the endpoint group

You just configured an endpoint group and now you will add/configure the actual endpoint. This is the end location where AWS Global Accelerator is going to send traffic. Endpoints in AWS Global Accelerator can be Network Load Balancers, Application Load Balancers, EC2 instances, or Elastic IP addresses.

  1. Select Add endpoint
    • Endpoint Type: Application Load Balancer
    • Endpoint: [Choose the ALB created via CloudFormation] - The list will auto-populate for you
    • Weight: 128 - we will see what endpoint weights are in the next lab
    • Keep Preserve client IP address checked
  2. Click Create accelerator


Learn more: AWS Global Accelerator endpoints

5. Patiently wait for deployment

Great job! The AWS Global Accelerator service is now creating an accelerator for you. This typically takes about 5 minutes to move from the In Progress to Deployed status. Once it’s deployed, you should be able to see the two static anycast IP addresses and the assigned DNS name for the accelerator.


Learn more: AWS Global Accelerator BYOIP

6. Verify endpoint health

Once the accelerator is in a Deployed state, we should double check that the back end endpoints are healthy. There is a really easy way to do this and that’s just to look at the accelerator itself.

  1. In Global Accelerator console, click on the accelerator (AGAWorkshop by default)
  2. Take a look at the bottom window pane at Listeners. You should see All healthy on the right. If not, you may have configured the listeners incorrectly. Go back up a few steps.


AWS Global Accelerator requires your router and firewall rules to allow inbound traffic from the IP addresses associated with Route 53 health checkers to complete health checks for Application Load Balancer, EC2 instance, or Elastic IP address endpoints. You can find information about the IP address ranges associated with Amazon Route 53 health checkers in the Amazon Route 53 Developer Guide. AWS Global Accelerator Health Check options can be found here.

7. Access your application via AWS Global Accelerator

At this point, you have deployed an accelerator and should be able to access your back end application. Get the URL/DNS for your accelerator from the AWS Global Accelerator console (see the previous screenshot), access the DNS via cURL and/or a browser.

  1. Via cURL
$ curl
Processed in US-WEST-2 by AGAWorkshop-Function-P5UKYRRL0N05
  1. Via a browser x

  2. If you are at an AWS Event, use the web page the instructor shared with you x

CHECKPOINT: You have a working accelerator with an ALB as endpoint, many of your users noticed performance improvements. We will discuss Global Accelerator performance in a later workshop.

CHALLENGE 2: You just received a business requirement: the application must use at least two ALBs. Reasons may be blue/green deployments, A/B testing, failover in case for example something happens to the Lambda function, or even to handle the increased traffic. How would you do this - Ready? Move to the next lab!