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:

AWS offers different types of API Gateways,

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.

How Private API Gateways Can Still Be Accessed From Outside Your VPC:

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
Portable by design: Rethinking data platforms in the age of digital sovereignty
Portable by design: Rethinking data platforms in the age of digital sovereignty

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-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten

Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten

Kann ein europäischer Cloud-Anbieter wie Ionos AWS oder Azure ersetzen? Wir testen es – und finden überraschende Vorteile in Bezug auf Kosten, Kontrolle und Unabhängigkeit.

Hören Sie auf, schlechte Qualitätsdaten zu laden
Hören Sie auf, schlechte Qualitätsdaten zu laden
Hören Sie auf, schlechte Qualitätsdaten zu laden

Vermeide schlechte Daten von Anfang an

Das Erfassen aller Daten ohne Qualitätsprüfungen führt zu wiederkehrenden Problemen. Priorisieren Sie die Datenqualität von Anfang an, um nachgelagerte Probleme zu vermeiden.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Belgien

Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen


USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm,
Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland


© 2025 Dataminded. Alle Rechte vorbehalten.


Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen

USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm, Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland

© 2025 Dataminded. Alle Rechte vorbehalten.


Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen

USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm, Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland

© 2025 Dataminded. Alle Rechte vorbehalten.