Using Gateway APIs as a Single Entry Point for Web Applications and APIs

The translation of the article was prepared especially for students of the course “High Load Architect” .




Introduction


AWS benefits, such as high availability, scalability, and resilience, have already proven their worth for SaaS providers (Software-as-a-Service). With the modernization of SaaS applications, AWS helps smoothly switch to a microservice architecture with providing API access to external applications.

API management tools such as the Amazon API Gateway are the natural choice for providing a secure and scalable external API. However, when moving their applications to the clouds, SaaS providers often face the need to quickly deploy their services to several different clients. And, of course, with the specific requirements of each of them.

The Gateway API helps create a multi-tenant microservice architecture. In such an architecture, a single instance of a microservice is used to serve different clients, which makes it possible to use resources more optimally and optimize costs. In this configuration, for servicing their customers, providers require the support of “white-label” domains, as well as the ability to identify a client domain to bind a specific business logic to a specific client in the backend.

This article talks about the reference architecture, which allows you to use the Gateway API as a single entry point for web applications and microservices based on APIs with several external clients, using different subdomains for each of them.

Amazon API Gateway - Single Entry Point


Building an architecture using a single Gateway API for multiple web applications and microservices is an important factor for component reuse and cost optimization.

Amazon API Gateway provides a highly scalable solution for creating and publishing RESTful APIs and WebSocket APIs. You can select a variety of technologies for the backend: AWS Lambda features , AWS Step Functions, or call HTTP endpoints hosted on AWS Elastic Beanstalk , Amazon EC2, or outside AWS.

API Gateway takes on typical API management tasks such as security, caching, throttling and monitoring. Although its main goal is to build an abstract layer on top of your internal API and microservices, it can also simplify your backend applications or provide access to static web pages and documents stored in Amazon S3 bucket .

In addition to the above, the following key API Gateway functions help create the architecture described here.

1. Support for custom domain names:


When deploying an API using the Gateway API, the default domain name of the API endpoint is not very convenient for the end user:

https://api-id.execute-api.region.amazonaws.com/stage

  • api-id Gateway API generated
  • region It is indicated by you when creating the API;
  • stage Specified by you when deploying the API.

The default API endpoint can be difficult to work with. But thanks to the integration with AWS Certificate Manager, which allows you to test subdomains based on SSL-certificates, you can give users of your API easier and more intuitive URL, such as, customer1.example.com. The Gateway API allows you to map multiple subdomains to a single API endpoint, which allows you to use the “white label” name in accordance with the requirements of external clients.

2. Modification of API requests / responses


The Gateway API allows you to configure separate processing for each part of the API endpoint address. Thanks to this, it is possible to route API requests to individual endpoint endpoints, and at the same time, change headers in the request / response for more flexible processing of API requests.

The advantages of such an architecture


The features described in this article are shown in the diagram below.



Here is the architecture for a typical SaaS provider that offers its services to other organizations and must support “white-label” domains for web and API infrastructures. A similar architecture is achieved using the following steps:

  1. The domain example.comcan be registered with a domain registrar, but you can create subdomains through the CNAME-record, for example customer1.example.com, customer2.example.com. This can be done in AWS using the Amazon Route 53 service or through any third-party DNS provider.
  2. AWS Certificate Manager (ACM) example.com *.example.com. ACM-, API Gateway.
  3. , ACM, API. API . : customer1.example.com customer2.example.com.

: CNAME- customer1 customer2 DNS, API Gateway.



4. API Endpoint


  • /service1 — integration type HTTP, ELB, ECS
  • /service2 - integration type HTTP, routing traffic to the endpoint of an ELB web application hosted in an EC2 cluster
  • /docs - integration type AWS S3, for static documents



5. The Gateway API can process the fully qualified domain name (FQDN) in the URL and map it to custom headers or parameters in the query string to send to the corresponding backend.

For example, we can create a custom “Customer” header to redirect customer1 or customer2 to a customer-specific backend application. This is done using the Method Request and Integration Request parameters in the Gateway API.

Total


As you can see, this is just one example of using the Gateway API as a single entry point for API-based microservices and static web application resources. Gateway API allows you to use the infrastructure more efficiently without losing scale while increasing the load on your applications. For more information on working with the Gateway API and Route 53 DNS, see the AWS documentation and use these features to create architectures that meet your requirements.

All Articles