AWS Elastic Beanstalk

Deploying applications in AWS safely and predictably

Developer problems on AWS

• Managing infrastructure
• Deploying Code
• Configuring all the databases, load balancers, etc
• Scaling concerns
• Most web apps have the same architecture (ALB + ASG)

Elastic Beanstalk is a developer-centric view of deploying an application on AWS. Beanstalk is free but you pay for the underlying instances.

Elastic Beanstalk — Components

• Application: a collection of Elastic Beanstalk components ( environments, versions, configurations…)
• Application Version: an iteration of your application code
• Environment:
  Collection of AWS resources running an application version (only one application version at a time);
  Tiers: Web Server Environment Tier & Worker Environment Tier;
  You can create multiple environments (dev, test, prod…)

Beanstalk Deployment Options for Updates

• All at once (deploy all in one go): fastest, but instances have downtime, great for quick iterations in dev environment, no additional cost
• Rolling: update a few instances at a time (bucket), and then move onto next bucket once the first bucket is healthy
• Rolling with additional batches: like Rolling, but spins up new instances to move the batch ( so that the old application is still available)
• Immutable: spins up new instances in a new ASG, deploys version to these instances, and then swaps all the instances when everything is healthy, Quick rollback in case of failures, great for prod
• Blue/Green: Not a “direct feature” of Beanstalk, zero downtime and release facility, create a new stage environment and deploy v2 there, the new environment (green) can be validated independently and roll back if issues, Route 53 can be setup using weighted policies to redirect a little bit of traffic to the staging environment, using Beanstalk “swap URLs” when down with the environment test

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html

Elastic Beanstalk — Traffic Splitting

• Canary Testing
• New application version is deployed to a temporary ASG with the same capacity
• A small % of traffic is sent to the temporary ASG for a configurable amount of time
• Deployment health is monitored
• If there is a deployment failure, this triggers an automated rollback (very quick)
• No application downtime
• New instances are migrated from the temporary to the original ASG
• Old application version is then terminated

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html
All accumulated Amazon EC2 burst balances to be lost happens in the following cases:
1 Managed platform updates with instance replacement enabled
2 Immutable updates
3 Deployments with immutable updates or traffic splitting enabled

Elastic Beanstalk CLI

• We can install an additional CLI called the “EB cli” which makes working with Beanstalk from the CLI easier. It’s helpful for your automated deployment pipelines.

eb create
eb status
eb health
eb events
eb logs
eb open
eb deploy
eb config
eb terminate

Elastic Beanstalk Deployment Process

• Describe dependencies (requirements.txt for Python, package.json for NodeJS)
• Package code as zip, and describe dependencies
• Console: upload zip file ( create new app version) and then deploy
• CLI: create new app version using CLI (uploads zip) and then deploy
• Elastic Beanstalk will deploy the zip on each EC2 instance, resolve dependencies and start the application

Beanstalk Lifecycle Policy

• Elastic Beanstalk can store at most 1000 application versions
• If you don’t remove old versions, you won’t be able to deploy anymore
• To phase out old applications, use a life policy
  Based on time (old versions are removed)
  Based on space ( when you have too many spaces)
• Versions that are currently used won’t be deleted
• Option not to delete the source bundle in S3 to prevent data loss

Beanstalk Extensions

• A zip file containing our code must be deployed to Elastic Beanstalk
• All the parameters set in the UI can be configured with code using files
• Requirements:
  in the .ebextensions/ directory in the root of source code
  YAML/JSON format
  .config extensions
  able to modify some default settings, using: option_settings
  ability to add resources such as RDS, ElastiCache, DynamoDB, etc…
• Resources managed by .ebextensions get deleted if the environment goes away

Beanstalk Under the Hood

• Under the hood, Beanstalk relies on CloudFormation. CloudFormation is used to provision other AWS services

• Use case: you can define CloudFormation resources in your .ebextensions to provision ElastiCache, an S3 bucket, anything you want.

Beanstalk Cloning

• clone an environment with the exact same configuration
• Useful for deploying a test version of your application
• All resources and configuration are preserved:
  Load Balancer type and configuration
  RDS database type (but the data is not preserved)
  Environment variables
• After cloning an environment, you can change settings

Beanstalk Migration: Load Balancer

To migrate:

• 1 create a new environment with the same configuration except LB (can’t clone)
• 2 deploy your configuration onto the new environment
• 3 perform a CNAME swap or Route 53 update

After creating an Elastic Beanstalk environment, you cannot change the Elastic Load Balancer type (only the configuration)

RDS with Beanstalk

• RDS can be provisioned with Beanstalk, which is great for dev/test
• This is not great for prod as the database lifecycle is tied to the Beanstalk environment lifecycle
• The best for prod is to separately create an RDS database and provide our EB application with the connection string

Beanstalk — Multi Docker Container