4 ms·

Yeah, that's not even bad... What AWS doesn't tell you, is elastic beanstalk creates new security groups and what not. So if (like me) you manage 12 Apps and yo

Yeah, that's not even bad... What AWS doesn't tell you, is elastic beanstalk creates new security groups and what not. So if (like me) you manage 12 Apps and you try to destroy one environment, the environment won't delete. Apparently, they all try to create the same named security group (as well as other components). This happens even if you change the security groups after launch. So it'll error out and be unable to delete the rest of the components. Leaving a "ghost" environment. That's just one of my many, many frustrations with it. I'm considering moving back to digitial ocean (where I was). However, the billing breakdown is nice to share with clients

spleen 8y ago
I would recommend separation of those applications into respective sub-accounts. The hierarchy can be defined in AWS Organizations and you avoid resource overlapping of any kind.
- lettergram 8y ago
  All these applications use the same backend and what not. This makes it easier to share access / permissions vis security groups and IAM role. Its actually separated quite well, just rediculous that if I try to destroy an environment I can't.
  - spleen 8y ago
    Oh, makes sense then.
nicoburns 8y ago
My understanding is that EB is a packaging together of lower-level AWS components (like auto-scaling groups) that you can use individually and patch together yourself if you wish. Maybe that could be a route to look into?
- lettergram 8y ago
  It is, I've gone through before and done that, took me a couple hours. But either way, this seems like it should be obvious to the AWS maintainers and should be fixed.
timf 8y ago
New environments are given a new, uniquely named security group (SG) by the service. Additional SGs can be supplied to allow access to the environment. There is a situation you can get into if you supply an SG auto-created by another environment which might be what is happening here? The documentation has a note that calls out how to avoid this dependency issue [1]. If that is not what is happening here, I am happy to help but might need more information about your environments. [1] - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.ec2.html#using-features.managing.ec2.securitygroups https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using...

spleen 8y ago

I would recommend separation of those applications into respective sub-accounts. The hierarchy can be defined in AWS Organizations and you avoid resource overlapping of any kind.

lettergram 8y ago
All these applications use the same backend and what not. This makes it easier to share access / permissions vis security groups and IAM role. Its actually separated quite well, just rediculous that if I try to destroy an environment I can't.
- spleen 8y ago
  Oh, makes sense then.

nicoburns 8y ago

My understanding is that EB is a packaging together of lower-level AWS components (like auto-scaling groups) that you can use individually and patch together yourself if you wish. Maybe that could be a route to look into?

lettergram 8y ago
It is, I've gone through before and done that, took me a couple hours. But either way, this seems like it should be obvious to the AWS maintainers and should be fixed.

timf 8y ago

New environments are given a new, uniquely named security group (SG) by the service. Additional SGs can be supplied to allow access to the environment. There is a situation you can get into if you supply an SG auto-created by another environment which might be what is happening here? The documentation has a note that calls out how to avoid this dependency issue [1]. If that is not what is happening here, I am happy to help but might need more information about your environments. [1] - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.ec2.html#using-features.managing.ec2.securitygroups https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using...