Phase 2: Core Cloud Services

API Gateway integration, throttling & authorization

Intermediate ~2 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you have a fantastic chef in a busy restaurant – that chef is like your super-smart computer program (called a "Lambda function") that can do amazing things, like process game scores or send out messages. But how do people, or other computer programs, order from this chef? They can't just walk into the kitchen!

This is where an "API (Application Programming Interface) Gateway" comes in. Think of it like the friendly host at a very popular restaurant. The API Gateway is the first person you meet. It takes your order (which we call a "request" when computers talk), makes sure you're in the right place, and then tells the chef what to cook. It's the essential "front door" for your digital kitchen, handling how other programs talk to your special chef programs.

There are different ways the host (API Gateway) can give the order to the chef. Sometimes, the host just takes your entire, exact order slip and hands it straight to the chef. The chef then reads everything and figures out how to make it. This is super easy for the host – they're just a direct messenger. Other times, the host might look at your order, maybe summarize it, translate some fancy ingredients into simpler terms for the chef, or add a special note before giving it to the chef. This takes a bit more work for the host but makes sure the chef gets exactly what they need in the easiest format for them.

Now, what if suddenly a huge bus full of hungry people shows up, and everyone wants to order at the exact same time? Even the best chef can get completely overwhelmed! The host has a very important job here: "Throttling." This means limiting how many orders can go into the kitchen at once. The host might politely say, "Sorry, we're full right now, please wait a few minutes," or "We can only take 10 new orders every minute to make sure the food is still perfect." This isn't to be mean; it's to protect your amazing chef from getting too stressed and making mistakes, making sure everyone eventually gets their delicious meal without the whole restaurant crashing down.

And finally, the host also handles "Authorization." This is like checking if you have a special invitation or if you're a regular customer who gets access to the secret menu. The host makes sure only the right people can order certain special dishes or use certain parts of the restaurant. If you're not allowed, they politely say, "Sorry, that's for VIPs only." So, when you build your own amazing online games or apps, using something like API Gateway means you can have millions of people use them without your backend programs getting overloaded. It helps you control who gets in, how much they can ask for, and makes sure your awesome programs can keep serving everyone perfectly!

API Gateway serves as the essential "front door" for your serverless applications, particularly when exposing AWS Lambda functions as REST or WebSocket APIs. Its primary integration type for Lambda is the "Lambda Proxy Integration," which simplifies development by passing the entire request context directly to your Lambda function and expecting a straightforward response structure. This minimizes configuration overhead on API Gateway, letting your Lambda handle all request parsing and response formatting. For more advanced scenarios, or when integrating with non-Lambda backends (like HTTP endpoints or other AWS services), "non-proxy" integrations offer granular control over request and response mapping, transforming data before it reaches your backend or client.

Beyond simple integration, API Gateway provides crucial mechanisms for managing API traffic. Throttling is a vital feature for protecting your backend services (like Lambda functions or databases) from being overwhelmed by excessive requests, whether accidental or malicious (DDoS). You can configure global account-level limits, and more granular per-method or per-stage throttling rules. This ensures service availability and predictable performance, preventing individual endpoints from consuming too many resources and impacting other parts of your application or incurring unexpected costs.

Finally, robust authorization is paramount for securing your APIs. API Gateway offers several powerful options: AWS IAM for granting access to trusted AWS principals using roles and policies; Lambda Authorizers (formerly Custom Authorizers) for highly flexible, custom authentication and authorization logic (e.g., validating JWTs from external identity providers, or implementing complex policy lookups); and Amazon Cognito User Pools, which provide managed user authentication and authorization, simplifying the integration of standard OIDC tokens for user-facing applications. Choosing the right authorization method depends on your specific security requirements and existing identity management systems.

Key Takeaways

  • API Gateway acts as the scalable HTTP interface for your Lambda functions and other backends.
  • Lambda Proxy integration is the simplest and most common way to integrate API Gateway with Lambda.
  • Throttling prevents backend overload, ensures API stability, and helps manage costs by limiting request rates.
  • API Gateway offers flexible authorization options (IAM, Lambda Authorizers, Cognito) to secure your endpoints based on your use case.

Code Example

yaml
functions:
  myProtectedLambda:
    handler: handler.myProtectedFunction
    events:
      - http:
          path: /protected-resource
          method: GET
          cors: true
          # Throttling limits for this method
          request:
            throttle:
              rateLimit: 5   # requests per second
              burstLimit: 10 # burst capacity
          # Authorization using a custom Lambda Authorizer
          authorizer:
            name: customAuthorizer
            arn: arn:aws:lambda:REGION:ACCOUNT_ID:function:MyAuthorizerFunction
            type: request # or token
            identitySource: method.request.header.Authorization
            resultTtlInSeconds: 300 # cache authorization decisions

How this code works

This code defines a serverless Lambda function, myProtectedLambda, and exposes it as an API endpoint, GET /protected-resource, with built-in protections for rate limiting and custom authorization. The cors: true setting ensures the API can be called from different web domains.

The request block, specifically throttle, is crucial for managing traffic. rateLimit: 5 permits only five requests per second to this endpoint, while burstLimit: 10 allows for temporary spikes in traffic, preventing the API from being overloaded and maintaining stability. Following this, the authorizer block enforces access control. It specifies a custom Lambda function, MyAuthorizerFunction, to validate incoming requests. The identitySource: method.request.header.Authorization tells API Gateway where to find the authorization token (in the Authorization header). A subtle but important detail is type: request, which means the entire request context (headers, query strings, etc.) is sent to the authorizer, not just a single token. This provides immense flexibility for complex authorization logic, unlike type: token which is more restrictive. Finally, resultTtlInSeconds: 300 caches authorization decisions for 5 minutes, significantly reducing the authorizer's invocation count and improving performance and cost efficiency.

Resources

Related Articles

Hand-picked reads to go deeper on serverless & lambda.

Back to Cloud Architect Roadmap