I've used EB extensively for a range of applications and it has been very reliable. There have been a few pain points (see cons below), but I suppose this is to be expected given the complexity that it tries to manage.<p>Pros (in addition to managing much of the complexity of a highly available application):<p>- Works well with docker-compose (multi-container environment)<p>- Easy to setup multiple environments (e.g. staging, production etc)<p>- EB extensions: these are optional scripts that run on newly created instances before they come online. This might include adding CRON jobs, attaching an EFS, or flagging an instances as the "leader" to ensure only one instance runs DB migrations.<p>Cons:<p>- It can be difficult finding relevant errors in logs, as several logs groups for different services are output. Be sure to stream logs to Cloudwatch (this is easily done in the config), otherwise you won't be able to extract logs from a buggy instance that has since been terminated.<p>- Depending on your configuration, deployments can be slow. If you've configured rolling deployments and have 5 servers running, you will have to wait for 5 newly created instances to come online, each in turn. The upside is that rolling deployments give you a chance to catch newly deployed bugs and rollback the deployment before it affects all servers. You could alternatively configure an "all at once" deployment strategy.<p>- If your instance health checks are too stringent, it can become frustrating to get your application back in the healthy state. Consider a scenario where your health check page (e.g. /health) pings a non-essential cache database. If your cache database goes offline, EB will treat your application as unhealthy. I recommend keeping the health check page very simple, and setting up separate alarms for other services.<p>To add to/counteract some points seen in another comment:<p>Cloudposse has modules that make beanstalk quite manageable with Terraform: <a href="https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment" rel="nofollow">https://github.com/cloudposse/terraform-aws-elastic-beanstal...</a><p>"Hard to attract talent": I'm skeptical this is an issue in most cases. After all, EB exists so that you don't have to think too much about the infra. For simple use cases, a general understanding of the infra components (not EB-specific) will go a long way. However I can understand talent/developer time could be an issue you're doing something really fancy with EB, such as making heavy use of EB extensions.<p>"Not the future": This sounds like another way of saying "it's not trendy". Whilst I agree, this point doesn't weigh heavily for me, as I'd try to focus on doing what's right for the application and the team.