[AWS] Elastic Beanstalk

EB is a PaaS (Platform as a Service) to quickly deploy and manage applications in AWS without worrying about the underlying infrastructure.

---

Features

AWS Elastic Beanstalk is used deploy and scale applications and services.

You can simply upload your code, and AWS Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, and auto scaling to application health monitoring.

• Supports many programming languages.
  • Java, .NET, PHP, Node.js, Python, Ruby, and Go
• Supports many platforms
  • Apache, Tomcat, Nginx, Passenger, and Internet Information Services (IIS)
• Supports Docker images
• Fits best to provision an environment with little admin overhead but not good for low-level infrastructure control.
• Can host multiple different versions in separate URLs.
  • Basic Monitoring with CloudWatch and CloudTrail
• Monitors application health via a health dashboard.
• Can only be used to deploy application to the AWS cloud. It is not used to deploy application on-premise environment.

---

Key Architecture Components

Application

• An application is a logical collection of Elastic Beanstalk Components such as environments, versions, and environment configurations.
• You can think of the application as a container or a package.

Application version

• An application version refers to a distinct iteration of an application that’s packaged into a bundle. It points to an S3 object that contains the deployable code.

Environment

• An environment is a collection of AWS resources running a specific application version.
• Each environment runs only one application version at a time.

---

Deployment Types

Deploying applications to Elastic Beanstalk environments – AWS Elastic Beanstalk (amazon.com)

All at once

• Deploys the new version to all instances simultaneously.
  • Quick and simple, not recommended for production
  • Good for the first deployment
• Roll back: Need to redeploy the old version to all instances

Rolling

• Splits instances into batches and deploys one batch at a time to the existing instances
  • No service outage but your service capacity will be reduced by the batch size.
  • Not good for performance-sensitive applications
• Roll back: Need to do another rolling update to the old version

Rolling with additional batch

• Deploys the new version in batches, but the first batch is deployed to the newly created instances.
• Once the first batch is successfully deployed in a new environment, all existing instances will be deployed in batch.
• It ensures full capacity during the deployment process.
• Roll back: You need to another rolling update.

Immutable

• Immutable environment updates are an alternative to rolling updates.
  • You do not modify or update the existing environment.
  • You need to create a new environment for a new version.
• Deploy the new version to a new single instance. Once succeeded, a new fleet of instances is created and deployed. And then, old instances are terminated.
• Rollback: Just delete the new environments.

Traffic splitting

• Deploys the new version to new instances just like immutable deployment
• And then temporarily split traffic between the new version and the old version. (Canary testing)

<Note> Some policies – Deployments with immutable updates or traffic splitting – replace all instances during the deployment or update. This causes all accumulated Amazon EC2 burst balances to be lost.

Deployment Type	Deploy time	Zero downtime	DNS Change	Failed Deployment	Rollback	Deploy to
All at once	Quick	No	No	Downtime	Manual	Existing instances
Rolling	Medium	Yes	No	Single batch out of service, Mix of old/new version	Manual	Existing instances
Rolling with an additional batch	Medium+	Yes	No	Minimal if the first batch fails, otherwise similar to Rolling	Manual	New and Existing instances
Immutable	Long	Yes	No	Minimal	Terminate new instances	New instances
Traffic Splitting	Long	Yes	No	Percentage of traffic to new version	Reroute traffic and terminate new instances	New instances
Blue/Green	Long	Yes	Yes	Minimal	Swap URL	New instances

---

Using Elastic Beanstalk with Amazon RDS

Option 1: Launch RDS within the Elastic Beanstalk environment

• Launch RDS inside the Elastic Beanstalk
• When you terminate the environment, the RDS is also terminated
• It is OK for dev and test environment, but not good for the production environment.

Option 2: To allow your EC2 instances in the EB environment to connect to an outside database:

1. Configure an additional security group allowing access to the database
2. Add the security group to the Auto Scaling group that’s associated with your environment
3. Pass the connection information, such as the endpoint and password, to your application by using environment properties

---

Configuration Options

During environment creation, configuration options are applied from multiple sources with the following precedence, from highest to lowest:

1. Settings applied directly to the environment
2. Saved Configurations
3. Configuration Files (.ebextensions folder in the top-level directory of your application source code bundle)
   • Amazon Linux 1 platforms only
4. Default Values

For Amazon Linux 2 platforms:

• Use Buildfire, Procfile, or platform hooks
• Run custom code during instance provisioning