AWS Elastic Beanstalk makes it even easier for developers to quickly deploy and manage applications in the AWS Cloud. Developers simply upload their application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.
Those who want to deploy and manage their applications within minutes in the AWS Cloud. You don’t need experience with cloud computing to get started. AWS Elastic Beanstalk supports Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker web applications.
AWS Elastic Beanstalk automates the details of capacity provisioning, load balancing, auto scaling, and application deployment, creating an environment that runs a version of your application. You can simply upload your deployable code (e.g., WAR file), and AWS Elastic Beanstalk does the rest. The AWS Toolkit for Visual Studio and the AWS Toolkit for Eclipse allow you to deploy your application to AWS Elastic Beanstalk and manage it without leaving your IDE. Once your application is running, Elastic Beanstalk automates management tasks–such as monitoring, application version deployment, a basic health check–and facilitates log file access. By using Elastic Beanstalk, developers can focus on developing their application and are freed from deployment-oriented tasks, such as provisioning servers, setting up load balancing, or managing scaling.
Most existing application containers or platform-as-a-service solutions, while reducing the amount of programming required, significantly diminish developers’ flexibility and control. Developers are forced to live with all the decisions predetermined by the vendor–with little to no opportunity to take back control over various parts of their application’s infrastructure. However, with AWS Elastic Beanstalk, developers retain full control over the AWS resources powering their application. If developers decide they want to manage some (or all) of the elements of their infrastructure, they can do so seamlessly by using Elastic Beanstalk’s management capabilities.
With AWS Elastic Beanstalk, you can:
- Select the operating system that matches your application requirements (e.g., Amazon Linux or Windows Server 2016)
- Choose from several Amazon EC2 instances including On-Demand, Reserved instances, and Spot instances
- Choose from several available database and storage options
- Enable login access to Amazon EC2 instances for immediate and direct troubleshooting
- Quickly improve application reliability by running in more than one Availability Zone
- Enhance application security by enabling HTTPS protocol on the load balancer
- Access built-in Amazon CloudWatch monitoring and getting notifications on application health and other important events
- Adjust application server settings (e.g., JVM settings) and pass environment variables
- Run other application components, such as a memory caching service, side-by-side in Amazon EC2
- Access log files without logging in to the application servers
There is no additional charge for AWS Elastic Beanstalk–you pay only for the AWS resources actually used to store and run your application.
Components
- Application
- An Elastic Beanstalk application is a logical collection of Elastic Beanstalk components, including environments, versions, and environment configurations.
- Application Version
- An application version refers to a 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
- 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
- An environment configuration 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
- Configuration Template
- A configuration template is a starting point for creating unique environment configurations
Architecture
Elastic Beanstalk environment requires an environment tier, platform, and environment type
Environment tier determines whether Elastic Beanstalk provisions resources to support a web application that handles HTTP(S) requests or a web application that handles background-processing tasks
Web Environment Tier
- An environment tier whose web application processes web requests is known as a web server tier.
- AWS resources created for a web environment 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
- AWS resources created for a worker environment tier include an Auto Scaling group, one or more Amazon EC2 instances, and an IAM role.
- For the worker environment tier, Elastic Beanstalk also creates and provisions an SQS queue, if one doesn’t exist
- When a worker environment tier is launched, 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.
Deployment
- Elastic Beanstalk supports environments as
- Single Instance environments, with a single instance and auto scaling to maintain the minimum/maximum 1 instance
- Load Balanced environments, with load balancing and auto scaling
- Elastic Beanstalk allows multiple deployment options or strategies that can be selected depending upon the requirements for deployment time, downtime, DNS change and rollback process
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)
- All at Once deployments performs an in place deployment on all instances at the same time
- All at Once deployments are simple and fast, however rollback would take time in case of any issues
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.
- Elastic Beanstalk 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.
- When all instances in the batch pass enough health checks to be considered healthy by ELB, the batch is complete.
- 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.
Rolling with Additional Batch Deployments
- Rolling with Additional Batch deployments are 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
- 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
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.
Blue Green Deployments
- 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
- 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
- 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.
with other AWS Services
- Elastic Beanstalk supports VPC and launches AWS resources, such as instances, into the VPC
- Elastic Beanstalk 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
- Elastic Beanstalk is integrated with CloudTrail, a service that captures all of the Elastic BeanstalkAPI calls and delivers the log files to an S3 bucket that you specify.
- CloudTrail 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
- Elastic Beanstalk provides support 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.
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
