当服务（在 ecs fargate 上）返回 503 时，AWS 弹性负载均衡器能否将请求重定向到 lambda function

Question

The goal is that when the service is unavailable I'd redirect it to the lambda function.

Requests going through AWS Elastic Loadbalancer to service in ECS, let say service is paused (ie task count=0) then we get a message "503 services temporarily unavailable" on the web. now when this happens I would like to redirect this request to a lambda or anywhere else.

addition1: I am using route53 as my DNS. I am doing filtering of requests on ALB level, In route53 I have a record *.example.com send to my ALB then on ALB I'm filtering using host-header and send to target group containing the target.

addition2: (based on my research so far) I have two approaches in my mind, it would be helpful if received some comments

Approach1: Two target groups 1 directs to target other directs to lambda function then based on trigger events I can change weights for these target groups

Approach2: Two targets in single target group base on the event I will toggle btw targets

Answer 1

You can't do it directly on ELB alone.

However, if you can use Route53, you could configure DNS failover with failover records .

Using the failover records you would define primary and secondary records . The primary would point to the ELB, while secondary, for example, to a S3 static website. The health checks on the primary record would automatically failover your users to the secondary record if ELB (ie your ecs tasks go to zero).

When ELB becomes health again, failover will start routing traffic from it again automatically .

Answer 2

You have 2 choices for how you can handle this type of issue.

The first way to do this is through using Route 53, assuming you're not using Route 53 as your DNS solution you would need to first migrate to using Route 53 as your DNS provider.

Once you have migrated you can then update the record for the host to become a failover record which would automate the failing over to the secondary value in the event of an issue.

However, no everyone wants to migrate to Route 53 or possibly cannot migrate. For this there is another solution, which is to use a CloudFront distribution in front of your endpoint.

By doing this you are presented with a couple of solutions:

• CloudFront Custom Error pages for displaying a nice friendly error if something occurs (this is what Amazon used to display there error pages during Prime Day of Dogs of Amazon ).
• Use a Lambda@Edge to modify the behaviour if an error code is detected.

The advantage to the CloudFront solutions is that both actually apply instantly when an error occurs, whereas Route 53 takes potentially a few health checks, looking at 30-60 seconds before failover.

This means whenever your service becomes available again you will have instant service return back with CloudFront.