/elastic-beanstalk

name: elastic-beanstalk
description: "Deploy to AWS Elastic Beanstalk. Triggers on: elastic beanstalk, EB, managed EC2 platform, web app with managed patching, worker on EC2, Heroku alternative, don't want to manage servers or container orchestration, migrate from Heroku, managed operational lifecycle. Covers Elastic Beanstalk on EC2 for web and worker applications."

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](references/platforms.md)) 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

| Setting | Dev | Production | | ------------------------- | --------------------------------- | --------------------------------- | | Environment type (web) | Load-balanced (min=1, max=1) | Load-balanced, Multi-AZ | | Environment type (worker) | Auto Scaling group (min=1, max=1) | Auto Scaling group (min=2, max=4) | | Instance | t3.small | t3.medium or larger | | Deployments | All-at-once | Rolling with additional batch | | Health reporting | Enhanced | Enhanced | | Managed updates | Enabled (weekly) | Enabled (maintenance window) | | HTTPS (web only) | ACM certificate + ALB | ACM certificate + ALB |

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

| Signal in Codebase | Environment Type | | ----------------------------------------------------- | ---------------------------------------- | | HTTP listener, web framework, API routes | Web server | | Queue-based consumer, SQS processing, no HTTP serving | Worker | | HTTP serving + queue-based background processing | Web server + separate Worker environment |

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 requi