Elastic Beanstalk

Elastic Beanstalk

Deploy web and worker applications to production on AWS with full lifecycle management. Elastic Beanstalk is an application management service: the user provides application code, AWS manages everything underneath (deployment, scaling, patching, monitoring, health response).

When to Use

Elastic Beanstalk is the right choice when:

• User explicitly asks for Elastic Beanstalk, EB, or a managed application platform
• User says "don't want to manage servers", "managed patching", or "Heroku-like"
• User is migrating from Heroku, Render, or Railway
• User wants AWS to manage ongoing operational lifecycle (patching, scaling,

health monitoring, rollback, deployments) after initial setup

• App is a web framework, API, or background worker on a standard runtime and

the user signals low infrastructure involvement

Elastic Beanstalk is NOT the right choice when:

• User explicitly wants serverless/Lambda — this imposes a different programming

model (event-driven functions, stateless, cold starts, 15-min max execution) rather than just eliminating server management

• User wants fine-grained container orchestration control (use ECS)
• User already has Kubernetes expertise and wants direct K8s access (use EKS)
• App is a static site or SPA (use Amplify Hosting for the frontend; deploy the

backend API separately if present)

• User already has ECS task definitions or Fargate configuration

Key Distinction

ECS and EKS are infrastructure management services: the user defines and operates the deployment infrastructure (task definitions, services, clusters, scaling policies) and owns ongoing operational decisions. Elastic Beanstalk is an application management service: the user provides source code or a Docker image, and AWS provisions and operates the production environment on an ongoing basis. The result is the same reliability, but with lower ongoing maintenance cost because operational responsibility stays with the provider.

Both models support IaC (CDK, CloudFormation, Terraform). The distinction is not about tooling — it is about who manages the lifecycle after deployment.

Lambda/serverless is a different axis entirely. "Don't want to manage servers" does not mean "wants serverless" — Elastic Beanstalk also eliminates server management while preserving the standard application programming model (long-running processes, persistent connections, threads, local state). Serverless imposes a specific programming model: stateless functions, cold starts, event-driven invocation, and a 15-minute execution ceiling. Route to Lambda only when the user explicitly asks for serverless or the workload is natively event-driven (e.g., S3 triggers, API Gateway request/response with no session state).

Workflow

This skill is invoked after the deploy skill selects Elastic Beanstalk as the deployment target. The deploy skill handles codebase analysis and cost estimation. This skill handles EB-specific configuration:

1. Map to platform - Select the EB platform branch (see platforms) 2. Configure - Environment type (web server or worker), instance size, scaling 3. Generate - AWS CLI commands, CDK, or Terraform (see IaC section below) 4. Deploy - Execute with user confirmation

Defaults

Default to dev unless user says "production" or "prod".

Always use load-balanced environments for web server types. This ensures instances stay in private subnets behind an ALB, HTTPS terminates via ACM automatically, and scaling up later is a config change rather than an environment type migration. Dev deployments with min=max=1 cause brief downtime on deploy (single instance, all-at-once). If zero-downtime dev is needed, use min=1 max=2 with rolling.

Worker environments do not have load balancers — they receive work from SQS and are scaled via Auto Scaling group settings.

Environment Types

Worker environments receive work via an SQS queue managed by Elastic Beanstalk. EB's SQS daemon sends HTTP POST requests to the application at a configurable path (default: POST /). The application must expose this HTTP endpoint to process each message — no SQS SDK integration required.

Worker environments also support periodic tasks via cron.yaml for scheduled jobs (alternative to EventBridge + Lambda when the user is already using EB).

If the app uses in-process background threads or async tasks (not queue-based), a single web server environment is sufficient — do not create a separate Worker.

IaC Generation

Default: AWS CLI — no extra tooling to install. The agent orchestrates the multi-step workflow:

1. aws elasticbeanstalk create-storage-location → returns the S3 bucket (idempotent — returns existing bucket if already created) 2. aws elasticbeanstalk create-application 3. Zip source bundle, upload to the bucket from step 1 4. aws elasticbeanstalk create-application-version 5. aws elasticbeanstalk create-environment with --option-settings (web: --tier Name=WebServer,Type=Standard, worker: --tier Name=Worker,Type=SQS/HTTP) 6. aws elasticbeanstalk wait environment-updated 7. Subsequent deploys: new version + update-environment

Resolve the --solution-stack-name by running aws elasticbeanstalk list-available-solution-stacks and filtering for the detected platform (e.g., ".NET" + "Amazon Linux 2023"). Alternatively, use --platform-arn from aws elasticbeanstalk list-platform-versions.

Use .ebextensions/ and platform hooks for customization.

See AWS CLI EB reference for full command documentation.

Override: CDK (TypeScript) when the user has an existing CDK project, wants repeatable IaC, or explicitly requests it:

• CfnApplication, CfnEnvironment, CfnConfigurationTemplate

Override: Terraform when the user's repo already has Terraform:

• aws_elastic_beanstalk_application, aws_elastic_beanstalk_environment

CDK and Terraform templates are scannable by cfn-nag/checkov pre-deploy.

Security

Apply these automatically:

• Web server instances in private subnets behind ALB
• Worker instances in private subnets with NAT Gateway for outbound
• HTTPS via ACM certificate on ALB (web server environments)
• IAM instance profile with least-privilege permissions — scan source code for

AWS SDK client usage to determine required actions (e.g., AmazonBedrockRuntimeClient → bedrock:InvokeModel, AmazonS3Client → s3:GetObject/s3:PutObject on specific buckets)

• Enhanced health reporting enabled
• Managed platform updates enabled
• Security groups: ALB accepts 443, instances accept only from ALB

See the deploy skill's security defaults for encryption, VPC placement, and IAM patterns.

Cost

Elastic Beanstalk has no service fee. Cost = underlying AWS resources. Query the awspricing MCP server for region-accurate estimates. Approximate us-east-1 pricing:

Add RDS/Aurora costs separately if database is included.

References

• Supported platforms and detection
• Configuration and customization

Configuration and Customization

Configuration Hierarchy

Option settings are applied in this order (later overrides earlier):

1. Platform defaults (managed by AWS) 2. Saved configurations (reusable templates) 3. .ebextensions/*.config files (in source bundle) 4. Environment properties (set via console/CLI/API)

Platform hooks (/platform/hooks/prebuild/, predeploy/, postdeploy/) run shell scripts during deployment lifecycle but do not set option settings. They are the preferred customization mechanism on AL2023 for non-option-setting tasks. Use .ebextensions/ for option settings and resource declarations.

See Configuration options precedence for full details.

Option Settings Format

When using --option-settings with the AWS CLI, pass a JSON array:

[
  {
    "Namespace": "aws:autoscaling:launchconfiguration",
    "OptionName": "InstanceType",
    "Value": "t3.small"
  },
  {
    "Namespace": "aws:autoscaling:launchconfiguration",
    "OptionName": "IamInstanceProfile",
    "Value": "bedrock-chatbot-instance-profile"
  },
  {
    "Namespace": "aws:elasticbeanstalk:environment",
    "OptionName": "LoadBalancerType",
    "Value": "application"
  },
  {
    "Namespace": "aws:elasticbeanstalk:environment:process:default",
    "OptionName": "HealthCheckPath",
    "Value": "/health"
  }
]

See Configuration options namespaces for the full list of namespaces and option names.

Key Patterns

Run commands on deploy

container_commands:
  01_migrate:
    command: "python manage.py migrate --noinput"
    leader_only: true

Use leader_only: true for commands that should run on only one instance (database migrations, cache warmup).

Procfile

Define the process to run. EB uses this instead of platform defaults:

web: gunicorn myapp.wsgi --bind 0.0.0.0:8000

For worker environments, the Procfile defines the HTTP server that receives SQS daemon POST requests (not a queue consumer like Celery — EB Workers use HTTP, not a message broker SDK).

Environment Properties and Secrets

Non-secret config uses aws:elasticbeanstalk:application:environment. For secrets, use the native secrets integration which injects Secrets Manager values as environment variables without application-side SDK calls:

option_settings:
  aws:elasticbeanstalk:application:environment:
    APP_ENV: production
  aws:elasticbeanstalk:application:environmentsecrets:
    DB_PASSWORD: arn:aws:secretsmanager:us-east-1:123456789:secret:myapp/db

The environmentsecrets namespace requires platform versions released March 2025 or later. Verify via aws elasticbeanstalk list-available-solution-stacks.

Never hardcode secrets in .ebextensions/ or source code. Provision databases and secrets as separate resources — not coupled to the EB environment lifecycle.

See Environment secrets for supported secret sources.

Deployment Policies

Default: All at once for dev, Rolling with additional batch for production.

See Deployment policies and settings for configuration details.

Reverse Proxy Port

AL2023 platforms use nginx as a reverse proxy, forwarding to port 5000 by default. If the application listens on a different port, set the PORT environment property to match. Mismatched ports result in 502 Bad Gateway from nginx.

Health Check

Always configure a dedicated health check endpoint. Do not use / if it performs database queries or heavy computation.

The agent should verify that the application exposes a health endpoint (default: /health). If no health route exists, scaffold a minimal one that returns 200 OK. The ALB health check will fail without this, causing deployment to roll back.

See Health check setting for ALB health check configuration.

Heroku Migration

When migrating from Heroku/Render/Railway, audit for these patterns:

• DATABASE_URL → Provision RDS/Aurora separately, pass via environment secrets
• REDIS_URL → Provision ElastiCache, pass endpoint via environment properties
• Add-on env vars (e.g., SENDGRID_API_KEY) → Store in Secrets Manager
• PORT → See Reverse Proxy Port section above; set if app doesn't use 5000
• Procfile → Works as-is (same format)
• Explicit AWS credentials → Remove; use IAM instance profile instead

Supported Platforms

These rules apply after Elastic Beanstalk has been selected as the deployment target by the deploy skill.

Detect the application's language and framework, then map to an EB platform branch.

Platform Detection

Platform Selection Rules

1. If Dockerfile exists AND a language runtime is also detected, ask the user for an explicit selection. 2. If multiple languages detected, ask the user for an explicit selection. 3. Always use Amazon Linux 2023 unless the app requires Windows (.NET Framework, IIS dependencies). 4. For Java apps: if .war file, deploy to Tomcat platform. If .jar with embedded server (Spring Boot), use Corretto platform. 5. Always use the latest supported runtime version unless the application specifies a version constraint (e.g., engines in package.json, <TargetFramework> in .csproj).

Supported Deployment Artifacts

.NET and Java platforms require pre-built artifacts. Run dotnet publish or mvn package/gradle build before zipping. Other language platforms (Python, Node.js, Ruby, Go, PHP) accept raw source and build on-instance.

Worker Platform Considerations

Worker environments use the same platforms as web server environments. The difference is the SQS daemon that delivers messages to the application over HTTP on localhost. The application must expose an HTTP endpoint (default: POST /) that processes each message.