Failover POC

AWS Global Accelerator continuously monitors the health of your application endpoints by using TCP, HTTP, and HTTPS health checks. It instantly reacts to changes in the health or configuration of your endpoints, and redirects user traffic to healthy endpoints that deliver the best performance and availability to your users. The guidance for determining the health of each endpoint and the timing for the health checks depend on the type of endpoint resource.

For load balancer endpoints, Global Accelerator always uses the health check settings that you’ve configured on the Elastic Load Balancing console. Health check settings that you configure in Global Accelerator are used only for EC2 instance and Elastic IP address endpoints. For more information about Global Accelerator Health Checks options, see the documentation.

The endpoint group page displays information related to health checks. x

For some reason, one of your endpoints stops responding and the Application Load Balancer health check fails. Once an endpoint is market as unhealthy, it takes AWS Global Accelerator up to 30 seconds (the health check interval) to direct new connections to the next closest endpoint: this can be in the same region (if the endpoint group has different endpoints) or in a different AWS Region.

To simulate a failure, change the response status code returned by the Lambda function from 200 to 403 for example and Save (chose any of the 3 regions your application is deployed in, I chose AP-NORTHEAST-1 region).

  1. Open the AWS Lambda console (make sure you are in the right region).
  2. Click on the function name (AGAWorkshop-Function-**** by default).
  3. In the Function code, change the statusCode from 200 to 403
  4. Scroll up and Save


After a maximum of 60 seconds (30 seconds for the ALB and 30 seconds for the Global Accelerator health checks), the endpoint status will become Unhealthy and Global Accelerator will start sending new connections automatically to the next available endpoint.


Let’s see how Global Accelerator handles new traffic from Singapore, normally processed by AP-NORTHEAST-1 (Tokyo) region.


Requests from Singapore are now served from Dublin. Global Accelerator routed traffic Dublin because at the time of the requests, EU-WEST-1 (Dublin) was better than US-WEST-2 (Oregon) to serve traffic from Singapore. This failover is automatic and transparent to the end users. Global Accelerator will continue to monitor the Tokyo endpoint, and will resume sending traffic to it once it becomes healthy. Before we continue, revert the change we did to the Lambda function, change the statusCode from 403 back to 200.

CHECKPOINT: You just tested your web application to make sure that a failure of an endpoint would not impact it availability.

CHALLENGE 6: You just received an email from your sysadmin, logs show that most of the traffic to your web application hits directly the ALBs (using their DNSs), bypassing the accelerator endpoint. Also, the sysadmin is looking for a way to protect the application against DDoS attacks. How would you achieve this? Move to the next lab when you are ready!