Why the ‘Private’ API Gateway of AWS Might Not Be as Secure as You Think
20.04.2025
•
Crochelet Pierre
AWS Private API Gateways aren’t always private, misconfigs can expose access. Use resource policies to secure them properly.
Designing secure applications is a challenge for everyone. A big part of this is based on who can access what. In this blog I want to dig deeper into how to secure your Private API Gateway using AWS. Furthermore, I want to share an experience I had where, what I thought to be a secure integration would have turned out to be broadly accessible if not for the help of my colleague.
Context
When developing a platform or an application, one might use API Gateways. These offer an abstraction between your front-end and back-end to your customers. They act as a single point of entry for all API requests and can be configured for security and monitoring, in contrast with Load Balancers whose main purpose is to distribute traffic so that no back-end server gets overloaded.
AWS offers different types of API Gateways, one of which has an extra layer of security , the private REST API gateway. A private API can only be called from VPCs through PrivateLink. When one creates such an API through the console, one can read the following description:

How Private API Gateways Can Still Be Accessed From Outside Your VPC:
When I first created a private API Gateway, I understood the above console description to mean that it would only be accessible from within my own VPC. After all, when creating the gateway, I even specified a VPC endpoint that resides inside my VPC. I was then quite surprised when, after creation I came across the resource policy tab.
That’s when my colleague explained that thePrivatein the Gateway just means that it does not resolve outside of PrivateLink, i.e. over the Internet. However, any resources communicating over PrivateLink are still able to resolve, and reach it. This was a quite an important realization for me since, when I thought I was creating a super-secure resource, I was in fact creating a slightly-more-annoying-to-reach resource. As a matter of fact, anyone who can create an EC2 instance in a VPC can then reach the API Gateway.

This shows the importance of having a resource-based policy on the API Gateway such as the following, which limits access to communications originating from your VPC-id only:{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNotFromVPC",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals" {
"aws:sourceVPC": <your-vpc-id>
}
}
}
]
}
Conclusion
In this blog post, we looked into private API gateways. We showed that, by default, they are accessible from any resource in any VPC. This underlines the importance of the resource-based policy. Indeed, one can use that policy to restrain access to their API gateway from a certain source VPC only, or a certain source VPC endpoint.
Latest
The ROI Challenge: Why Measuring Data’s Value is Hard, but Crucial
Too many data products, not enough ROI? Learn how to track value, cost & governance to manage data as a true business asset.
Authorizing AWS Principals on Azure
How to delegate trust from Entra to AWS IAM through Cognito, authorizing Azure actions without needing long-lived credentials.
Why Your Next Data Catalog Should Be a Marketplace
Why data catalogs fail - and how a Data Product Marketplace can rebuild trust, drive adoption, and unlock business value from your data.