Elastic Beanstalk
Deploy to AWS Elastic Beanstalk, in either Beanstalk Standard mode (EC2) or Beanstalk...
Install
npx skills add awslabs/agent-plugins --skill elastic-beanstalk -g -a claude-code -y- Repository
- awslabs/agent-plugins933
- Category
- DevOps
- Updated
- 20d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 2,898 tokens
- Runs scripts
- No, instructions only
What it does
Deploy to AWS Elastic Beanstalk, in either Beanstalk Standard mode (EC2) or Beanstalk Cluster mode (managed EKS). Triggers on: elastic beanstalk, EB, beanstalk standard, beanstalk cluster, 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, containerised app without operating Kubernetes, several services sharing a managed cluster, managed EKS without kubectl. Covers web and worker applications on EC2, and containerised single- and multi-service applications on managed EKS.
Elastic Beanstalk
Deploy applications to production on AWS with full lifecycle management. Elastic Beanstalk is an application management service: the user provides application code or a container image, AWS manages everything underneath (deployment, scaling, patching, monitoring, health response).
There are two modes, and the choice determines every setting that follows. Standard runs the application on Amazon EC2; Cluster runs a container on a managed Amazon EKS Auto Mode cluster. See Choose the Mode.
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
