AWS CloudFormation vs AWS Elastic Beanstalk: What are the differences?
AWS CloudFormation: Create and manage a collection of related AWS resources. You can use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You don’t need to figure out the order in which AWS services need to be provisioned or the subtleties of how to make those dependencies work; AWS Elastic Beanstalk: Quickly deploy and manage applications in the AWS cloud. Once you upload your application, Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.
AWS CloudFormation belongs to "Infrastructure Build Tools" category of the tech stack, while AWS Elastic Beanstalk can be primarily classified under "Platform as a Service".
Some of the features offered by AWS CloudFormation are:
- AWS CloudFormation comes with the following ready-to-run sample templates: WordPress (blog),Tracks (project tracking), Gollum (wiki used by GitHub), Drupal (content management), Joomla (content management), Insoshi (social apps), Redmine (project mgmt)
- No Need to Reinvent the Wheel – A template can be used repeatedly to create identical copies of the same stack (or to use as a foundation to start a new stack)
- Transparent and Open – Templates are simple JSON formatted text files that can be placed under your normal source control mechanisms, stored in private or public locations such as Amazon S3 and exchanged via email.
On the other hand, AWS Elastic Beanstalk provides the following key features:
- Elastic Beanstalk is built using familiar software stacks such as the Apache HTTP Server for Node.js, PHP and Python, Passenger for Ruby, IIS 7.5 for .NET, and Apache Tomcat for Java
- There is no additional charge for Elastic Beanstalk - you pay only for the AWS resources needed to store and run your applications.
- Easy to begin – Elastic Beanstalk is a quick and simple way to deploy your application to AWS. You simply use the AWS Management Console, Git deployment, or an integrated development environment (IDE) such as Eclipse or Visual Studio to upload your application
"Automates infrastructure deployments" is the primary reason why developers consider AWS CloudFormation over the competitors, whereas "Integrates with other aws services" was stated as the key factor in picking AWS Elastic Beanstalk.
Sellsuki, Close, and Edify are some of the popular companies that use AWS Elastic Beanstalk, whereas AWS CloudFormation is used by Expedia.com, Redox Engine, and TimeHop. AWS Elastic Beanstalk has a broader approval, being mentioned in 374 company stacks & 118 developers stacks; compared to AWS CloudFormation, which is listed in 197 company stacks and 77 developer stacks.
What is AWS CloudFormation?
What is AWS Elastic Beanstalk?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
When creating the web infrastructure for our start-up, I wanted to host our app on a PaaS to get started quickly.
A very popular one for Rails is Heroku, which I love for free hobby side projects, but never used professionally. On the other hand, I was very familiar with the AWS ecosystem, and since I was going to use some of its services anyways, I thought: why not go all in on it?
It turns out that Amazon offers a PaaS called AWS Elastic Beanstalk, which is basically like an “AWS Heroku”. It even comes with a similar command-line utility, called "eb”. While edge-case Rails problems are not as well documented as with Heroku, it was very satisfying to manage all our cloud services under the same AWS account. There are auto-scaling options for web and worker instances, which is a nice touch. Overall, it was reliable, and I would recommend it to anyone planning on heavily using AWS.
We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.
We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.
In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.
Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache
We use Terraform because we needed a way to automate the process of building and deploying feature branches. We wanted to hide the complexity such that when a dev creates a PR, it triggers a build and deployment without the dev having to worry about any of the 'plumbing' going on behind the scenes. Terraform allows us to automate the process of provisioning DNS records, Amazon S3 buckets, Amazon EC2 instances and AWS Elastic Load Balancing (ELB)'s. It also makes it easy to tear it all down when finished. We also like that it supports multiple clouds, which is why we chose to use it over AWS CloudFormation.
I use Terraform because it hits the level of abstraction pocket of being high-level and flexible, and is agnostic to cloud platforms. Creating complex infrastructure components for a solution with a UI console is tedious to repeat. Using low-level APIs are usually specific to cloud platforms, and you still have to build your own tooling for deploying, state management, and destroying infrastructure.
However, Terraform is usually slower to implement new services compared to cloud-specific APIs. It's worth the trade-off though, especially if you're multi-cloud. I heard someone say, "We want to preference a cloud, not lock in to one." Terraform builds on that claim.
Terraform Google Cloud Deployment Manager AWS CloudFormation
I use Gunicorn because does one thing - it’s a WSGI HTTP server - and it does it well. Deploy it quickly and easily, and let the rest of your stack do what the rest of your stack does well, wherever that may be.
uWSGI “aims at developing a full stack for building hosting services” - if that’s a thing you need then ok, but I like the principle of doing one thing well, and I deploy to platforms like Heroku and AWS Elastic Beanstalk where the rest of the “hosting service” is provided and managed for me.
Manually clicking around the AWS UI or scripting AWS CLI calls can be both a slow and brittle process.
We needed to be able to reconstruct CloudRepo's infrastructure in case of disaster or moving to another AWS Region.
Setting up our infrastructure with CloudFormation allows us to update it easily as well as duplicate or recreate things when the need arises.
Opstax uses CloudFormation for anything infrastructure related! CloudFormation allows us to use infrastructure-as-code as a constant blueprint/map of our environment. It means we can accurately and efficiently deploy replicated or new infrastructure with no time wasted clicking around and no human error.
Elastic Beanstalk gives us a managed platform for our front end servers to make sure that traffic is never overloading our servers and that deployments are always successful.
Manage infrastructure as codes. Native AWS solution so it has better support to AWS resources than Terraform, also can leverage AWS Business Support.
Elastic Beanstalk manages our environments. We rely on it to manage rolling out new versions of services.
Easy to get started. Essentially a package of several AWS products integrated for you.
For convenience I use Elastic Beanstalk to host all my sites.
All server-side deployments go to one of 5 EB environments.