Elastic Beanstalk simplifies the deployment and management of web applications by handling infrastructure provisioning and configuration automatically.
Elastic Beanstalk allows you to deploy your web applications and web services to AWS. It is an orchestration service that provisions resources and automatically handles the deployment. It monitors application health via a health dashboard. (source_page: 1)
Elastic Beanstalk is a Platform-as-a-Service (PaaS) offering that makes it easy to deploy and scale web applications and services. (source_page: 7)
It is effectively an IT department in a can, allowing users to drag and drop their web app and let Elastic Beanstalk build out the infrastructure, deploy the application, and set up auto-scaling. (source_page: 5)
EB makes it easy to quickly deploy applications on AWS without having to worry about infrastructure by following these steps: 1. Create the app, 2. Deploy the App, 3. EB provisions capacity, sets up load balancing and auto-scaling, and configures monitoring, 4. You manage the environment and deploy new apps. (source_page: 1)
Elastic Beanstalk supports various programming languages and containerized applications, including .Net, GlassFish, Go, Java, Node.js, PHP, and Python. It also supports Docker containers for running any language or configuration. (source_page: 5, 7)
You want to spend minimal time learning/configuring infrastructure. It's suitable for quick prototyping and testing, and shorter application lifecycles. It allows you to maintain some flexibility over the resources powering your apps. It is great for simpler applications. (source_page: 1, 5)
Elastic Beanstalk is not suitable if you need complete control over resource configurations. Existing applications can be difficult to fit into the Beanstalk model, and it can get complicated if you have a lot of dependencies. It is not suitable for more complex applications or for serverless architectures because it handles traditional architecture like EC2 instances, VPCs, Auto Scaling, and Load Balancers. (source_page: 1, 5)
OpsWorks provides more control over infrastructure design and management than Elastic Beanstalk. OpsWorks can provide more customization than Elastic Beanstalk and is better for longer application lifecycles (EB for shorter app lifecycle). (source_page: 3)
Elastic Beanstalk is not typically used for containerized applications, as there are other AWS services, such as ECS and EKS, that are better suited for that purpose. (source_page: 5)
CloudFormation provides more granular control for complex architectures, while Elastic Beanstalk is a good option for simple situations. (source_page: 5)
Elastic Beanstalk organizes applications into several key components to manage deployments and environments.
The collection of components such as environments, versions, and configurations. (source_page: 1)
Part of an App. Apps can have multiple versions. You can deploy multiple versions to test them. (source_page: 1)
A version that is deployed with AWS resources. (source_page: 1)
Settings and parameters that define the environment and resources. (source_page: 1)
Used to create repeatable environment configurations. (source_page: 1)
Elastic Beanstalk provides different environment types optimized for various application needs, from single-instance development to highly available production deployments.
This environment type includes Auto Scaling, which handles launching, configuring, and terminating instances. An Elastic Load Balancer (ELB) handles client requests and communicates with back-end instances. (source_page: 1)
This corresponds to a 'Load-Balanced' instance type, used for production and complex workloads, providing Autoscaling groups, a load balancer, and a public URL. (source_page: 7)
This environment type uses one instance with an Elastic IP Address. The Auto Scaling Group keeps one instance running, but there is no Load Balancer. (source_page: 1)
This is categorized as a 'Single-Instance' type, which uses one instance with an EIP and is primarily for development only. (source_page: 7)
Hosts web applications. Provides a CNAME URL, managed load balancer, and Autoscaling group. It can manage an RDS database instance, though this is not a best practice. (source_page: 7)
An Autoscaling group hosting an application that reads messages from an SQS queue. It scales based on queue depth. (source_page: 7)
Elastic Beanstalk supports various deployment methods to update applications with different trade-offs regarding speed, downtime, and rollback capabilities.
Updates all existing instances at the same time. On deployment failure, you redeploy a working version. (source_page: 1)
Technical Specs: Pros: Fastest Method, requires no DNS changes
Cons: Can cause downtime
Updates one batch of instances at a time. On deployment failure, you redeploy with another Rolling Deployment. (source_page: 1)
Technical Specs: Pros: Prevents downtime, control over number of instances update, uses health checks, requires no DNS changes
Cons: If deployment fails halfway through, instances serve different versions of the app; can cause capacity issues
Updates one batch of instances at a time, starting with a new instance not in rotation. On deployment failure, you redeploy with another rolling with additional batch deployment. (source_page: 1)
Technical Specs: Pros: Same as rolling deployment and prevents capacity issues
Cons: Can take longer than the rolling deployment
Replaces existing instances with new instances by creating a temporary Auto Scaling Group (ASG), testing one instance with the new app, then adding the new instances to the original ASG while terminating the original instances and the temporary ASG. On deployment failure, you terminate the temporary ASG and redeploy. (source_page: 1)
Technical Specs: Pros: Prevents downtime, uses new resources instead of in-place updates, simple and clean rollback
Cons: Doubles the number of instances for a short period
Replaces all resources, including the ELB, ASG, and instances. On deployment failure, you swap URLs. (source_page: 1)
For Blue/Green deployments, URL swapping is a key concept. (source_page: 7)
Technical Specs: Pros: Prevents downtime, uses new resources instead of in-place updates, can test updates in an isolated environment
Cons: Requires a DNS name change and doubles the number of instances while deployments are running instance
Elastic Beanstalk environments can be configured using various methods to provide the necessary resources and settings for your application.
Environments can be configured via: Configuration Files (in .ebextensions), Saved Configurations, CloudFormation Configurations, or Direct Changes. (source_page: 1)
You can configure deployment options, software dependencies, CloudWatch Metrics and Alarms, Autoscaling and other service configurations, and the creation of other resources (like SQS, SNS, RDS). (source_page: 1)
Configuration files contain sections like `option_settings`, `Resources`, and other sections. (source_page: 1)
Defines values for configuration settings. Can configure the EB environment, AWS resources in our environment, and software on instances. (source_page: 1)
Allows you to define and customize resources in your environment. (source_page: 1)
Configurations can be saved and stored as objects in S3. They can be used to save settings applied to an existing environment during or after environment configuration. (source_page: 1)
Docker can be used with Elastic Beanstalk to maintain consistency, abstract applications, and ensure reliable execution across environments.
Docker can be used with Elastic Beanstalk to maintain consistency across multiple uses, abstract the application from underlying virtualized hardware, and answer the question: 'Do I have all I need to run my application reliably?'. (source_page: 1)
Used to deploy a Docker image and source code inside a single container per instance. The single container environment can have both a Dockerfile (describing the image to build) and a Dockerrun.aws.json file (specifying the image and EB configurations). (source_page: 1)
Used to deploy multiple containers per instance. It uses Amazon ECS to deploy a cluster in the EB environment. For example, PHP in one container and Nginx in another. This deployment requires a Dockerrun.aws.json file and does not support custom images with Dockerfiles; instead, images need to be hosted in public or private repositories. (source_page: 1)
In addition to the Dockerrun file, configuration files can be placed in the .ebextensions directory. An example for creating an ELB with a listener for port 8080 and mapping it to a container port from the host instance in the Dockerrun file. (source_page: 1)
Technical Specs: ELB Listener Configuration in .ebextensions:
```json
option_settings:
aws:elb:listener:8080:Container
ListenerProtocol: HTTP
InstanceProtocol: HTTP
InstancePort: 8080
```
Port Mapping in Dockerrun.aws.json:
```json
"portMappings": [
{"hostPort": 8080,
"ContainerPort": 8080
}
[
```
Elastic Beanstalk is not typically used for containerized applications, as there are other AWS services, such as ECS and EKS, that are better suited for that purpose. (source_page: 5)
Elastic Beanstalk provides options for integrating with Amazon RDS, with best practices depending on the environment type.
Elastic Beanstalk provides support for running RDS instances in your Elastic Beanstalk environment. This is great for dev and test environments. (source_page: 1)
Running RDS within the EB environment is not ideal for a production environment because it ties the lifecycle of the DB to the lifecycle of the application. To decouple your database instance from your environment, you can run a database instance in Amazon RDS separately and configure your application to connect to it on launch. This enables you to connect multiple environments to a database, terminate an environment without affecting the database, and perform seamless updates with blue-green deployments. (source_page: 1)
Elastic Beanstalk is recommended for projects seeking a managed platform with minimal infrastructure configuration, balancing simplicity, speed, and cost for small to medium scale applications.
For the SAA-C03 Study System migration, Architecture 3 (PaaS Simple with Elastic Beanstalk) is the recommended approach for its low complexity and fast deployment. (source_page: 6)
Philosophy
Managed platform with zero infrastructure configuration. (source_page: 6)
AWS Services Used
AWS Elastic Beanstalk (Python 3.12 platform) manages EC2 instances, ALB, Auto Scaling, and Security Groups. It uses t3.micro instances (1-2 instances), Amazon RDS PostgreSQL (db.t4g.micro), and Amazon S3 for storage (managed by Beanstalk). Authentication uses Flask-Login + RDS users table, and CI/CD is via GitHub Actions → EB CLI deploy. (source_page: 6)
Cost
An estimated cost of $33-45/month for 50 users. This includes EC2 ($7.49 for t3.micro x 1), ALB ($16.78), RDS ($15.72), and CloudWatch ($0.80), totaling $40.79/month. Can be optimized to $33-37/month using Spot instances and RDS Savings Plans. (source_page: 6)
EC2 (t3.micro x 1):
$7.49/month
ALB:
$16.78/month
RDS (db.t4g.micro):
$15.72/month
CloudWatch:
$0.80/month
Optimized total (Spot instances + RDS Savings Plans):
$33-37/month
Pros
Fastest deployment (live in 1-2 days), zero infrastructure management, minimal code changes (~350 LOC), cheapest managed option, perfect for beginners, GUI-based monitoring and deployment, one-click rollback, no Docker knowledge required. (source_page: 6)
Cons
Less control than ECS, AWS-specific (but app is portable), and EC2 instances run 24/7. (source_page: 6)
When to Choose
Ideal for limited DevOps experience, wanting the fastest MVP (1-2 days), a budget of $35-50/month, small teams (1-2 developers), and proof-of-concept phases. (source_page: 6)
Scaling Path
For 50 → 500 users: $70-80/month (2-4 instances, db.t4g.small). For 500 → 5,000 users: $300-400/month (4-10 instances, RDS + caching). For 5,000+ users: Consider migration to serverless or ECS. (source_page: 6)
This section outlines the steps for setting up an Elastic Beanstalk application and environment using the EB CLI and AWS Console, as part of a Python application migration.
Detailed steps for preparing application code, installing the EB CLI, configuring .ebextensions, initializing the EB application, creating an environment, and deploying. (source_page: 6)
Prerequisites
- Create a service role for Elastic Beanstalk (IAM Console: Roles -> Create role -> Elastic Beanstalk - Customizable, role name e.g., 'CustomServiceRoleForElasticBeanstalk'). (source_page: 5)
- Create an EC2 instance profile for Elastic Beanstalk (IAM Console: Roles -> Create role -> EC2 -> Select 'AWSElasticBeanstalkReadOnly' policy, role name e.g., 'CustomEC2InstanceProfileForElasticBeanstalk'). (source_page: 5)
- An RDS PostgreSQL database configured with endpoint URL and credentials (e.g., db.t4g.micro, 20GB gp3 SSD, private access, new security group 'rds-postgres-sg', initial DB 'saa_quiz_db'). (source_page: 6)
- An S3 bucket for static assets (e.g., 'saa-quiz-app-static') with content uploaded. (source_page: 6)
- Secrets stored in AWS Secrets Manager (e.g., 'saa-quiz-app/rds-credentials', 'saa-quiz-app/flask-secret-key'). (source_page: 6)
1
Install EB CLI
💡 The EB CLI is essential for interacting with Elastic Beanstalk environments from the command line.
pip install awsebcli
eb --version # Verify installation
2
Create .ebextensions Configuration
💡 These YAML configuration files define environment properties, static file mappings, and custom commands to run on instances.
File: .ebextensions/01_python.config
```yaml
option_settings:
aws:elasticbeanstalk:application:environment:
PYTHONPATH:"/var/app/current:$PYTHONPATH"
FLASK_APP:"web.application:application"
aws:elasticbeanstalk:container:python:
WSGIPath:"web.application:application"
aws:elasticbeanstalk:environment:proxy:staticfiles:
/static: web/static
commands:
01_migrate:
command:"source /var/app/venv/*/bin/activate && python web/init_db.py"
leader_only:true
```
File: .ebextensions/02_environment.config
```yaml
option_settings:
aws:elasticbeanstalk:application:environment:
DATABASE_URL:'`{"Ref": "AWSEBSecretArn"}`'
SECRET_KEY:'`{"Ref": "AWSEBSecretArn2"}`'
```
3
Create .ebignore File
💡 This file specifies which local files and directories should be excluded from the application source bundle uploaded to Elastic Beanstalk, optimizing deployment size and preventing unwanted files from being deployed.
File: .ebignore
```plain text
.git/
.venv/
venv/
__pycache__/
*.pyc
.pytest_cache/
.coverage
.env
.DS_Store
data/progress/
data/extracted/
docs/
tools/notion_integration/
*.db
```
4
Initialize Elastic Beanstalk Application
💡 This command sets up the local directory for EB CLI interaction and configures default settings like platform, load balancer, VPC, and SSH access.
cd /home/zufirewinubu/Developer/Portfolio/SAA-C03StudySystem
eb init -p python-3.12 saa-quiz-app --region us-east-1
# Configure default settings (select as prompted):
# Select: Create new Application Load Balancer
# Select: Default VPC
# SSH: Yes (optional, for debugging)
5
Create Beanstalk Environment
💡 This command provisions the AWS resources for the Elastic Beanstalk environment, including EC2 instances, load balancer, and Auto Scaling group.
eb create saa-quiz-production \
--instance-type t3.micro \
--envvars DATABASE_URL=postgresql://postgres:PASSWORD@YOUR_RDS_ENDPOINT:5432/saa_quiz_db,SECRET_KEY=YOUR_SECRET_KEY \
--single \
--region us-east-1
6
Configure Environment Variables (Alternative to CLI)
💡 Environment variables are used to pass configuration settings, such as database credentials and application secret keys, to the running application.
Via AWS Console:
1. Navigate to Elastic Beanstalk → Environments → saa-quiz-production
2. Configuration → Software → Edit
3. Environment properties:
- DATABASE_URL: postgresql://postgres:PASSWORD@YOUR_RDS_ENDPOINT:5432/saa_quiz_db
- SECRET_KEY: (paste generated secret key)
4. Save → Apply changes (triggers rolling update)
7
Configure RDS Security Group
💡 Ensures that the RDS database only accepts connections from the Elastic Beanstalk instances, maintaining security.
1. Navigate to EC2 → Security Groups → rds-postgres-sg
2. Inbound rules → Edit
3. Add rule:
- Type: PostgreSQL (5432)
- Source: Beanstalk instance security group (find in EB environment config)
4. Save
8
Initialize Database
💡 Runs the database initialization script (`init_db.py`) on the deployed instance to create necessary tables.
eb ssh
source /var/app/venv/*/bin/activate
cd /var/app/current
python web/init_db.py
exit
9
Test Deployment
💡 Verifies that the application is running correctly and accessible.
eb open
eb logs
eb health
Setting up a Continuous Integration/Continuous Deployment (CI/CD) pipeline for Elastic Beanstalk ensures automated and consistent application deployments from source control.
Configuring GitHub Actions to automatically deploy code changes to an Elastic Beanstalk environment. (source_page: 6)
Prerequisites
- An initialized Elastic Beanstalk application and environment.
- GitHub repository for application code.
1
Create GitHub Actions Workflow
💡 This YAML file defines the automated workflow that triggers on code pushes to the `main` branch, checks out code, installs dependencies, runs tests, installs the EB CLI, configures AWS credentials, and deploys to Elastic Beanstalk.
File: .github/workflows/deploy-beanstalk.yml
```yaml
name: Deploy to Elastic Beanstalk
on:
push:
branches:
- main
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version:'3.12'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Run tests
run: |
pip install pytest pytest-cov
pytest --cov=web --cov-report=xml || true
- name: Install EB CLI
run: |
pip install awsebcli
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v2
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- name: Deploy to Elastic Beanstalk
run: |
eb deploy saa-quiz-production --staged
env:
AWS_DEFAULT_REGION: us-east-1
- name: Verify deployment
run: |
eb health saa-quiz-production
```
2
Configure GitHub Secrets and IAM User
💡 Securely provides AWS credentials to the GitHub Actions workflow without hardcoding them in the repository. The IAM user requires `AWSElasticBeanstalkFullAccess` and `AmazonS3FullAccess` policies for deployment operations.
In GitHub Repository:
1. Navigate to Settings → Secrets and variables → Actions
2. Add repository secrets:
- AWS_ACCESS_KEY_ID: Your IAM access key
- AWS_SECRET_ACCESS_KEY: Your IAM secret key
Create IAM User for GitHub Actions:
1. AWS Console → IAM → Users → Create user
2. User name: github-actions-saa-quiz
3. Attach policies directly:
- AWSElasticBeanstalkFullAccess
- AmazonS3FullAccess (for application versions)
4. Create access key → Application running outside AWS
5. Copy access key ID and secret access key to GitHub secrets
Configuring Auto Scaling policies in Elastic Beanstalk ensures your application can automatically adjust its capacity to handle varying loads.
Steps to set up Auto Scaling triggers based on CPU utilization to scale instances in and out. (source_page: 6)
Prerequisites
- An active Elastic Beanstalk environment.
1
Configure Scaling Policies
💡 Auto Scaling policies allow the environment to automatically add or remove instances to match demand, optimizing performance and cost.
Via Beanstalk Console:
1. Configuration → Capacity → Edit
2. Auto Scaling group:
- Environment type: Load balanced
- Min instances: 1
- Max instances: 4
3. Scaling triggers:
- Metric: CPUUtilization
- Statistic: Average
- Unit: Percent
- Period: 5 minutes
- Breach duration: 5 minutes
- Upper threshold: 70 (scale out)
- Lower threshold: 20 (scale in)
- Scale up increment: 1
- Scale down increment: -1
Optimizing costs for Elastic Beanstalk involves leveraging AWS pricing models for compute and database resources.
An example monthly cost breakdown for 50 users on an Elastic Beanstalk environment (t3.micro instance, ALB, RDS db.t4g.micro, CloudWatch). (source_page: 6)
Technical Specs: EC2 (t3.micro x 1): $7.49
ALB: $16.78
RDS: $15.72
CloudWatch: $0.80
Total: $40.79/month
Two primary optimizations can reduce the monthly cost: using EC2 Spot Instances and RDS Savings Plans. (source_page: 6)
Configuring Elastic Beanstalk to use EC2 Spot Instances can save 70% on EC2 costs. This can be enabled in the Beanstalk console under 'Configuration → Capacity → Edit → Enable Spot'. (source_page: 6)
Technical Specs: New EC2 cost: $2.25/month
New total (with other costs): $37-40/month
Utilizing RDS Savings Plans offers a 40% discount with a 1-year commitment. (source_page: 6)
Technical Specs: New RDS cost: $9.43/month
New total (with other costs): $36-39/month
Combining both EC2 Spot Instances and RDS Savings Plans can bring the optimized total monthly cost to $33-37. (source_page: 6)
Technical Specs: Optimized total: $33-37/month
Addressing potential risks during an Elastic Beanstalk migration is crucial for ensuring a smooth and reliable deployment.
Deployment failures are a potential risk. This can be mitigated by always deploying to a staging environment first, implementing comprehensive health checks, and configuring auto-rollback features. (source_page: 6)