Global Accelerator with private ALB: restrict access to accelerator IPs

ANS-C01 By islever Editorial Last updated

Design a solution that incorporates edge network services to optimize user performance and traffic management for global architectures. Design solutions that integrate load balancing to meet high availability, scalability, and security requirements. Implement and maintain network features to meet security and compliance needs and requirements.

Short answer

D Place the ALB in a private subnet, attach an internet gateway, add the subnet route, and restrict the ALB security group to Global Accelerator IPs so vending-machine HTTPS traffic can reach the app only through the accelerator.

Question

A company has developed an application on AWS that will track inventory levels of vending machines and initiate the restocking process automatically. The company plans to integrate this application with vending machines and deploy the vending machines in several markets around the world. The application resides in a VPC in the us-east-1 Region. The application consists of an Amazon Elastic Container Service (Amazon ECS) cluster behind an Application Load Balancer (ALB). The communication from the vending machines to the application happens over HTTPS.
The company is planning to use an AWS Global Accelerator accelerator and configure static IP addresses of the accelerator in the vending machines for application endpoint access. The application must be accessible only through the accelerator and not through a direct connection over the internet to the ALB endpoint.
Which solution will meet these requirements?
  1. Configure the ALB in a private subnet of the VPC. Attach an internet gateway without adding routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB’s security group to only allow inbound traffic from the internet on the ALB listener port.
  2. Configure the ALB in a private subnet of the VPC. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the internet on the ALB listener port.
  3. Configure the ALB in a public subnet of the VPAttach an internet gateway. Add routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the accelerator's IP addresses on the ALB listener port.
  4. Configure the ALB in a private subnet of the VPC. Attach an internet gateway. Add routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the accelerator's IP addresses on the ALB listener port. Correct Answer

Key Takeaways

It tests whether you can combine Global Accelerator endpoint groups with an internal ALB and security-group scoping; the trap is choosing a public ALB or an open internet security group just because the accelerator uses static IPs.

This ANS-C01 scenario tests AWS Global Accelerator access to an internal Application Load Balancer while preventing direct internet access. The correct design is D: keep the ALB in a private subnet and limit its security group to Global Accelerator IPs.

Common mistake: Option C is tempting because it restricts the ALB security group to accelerator IPs, but it leaves the ALB in a public subnet with an internet gateway route, preserving a direct internet-facing load balancer rather than making the accelerator the only ingress path.

Expert Analysis

The requirement has two independent controls. Global Accelerator supplies global anycast static IPs, but the design still has to prevent a vending machine—or anyone else—from resolving and calling the ALB directly. That means the ALB endpoint should be internal/private, and the ALB security group must allow only the accelerator's addresses on the HTTPS listener. A security group that allows the whole internet, as in A and B, fails the isolation condition even if the ALB is in a private subnet.

Why D is the best fit. D keeps the ALB in a private subnet, attaches an internet gateway to the VPC, adds the route, and scopes the security group to Global Accelerator IP addresses. The comments repeatedly point to the Global Accelerator secure-VPC documentation, which says an internal ALB endpoint must be targeted in a private subnet and the VPC must have an internet gateway attached; one comment emphasizes that a subnet route to the internet gateway is not what enables the Accelerator path. In this option set, that extra route is not the security boundary—the ALB remains internal and the security group is the deterministic control. C is the common trap: it scopes the security group correctly but leaves the ALB in a public subnet with an internet gateway route, so the load balancer still has a public-facing endpoint and the architecture relies only on a security-group rule to hide it.

Adjacent decision that flips the outcome. If the requirement changed to allow direct ALB access from specific partner IP ranges, you would need an internet-facing ALB or a public NLB path, and the security-group source would be those partner CIDRs rather than accelerator addresses. If the endpoint were an NLB or EC2 instance instead of an ALB, client-IP preservation and security-group design change, so do not reuse this pattern blindly.

Operational consequence. Getting it wrong leaves an internet-reachable load balancer endpoint or opens the listener to the world. Either result breaks the "only through Global Accelerator" guarantee and creates an audit finding. The safe validation is to test from outside: the ALB DNS name should not serve application traffic, while the accelerator's static IPs should.

Official Reference

https://docs.aws.amazon.com/global-accelerator/latest/dg/secure-vpc-connections.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a question requires that a service be reachable only through Global Accelerator, decide on two layers: the endpoint's network placement and the security-group source. Eliminate any option that leaves an internet-facing load balancer endpoint or opens the ALB security group to the whole internet, even if the accelerator static IPs are configured. Then verify the Global Accelerator prerequisite for internal ALB endpoints—the VPC needs an internet gateway attached—and pick the option that preserves private addressing while scoping ingress to accelerator addresses.

Frequently Asked Questions

Why can a private ALB be targeted by AWS Global Accelerator?

Global Accelerator can target an internal ALB in a private subnet when the VPC has an internet gateway attached. The accelerator carries traffic over the AWS global network, and the ALB security group controls which accelerator addresses may reach the listener.

Should the ALB security group allow the vending machines' public IP addresses?

No. The requirement is to make the accelerator the only ingress path, so the ALB listener should trust the Global Accelerator IP addresses rather than the whole internet or the vending machines' public addresses.

Does placing the ALB in a private subnet alone prevent direct internet access?

It removes the public-facing ALB endpoint, but you should also scope the security group to accelerator addresses. The combination of private placement and restrictive ingress is what proves traffic is only reachable through Global Accelerator.

More ANS-C01 FAQ →

Community Votes

D
42%
C
32%
A
26%

42% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 25 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 25

  1. study_aws1 👍 32
    This is not a normal scenario of attaching IGW to EC2 instance by creating a route in subnet. Please read the below link typically describing ELB integration with AWS Global accelator (and the last line of the extract) - https://docs.aws.amazon.com/global-accelerator/latest/dg/secure-vpc-connections.html "When you add an internal Application Load Balancer or an Amazon EC2 instance endpoint in AWS Global Accelerator, you enable internet traffic to flow directly to and from the endpoint in Virtual Private Clouds (VPCs) by targeting it in a private subnet. The VPC that contains the load balancer or EC2 instance must have an internet gateway attached to it, to indicate that the VPC accepts internet traffic. However, you don't need public IP addresses on the load balancer or EC2 instance. You also don't need an associated internet gateway route for the subnet."
  2. PhilMultiCloud 👍 4
    The requirement here is that the application must be accessible only through the Global Accelerator, and not via a direct connection over the internet to the ALB endpoint. Hence, the ALB should be placed in a private subnet and should be configured such that only traffic coming from the Global Accelerator can reach the ALB. Option A: This won't work because we're allowing inbound traffic from the internet on the ALB listener port. We need to restrict the traffic to the ALB only from the Global Accelerator's IP addresses. Option B: This won't work for the same reason as option A - we're allowing traffic from the entire internet to reach the ALB. Option C: This won't work because placing the ALB in a public subnet will allow it to be accessible from the internet, which we don't want. Option D: This is the correct option. Here, we're placing the ALB in a private subnet, which prevents direct access from the internet. The traffic is allowed only from the IP addresses of the Global Accelerator. Thus, access to the ALB is only possible through the Global Accelerator, fulfilling the requirement.
  3. Andrea13 👍 4
    The correct answer is C. Configure the ALB in a public subnet of the VPC. Attach an internet gateway. Add routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB’s security group to only allow inbound traffic from the accelerator’s IP addresses on the ALB listener port.
  4. vikasj1in 👍 3 Answered A
    Placing the ALB in a private subnet ensures that it is not directly accessible from the internet. Adding an internet gateway without adding routes in the subnet route tables prevents direct internet traffic to the ALB. Configuring the AWS Global Accelerator with endpoint groups that include the ALB endpoint allows controlled access to the application through the accelerator. Configuring the ALB's security group to only allow inbound traffic from the internet on the ALB listener port further restricts direct access, ensuring that the application is accessed only through the AWS Global Accelerator.
  5. Joselito79 👍 3 Answered C
    ALB on public subnet + IGW + routes SG only allows traffic from Global Accelerator IPs ✔ ALB internet-facing (GA technical requirement) ✔ The only allowed source is Global Accelerator ✔ Even though the ALB has a public DNS: It is not directly accessible because SG blocks it ✔ It meets the requirement: “The application must be accessible only through the accelerator”
Show 20 more comments
  1. merajk 👍 3 Answered A
    Well described here: https://docs.aws.amazon.com/global-accelerator/latest/dg/secure-vpc-connections.html
  2. gpt_test 👍 2 Answered D
    By configuring the ALB in a private subnet, you ensure that it is not directly accessible over the internet. Attaching an internet gateway and adding routes to the subnet route tables will allow traffic from the accelerator to reach the ALB. When you configure the accelerator with endpoint groups that include the ALB endpoint, you enable traffic to be routed through the accelerator to the ALB. Finally, configuring the ALB's security group to allow inbound traffic only from the accelerator's IP addresses on the ALB listener port ensures that the application is accessible solely through the accelerator, meeting the requirements.
  3. scofield101 👍 2
    Option C is the correct option. Every other option suggested created ALB in a private subnet without internet gateway. The ALB won’t be accessible from the internet including the accelerator which isn’t a VPC component. You create an ALB in a private subnet if you want the ALB to be accessed internally ( within the vpc) and the accelerator is a global and not a vpc based component.
  4. emmanuelodenyire 👍 2 Answered D
    Configure the ALB in a private subnet of the VPC. Attach an internet gateway. Add routes in the subnet route tables to point to the internet gateway. Configure the accelerator with endpoint groups that include the ALB endpoint. Configure the ALB's security group to only allow inbound traffic from the accelerator's IP addresses on the ALB listener port.
  5. seochan 👍 2
    D is wrong. When using internal ALB, you must use Preserve Client IP on the Global Accelerator. In that case, the security group in your ALB should allow all internet traffic (because you should allow the IP addresses of your clients), not Global Accelerator's IP. Plus, the target VPC of the Global Accelerator must attach an Internet gateway.
  6. ranac 👍 2 Answered D
    The ALB can be configured in a private subnet of the VPC to ensure that the application is not directly accessible from the internet. An internet gateway needs to be attached to the VPC and routes added in the subnet route tables to point to the internet gateway to enable connectivity with the AWS Global Accelerator.
  7. Tiger4Code 👍 2 Answered A
    i think all the options are wrong! correct answer should be: - private ALB - IGW with no routes - ALB SG allows inbound from global accelerator static ip addresses https://aws.amazon.com/blogs/networking-and-content-delivery/accessing-private-application-load-balancers-and-instances-through-aws-global-accelerator/
  8. fojta 👍 2 Answered D
    If the security group for the ALB allows inbound traffic from the internet, it will not automatically allow traffic from the Global Accelerator's IP addresses, even though they are public IPs.
  9. gonzales 👍 2 Answered A
    Internal ALB IGW attached No subnet route to IGW Reachability provided by Global Accelerator https://docs.aws.amazon.com/global-accelerator/latest/dg/secure-vpc-connections.html
  10. jasonlll88 👍 1
    "When you add a Network Load Balancer, an internal Application Load Balancer, or an Amazon EC2 instance endpoint in AWS Global Accelerator, you enable internet traffic to flow directly to and from the endpoint... by targeting it in a private subnet. The VPC that contains the load balancer or EC2 instance must have an internet gateway attached to it, to indicate that the VPC accepts internet traffic. However, you don't need public IP addresses on the load balancer... You also don't need an associated internet gateway route for the subnet." And directly from the AWS blog on this exact pattern: "To avoid internet traffic from inadvertently flowing into a private subnet, we require that an internet gateway is attached to the VPC... The internet gateway does not need a route in the relevant subnet route table, or any subnet route table for that matter. The subnet essentially remains private... The Global Accelerator ENIs that are created only allow traffic to and from AWS Global Accelerator service. They do not allow any type of broad access to the internet."
  11. 73f8ac3 👍 1 Answered D
    Private subnet: Placing the ALB in a private subnet ensures that it is not directly accessible from the internet, enhancing security. Internet gateway: The internet gateway allows outbound traffic from the private subnet to reach the internet, which is necessary for the ALB to communicate with the AWS Global Accelerator. Route tables: The routes in the subnet route tables point to the internet gateway, ensuring that traffic from the ALB can reach the internet. Endpoint groups: The endpoint groups in the AWS Global Accelerator associate the ALB endpoint with the accelerator, allowing the vending machines to connect to the ALB through the accelerator's static IP address. Security group: The ALB's security group restricts inbound traffic to only the IP addresses of the AWS Global Accelerator, preventing direct internet access to the ALB.
  12. Ravan 👍 1 Answered D
    ALB in a private subnet: Ensures that the ALB cannot be accessed directly from the internet, protecting it from unauthorized access. Internet gateway: Allows the ALB to communicate with the internet, even though it's in a private subnet. Routes pointing to the internet gateway: Enables the ALB to send responses back to the internet through the Global Accelerator. Global Accelerator: Provides a globally distributed load balancer that can be accessed through static IP addresses, making it ideal for applications that need to be accessible from multiple locations worldwide. Endpoint groups: Associate the ALB with the Global Accelerator, allowing traffic to be routed to it. Security group: Restricts inbound traffic to the ALB, ensuring only traffic from the Global Accelerator can reach the application.
  13. sarutc 👍 1 Answered C
    Options Analysis A) ALB in private subnet + IGW but no route -> X Doesn't make sense. Private subnets + IGW with no routes -> unreachable B) ALB in private subnet + accelerator --> SG allows Internet traffic -> X Wrong. That would allow direct Internet access , breaking the requirement C) ALB in public subnet + IGW + routes + SG allows traffic only from GA IPs --> / Correct. Public ALB (so GA can reach it), but inbound restricted to GA --> vending machines can only come via GA static IPs D) ALB in private subnet + IGW + routes + SG allows GA IPs -> X ALB must be in public subnets (not private) to receive traffic directly from GA. Private subnet ALBs can't serve GA endpoints.
  14. ChinkSantana 👍 1
    Well explained here: When you add an internal Application Load Balancer or an Amazon EC2 instance endpoint in AWS Global Accelerator, you enable internet traffic to flow directly to and from the endpoint in Virtual Private Clouds (VPCs) by targeting it in a private subnet. The VPC that contains the load balancer or EC2 instance must have an internet gateway attached to it, to indicate that the VPC accepts internet traffic. However, you don't need public IP addresses on the load balancer or EC2 instance. You also don't need an associated internet gateway route for the subnet.
  15. Kraftzman 👍 1 Answered C
    Let's double-check why an internal ALB might be problematic. It's not. It's the better solution. So why isn't it an option? The options are poorly written. But we must choose the best one. Option C describes a complete, working system. Option A/B describes a better architecture but with flawed/incomplete rules. In a multiple-choice context, you choose the most complete and correct description. C is a self-contained, working, if not ideal, solution.
  16. xTrayusx 👍 1 Answered D
    Placing the ALB in a private subnet ensures that it is not directly accessible from the internet.The ALB's security group should be configured to only allow inbound traffic from the accelerator's IP addresses on the ALB listener port. This ensures that only traffic originating from the accelerator is allowed to access the ALB.
  17. Raphaello 👍 1 Answered D
    Correct answer is D. The request is to allow flow ONLY through the accelerator and not through a direct connection over the internet to the ALB endpoint. So clearly option A (Configure the ALB’s security group to only allow inbound traffic from the internet on the ALB listener port) is not the answer. D is correct.
  18. braveheart22 👍 1 Answered C
    The correct option here is C. Configure the ALB in a public subnet… and restrict inbound traffic to only the accelerator's IP addresses. The pattern here should be: 1. ALB must be internet-facing 2. Use Security Group restrictions to Global Accelerator IPs
  19. LeoSantos121212121212121 👍 1 Answered C
    It's C. ALB is public, but you restrict access with a security group so that only GA’s static IP addresses can reach it. That way, vending machines must go through GA, and direct ALB access is blocked.
  20. CeboR 👍 1 Answered C
    Global Accelerator cannot reach private subnets

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to make one AWS Direct Connect connection primary and the other failover-only?

S-grade

How to Copy On-Premises Application Logs to Amazon S3 Over AWS Direct Connect?

S-grade

Why Does VPC Traffic Mirroring Randomly Drop Traffic?

S-grade

What is the most secure way to expose cross-account microservices with API Gateway?

S-grade

Practice All ANS-C01 Questions

Access 137 questions with complete answers and detailed explanations.

View Full ANS-C01 Practice Test →

← Back to ANS-C01 Study Guide