Provisioning Resources with Elastic Beanstalk and Cloud Formation
- Published on
- Reading time
- 3 min read
Overview
Besides the management console and SDK/CDKs, provisioning AWS resources can be done using two services, Elastic Beanstalk and Cloud Formation. The main difference in these two is their granularity of control over resources, but often they are used together.
Elastic Beanstalk
Elastic Beanstalk is a free AWS service designed to reduce the complexity of deploying web applications by automatically provisioning all of the resources required. It takes care of load balancing, health monitoring, and auto scaling.
Deploying a web app with Elastic Beanstalk
Upload the application's code as an application version
Select the platform to create an environment (Node, Python, etc...)
Elastic Beanstalk automatically provisions resources for the application based on any config files in the codebase
Example: Deploying a Next.js application
Upload the application to Elastic Beanstalk as a zipped folder
Set the platform to Node and configure the environment
Elastic Beanstalk deploys by looking through the uploaded code for several config files including
package.json
to build the appBy default, the app is deployed into an EC2 instance, but this can be changed to a container by including a
Dockerrun.aws.json
config file
The previous example begs the question: When is Elastic Beanstalk better for deploying applications than Amplify? Although, I guess this question could be rewritten as: When should I use serverless or server-based. Elastic Beanstalk (server-based) is recommended over Amplify (serverless) if more granular control is needed than what's possible in a serverless environment. This might be the case for complex backends needing customized security groups or teh ability to leverage a specialized instance type, like a compute instance for batch processing. If rapid deployment is more important or much of the app is static, Amplify would be better.
Cloud Formation
Cloud Formation works by writing JSON or YAML templates that dictate what and how to create resources such as EC2 instances or RDS databases. In the management console, one would click through screens and select all of these settings manually, but by writing out a template for resources that need to be created often, that time demand can be automated away.
One use case might be to deploy the same stack template across different environments like development and production or different regions.
Steps to create and manage a CloudFormation stack
Create a template with a text editor or a visual tool like AWS Application Composer or CloudFormation Designer that defines all necessary resources and their settings
Recommended to store template in an S3 bucket, but they can be stored locally for the local development environment
Use this template (by providing the S3's file URL) to create a CloudFormation Stack which is the collection of resources
Optionally, an entire stack can be deleted to delete all of the resources that were created
Template Example
This example provides CloudFormation with a blueprint to create an S3 bucket for hosting a static website. It specifies the index.html and error.html for the website. Additionally, the creation and/or upload of the websites files could be automated as well when paired with a Lambda function. The function would be created beforehand and then referenced as a handler in the template. The trigger would be CloudFormation's stack creation event.
{
"Resources": {
"BucketName": {
"Type": "AWS::S3:Bucket",
"Properties": {
"AccessControl": "PublicRead",
"WebsiteConfiguration": {
"IndexDocument": "index.html",
"ErrorDocument": "error.html"
}
}
}
}
}