Amazon API Gateway

  1. A fully managed service used to create, publish, maintain, monitor, and secure APIs at any scale.
  2. Act as the "front door" for applications to access data, business logic, or functionality from your backend services.
  3. Create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications.
  4. Supports containerized and serverless workloads, as well as web applications.

1. Types of APIs supported by API Gateway

Amazon API Gateway supports the following three types of APIs supported by Amazon API Gateway:

  1. HTTP APIs(Stateless):
    1. Optimized for serverless workloads: HTTP APIs are designed to proxy requests to AWS Lambda functions or other HTTP backends, making them ideal for building serverless applications.
    2. No API management features: Unlike REST APIs, HTTP APIs are simpler and do not offer features like API key management, usage plans, or analytics.
  2. REST APIs(Stateless):
    1. Proxy functionality with API management: REST APIs in API Gateway offer the ability to proxy requests to backend services (like Lambda or HTTP endpoints), while also providing a comprehensive suite of API management features.
    2. API management features include:
      1. Usage plans
      2. API keys
      3. Publishing
      4. Monetization
      5. These features allow you to manage and scale your APIs effectively.
  3. WebSocket APIs(Stateful):
    1. Persistent connection for real-time communication: WebSocket APIs maintain an open connection between the client and the server, allowing for continuous, two-way communication.
    2. Real-time message delivery: Ideal for real-time applications such as chat, gaming, and live data feeds. When a message is received from a client, WebSocket APIs can trigger backend integrations, such as AWS Lambda functions, Amazon Kinesis, or HTTP endpoints.

2. Throttling incoming requests

Amazon API Gateway uses throttling to control the rate of incoming requests and prevent API from being overwhelmed. This is done using the token bucket algorithm.

  1. Token Bucket Algorithm:
    1. The token bucket algorithm is used to manage the flow of requests. Tokens are added to the bucket at a fixed rate, and each incoming request requires a token to be processed.
    2. If there are no tokens available when a request arrives, the request is throttled (rejected or delayed until tokens become available).
  2. Steady-State Rate:
    1. This is the rate at which tokens are added to the bucket, essentially the normal request processing rate over time. It is defined in requests per second (RPS).
  3. Burst Limit:
    1. The burst is the maximum number of requests that can be handled at once beyond the steady-state rate, without exceeding the limit. This is the maximum bucket size.
    2. If the number of incoming requests exceeds the available tokens in the bucket (and the bucket is full), excess requests will be throttled or rejected.

3. API Gateway vs Internet Gateway

  1. API Gateway:
    1. A regional service.
    2. Operates at the Application Layer 7(request level)
    3. Handle requests coming from outside to access backend resources in VPC.
  2. Internet Gateway:
    1. Operates at the Network Layer 3(IP Address)
    2. Handle requests going outside from a resource within a public subnet VPC.
    3. Allows instances in your VPC to communicate with the internet, handling outbound traffic like software updates or API calls to third-party services.
    4. Attached to a VPC and provides a connection between that VPC and the internet.
    5. It's specific to a VPC, so each VPC can have only one Internet Gateway.

4. API Gateway Caching

  1. You can enable caching in Amazon API Gateway to cache your endpoint's responses.
  2. Reduces the number of calls to your endpoint and improves latency for API requests.
  3. Caching is enabled for a specific stage in API Gateway.
  4. API Gateway caches responses for a specified time-to-live (TTL) period (in seconds).
  5. The default TTL value for API caching is 300 seconds.
  6. The maximum TTL value is 3600 seconds.
  7. Setting TTL=0 means that caching is disabled.
  8. Ideal for use cases where stale data can be accepted for up to 24 hours.
  9. API Gateway responds to requests by looking up responses in the cache, reducing the need to query the endpoint.
  10. When to Use API Gateway Caching:
    1. When caching is needed for single-stage API requests and responses.
    2. For simple TTL-based caching with minimal setup.
    3. When caching logic is tied directly to an API Gateway stage, reducing complexity.
  11. Redis Cache is ideal for complex, shared, and flexible caching scenarios, while API Gateway caching is suited for simple, stage-specific caching needs. Example where redis cache is preferred - An e-commerce platform has multiple microservices for product catalog, user recommendations, and inventory management. These services need to access the same frequently queried data (e.g., product details, stock availability) with different requirements

5. Pricing

  1. Core Pricing: Number of API requests processed + amount of data transferred out of the API Gateway as response.
  2. Optional: Caching (charged hourly based on size).

6. HTTP_PROXY and AWS_PROXY

HTTP_PROXY and AWS_PROXY are two integration types for Amazon API Gateway when connecting to backend services.

  1. HTTP_PROXY: A direct integration with an HTTP or HTTPS endpoint. API Gateway forwards client requests to the specified backend endpoint, acting as a transparent HTTP proxy.
  2. AWS_PROXY: Also known as Lambda Proxy integration, this is a direct integration with AWS Lambda functions or other AWS services (using AWS SDK).

7. Configure a Custom Domain for API Gateway with Route 53

User --> DNS Lookup (Route 53) --> API Gateway Custom Domain (api.example.com) --> Backend API

  1. Create an API Gateway Regional Endpoint: Deploy the backend microservices in API Gateway with a regional endpoint.
  2. Get an SSL/TLS Certificate: Use AWS Certificate Manager (ACM) in the same region as API Gateway to request or import a certificate for your domain (e.g., api.example.com).
  3. Set Up a Custom Domain in API Gateway: Associate the custom domain name (api.example.com) with the API Gateway endpoint and attach the ACM certificate in the same region where the API Gateway is hosted.
  4. Configure Route 53: Create an alias record for api.example.com in the Route 53 hosted zone to point to the API Gateway custom domain.
  5. Test the Setup: Access the API securely via https://api.example.com and verify functionality and HTTPS encryption.

8. Question:

A company has registered its domain name with Amazon Route 53. The company uses Amazon API Gateway in the ca-central-1 Region as a public interface for its backend microservice APIs. Third-party services consume the APIs securely. The company wants to design its API Gateway URL with the company's domain name and corresponding certificate so that the third-party services can use HTTPS. Which solution will meet these requirements?

  1. Create a Regional API Gateway endpoint. Associate the API Gateway endpoint with the company's domain name. Import the public certificate associated with the company's domain name into AWS Certificate Manager (ACM) in the same Region. Attach the certificate to the API Gateway endpoint. Configure Route 53 to route traffic to the API Gateway endpoint. (Correct Ans)
  2. Create a Regional API Gateway endpoint. Associate the API Gateway endpoint with the company's domain name. Import the public certificate associated with the company's domain name into AWS Certificate Manager (ACM) in the us-east-1 Region. Attach the certificate to the API Gateway APIs. Create Route 53 DNS records with the company's domain name. Point an A record to the company's domain name.

9. Question: Listener rule - redirect http to https

A company has a website hosted on AWS. The website is behind an Application Load Balancer (ALB) that is configured to handle HTTP and HTTPS separately. The company wants to forward all requests to the website so that the requests will use HTTPS. What should a solutions architect do to meet this requirement?

  1. Update the ALB's network ACL to accept only HTTPS traffic.
  2. Create a rule that replaces the HTTP in the URL with HTTPS.
  3. Create a listener rule on the ALB to redirect HTTP traffic to HTTPS. (Correct Ans)
  4. Replace the ALB with a Network Load Balancer configured to use Server Name Indication (SNI).

Explanation: It is not possible to replace the HTTP in the URL with HTTPS directly using a single rule on the ALB. The correct action is to redirect all incoming HTTP traffic to HTTPS by create a listener rule using the redirect-to-https action on the ALB that automatically redirects HTTP traffic to HTTPS. This allows the ALB to inspect incoming requests and, when detecting HTTP traffic, redirect it to the HTTPS listener.

8. List of Gateways in AWS