Handle Different Web Services and API Microservices using AWS – API Gateway as a Single Entry Point

AWS is providing benifits of availability, scalability and elasticity. It is a boon for Software as a Service (SaaS) providers. Also AWS is providing microservices architecture for modernizing these SaaS applications and providing API-based access for external applications.

Amazon API Gateway is a good choice for customers to expose APIs externally in a secure and highly scalable manner. However, as they adopt cloud plateform, these providers may spin up redundant AWS environments to support them for multiple customers. Ofcourse they have unique requirements and provider has to support them in any condition.

However, there is potential to create a multi-tenant microservices architecture using the capabilities of API Gateway. This blog post talks about a reference architecture that allows API Gateway to act as single entry point for external-facing, API-based microservices and web applications across multiple external customers by leveraging a different subdomain for each one.

Amazon API Gateway: A Single Entry-Point

Using a single API Gateway in the architecture across multiple web portal applications and microservices is an important examination towards the goal of reusability of components and cost optimization.

We can create and publish RESTful and Websocket APIs. It provides AWS Lambda function, State machines, HTTP(s) endpoint of EC2 and third party hosted HTTP based services. Also it is allows security, caching, throttling and monitoring. While its primary objective is to provide that abstraction layer on top of your backend APIs and microservices, it can also allow backends to be simple web applications for web portal access or Amazon S3 buckets for providing access to static web content or documents.

Key features of API Gateway

1. Domain Name Support
When we create new API endpoint, it looks like below:

In this url, domain name is not user friendly. region and stage are specified by you when creating the API. The default name is difficult to understand to end users and we have to give perticular domain name to this endpoint while we providing to other customers. For example: customer1.example.com, customer2.example.com.

Route53 is provide service to create domain and sub domains. Also we can integrate multiple sub domains into API Gateway endpoint. Insort, we can provide white labeling domain names to external customers for single API endpoint.

2. API request/response
API Gateway allows you to specify the integration of each path of the API endpoint separately. This allows you to route API requests for each path to a separate backend endpoint and at the same time apply any request/response transformations, such as customer header insertion or modification of existing headers to manage any custom handling of APIs.

Architecture

In the architecture shown in the diagram below, the features explained in this blog are utilized.

This architecture is an example of typical Saas provider who wants to offer services to other customers and needs to support white-labeling domains.

1. Create domain and sub domains for your customers using Rout53 or third party domain name provider.
2. ACM (AWS Certificate Manager) applied on domain and API Gateway. Make sure that ACM is allowing multiple sub-domains.
3. Using ACM, create custom domain for API endpoint. It will server two different sub-domains for two different customers and specify paths.



4. API endpoint configured with the following resources.
   • HTTP integration of /service1 to route traffic to the ELB endpoint of microservice hosted on an ECS cluster
   • HTTP integration of /service2 to route traffic to the ELB endpoint of web application hosted on an EC2 cluster
   • /docs API resource is integrated with AWS S3 for any static documents



5. API Gateway allows Custom headers, Query string parameters and sent it to Backend service or HTTP endpoint.

Summary

This is the approach to use API Gateway as a single entry point for API based mocroservices and web application assets. Most helpful is we can expand infrastructure anytime without losing anything and easily manage different services without depend on each other.