Elastic Beanstalk

AWS Elastic Beanstalk

AWS Elastic Beanstalk can be used to quickly deploy and manage applications in the AWS Cloud.

Developers upload applications and Elastic Beanstalk handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.

AWS Elastic Beanstalk leverages Elastic Load Balancing and Auto Scaling to automatically scale your application in and out based on your application’s specific needs.

In addition, multiple availability zones give you an option to improve application reliability and availability by running in more than one zone.

Considered a Platform as a Service (PaaS) solution.

Supports Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker web applications.

Supports the following languages and development stacks:

  • Apache Tomcat for Java applications.
  • Apache HTTP Server for PHP applications.
  • Apache HTTP Server for Python applications.
  • Nginx or Apache HTTP Server for Node.js applications.
  • Passenger or Puma for Ruby applications.
  • Microsoft IIS 7.5, 8.0, and 8.5 for .NET applications.
  • Java SE.
  • Docker.
  • Go.

Deploys to server platforms such as Apache Tomcat, Nginx, Passenger, Puma, and IIS.

Developers can focus on writing code and don’t need to worry about deploying infrastructure.

You maintain full control of the underlying resources.

You pay only for the resources provisioned, not for Elastic Beanstalk itself.

Elastic Beanstalk automatically scales your application up and down.

You can select the EC2 instance type that is optimal for your application.

Can retain full administrative control or have Elastic Beanstalk do it for you.

The Managed Platform Updates feature automatically applies updates for your operating system, Java, PHP, Node.js etc.

Elastic Beanstalk monitors and manages application health and information is viewable via a dashboard.

AWS CloudFormation is used by Elastic Beanstalk to deploy the resources.

Integrated with CloudWatch and X-Ray for performance data and metrics.

Elastic Beanstalk Layers

There are several layers that make up Elastic Beanstalk and each layer is described below:

Application:

  • Within Elastic Beanstalk, an application is a collection of different elements, such as environments, environment configurations, and application versions.
  • You can have multiple application versions held within an application.

Application version:

  • An application version is a very specific reference to a section of deployable code.
  • The application version will point typically to an Amazon s3 bucket containing the code.

Environment:

  • An environment refers to an application version that has been deployed on AWS resources.
  • The resources are configured and provisioned by AWS Elastic Beanstalk.
  • The environment is comprised of all the resources created by Elastic Beanstalk and not just an EC2 instance with your uploaded code.

Elastic Beanstalk Applications Environments and Versions

Environment tier:

  • Determines how Elastic Beanstalk provisions resources based on what the application is designed to do.
  • Web servers are standard applications that listen for and then process HTTP requests, typically over port 80.
  • Workers are specialized applications that have a background processing task that listens for messages on an Amazon SQS queue.

Environment configurations:

  • An environment configuration is a collection of parameters and settings that dictate how an environment will have its resources provisioned by Elastic Beanstalk and how these resources will behave.

Configuration template:

  • This is a template that provides the baseline for creating a new, unique environment configuration.

Click the image above to watch the FREE Video Tutorial on Elastic Beanstalk Deployment Options

Deployment Options

AWS Elastic Beanstalk provides several options for how deployments are processed, including deployment policies and options that let you configure batch size and health check behavior during deployments.

Deployment options

Single instance: great for development.

High availability with load balancer: great for production.

Deployment policies

The deployment policies are: All at once, Rolling, Rolling with additional batch, and Immutable.

All at once:

  • Deploys the new version to all instances simultaneously.
  • All of your instances are out of service while the deployment takes place.
  • Fastest deployment.
  • Good for quick iterations in the development environment.
  • You will experience an outage while the deployment is taking place – not ideal for mission-critical systems.
  • If the update fails, you need to roll back the changes by re-deploying the original version to all of your instances.
  • No additional cost.

Rolling:

  • Update a few instances at a time (batch), and then move onto the next batch once the first batch is healthy (downtime for 1 batch at a time).
  • The application is running both versions simultaneously.
  • Each batch of instances is taken out of service while the deployment takes place.
  • Your environment capacity will be reduced by the number of instances in a batch while the deployment takes place.
  • Not ideal for performance-sensitive systems.
  • If the update fails, you need to perform an additional rolling update to roll back the changes.
  • No additional cost.
  • Long deployment time.

Rolling with additional batch:

  • Like Rolling but launches new instances in a batch ensuring that there is full availability.
  • The application is running at capacity.
  • You can set the bucket size.
  • The application is running both versions simultaneously.
  • Small additional cost.
  • Additional batch is removed at the end of the deployment.
  • Longer deployment.
  • Good for production environments.

Immutable:

  • Launches new instances in a new ASG and deploys the version update to these instances before swapping traffic to these instances once healthy.
  • Zero downtime.
  • New code is deployed to new instances using an ASG.
  • High cost as double the number of instances running during updates.
  • Longest deployment.
  • Quick rollback in case of failures.
  • Great for production environments.

Additionally, Elastic Beanstalk supports blue/green deployment.

Blue / Green deployment:

  • This is not a feature within Elastic Beanstalk
  • You create a new “staging” environment and deploy updates there.
  • The new environment (green) can be validated independently and you can roll back if there are issues.
  • Route 53 can be set up using weighted policies to redirect a percentage of traffic to the staging environment.
  • Using Elastic Beanstalk, you can “swap URLs” when done with the environment test.
  • Zero downtime.

The following tables summarizes the different deployment policies:

Elastic Beanstalk Deployment Policies

Elastic Beanstalk CLI

There is an additional CLI called “eb cli”.

The EB CLI is a command-line interface for AWS Elastic Beanstalk that provides interactive commands that simplify creating, updating and monitoring environments from a local repository.

You can use the EB CLI as part of your everyday development and testing cycle as an alternative to the Elastic Beanstalk console.

Security

Elastic Beanstalk works with HTTPS:

  • Load the SSL certificate onto the load balancer.
  • Can be performed from the console or in code (.ebextensions/securelistener-alb.config).
  • SSL certificate can be provisioned using ACM or CLI.

For redirecting HTTP to HTTPS:

  • Configure in the application.
  • Configure the ALB with a rule.
  • Ensure health checks are not redirected.

Lifecycle Policies

Elastic Beanstalk can store at most 1000 application versions.

To phase out old versions use a lifecycle policy:

  • Time-based – specify max age.
  • Count based – specify max number to retain.

Versions that are in use will not be deleted.

Option to not delete the source bundle in S3 to prevent data loss.

Worker environments

If an application performs tasks that take a long time to complete (long-running tasks), offload to a worker environment.

It allows you to decouple your application tiers.

Can define periodic tasks in the cron.yaml file.

Elastic Beanstalk Worker Environment

Elastic Beanstalk Extensions

You can add AWS Elastic Beanstalk configuration files (.ebextensions) to your web application’s source code to configure your environment and customize the AWS resources that it contains.

Customization includes defining packages to install, create Linux users and groups, running shell commands, specifying services to enable, configuring a load balancer, etc.

Configuration files are YAML- or JSON-formatted documents with a .config file extension that you place in a folder named .ebextensions and deploy in your application source bundle.

The .ebextensions folder must be included in the top-level directory of your application source code bundle.

All the parameters set in the UI can be configured in the code.

Requirements:

  • Must be located in the .ebextensions/ directory of the source code.
  • YAML or JSON format.
  • .config extensions can be included (e.g. logging.config).
  • You can modify some default settings using “option_settings”.
  • You can add resources such as RDS, ElastiCache, and DynamoDB.

Resources managed by .ebextensions get deleted if the environment is terminated.

Elastic Beanstalk with Amazon Relational Database Service (RDS)

You can deploy Amazon RDS within an Elastic Beanstalk environment as in the diagram below:

Elastic Beanstalk Environment with RDS

However, if you terminate your Elastic Beanstalk environment you also lose the database.

The use case is only for development environments, typically not suitable for production.

For production, it is preferable to create the Amazon RDS database outside of Elastic Beanstalk as in the diagram below:

Elastic Beanstalk and Amazon RDS

Steps to migrate from RDS within a Beanstalk environment to standalone RDS:

  • Take a snapshot of the RDS DB.
  • Enable deletion protection on the RDS DB.
  • Create a new environment without an RDS DB and point applications to the existing RDS DB.
  • Perform a blue/green deployment and swap the new and old environments.
  • Terminate the old environment (RDS will not be deleted due to termination protection).
  • Delete the CloudFormation stack (will be in the DELETE_FAILED state).

Connecting to an Amazon RDS database

When the environment update is complete, the DB instance’s hostname and other connection information are available to your application through the following environment properties:

  • RDS_HOSTNAME – The hostname of the DB instance.
  • RDS_PORT – The port on which the DB instance accepts connections. The default value varies among DB engines.
  • RDS_DB_NAME – The database name, ebdb.
  • RDS_USERNAME – The user name that you configured for your database.
  • RDS_PASSWORD – The password that you configured for your database.

 

Scroll to Top