CODEWITHSUNDEEP
amazon-web-servicesamazon-ec2aws-api-gatewayamazon-vpc
degath
degath

Reputation: 1621

AWS HTTP API Gateway connected to ALB returns 503

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:

{
    "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"
}

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

Upvotes: 7

Views: 3894

Answers (5)

Woody1193
Woody1193

Reputation: 7970

For me, the issue was having the ALB and VPC link inside the same security group. Apparently, if you do that, the security group needs to have access to itself (which it didn't, because who thinks of doing that!?). Anyway, after I created dedicated security groups for the VPC link AND the ALB and ensured that they had access to each other, then the connections were actually less broken. I'm still getting 500 errors due to TLS negotiation issues, but at least the 503s are gone.

Upvotes: 0

Dalibor Frivaldsky
Dalibor Frivaldsky

Reputation: 850

For me, this was caused by having the default security group of the VPC with no outbound rules (and no inbound rules either, but that doesn't matter in this case). Without providing any security groups to the VpcLink, it was actually using the default one, which was blocking all outbound traffic from the VpcLink to my ALB.

I verified this was the case by temporarily adding an outbound rule to my default security group for all traffic and it started to work.

Thus, the solution I went with was to create a security group specifically for the VpcLink, with single outbound rule allowing traffic to the security group of my ALB.

Note I was using AWS CDK apigateway2-alpha, version 2.104.0a0

Upvotes: 3

jns_ai_unr
jns_ai_unr

Reputation: 903

So I was using the AWS CDK 2.85.0 and I created an HttpAlbIntegration and just passed the (first) listener of the ALB of my Fargate service. For some reason AWS does create a VPC link for you, but that VPC link does not receive the appropriate SecurityGroups. Therefore the "out of the box" setup does not work. Manually creating a VPC link and adding that to the props of the HttpAlbIntegration did it for me:

const securityGroup = new SecurityGroup(this, "allow-in", {
  vpc: myVpc,
  allowAllOutbound: true,
})
securityGroup.connections.allowFrom(ec2.Peer.anyIpv4(), ec2.Port.tcp(80))
securityGroup.connections.allowFrom(ec2.Peer.anyIpv4(), ec2.Port.tcp(443))

const vpcLink = new VpcLink(this, "link", {
  vpc: myVpc,
  subnets: {
    subnetType: SubnetType.PRIVATE_WITH_EGRESS
  },
  securityGroups: [securityGroup]
})

const api = new HttpApi(this, "my-api", {})

const proxyIntegration = new HttpAlbIntegration('my-alb', myLoadBalancer.listeners[0], {
  vpcLink: vpcLink
})
api.addRoutes({
  path: "/myroute",
  methods: [HttpMethod.ANY],
  integration: proxyIntegration
})

(Please note, that this code is part of a larger setup and might not work independently)

Upvotes: 4

user19833168
user19833168

Reputation: 31

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.

Upvotes: 3

Warren Parad
Warren Parad

Reputation: 4074

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.

Upvotes: 3

Related Questions