Skip to content

How can we set API gateway in private subnet, then allow the Cloudfront access it?

0

We have deployed a Cloudformation stack, the architecture is just similar with what shows in this link(https://www.wellarchitectedlabs.com/security/300_labs/300_multilayered_api_security_with_cognito_and_waf/3_prevent_requests_from_accessing_api_directly/ ). Currently API Gateway is in public subnet, and we add a custom header to prevent requests from accessing API directly. Is it possible to make the API Gateway private (a private subnet without Internet Endpoint, NAT or Gateway) and then allow the Cloudfront access it. Could you advice if the current architecture is good enough to make it secure?

2 Answers
0

Short answer: No, you can't do that (access an API Gateway on a private subnet in a VPC from outside the VPC).

Note that in the diagram on the page that you've linked to that the API Gateway is not hosted in a VPC. The intention of that section of the lab is to show that access to API Gateway comes through CloudFront; but it doesn't require API Gateway to be hosted in a VPC in order to increase security.

Is there a reason that you want the API to be in a VPC?

You've also asked whether the architecture is "good enough to make it secure". We can't answer that question - you need to look at the risks that you're trying to mitigate and determine whether the mechanisms for securing the API (or anything else) are appropriate for you.

EXPERT

answered 3 years ago

0

One approach can be the following. Create a private rest api gateway in a private subnet and front it with a vpc interface endpoint, which will provide dns access. Security to be enforced via api gw resources policies, and endpoint security groups and policies.

Now in another vpc or account, create a public facing ALB, where you can attach a Cloudfront distribution on. Use a target group and provide the ip addresses of the vpc interface endpoints previously created.

This is just one possible way of separating private endpoints with public ones, with assumption that you want to publicly access an api from a central public entry point, without exposing its private implementations, which could be managed by different teams.

As said, not a solution, but a trade off to consider ;)

EXPERT

answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.