The CloudFormation template you used to create the web application created public subnets and internet facing ALBs in the three regions, you can access these ALBs directly from any region using their DNS. In the workshop initialization you were able to access the endpoint using the ALB DNS, let’s try to access directly the Tokyo ALB (get the ALB DNS from EC2 console, Load Balancers menu):
Your application is currently exposed to 5 different access points (the 4 ALBs and the Global Accelerator endpoint), this exposes it to distributed denial of service (DDoS) attacks and does not allow you to have control over how your end users reach the application. AWS Global Accelerator offers a feature to obfuscate the source origin through functionality commonly referred to as origin cloaking, allowing private ALBs and private EC2 instances to be accessed through Global Accelerator in a secure and simplified manner.
Origin cloaking allows you to make Global Accelerator the single internet-facing access point for your applications running in a single or multiple AWS Regions. The applications are centrally protected from distributed denial of service (DDoS) attacks through AWS Shield. You can also have greater control over how your end users reach your applications.
You can add internal Application Load Balancers or private Amazon EC2 instances as endpoints in AWS Global Accelerator, when you do so you enable internet traffic to flow directly to and from the endpoint in Virtual Private Clouds (VPCs) by targeting it in a private subnet. For more information, see the documentation
Let’s make one of the endpoints not accessible directly from the internet, I choose the Tokyo ALB. The CloudFormation template we used created a VPC with a default Security Group (SG) named default, and an ALB with an SG attached to it (it name depends on your CFN stack name, by default AGAWorkshop-ALBSecurityGroup-StackID) that allows HTTP and HTTPS traffic from 0.0.0.0/0. When you create an accelerator, Global Accelerator creates and manages an SG named GlobalAccelerator with no permission entry, it also creates Elastic Network Interfaces (ENIs) in each subnet that has at least one ENI of the ALB in it that is fronted by an accelerator in your account, these ENIs allow traffic only to and from the AWS Global Accelerator service.
To allow only our accelerator to access the ALB, update the SG associated to the ALB by removing the HTTP and HTTPs entries, and adding the Global Accelerator SG:
Repeat this for other ALB security groups to protect your application from being accessed directly using ALB DNSs, Global Accelerator would be the single entry point.
Let’s revert the changes we made (allow public HTTP and HTTPS traffic), we will need ALB endpoints for the next labs.
CHECKPOINT: You just learned how you private Application Load Balancers (ALBs) and private EC2 instances can be accessed through Global Accelerator in a secure and simplified manner. For more information about this feature, read this blog post.
CHALLENGE 7: You initially decided to add an accelerator in front of your application because you wanted to improve traffic performance. Your management just scheduled a meeting to discuss performance improvements with Global Accelerator. How would you do this, what tools would you use? Move to the next lab when you are ready!