Remove the automatic EIP allocation in single instance Elastic Beanstalk environments

0

Hello

After a lot of testing, researching and reading, I have come to the conclusion that this is an error that needs to be addressed. Honestly, it does not matter if it's intended or not; it should not work like this.

Specifically, when launching a new Elastic Beanstalk environment, if you choose to deploy it as a single instance without load balancer, it doesn't matter if you deploy it in a private subnet or public subnet, and, most importantly, it doesn't matter if you DO NOT choose to assign a public IP (Configure networking and database ⇾ Instance settings ⇾ Public IP address), the instance will still get an Elastic IP either way.

I could manually disassociate the EIP from the instances after the deployment (and that's what I'm doing), but Elastic Beanstalk starts to behave weirdly in a random manner. In fact, sometimes it deploys the new application versions immediately as if nothing happened and sometimes it takes around 5 minutes before actually deploying, stating:

Address '11.22.33.44' not found. (Service: AmazonEC2; Status Code: 400; Error Code: null; Request ID: b1234-b1234-1234-b1234-b1234; Proxy: null) There is not an EIP associated with this environment. It may have been deleted.

Now, this wouldn't be much of a problem before February 2024, since associated EIPs were free. Now, on the other hand, EIPs have a cost of 3.65 USD each, whether they're associated to a running instance or not.

I manage, for example, many environments of different applications, and it's perfectly fine to use a NAT instance or proxy with only one Elastic IP to serve all the environments. This is an example showing that there could be a solution where EIPs aren't necessary to serve my web applications. Also, my deployment could be a backend-only application with no need for public access.

This said, Elastic Beanstalk should not assign an EIP automatically, especially when deploying my instances in private subnets, especially when I do choose not to.

2 Answers
4

Hlo Team,

1.Contact AWS Support: Reach out to AWS Support to report this behavior. They can investigate further and provide insights into whether this behavior is intended or if it's a bug that needs to be addressed. Review Elastic Beanstalk Configuration: Double-check your Elastic Beanstalk environment configuration to ensure that you've explicitly chosen not to assign a public IP address to instances. If you've configured the environment correctly and still encounter this issue, it might indicate a bug in Elastic Beanstalk.

2.Workaround: Manual Disassociation: As you mentioned, manually disassociating the EIPs after deployment is a workaround, but it's not ideal due to the unpredictable behavior you've observed. However, if this workaround is feasible for your use case, you may continue using it until a better solution is available.

3.Consider Other Deployment Options: If Elastic Beanstalk's behavior doesn't align with your requirements and there's no immediate resolution, you might explore alternative deployment options such as AWS ECS, AWS Fargate, or managing your EC2 instances directly. These services provide more fine-grained control over networking configurations and may better suit your needs.

4.Stay Informed: Keep an eye on AWS release notes, forums, and announcements for any updates regarding this issue or related changes to Elastic Beanstalk's behavior. AWS frequently introduces enhancements and fixes based on customer feedback.

5.Community Feedback: Engage with the AWS community through forums, discussion groups, or social media platforms to share your experience and gather insights from other users who may have encountered similar issues or devised workarounds.

answered 12 days ago
0
profile picture
GK
answered 12 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions