Overall Satisfaction with AWS Elastic Beanstalk
We use Elastic Beanstalk for an easy deployment of our API workloads. This allows your development teams to be agile and have regular releases with 0 downtime, and with minimal infrastructure worries as the VPC the workloads are deployed to are already securely locked down. Prior to this the development teams would have had to request a new server and go through the change control taking up to 1 week before a new release could be pushed out.
- Zero downtime deployments
- Auto scales, ensuring maximum flexibility.
- Auto scaling also provides a cost saving as you only use what you need.
- Agile deployments - dev environments regularly have 5+ releases a day.
- More flexibility on the subnet structure (depending on use case scenario and how your VPC is carved up you can run out of address space quickly if you want to spread workloads across multiple AZs).
- If development teams need Elastic Beanstalk admin access.....they automatically get EC2:* permisisons which isn't ideal.
- A lot of the drawbacks can be addressed by using ECS.
- Positive - we are able to reliable scale our API workloads, due to nature of workloads we run on tiny instances (t2 series) meaning we only pay for what we need.
- Amazon CloudFront, Amazon Elastic Compute Cloud (EC2), Amazon CloudSearch, Amazon CloudWatch, Amazon Route 53, Amazon S3 (Simple Storage Service) and Amazon Simple Email Service
We now default to Amazon ECS, due to flexibility this gives us with how workloads scale, and more network flexibility as many of our workloads are internal / external facing. We selected Elastic Beanstalk at beginning of our containerization phase, which suited our needs whereby we wanted an 'out of the box' type experience from a CloudOps perspective.
Would recommend if you're new to container workloads or new to AWS. Also good if ayou're small start-up and don't necessarily want to worry about networking of your VPC or have the resources for a dedicated CloudOps engineer.