AWS Elastic Beanstalk helps to quickly deploy and manage applications in the AWS Cloud without having to worry about the infrastructure that runs those applications.

Elastic Beanstalk reduces management complexity without restricting choice or control.

We can upload code, and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, Auto-Scaling, to application health monitoring. Meanwhile, we can retain full control over the AWS resources used in the application and access the underlying resources at any time. 

Elastic Beanstalk enables automated infrastructure management and code deployment, by simply uploading, for applications and includes:

• Application platform management

• Capacity provisioning

• Load Balancing

• Auto scaling

• Code deployment

• Health Monitoring

Once an application is uploaded, Elastic Beanstalk automatically launches an environment, creates and configures the AWS resources needed to run the code. After your environment is launched, it can be managed and used to deploy new application versions,

Provides you with a unique domain name for your application environment (e.g., yourapp.elasticbeanstalk.com) 

AWS resources launched by Elastic Beanstalk are fully accessible i.e. EC2 instances can be sshed into.

CloudFormation, using templates, is a better option if the internal AWS resources to be used are known and fine grained control is needed.

We can create the deployment in one instance or using one ELB.

NGINX can be hosted on an EC2 instance through a series of clear steps- Launch an EC2 instance through the console. Connect to the instance over SSH and use the command yum install -y Nginx to install Nginx. Also, make sure that it is configured to restart automatically after a reboot.

With Elastic Beanstalk, you can provide a Dockerfile (container), and Elastic Beanstalk takes care of scaling your provisioning of the number and size of nodes.

Three architecture models:

Supported Plaforms

• Go

• Java

• Python

• Node.js

• Ruby

• PHP

• Application servers (Tomcat, Passenger, Puma) 

• Single Container Docker

• Multi Container Docker

• Preconfigure Docker

• Write your own custom platforms (If the any of the above is not supported)

Deployment Modes

When you create an AWS Elastic Beanstalk environment, you can specify an AMI to use instead of the standard Elastic Beanstalk AMI included in your platform version. 

• A custom AMI can improve provisioning times when instances are launched in your environment if you need to install a lot of software that isn't included in the standard AMIs. 

You can modify the launch configuration or the Environment Manifest to change the instance type, key pair, Amazon EBS storage, and other settings that can only be configured when you launch an instance. 

c

c

Application

1. • An Elastic Beanstalk application is a logical collection of Elastic Beanstalk components, including environments, versions, and environment configurations.

Application Version

1. • Specific, labeled iteration of deployable code for a web application.

   • Applications can have many versions and each application version is unique and points to an S3 object.

   • Multiple versions can be deployed for an Application for testing differences and helps rollback to any version if case of issues.

Environment

1. • An environment is a version that is deployed onto AWS resources.

   • An environment runs a single application version at a time, but same application version can be deployed across multiple environments.

   • When an environment is created, Elastic Beanstalk provisions the resources needed to run the application version you specified.

Environment Configuration

1. • Identifies a collection of parameters and settings that define how an environment and its associated resources behave.

   • When an environment’s configuration settings is updated, Elastic Beanstalk automatically applies the changes to existing resources or deletes and deploys new resources, depending upon the change.

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

     • Settings applied directly to the environment – Settings specified during a create environment or update environment operation on the Elastic Beanstalk API by any client, including the AWS Management Console, EB CLI, AWS CLI, and SDKs. 

     • Saved Configurations – Settings for any options that are not applied directly to the environment are loaded from a saved configuration, if specified.

     • Configuration Files (.ebextensions) – Settings for any options that are not applied directly to the environment and not specified in a saved configuration are loaded from configuration files in the .ebextensions folder at the root of the application source bundle.

     • Configuration files are executed in alphabetical order. For example, .ebextensions/01run.config is executed before .ebextensions/02do.config.

     • Default Values – If a configuration option has a default value, it only applies when the option is not set at any of the above levels.

Configuration Template

• Starting point for creating unique environment configurations.

Lifecycle Policy

• Each time you upload a new version of your application with the Elastic Beanstalk console or the EB CLI, Elastic Beanstalk creates an application version.

•  If you don't delete versions that you no longer use, you will eventually reach the application version quota and be unable to create new versions of that application. 

• A lifecycle policy tells Elastic Beanstalk to delete application versions that are old, or to delete application versions when the total number of versions for an application exceeds a specified number. 

Elastic Beanstalk Extensions: AWS Elastic Beanstalk supports a large number of configuration options that let you modify the settings that are applied to resources in your environment. 

• Several of these options have default values that can be overridden to customize your environment. Other options can be configured to enable additional features.

• 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:

• Elastic Beanstalk supports two methods of saving configuration option settings. 

  • Configuration files in YAML or JSON format can be included in your application's source code in a directory named .ebextensions and deployed as part of your application source bundle. 

• Resources managed by .ebextensions get deleted if the environment goes away

• 
  

Requires an environment tier platform, and environment type.

Environment tier determines whether we can to support a web application that handles HTTP(S) requests or a web application that handles background-processing tasks.

Web Environment Tier

•  Web application processes web requests is known as a web server tier.

• Include a Elastic Load Balancer, an Auto Scaling group, one or more EC2 instances.

• Every Environment has a CNAME url pointing to the ELB, aliased in Route 53 to ELB url.

• Each EC2 server instance that runs the application uses a container type, which defines the infrastructure topology and software stack.

• A software component called the host manager (HM) runs on each EC2 server instance and is responsible for

  • Deploying the application

  • Aggregating events and metrics for retrieval via the console, the API, or the command line.

  • Generating instance-level events.

  • Monitoring the application log files for critical errors.

  • Monitoring the application server.

  • Patching instance components.

  • Rotating your application’s log files and publishing them to S3.

Worker Environment Tier 

• An environment tier whose web application runs background jobs is known as a worker tier

• In "long-running process" an Elastic Beanstalk Worker environment is preferred over the Elastic Beanstalk Web environment. 

• Include an Auto Scaling group, one or more Amazon EC2 instances, and an IAM role.

  • Also creates and provisions an SQS queue, if one doesn’t exist.

  • Elastic Beanstalk installs the necessary support files for the programming language of choice and a daemon on each EC2 instance in the Auto Scaling group reading from the same SQS queue.

  • Daemon is responsible for pulling requests from an SQS queue and then sending the data to the web application running in the worker environment tier that will process those messages.

  • Elastic Beanstalk worker environments support SQS dead letter queues which can be used to store messages that could not be successfully processed. Dead letter queue provides the ability to sideline, isolate and analyze the unsuccessfully processed messages.

One environment cannot support two different environment tiers because each requires its own set of resources; a worker environment tier and a web server environment tier each require an Auto Scaling group, but Elastic Beanstalk supports only one Auto Scaling group per environment.

Supports VPC and launches AWS resources, such as instances, into the VPC.

Supports IAM and helps you securely control access to your AWS resources.

CloudFront can be used to distribute the content in S3, after an Elastic Beanstalk is created and deployed.

CloudTrail:

• Use CloudTrail, to capture all of the Elastic BeanstalkAPI calls and delivers the log files to an S3 bucket that you specify.

• Captures API calls from the Elastic Beanstalk console or from your code to the Elastic Beanstalk APIs and help to determine the request made to Elastic Beanstalk, the source IP address from which the request was made, who made the request, when it was made etc.

RDS:

• For running RDS instances in the Elastic Beanstalk environment which is ideal for development and testing but not for production.

• For a production environment, it is not recommended because it ties the lifecycle of the database instance to the lifecycle of application’s environment. So it the Elastic beanstalk environment is deleted, the RDS instance is deleted as well.

• It is recommended to launch a database instance outside of the environment and configure the application to connect to it outside of the functionality provided by Elastic Beanstalk.

• Using a database instance external to your environment requires additional security group and connection string configuration, but it also lets the application connect to the database from multiple environments. Use database types not supported with integrated databases, perform blue/green deployments, and tear down your environment without affecting the database instance.

• Lifecycle

  • The following deletion policies apply to a database after you decouple it from an Elastic Beanstalk environment or terminate the Elastic Beanstalk environment. 

  • Snapshot — Before Elastic Beanstalk terminates the database, it saves a snapshot of it. You can restore a database from a snapshot when you add a DB instance to an Elastic Beanstalk environment or when you create a standalone database. 

  • Delete — Elastic Beanstalk terminates the database. After it's terminated, the database instance is no longer available for any operation. 

  • Retain — The database instance isn't terminated. It remains available and operational, though decoupled from Elastic Beanstalk. You can then configure one or multiple environments to connect to the database as an external Amazon RDS database instance. 

S3

• Elastic Beanstalk creates an S3 bucket named elasticbeanstalk-region-account-id for each region in which environments is created.

• Elastic Beanstalk uses the bucket to store application versions, logs, and other supporting files.

• It applies a bucket policy to buckets it creates to allow environments to write to the bucket and prevent accidental deletion.

Describe dependencies

• (requirements.txt for python, package.json for node.js)

Package code as zip

Zip file is uploaded to each EC2 machine

Each EC2 machine resolves dependencies (SLOW)

Optimization in case of long deployments:

• Package dependencies with source code to improve deployment performance and speed

All at Once Deployments

• Elastic Beanstalk environment uses all-at-once deployments if it is created with a different client (API, SDK, or AWS CLI),

• Performs an in place deployment on all instances at the same time.

• Simple and fast, however rollback would take time in case of any issues.

• Fastest, but instances aren't available to serve traffic for awhile (longer downtime)

• No additional cost

Rolling Deployments

• Elastic Beanstalk environment uses rolling deployments if it is created with console or EB CLI.

• Elastic Beanstalk splits the environment’s EC2 instances into batches and deploys the new version of the application to one batch at a time, leaving the rest of the instances in the environment running the old version.

• During a rolling deployment, part of the instances serve requests with the old version of the application, while instances in completed batches serve other requests with the new version.

• You can set the bucket size 

• Application will run below capacity during update 

• At some point, the application will run both versions simultaneousl 

• Can be a very long deployment time depending on number of instances running 

• No additional cost 

• Performs the rolling deployments as:

  • When processing a batch, detaches all instances in the batch from the load balancer, deploys the new application version, and then reattaches the instances.

  • To avoid any connection issues when the instances are detached, connection draining can be enabled on the load balancer.

  • After reattaching the instances in a batch to the load balancer, ELB waits until they pass a minimum number of health checks (the Healthy check count threshold value), and then starts routing traffic to them.

  • Elastic Beanstalk waits until all instances in a batch are healthy before moving on to the next batch.

  • If a batch of instances does not become healthy within the command timeout, the deployment fails.

  • If a deployment fails after one or more batches completed successfully, the completed batches run the new version of the application while any pending batches continue to run the old version.

  • If the instances are terminated from the failed deployment, Elastic Beanstalk replaces them with instances running the application version from the most recent successful deployment.

• Example:

  • option_settings:

  •   aws:elasticbeanstalk:command:

  •     DeploymentPolicy: Rolling

  •     BatchSizeType: Percentage

  •     BatchSize: 25

Rolling with Additional Batch Deployments

• Helpful when you need to maintain full capacity during deployments.

• This deployment is similar to Rolling deployments, except they do not do an in place deployment but a disposable one, launching a new batch of instances prior to taking any instances out of service.

• Application is running at capacity 

• When the deployment completes, Elastic Beanstalk terminates the additional batch of instances.

• Rolling with additional batch deployment does not impact the capacity and ensures full capacity during the deployment process.

• Example:

  • option_settings:

  •   aws:elasticbeanstalk:command:

  •     DeploymentPolicy: RollingWithAdditionalBatch

  •     BatchSizeType: Fixed

  •     BatchSize: 5

Immutable Deployments

• All at Once and Rolling deployment method updates existing instances.

• If you need to ensure the application source is always deployed to new instances, instead of updating existing instances, environment can be configured to use immutable updates for deployments.

• Immutable updates are performed by launching a second Auto Scaling group is launched in the environment and the new version serves traffic alongside the old version until the new instances pass health checks.

• Immutable deployments can prevent issues caused by partially completed rolling deployments. If the new instances don’t pass health checks, Elastic Beanstalk terminates them, leaving the original instances untouched.

• High cost, double capacity 

• Longest deployment

• Quick rollback in case of failures

• Best for production environments 

• Example:

  • option_settings:

  •   aws:elasticbeanstalk:command:

  •     DeploymentPolicy: Immutable

  •     HealthCheckSuccessThreshold: Warning

  •     IgnoreHealthCheck: true

  •     Timeout: "900"

Traffic splitting

• A canary testing deployment method. 

• Suitable if you want to test the health of your new application version using a portion of incoming traffic, while keeping the rest of the traffic served by the old application version. 

• The percentage of traffic to be diverted to the new version is specified in ‘NewVersionPercent’ while evaluation time is specified in the ‘EvaluationTime’ parameter in minutes. 

• Template will be as follows:

  • option_settings:

  •   aws:elasticbeanstalk:command:

  •     DeploymentPolicy: TrafficSplitting

  •   aws:elasticbeanstalk:trafficsplitting:

  •     NewVersionPercent: "15"

  •     EvaluationTime: "10"

Blue Green Deployments

• This is not a direct feature of Elastic Beanstalk 

• Elastic Beanstalk performs an in-place update when application versions is updated, that may result in application becoming unavailable to users for a short period of time .

• To do this, deploy the new version to a separate environment, and then SWAP the CNAMEs of the two environments to redirect traffic to the new version instantly. 

• Blue Green approach is suitable for deployments that depend on resource configuration changes or a new version that can’t run alongside the old version.

• Elastic Beanstalk enables the Blue Green deployment through Swap Environment URLs feature.

• Blue Green deployment provides almost zero downtime solution, where a new version is deployed to a separate environment, and then CNAMEs of the two environments are swapped to redirect traffic to the new version.

• Blue/green deployments require that the environment runs independently of the production database i.e. not maintained by Elastic Beanstalk, if your application uses one. Because if the environment has an RDS DB instance attached to it, the data will not transfer over to the second environment, and will be lost if the original environment is terminated.

• Create a new staging environment and deploy your newest version there 

• Route 53 can be setup using weighted policies to redirect a little bit of traffic to the staging environment 

• Blue Green deployment entails a DNS change and hence do not terminate the old environment until the DNS changes have been propagated and the old DNS records expire.

• DNS servers do not necessarily clear old records from their cache based on the time to live (TTL) you set on the DNS records.

• Using the elastic beanstalk console, you can "swap URLs" when with the testing environment 

 .dockerignore

• The .dockerignore file specifies a list of patterns to exclude from the build context during creation of the Docker image. These files are not required by the execution of the container, and should be removed to reduce the size of the final image.

.elasticbeanstalk/

• Elastic Beanstalk uses this directory to store temp files and configuration information about the current AWS account, EB Application name and IAM credentials to utilize.

config.yml file,

• which is a configuration file that is used to define certain parameters for your newly minted Beanstalk application.

.ebextensions 

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

• timeout-commands.config

  • Use the Timeout option in the aws:elasticbeanstalk:command to allow the instances in your environment more time to complete deployments and on-instance configuration changes.

• timeout-waitcondition.config

  • Modify the Timeout setting on the wait condition that Elastic Beanstalk creates to allow instances time to bootstrap during environment creation, including time to install libraries, deploy your application, and perform on-instance confguration. 

  • If your application takes a long time to deploy due to long running scripts in configuration files, use this setting in conjunction with command timeout (timeout-commands.config) to avoid timeouts during environment creation.

• updates-immutable.config

  • Use immutable updates for all deployments and configuration changes that require instance replacement.

• workertier-scaleonqueuesize.config

  • By default, worker environments scale based on network throughput. Use this configuration file to scale based on the number of jobs waiting in the environment's SQS queue instead.

• vpc-custom-loadbalanced.config

  • Use this configuration file to tell Elastic Beanstalk to create your instances and load balancer in a custom VPC that you created, instead of in the default VPC.

• add-ebs-volume.config

  • This configuration file add a new volume to the instance, create filesystem and mount it.

• add-secondary-network-interface.config

  • This configuration file adds a secondary NetworkInterface to the EC2 instance. The SubnetId for the secondary interface has to be in the same Availability Zone as the instance.

• amazon-inspector-install.config

  • This configuration file installs Amazon Inspector Agents on the instance launched under Elastic Beanstalk.

• awslogs-change-frequency.config

  • This configuration file modifies logrotate frequency to 5 minutes and upload to S3.

• change-nginx-max-body-size.config

  • This configuration file client_max_body_size in nginx within a Java environment by adding a hook.

• cron-leaderonly-linux.config

  • Run a cron job on only one Linux instance in the environment.

• cron-linux.config

  • This configuration file shows an example of running a cron job on all linux instances in the environment.

• env-regionname.config

  • Configure Elastic Beanstalk to pass your environment's region to your application with an environment variable.

• files-downloadfromS3.config

  • Use the files key to download a file from a bucket in Amazon S3 to the instances in your environment, providing the instance profile role to use for authorization. Use this mechanism to securely provide your application with secrets that you can't include in your source code, such as private keys and database passwords.

• install-newrelic-agent.config

  • This configuration file install the infrastructure agent on the instance launched under Elastic Beanstalk.

• install-nodejs.config

  • This configuration file installs nodejs to a non-NodeJs solution stack.

• java-increase-file-descriptors.config

  • Increase file descriptors for Java Tomcat environment.

• logs-streamtocloudwatch-linux.config

  • Configure Cloudwatch log agent to stream logs to Cloudwatch

• logs-uploadonterminate-linux.config

  • Publish logs to S3 on termination of a linux instance.

• network-mtu-jumboframe.config

  • This configuration file Changes MTU for Jumbo-Frame enabled instances e.g->C3.large

• nodejs-increase-file-descriptors.config

  • Increase available file descriptors to Node.js.

• package-oracle-jdk.config

  • Install Oracle JDK and set as default

• proxy-configure-nodejs.configs

  • Use the option_settings key to modify Node.js Platform Options 

  • ProxyServer to select which web server should be used to proxy connections to Node.js. 

  • Supported values for ProxyServer can be either nginx, apache or none

• storage-efs-createfilesystem.config

  • Use the Resources key to create a new file system in Amazon Elastic File System (Amazon EFS). 

  • All of the instances in your environment can connect to the same EFS file system for shared, scalable storage. 

  • Use storage-efs-mountfilesystem.config to mount the file system on each instance. 

• storage-efs-mountfilesystem.config

  • Mount an Amazon EFS file system to a local path on the instances in your environment. 

• storage-imagevolume-docker.config

  • Configure the volume used by the instances in your Docker environment.

• t2unlimited-instance.config

  • This configuration file will allow T2 Unlimited with Elastic Beanstalk for Linux based Environments. 

• timezone-linux.config

  • Configure the timezone on each instance.

• alb-http-to-https-redirection.config

  • This configuration file usage resources to configure HTTP to HTTPS auto redirection at application load balancer (ALB) layer. 

• autoscaling-cloudwatch-group-metrics.config

  • Configures your environment's Auto Scaling Group to send group metrics to Amazon CloudWatch at 1-minute intervals.

• autoscaling-memory-utlization.config

  • This configuration file will create custom cloudwatch metrics along with alarms to monitor memory usage of EC2 instances and Trigger auto-scale events based on cloud watch alarms. 

• autoscaling-terminate-newest-instance.config

  • Terminate newest instance in autoscaling group at the time of scale down event

• autoscaling-triggers-createnew.config

  • Add scaling triggers to your environment's AutoScaling group, in addition to those provisioned by Elastic Beanstalk.

• autoscaling-triggers-customize.config

  • Modify the scaling triggers that Elastic Beanstalk creates for your environment's Auto Scaling group.

• autoscaling-triggers-disabledefault.config

  • Disable the scaling triggers that Elastic Beanstalk creates for your environment's Auto Scaling group.

• loadbalancer-accesslogs-existingbucket.config

  • Configure the load balancer in your environment to upload access logs to an existing bucket that you have configured to allow ELB write access.

• loadbalancer-accesslogs-newbucket.config

  • Create a new bucket and configure the load balancer to write access logs to it.

• sns-topic.config

  • Create an SNS topic for notifications, or to use in your application.

• https-instancecert

  • Install a certificate and private key stored in Amazon S3, and configure the proxy server that runs in front of your application to terminate HTTPS connections. 

• https-redirect

  • Configure the proxy server that runs in front of your application to redirect HTTP requests on port 80 to the same path on HTTPS/443.

• proxy-ratelimit-linux

  • Configure Apache or Nginx to rate limit the amount of unique inbound connections per instance in that environment.

• https-singleinstance-securitygroup.config

  • Modify your instance's security group to allow HTTPS traffic on port 443. 

• loadbalancer-alb-securelistener.config

  • The example uses options in the aws:elbv2:listener namespace to configure an HTTPS listener on port 443 with the specified certificate.

• loadbalancer-nlb-securelistener.config

  • The example uses options in the aws:elbv2:listener namespace to configure a listener on port 443. The listener routes traffic to the default process. 

• rds-ssl-java.config

  • Install SSL certificates for RDS database connections with JDBC.

• redshift-ssl-java.config

  • Install SSL certificates for Redshift database connections with JDBC.

• securitygroup-addexisting.config

  • Configure the Auto Scaling Group to launch EC2 instances with an existing Security Group. 

  • This is an additional Security Group to the one automatically created by Elastic Beanstalk for the EC2 instances.

• securitygroup-loadbalanced-configureexisting.config

  • Configure the Security Groups for the ELB and the EC2 instances apart of the Auto Scaling Group. This is useful If you'd like to make changes to the default Security Groups created by Elastic Beanstalk.

• ssh-sourcerestriction.config

  • Use the SSHSourceRestriction option in the aws:autoscaling:launchconfiguration namespace to restrict SSH traffic to connections from instances in a security group that you control. 

• 
  

Dockerrun.aws.json V1: To deploy a single docker container to the amazon beanstalk environment.

Dockerrun.aws.json V2: To deploy Amazon EC2 instances running Multicontainer Docker in an Elastic Beanstalk environment.

cron.yaml: If you want to deploy a worker application that processes periodic background tasks, your application source bundle must also include a cron.yaml file. 

env.yaml: You can include a YAML formatted environment manifest in the root of your application source bundle to configure the environment name, solution stack and environment links to use when creating your environment. 

• Example:

  • AWSConfigurationTemplateVersion: 1.1.0.0

  • SolutionStack: 64bit Amazon Linux 2015.09 v2.0.6 running Multi-container Docker 1.7.1 (Generic)

  • OptionSettings:

  •   aws:elasticbeanstalk:command:

  •     BatchSize: '30'

  •     BatchSizeType: Percentage

  •   aws:elasticbeanstalk:sns:topics:

  •     Notification Endpoint: me@example.com

  •   aws:elb:policies:

  •     ConnectionDrainingEnabled: true

  •     ConnectionDrainingTimeout: '20'

  •   aws:elb:loadbalancer:

  •     CrossZone: true

  •   aws:elasticbeanstalk:environment:

  •     ServiceRole: aws-elasticbeanstalk-service-role

  •   aws:elasticbeanstalk:application:

  •     Application Healthcheck URL: /

  •   aws:elasticbeanstalk:healthreporting:system:

  •     SystemType: enhanced

  •   aws:autoscaling:launchconfiguration:

  •     IamInstanceProfile: aws-elasticbeanstalk-ec2-role

  •     InstanceType: t2.micro

  •     EC2KeyName: workstation-uswest2

  •   aws:autoscaling:updatepolicy:rollingupdate:

  •     RollingUpdateType: Health

  •     RollingUpdateEnabled: true

  • Tags:

  •   Cost Center: WebApp Dev

  • CName: front-A08G28LG+

  • EnvironmentName: front+

  • EnvironmentLinks:

  •   "WORKERQUEUE" : "worker+"

We can install an additional CLI called the “EB cli” which makes working with Beanstalk from the CLI easier

Basic commands are:

• eb create

• eb status

• eb health

• eb events

• eb logs

• eb open

• eb deploy

• eb config

• eb terminate

It’s helpful for your automated deployment pipelines!