AWS Elastic Beanstalk

The Core Concepts of Elastic Beanstalk

Elastic Beanstalk organizes your application using a simple, logical hierarchy.

1. Application

An Elastic Beanstalk Application is a high-level logical container for your project. It's like a folder that groups together all the different versions of your code and the environments where they run.

2. Application Version

An Application Version refers to a specific, labeled iteration of your deployable code. When you upload your code (e.g., a ZIP or WAR file), Elastic Beanstalk creates a new version. This allows you to deploy specific versions to your environments and easily roll back to a previous, stable version if needed.

3. Environment

An Environment is the core of Elastic Beanstalk. It refers to the running instance of your application—the collection of AWS resources provisioned to execute a specific Application Version. You can have multiple environments for a single application, such as dev, staging, and prod. Each environment runs only one application version at a time, but you can update it to run a different version.

Environment Tiers: Web Server vs. Worker

Elastic Beanstalk offers two distinct types of environments, known as tiers, to support different application architectures.

Web Server Environment

• Purpose: This is the standard tier, designed for applications that handle synchronous, user-facing HTTP requests.
• Architecture: It typically consists of an Elastic Load Balancer to distribute traffic to an Auto Scaling group of EC2 instances running your application.
• Use Case: Ideal for websites, REST APIs, and any other request-response style application.

Worker Environment

• Purpose: This tier is designed for applications that perform asynchronous, background processing tasks.
• Architecture: It pulls messages from an Amazon Simple Queue Service (SQS) queue. A daemon process on the EC2 instances in the environment processes these messages. The environment does not have a public-facing load balancer.
• Use Case: Perfect for long-running tasks that shouldn't block the main application thread, such as sending emails, generating reports, or transcoding media files. The Web Server tier can offload these tasks by placing a message in the SQS queue.

Application Deployment Strategies

Elastic Beanstalk provides several deployment policies to update your application, each with different trade-offs in terms of speed, safety, cost, and downtime.

• All at Once: The fastest method. It deploys the new version to all existing instances simultaneously.
  • Pros: Fastest deployment time. No additional cost.
  • Cons: Causes downtime during the deployment. If the deployment fails, you must roll back, which causes further downtime.
• Rolling: Deploys the new version in batches. A subset of instances is taken out of service, updated, and then placed back into service.
  • Pros: Maintains reduced capacity, avoiding downtime. No additional cost.
  • Cons: Deployment takes longer. If a batch fails, the rollback process can be lengthy.
• Rolling with Additional Batch: Similar to a rolling update, but it first launches a new batch of instances to ensure full capacity is maintained during the deployment.
  • Pros: No downtime and no capacity reduction during the update.
  • Cons: Incurs the cost of running an extra batch of instances during the deployment period.
• Immutable: Deploys the new version to a completely new set of instances in a separate, temporary Auto Scaling group. Once the new instances are healthy, traffic is switched to them, and the old instances are terminated.
  • Pros: No downtime. Instant rollback is possible by simply terminating the new instances. Guarantees a clean, consistent deployment.
  • Cons: Highest cost, as it doubles the number of instances for a period. Longest deployment time.
• Blue/Green: A manual, infrastructure-level deployment strategy. You create a completely separate, new "Green" environment and deploy the new version there. Once you have tested it, you can swap the CNAME records of the "Blue" (old) and "Green" (new) environments, redirecting all traffic to the new version.
  • Pros: Safest method. Zero downtime. Instant rollback by swapping the CNAME back.
  • Cons: Highest cost, as it requires running a duplicate, parallel environment.

Customizing Environments with .ebextensions

While Elastic Beanstalk provides a managed platform, it doesn't lock you in. You can customize the underlying AWS resources by including a folder named .ebextensions in your application's source code bundle.

• How it Works: The .ebextensions directory contains configuration files (written in YAML or JSON) that allow you to define and configure the AWS resources in your environment.
• Common Use Cases:
  • Installing packages on the EC2 instances (e.g., yum install ...).
  • Creating and modifying security group rules.
  • Setting environment variables for your application.
  • Running custom scripts during deployment.

Pricing and Supported Platforms

• Pricing: There is no additional charge for Elastic Beanstalk itself. You only pay for the underlying AWS resources that it provisions to run your application (e.g., EC2 instances, S3 buckets, Elastic Load Balancers).
• Supported Platforms: Elastic Beanstalk has built-in support for a wide variety of popular programming languages and application servers, including:
  • Go
  • Java (SE, Tomcat)
  • .NET (on Windows Server)
  • Node.js
  • PHP
  • Python
  • Ruby
  • Docker (for single and multi-container applications)