CODEWITHSUNDEEP
amazon-web-servicesaws-lambdaaws-api-gatewayaws-elb
Abhijit
Abhijit

Reputation: 21

AWS Lambda (URL) rewrite flow

I am new to Lambda so I would like to understand how the following scenario can be deployed:

  1. Lambda connected to API gateway ( which in turn connected to a reverse proxy)
  2. The request from API gateway to lambda needs to be routed to 3 different ALBs each in different (VPCs) private subnets.

What configuration changes I need to bring in to achieve this apart from writing Lambda function (using python) to rewrite the urls?

It would be nice if someone can explain the message flow here.

Thanks Abhijit

Upvotes: 2

Views: 3469

Answers (1)

Chris Williams
Chris Williams

Reputation: 35238

This to me seems to be multiple issues, I'll try to break down whats trying to be achieved.

Using ALBs with API Gateway

There are many options for how API Gateway can use load balancers to serve http traffic. The solution really depends on which type of API Gateway you are trying to use.

Assuming your API is either REST or WebSockets you are left with 2 choices for enabling HTTP traffic inbound to a load balancer:

  • Directly as a HTTP or HTTP_PROXY request, listing publicly accessible hostnames to which API Gateway will forward the traffic.
  • If you want to keep transit private then your only option is to create a network load balancer and make use of VPCLink to create a private connection between API Gateway and your Network resource.

If you're creating a HTTP API (sometimes referred to as API Gateway v2) then you can make use of direct connection to a private ALB, however be aware that at this time HTTP API does not support all the features of REST APIs so you would want to compare feature sets before doing this.

Using multiple load balancers to direct traffic

You determine the value per each resource/method combo, for example POST /example would be assigned its target endpoint, but only one.

My suggestion would be to make use of stage variables if you're using a REST API to specify any endpoints that you're forwarding traffic for the following reasons:

  • Prevents mistyping of domain names
  • Allows quick replacement of a hostname
  • Provides functionality for canary deployments to shift traffic proportionally between 2 variable names (these could be anything as long as the type is the same e.g. Lambda to another Lambda, not Lambda to a load balancer).

Using a Lambda to redirect

Technically a Lambda can perform a redirect by return a response using the below syntax

{
    statusCode: 302,
    headers: {
      Location: 'https://api.example.com/new/path',
    }
}

However be aware this will change the request to become a GET request, this will also remove the payload of the body request when the redirect occurs. Additionally you would need to set this up for every resource/method combo that you wanted to redirect.

There are 2 options that you have available to get around these issues, both involve using CloudFront combined with a Lambda@Edge function.

The first solution can act as a workaround for the request type changing, in the Origin Request event you could modify the Request URI property to match the new URI structure. By doing this your clients would be able to use the API still, whilst you would notify them of the depercations to certain paths that you were migrating.

The second solution acts as a workaround for the need to add redirects to each resource/method combo which can create a lot of mess of methods just for redirects. You could create a Lambda@Edge function to perform the same redirect on an Origin Response event. You could create mappings in your Lambda function to work out which URL it should redirect to.

There are many great examples on the Lambda@Edge example functions page

Upvotes: 2

Related Questions