API Gateway is a fully managed service to develop and deploy RESTful APIs at scale. It acts as a “front” door to provide business services provided by the backend application team. It provides a mechanism to handle “cross-cutting” concerns – logging, authentication, access control, monitoring, traffic management, throttling, and API version management so the development team can focus on business logic and application functionality.

API Gateway is a good choice to expose public APIs to external clients without exposing backend services to the external world. This API-first strategy is more relevant to internal clients/teams as well. It doen’t make sense to access intra APIs through public internet. Multiple teams within the organization are working on different services. Considering all teams are working on AWS cloud and they wanted to leverage business services privately provided by each other, API gateway has come up with private REST API. This provides the capability to expose REST API privately through an API gateway so any other team within an organization can access your private REST APIs without leaving the AWS backbone network. It doesn’t require setting up VPC Peering, VPN, or Transit Gateway connectivity between AWS Accounts of respective teams. The same capability can be utilized to access the organization’s partner’s(who has exposed private REST API) APIs so your organization team can access partners’ API securely without leaving the AWS network – but we will keep that out of scope in this discussion.

Let’s see how this API can be configured in an API gateway and how it be called by other teams. Let’s say Team A has developed REST API in AWS Account A and Team B wants to leverage that API from AWS Account B. Both teams have deployed the workload in different AWS accounts/VPC and the same AWS region. Follow the below steps to complete the setup.

  1. Team B should create an “execute-api” interface VPC endpoint in the AWS account/region/vpc from which to access the private REST API developed by any other team within the organization.

Keep in mind the following points while creating a VPC endpoint –

  • Select two subnets to deploy the VPC endpoint in multiple AZs to have high availability in case of AZ failure
  • The security group of the VPC endpoint should allow inbound HTTPS(port 443) traffic from the workload that is accessing private REST API using the VPC endpoint. Either specific IPs from Team B’s VPC or entire VPC range or another security group.
  • Enable private DNS of VPC endpoint so Team B’s workload can easily call private REST API using private DNS
  • Setup up VPC endpoint policy to restrict which private REST APIs can be accessed from this VPC endpoint

Note down the VPC endpoint ID(ex. vpce-0f35f433adf02csde). This DNS name can be used by the workload in Team B’s account/region/VPC to access APIs developed by other teams privately once the setup is completed.

2. Team A should create REST API using API gateway and choose “private REST API” as the API type. Associate VPC endpoint ID(created by Team A) while creating private REST API. The association can be updated after creating a private REST API as well.

This API can be integrated with any type of different integration – Lambda, HTTP, AWS Services, VPC Link, etc. Team B doesn’t need to know about how Team B is providing business services and where/how that service is deployed in Team A’s AWS account/vpc/region. How private REST API Gateway is integrated with backend services is out of the scope of this blog. You can use any relevant integration to deploy your private REST API.

Keep in mind the following points while creating a VPC endpoint –

  • Resource policy of private REST API can restrict access to only the VPC endpoint provided by Team B. This will deny all access to private REST API except from the VPC endpoint mentioned in the resource policy.
  • Private REST API and VPC endpoint must be same AWS Region.

Note down API ID(ex. de39s8id) from the console after deploying private REST API.

Test setup by calling private REST API

Once setup is completed by Team A and Team B in their respective AWS Accounts, Team B can use the DNS name of the VPC endpoint to call private REST API. Team B’s workload can be deployed in EC2 or Lambda or container(ECS or EKS) platform and it can use the below URLs to call private REST API deployed by Team A. There are a couple of other ways to call private REST API from Team B’s AWS Account. One of the simplest ways is to use a private REST API URL that is generated after deploying API as below.

  • Call using the DNS name of private RES API
curl -i https://{API_ID}.execute-api.{REGION}.amazonaws.com/{STAGE_NAME}

Replace API_ID with API ID noted down while creating private REST API by Team A, Replace REGION with the region where the VPC endpoint is deployed by Team B, and Replace STAGE_NAME with the stage where private REST API is deployed by Team A. Make sure to append any relative path of the URL if private REST API has any. Team A can easily give a full URL after deployment to other teams.

Advance use cases

  • If Team A and Team B are operating their workload in AWS but in different AWS regions then Private REST API still can work but it needs to establish additional network connectivity. This connectivity can be established in multiple ways. One way is for Team A can create a VPC endpoint that can be utilized to call private REST API deployed by Team A itself and then Team B can set up VPC Peering or Transit Gateway connectivity to Team A’s VPC. Transit Gateway and deploying VPC endpoints in centralized VPC here is a good choice if there are multiple Team VPCs in different regions. I will publish a separate blog with more details on this.

  • If Team C is operating its workload on-premise and wants to leverage business services provided by Team A privately then Private REST API still can work but it needs to establish additional network connectivity similar to that mentioned in the above use case. I will publish a separate blog with more details.

In summary, an API gateway is a good choice to deploy APIs at scale with security. Private REST API provides an easy way to collaborate with other teams within the organization and use functionalities provided by each other.

References

If you enjoyed this post, I’d be very grateful if you’d help it spread by emailing it to a friend or sharing it on social media. Thank you and keep learning!