AWS HTTP API Gateway connected to ALB returns 503

user_6701496 0
Viewed 548

My current solution: My application consists of two separate services/containers deployed to ECS. These services are inside Virtual Private Cloud (VPC) and to expose the application I created EC2 Application Load Balancer, which works flawlessly, I can access the application through Load Balancer URL easily.

What I'm trying to achieve: Currently I'm trying to create an API Gateway linked to the load balancer mentioned above, to access the application by API Gateway instead of Load Balancer.

What I did to achieve this I found an AWS tutorial which basically does what I'm trying to do, so I went step by step with this tutorial

  1. Created Http API Gateway
  2. Created VPC-LINK (connected to all possibles subnets and all possible security groups just in case)
  3. Created single route ANY /{proxy+} to catch basically everything
  4. Created integration to that route (where I selected mentioned above load balancer as a target service).

Everything is step by step, the same as in the tutorial, but unfortunately last step where I should see my webpage I see ERROR: 503 {"message":"Service Unavailable"}

What I did additionally to solve the issue:

  • Added Api Gateway logs, but I'm not receiving anything interesting there, just raw data like below:
{
    "requestId": "PgELwjAyjoEEPgQ=",
    "ip": "185.244.96.51",
    "requestTime": "24/Mar/2022:18:09:40 +0000",
    "httpMethod": "GET",
    "routeKey": "ANY /{proxy+}",
    "status": "503",
    "protocol": "HTTP/1.1",
    "responseLength": "33"
}
  • played with different load balancer listeners (443 or 80).
  • played with different security groups (tried with same security groups as ALB, or with all possible security groups)

The question is, what I'm missing here? I guess the problem lies somewhere in the connection between VPC link and load balancer, but to be honest I don't know how to check and verify it. I clicked everything step by step, in many places there was single choice option, so I'm really confused where I could have made a mistake. Here is an illustrative photo of the infrastructure and my guess where the problem could be (but it's still a guess.enter image description here

aws-api-gateway amazon-vpc amazon-web-services amazon-ec2
2 Answers

The only thing I can think of is, why? Like seriously, APIGW doesn't provide any additional value over the ALB. If you are already using an ALB, the easiest, cheapest, and best thing to do, is point your route53 DNS at the ALB and be done.

In any case VPC-link will never work, APIGW doesn't work with internal VPC, and VPC-link requires the client to be in the same VPC as the service. Since VPC-link is inside the VPC and the HTTP API is outside of course this would cause a problem, and specifically "I can't find that dependency" where 503 is the expected status code.

If some ridiculous reason you still wanted to use APIGW with a public ALB, you can point the APIGW directly at the ALB DNS, and be done. But again, this offers negative value AND costs additional money + performance for an all around negative impact on your users, developers, and your corporate wallet.

If for some reason after all that, here is the AWS Documentation on VPC-Link. In reality the problem with the setup is likely a further configuration issue. You can validate this by checking the ALB flow logs.

user_50918740

One reason to want to do this approach is that the API Gw is being used with say Cognito to provide the access security to the backend API in the VPC rather than say an x-api-key header which is very insecure. In this way API Gw can provide user group level security of all the APIs exported by the backend service. It can also be used to deny access to certain apis through route configuration.

user_198331680
Related