Why the ‘Private’ API Gateway of AWS Might Not Be as Secure as You Think
Apr 20, 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
Portable by design: Rethinking data platforms in the age of digital sovereignty
Build a portable, EU-compliant data platform and avoid vendor lock-in—discover our cloud-neutral stack in this deep-dive blog.
Cloud Independence: Testing a European Cloud Provider Against the Giants
Can a European cloud provider like Ionos replace AWS or Azure? We test it—and find surprising advantages in cost, control, and independence.
Stop loading bad quality data
Ingesting all data without quality checks leads to recurring issues. Prioritize data quality upfront to prevent downstream problems.