Provisioning Resources with Elastic Beanstalk and Cloud Formation

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

1. Upload the application's code as an application version

2. Select the platform to create an environment (Node, Python, etc...)

3. Elastic Beanstalk automatically provisions resources for the application based on any config files in the codebase

Example: Deploying a Next.js application

1. Upload the application to Elastic Beanstalk as a zipped folder

2. Set the platform to Node and configure the environment

3. Elastic Beanstalk deploys by looking through the uploaded code for several config files including package.json to build the app

4. By 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

1. 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

2. Recommended to store template in an S3 bucket, but they can be stored locally for the local development environment

3. Use this template (by providing the S3's file URL) to create a CloudFormation Stack which is the collection of resources

4. 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"
        }
      }
    }
  }
}