aws / elastic-beanstalk-roadmap

AWS Elastic Beanstalk roadmap
https://aws.amazon.com/elasticbeanstalk/
Creative Commons Attribution Share Alike 4.0 International
283 stars 11 forks source link

Remove public IP on single instance deployments #47

Open karl-cardenas-coding opened 4 years ago

karl-cardenas-coding commented 4 years ago

Community Note

Tell us about your request Currently, when selecting a single instance (no load balancer), and validating that no public is specified. The EB instance is still being created with a Public IP, an ENI. This is not the desired configuration and does not reflect the choice I made as a user.

Is this request specific to an Elastic Beanstalk platform? All of them.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

If I attempt to disassociate the ENI from the instance, it get's re-associated. I can't find the automation in my account so it must be handled by the EB service behind doors.

Are you currently working around this issue? Not consuming the service and leveraging ECS instead, though not a good alternative due to everything else EB offers. Placing a load balancer on the instance does resolve the problem but there are situations where consumers just want to learn the service and that's when the single instance is ideal.

Additional context This is coming from an enterprise perspective. Having public instances in private subnets is not the ideal behavior.

Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

OkJaybird commented 4 years ago

This bit me pretty hard today, and it was really surprising/unfortunate to discover this as a blocker.

As for our particular use case - We have a large suite of simple but specialized applications that need to run as single instances inside of a private subnet. Not only do we not want public IPs attached to the instances, but we quickly hit our EIP limit if we go the single instance route. Of course, we can sort of hack the load balancer approach by provisioning an internal ELB and setting the number of instances to 1, but then that doesn't scale financially. Why pay for a large number of load balancers when there's nothing to load balance?

We would prefer to leverage all the built-in benefits of EB for managing the lifecycle of applications like these, but it doesn't seem there is really a path forward today for using EB under this constraint.

sebmellen commented 4 years ago

@OkJaybird I was in the same camp. We've since made the decision to switch to using ECS/Fargate and one ALB to route network traffic properly. I would've liked to solve this issue without Dockerization, but it seems EB is not yet mature enough for private subnet deployment.

csbakersoft commented 2 years ago

Any progress on this? It's a blocker for us as well and really disapointing to discover after having spun up a whole env.

pippolino commented 11 months ago

Any news after 4 years?

hchalouati commented 10 months ago

Hope this request will progress. It is a real limitation for EB

ggedde commented 3 months ago

I thought I could just add a script to aws ec2 associate-address ... with another EIP on a single instance deployment. The script does run successfully. However, moments later EB reassigns the old (unwanted) EIP to the instance. If we could fully remove the EIP from a Single Instance setup, then I wonder if this would work properly.