Using API Gateway Private Endpoints: Cost and Considerations

Tim Gray
March 5, 2019

API Gateway is a fantastic tool in the AWS Cloud toolkit. If you’re building serverless applications, creating functions that you don’t want to manage the servers for, or integrating many different services (AWS or otherwise) API Gateway chips in with a reasonably easy to manage solution.
Introduced in mid-2018 was AWS API Gateway support for private endpoints. This allows you to create API Gateway’s that are only accessible from inside your private VPC networks, and as such are hidden away from prying eyes on the internet. Let’s have a quick look at why you would want to use it, how much it costs, and how to get it up and running.

Use Cases

So why do we care about this API Gateway private endpoint thing anyway? Private endpoints allows us to write API functions that can be used by our applications without having to worry about this API being exposed to the risks of the wider internet.
Use cases for this type of API can be for things like shared services for your applications. Logging for example, could be done through API Gateway and the private endpoint will mean you can run this logging framework without authentication, and abstract the target of this logging platform away from the developers of each code block.
Another use could be for data retrieval from multiple sources and using API Gateway to aggregate these sources. With the gateway running in private endpoint mode this would eliminate some of the worries of this data traversing the public domain.

How do I get API Gateway Private Endpoints going then?

If you know how to get a standard API Gateway up and running there is not that much more work to get a private API running.
The first step is to create a private endpoint for execute-api service inside your VPC. You only need 1 of these per VPC, no matter how many API’s you wish to call through it.
To get it up and running.

  1. Open the AWS Console
  2. Go to the VPC console
  3. Click on Endpoints on the left
  4. Click the Create Endpoint blue button on the top
  5. On the next screen select AWS service
  6. In the list find and select ‘com.amazonaws.ap-southeast-2.execute-api’ of type Interface
  7. Select the VPC you wish to add the endpoint to in the dropdown list
  8. Add the relevant subnets
  9. Pick the security group (or create one) to secure your API
  10. Then click the Create Endpoint button at the bottom of the screen

We now have the endpoint for accessing the API without needing to traverse onto the internet.
The next stage is to create an API with the private endpoint type, and give the VPC access to this API. This process is the same as creating a normal API Gateway, except you need to select private endpoint on the creation screen.
The last thing remaining to do is create a Resource Policy for allowing access to this API Gateway. Official examples can be found here, and I’ll show a simple one that allows access to any machine running inside a specified VPC.

   "Version": "2012-10-17",
   "Statement": [
           "Effect": "Deny",
           "Principal": "*",
           "Action": "execute-api:Invoke",
           "Resource": "execute-api:/*/*/*",
           "Condition": {
               "StringNotEquals": {
                   "aws:sourceVpc": "{{vpcID}}"
           "Effect": "Allow",
           "Principal": "*",
           "Action": "execute-api:Invoke",
           "Resource": "execute-api:/*/*/*"

Reading this shows that it will deny access to any request where the source vpc does not match {{vpcID}}. Easy!
API Gateway Private Endpoints have the normal costs for an API Gateway install, plus the additional cost of having a private VPC endpoint for execute api enabled. This private endpoint runs around $10 USD a month with an extra $0.01 USD per GB of data processed through this endpoint. Nothing too prohibitive then.

That’s just a quick rundown of how API Gateway Private Endpoints can help.
Until next time
Tim Gray
Coffee to Code

Tim works on a lot of things here at optimal and writes blogs on a wide range of topics.

Connect with Tim on LinkedIn or read his other blogs here.

Copyright © 2019 OptimalBI LTD.