1

I'm using an Application Load Balancer with AWS Elastic Beanstalk

After an AWS automatic server update, I was getting a 503 Service Temporarily Unavailable page. (only this, with near zero server load - single instance)

[PHP 7.3 running on 64bit Amazon Linux/2.9.2 (upgraded from 2.9.1 automatically)]

The Environment itself showed healthy.

I'm using the Application Load Balancer for HTTPS and for future scaling.

It turns out that AWS EB had created a new EC2 instance and terminated the previous instance, and thus there was no instance registered in the Target Group for which the Application Load Balancer was directing to.

How can I configure AWS to have a replacement Elastic Beanstalk EC2 instance be automatically registered in a Target Group for an Application Load Balancer?

Improve this question

2 Answers 2

Reset to default
1

This was a while back, and what seems to have been working well for me is adding the applicable Target Group under the Target Group section under the Auto Scaling Groups.

So go to EC2 Console, then at the very bottom of the left menu (currently for me anyways) there's the Auto Scaling Groups. Click on the auto scaling group from the list, and on the Details tab, click Edit, and then add the applicable Target Group.

This then seems to keep them in sync even as the instances change.

So it should look like this: Screenshot

Improve this answer
1
  • @sfnd, if your option didn't work, you can try this. Sorry, by the time I knew this had solved it, I forgot I had posted this question.
    – Ben in CA
    Jun 10, 2020 at 19:17
0

I faced the exact same problem. After a day of Googling around and trying different approaches, I ended up adding a script to my .ebextensions directory with these directives:

container_commands:
   01_register_ALB_target:
    command: "aws elbv2 register-targets --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:xxxxxxxx:targetgroup/xxxxx/xxxxx
--targets Id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)"

To be honest, I'm not 100% sure it will work perfectly in an actual crash-and-reboot situation. For example, I'm making no effort to remove the previous instanceId from the target group (I'm guessing it gets removed automatically, at least after a while). But the command definitely gets run during deployment and seems to do no harm if the instance already was registered with the target.

See: https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .