Why I migrated from AWS Beanstalk to ECS + Fargate: A Personal Perspective

When faced with the choice of deployment an app in AWS, I found myself starting with Elastic Beanstalk since it was easier to start with and everyone was saying that that’s the most straightforward way to deploy something on AWS. At that time, I had never experienced ECS.

I worked with Beanstalk intensively in the last 6 months and finally decided to give up on it and try something else, which was going to be ECS.

While trying to point out clear facts about how Beanstalk is not good, I realised is not be that easy, but the most straightforward way to express my feelings — it just didn’t give me a great User Experience

So I did a step back and started to analyse again what options do I have.

AWS offers three distinct deployment levels, catering to different needs:

• Elastic Beanstalk: This is the most basic level, focusing solely on code deployment.
• ECS (Elastic Container Service): Positioned as a middle-ground solution, ECS revolves around Docker containers. This is where I found my sweet spot.
• EKS (Elastic Kubernetes Service): As the most advanced option, EKS is built on Kubernetes, offering extensive flexibility and customization.

As long as your application is not that big to require Kubernetes, ECS will stand out as the go-to solution for deploying scalable container services, especially in managed environments.

There are 2 underlying hosting options for the ECS:

• Fargate - this is the solution I’ve chose. I like going fully serverless.
• EC2 - this means you’ll have to manage the EC2 instances.

Once I’ve tried ECS, it became easier for me to point out the differences between Beanstalk and ECS and why the first one was not that good:

• Log Management: With Beanstalk, accessing logs is a tedious process. If you’re inside Beanstalk and want to see the logs for that specific service you need to request logs, to download an archive and then navigate through a maze of log groups and files. ECS streamlines this experience.
• Configuration Updates: Updating configurations on Beanstalk, especially across multiple instances, felt crappy. There were times when the service will get stuck, leaving us in a broken state. ECS offers a more consistent and faster configuration update process.
• GitHub Integration: Beanstalk lacks an official GitHub Action for deployment, forcing users to rely on community-built packages. In contrast, ECS boasts an official GitHub Action.
• CI/CD Limitations with Beanstalk: Our attempts to establish a comprehensive CI/CD pipeline with Beanstalk were fraught with challenges. We couldn’t modify environment variables during deployment or execute database migrations. ECS, on the other hand, is more supportive of CI/CD integrations.
• Auto-Scaling: While it might be possible to fine-tune auto-scaling with Beanstalk, the process isn’t straightforward. ECS shines in this aspect, offering a more dependable and efficient auto-scaling solution.

Conclusion

I did my job with it so far and I what I can say is that:

I think Beanstalk served its purpose — to be a starting point.

While both platforms have their merits, ECS’s advanced features, integration capabilities, and overall reliability made it the clear winner in my eyes. For those facing a similar choice, I recommend giving ECS a closer look.

In the next article I’ll present a very fast and straightforward way to start with ECS while migrating from something very basic, like Beanstalk.