Elastic Beanstalk environment fails to build due to failed health check

0

I'm creating an EB environment with no public IP address and an internal load balancer. The environment always fails with health check errors before it even loads my application. It seems like after the instance is added, it wants to wait for an OK healthcheck... but I don't think my application has been deployed yet, so the healthcheck will fail. I thought about configuring it to ignore health check for deployments, but should this be necessary?

EDIT: confirmed my application isn't deployed. So there is no http listener.

The event logs are as follows:

May 31, 2024 14:14:29 (UTC-5)	INFO	Launched environment: prod-api-server. However, there were issues during launch. See event log for details.
May 31, 2024 14:14:25 (UTC-5)	ERROR	The EC2 instances failed to communicate with AWS Elastic Beanstalk, either because of configuration problems with the VPC or a failed EC2 instance. Check your VPC configuration and try launching the environment again.
**May 31, 2024 14:14:25 (UTC-5)	ERROR	Stack named 'x' aborted operation. Current state: 'CREATE_FAILED' Reason: The following resource(s) failed to create: [AWSEBInstanceLaunchWaitCondition].**
**May 31, 2024 14:08:08 (UTC-5)	WARN	Environment health has transitioned from Pending to Severe. ELB processes are not healthy on all instances. Initialization in progress (running for 11 minutes). None of the instances are sending data. ELB health is failing or not available for all instances.**
May 31, 2024 14:00:09 (UTC-5)	INFO	Added instance [i-x] to your environment.
May 31, 2024 13:59:43 (UTC-5)	INFO	Created Load Balancer listener named: x
May 31, 2024 13:59:43 (UTC-5)	INFO	Created load balancer named: x
May 31, 2024 13:57:38 (UTC-5)	INFO	Created Auto Scaling group policy named: x
May 31, 2024 13:57:38 (UTC-5)	INFO	Created Auto Scaling group policy named: x
May 31, 2024 13:57:38 (UTC-5)	INFO	Created CloudWatch alarm named: x
May 31, 2024 13:57:38 (UTC-5)	INFO	Created CloudWatch alarm named: x
May 31, 2024 13:57:38 (UTC-5)	INFO	Waiting for EC2 instances to launch. This may take a few minutes.
May 31, 2024 13:57:38 (UTC-5)	INFO	Created Auto Scaling group named: x
May 31, 2024 13:57:23 (UTC-5)	INFO	Created target group named: x
May 31, 2024 13:57:09 (UTC-5)	INFO	Environment health has transitioned to Pending. Initialization in progress (running for 16 seconds). There are no instances.
May 31, 2024 13:57:08 (UTC-5)	INFO	Created Auto Scaling launch configuration named: x
May 31, 2024 13:57:07 (UTC-5)	INFO	Created security group named: x
May 31, 2024 13:57:07 (UTC-5)	INFO	Created security group named: x
May 31, 2024 13:56:51 (UTC-5)	INFO	Created Amazon CloudWatch log group named: /aws/elasticbeanstalk/prod-api-server/var/log/eb-hooks.log
May 31, 2024 13:56:51 (UTC-5)	INFO	Created Amazon CloudWatch log group named: /aws/elasticbeanstalk/prod-api-server/var/log/eb-engine.log
gefragt vor 5 Monaten206 Aufrufe
1 Antwort
1

Hello.

The EC2 instances failed to communicate with AWS Elastic Beanstalk, either because of configuration problems with the VPC or a failed EC2 instance. Check your VPC configuration and try launching the environment again.

If EC2 does not have a public IP address assigned, you will need to configure it to communicate with ElasticBeanstalk using something like NAT Gateway.
Check out the documentation below to troubleshoot your VPC configuration.
https://repost.aws/knowledge-center/elastic-beanstalk-instance-failure

profile picture
EXPERTE
beantwortet vor 5 Monaten
profile picture
EXPERTE
überprüft vor 5 Monaten
  • Thanks for your answer. Does this mean that EB cannot use private subnets to communicate with the instance? I'm surprised that EB management traffic and HealthWatch and such can't communicate with an instance using private subnets so all traffic stays within a VPC.

  • In fact, my reason for wanting to keep the EB environment non-public was this particular environment only communicates with one web server that is also inside the VPC. But rather than having to configure a bunch of VPC stuff like NAT Gateways I could simply enable the public IP address for this environment.

    If I do that, I'd like to "lock down" the Security Group to permit only traffic to/from my web server. I know how to do that...

    But can you tell me how I can keep enabling HealthWatch and Elastic Beanstalk management traffic? In other words, do I need to open connections to certain IP addresses that AWS uses for these services? Or, is AWS management / service traffic ALWAYS allowed and Security Groups only filter user (non aws) traffic?

Du bist nicht angemeldet. Anmelden um eine Antwort zu veröffentlichen.

Eine gute Antwort beantwortet die Frage klar, gibt konstruktives Feedback und fördert die berufliche Weiterentwicklung des Fragenstellers.

Richtlinien für die Beantwortung von Fragen