First, let's look at this architecture:
Explain
This is a 2-tier architecture, consisting of an application layer and a database layer. The application layer and database layer are placed in a private subnet, while the ALB is placed in a public subnet and allows traffic to access them through the API Gateway.
The question here is:
Why use the API Gateway before the ALB, when the public ALB is already sufficient to allow traffic to enter and access the application layer?
Yes, this is a viable option. However, consider what would happen if all origins were able to access your resources. How would you block origins other than your own? The answer is that you can use the API Gateway to create CORS rules to restrict access to your resources and block the origins that you don't want to allow access to.
However, there is another problem that you will face. Traffic may not go through the API Gateway, but instead go directly to the ALB. This means that your CORS configuration will not be applied to the ALB if traffic does not go directly through the API Gateway. In this case, you will need to create a custom header by integrating resource mapping to create the custom header at the API Gateway. Then, you can create a WAF rule at the ALB to check for the custom header. If the request does not contain the custom header, it means that it did not go through the API Gateway, and the traffic will be blocked.
Now, do you have the answer to the question of why use the API Gateway?
Top comments (0)