Elastic Beanstalk: AWS PaaS for Web Applications

You just pushed a hotfix to production. The deploy script ran, but the load balancer kept routing traffic to the old instances. Users saw errors for 15 minutes before someone noticed. That's the kind of pain Elastic Beanstalk eliminates—if you use it right. It's not a magic bullet; it's a managed environment that handles provisioning, health checks, and rolling updates, but only if you configure it properly. Many teams adopt it to escape the hell of manual EC2 management, only to hit new failure modes: environment drift, misconfigured health checks, or bloated AMIs. The truth is, Elastic Beanstalk is a powerful abstraction, but it demands respect. You still need to understand the underlying services—VPC, security groups, RDS—or you'll trade one set of problems for another. This guide cuts through the marketing fluff and shows you how to deploy a production-ready app without the gotchas.

What Is Elastic Beanstalk and Why Use It?

Elastic Beanstalk is AWS's Platform-as-a-Service (PaaS) offering that abstracts away the underlying infrastructure for web applications. You upload your code, and Beanstalk automatically handles capacity provisioning, load balancing, auto-scaling, and health monitoring. It supports multiple platforms: Node.js, Python, Java, .NET, PHP, Ruby, Go, and Docker. For teams that want to focus on code rather than managing EC2 instances, security groups, or scaling policies, Beanstalk is a solid choice. However, it's not magic — you still need to understand the underlying services to debug production issues. The key trade-off: you trade granular control for operational speed. If you need custom AMIs or exotic networking, Beanstalk may feel restrictive. But for standard web apps, it's a huge time saver.

#!/bin/bash
# Initialize a Beanstalk application
pip install awsebcli --upgrade --user
eb init my-app --platform node.js --region us-east-1
# Create an environment and deploy
eb create my-env --instance-type t3.small --keyname my-key
eb deploy

Setting Up Your First Beanstalk Environment

Start by installing the EB CLI and initializing your project. Run eb init to configure your application name, platform, and region. This creates a .elasticbeanstalk directory with configuration files. Next, create an environment with eb create. You can choose between a load-balanced environment (for production) or a single-instance environment (for dev). The CLI packages your code, uploads it to S3, and provisions resources. Beanstalk creates an Auto Scaling group, an Elastic Load Balancer, and a security group. It also sets up CloudWatch alarms for basic health checks. For a Node.js app, Beanstalk expects a package.json and will run npm start automatically. You can customize the environment with environment properties (e.g., NODE_ENV=production) via the console or CLI. Remember to set up a key pair for SSH access to debug issues.

#!/bin/bash
mkdir my-app && cd my-app
npm init -y
npm install express
cat > app.js << 'EOF'
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;
app.get('/', (req, res) => res.send('Hello from Beanstalk!'));
app.listen(port, () => console.log(`Listening on ${port}`));
EOF
eb init my-app --platform node.js --region us-east-1
eb create my-env --single

Understanding the Beanstalk Architecture

Beanstalk environments consist of several AWS resources working together. At the core is an Auto Scaling group that manages EC2 instances. An Elastic Load Balancer distributes traffic across instances. A security group controls inbound/outbound traffic. Beanstalk also creates an S3 bucket for storing application versions and logs. For databases, you can attach an RDS instance, but it's better to run RDS separately to avoid coupling. The environment has a CNAME that points to the load balancer. Beanstalk monitors instance health via a health check URL (default: /). If an instance fails health checks, it's terminated and replaced. You can customize the health check path and thresholds. The architecture is designed for high availability, but you must ensure your app is stateless — store session data in ElastiCache or DynamoDB, not on the local filesystem.

option_settings:
  aws:autoscaling:asg:
    MinSize: 2
    MaxSize: 4
  aws:elasticbeanstalk:environment:process:default:
    HealthCheckPath: /health
    Port: 3000
  aws:autoscaling:launchconfiguration:
    InstanceType: t3.small
    IamInstanceProfile: aws-elasticbeanstalk-ec2-role

Deploying Application Versions and Rolling Updates

Beanstalk uses application versions — each deploy creates a new version stored in S3. You can deploy with eb deploy or upload a ZIP via the console. For production, use rolling updates to avoid downtime. Beanstalk supports several deployment policies: All at once (fastest, but downtime), Rolling (batches instances), Rolling with additional batch (spins up new instances before terminating old ones), and Immutable (launches a new ASG, swaps CNAME). Immutable is safest for critical apps. You can also use blue/green deployments by creating a separate environment and swapping URLs. To rollback, simply deploy a previous version. Beanstalk keeps the last 100 versions by default. Monitor deployments via the Events tab. If a deployment fails, Beanstalk can automatically roll back (if configured).

#!/bin/bash
# Set deployment preference to immutable
eb deploy --staged --timeout 20
# Or via config:
eb config set aws:elasticbeanstalk:command DeploymentPolicy Immutable

Configuring Environment Properties and Secrets

Environment properties are key-value pairs injected as environment variables into your application. Use them for configuration like database URLs, API keys, and feature flags. Never hardcode secrets in your code. For sensitive values, use AWS Systems Manager Parameter Store or Secrets Manager. Beanstalk can retrieve parameters at startup via a custom script or by using the aws:elasticbeanstalk:application:environment namespace. You can set properties via the EB CLI, console, or .ebextensions. For example, to set DB_URL, run eb setenv DB_URL=postgres://.... Properties are encrypted at rest but visible in the console — use Parameter Store for true secrets. Also, you can use aws:elasticbeanstalk:environment:process:default to set environment-specific settings like health check paths.

#!/bin/bash
# Set environment variables
eb setenv NODE_ENV=production DB_URL=postgres://user:pass@host:5432/mydb
# Or use Parameter Store
eb setenv DB_URL_PARAM=resolve:ssm:/myapp/db_url

Monitoring and Logging with CloudWatch

Beanstalk integrates with CloudWatch for metrics and logs. By default, it publishes basic metrics: CPU utilization, request count, latency, and health status. You can enable detailed CloudWatch metrics for more granularity (at extra cost). For logs, Beanstalk can stream instance logs to CloudWatch Logs. Configure this in the environment's software configuration. You can also tail logs via eb logs. Set up CloudWatch alarms for critical metrics like high CPU or 5xx errors. For advanced monitoring, use X-Ray for tracing requests. Beanstalk also provides a health dashboard showing environment color (Green, Yellow, Red). If the environment turns red, check the Events tab for root cause. Common issues: out of memory, failing health checks, or deployment failures.

#!/bin/bash
# Tail logs from all instances
eb logs --all
# Enable CloudWatch logs via config
eb config set aws:elasticbeanstalk:cloudwatch:logs StreamLogs true
# Create a CloudWatch alarm
aws cloudwatch put-metric-alarm --alarm-name high-cpu --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 80 --comparison-operator GreaterThanThreshold --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:123456789012:my-topic

Scaling Your Application Automatically

Beanstalk's Auto Scaling group can scale based on metrics like CPU, network, or request count. Configure scaling triggers in the environment's capacity settings. For example, add a trigger to scale up when CPU > 70% for 5 minutes, and scale down when CPU < 30% for 10 minutes. Beanstalk also supports scheduled scaling for predictable traffic patterns. For stateless apps, scaling works well. However, if your app has long-running tasks or sticky sessions, scaling can cause issues. Use connection draining on the load balancer to allow in-flight requests to complete before instances are terminated. Also, consider using target tracking scaling policies for simpler configuration. Remember that scaling up takes time (launching EC2 instances), so pre-warm for flash crowds.

option_settings:
  aws:autoscaling:trigger:
    MeasureName: CPUUtilization
    Statistic: Average
    Unit: Percent
    Period: 5
    EvaluationPeriods: 2
    UpperThreshold: 70
    UpperBreachScaleIncrement: 1
    LowerThreshold: 30
    LowerBreachScaleIncrement: -1
  aws:autoscaling:asg:
    MinSize: 2
    MaxSize: 10

Customizing the Platform with .ebextensions and Platform Hooks

Beanstalk allows customization via .ebextensions (YAML/JSON config files) and platform hooks (scripts). .ebextensions can modify configuration files, install packages, run commands, and create resources. For example, you can install a CloudWatch agent or configure Nginx. Platform hooks are scripts that run at specific lifecycle events: prebuild, predeploy, postdeploy. These are placed in .platform/hooks/ directories. Use hooks for tasks like running database migrations or clearing caches. Be careful with ordering and idempotency — hooks run on every deploy. For complex customizations, consider using a custom platform or Docker. Always test customizations in a staging environment first.

#!/bin/bash
# Run database migrations after deploy
cd /var/app/current
npm run migrate
# Only run on first instance? Use a lock
if [ ! -f /tmp/migrated ]; then
  touch /tmp/migrated
fi

Troubleshooting Common Beanstalk Issues

Common issues include: environment turning red, deployment failures, and high latency. First, check the Events tab for error messages. For deployment failures, look at the logs (eb logs). If the app fails to start, ensure the health check URL returns 200. For high latency, check if instances are under-provisioned or if the database is slow. Use CloudWatch metrics to identify bottlenecks. Another common issue: out-of-disk space on instances. Beanstalk instances have limited root volume (default 10 GB). Monitor disk usage and increase volume size via .ebextensions or use EFS for shared storage. Also, check security group rules — if the load balancer can't reach instances, health checks fail. For sticky sessions, ensure the load balancer has session stickiness enabled if needed.

#!/bin/bash
# Check environment health
eb health
# Tail logs
eb logs
# SSH into an instance
eb ssh
# Check disk space on instance
df -h

When to Move Beyond Beanstalk

Beanstalk is great for standard web apps, but it has limitations. If you need fine-grained control over infrastructure (e.g., custom VPC, multiple subnets, specific AMIs), consider using EC2 directly with Auto Scaling and ELB. For containerized apps, ECS or EKS offer more flexibility. For serverless, use Lambda with API Gateway. Beanstalk also has a 500 MB application version limit — for large apps, use Docker or S3 directly. Additionally, Beanstalk's deployment speed can be slow for large environments. If you need faster deployments, consider blue/green with separate environments. Finally, Beanstalk's cost can be higher than managing EC2 yourself due to the abstraction overhead. Evaluate your team's expertise and requirements before committing.

#!/bin/bash
# Example: Export Beanstalk environment to CloudFormation
aws elasticbeanstalk retrieve-environment-info --environment-name my-env --info-type tail
# Then recreate with CloudFormation or Terraform