AWS Elastic Beanstalk にデプロイします。 **次のような場合に使用:** - Elastic Beanstalk または EB について - EC2（クラウド上の仮想サーバー）を自動で管理したいプラットフォーム - セキュリティ更新などを自動で適用する Web アプリケーション - EC2 上で動作するワーカーアプリケーション - Heroku（サーバー管理不要なサービス）の代わりを探している - サーバーやコンテナ管理（複数の処理環境を統制する手段）を自分でしたくない - Heroku から切り替えたい - 運用のライフサイクル（サービスの構築から終了までの一連の過程）が管理されている環境が必要 **対応範囲:** EC2 上で動作する Web アプリケーションとワーカーアプリケーション向けの Elastic Beanstalk に対応しています。
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.
WebアプリケーションおよびWorkerアプリケーションを、フルライフサイクル管理とともにAWS本番環境へデプロイします。 Elastic BeanstalkはアプリケーションマネジメントServiceです。ユーザーはアプリケーションコードを提供するだけで、 その下のすべて（デプロイ、スケーリング、パッチ適用、監視、ヘルス対応）をAWSが管理します。
以下に当てはまる場合、Elastic Beanstalkが適切な選択です:
以下に当てはまる場合、Elastic Beanstalkは適切ではありません:
ECSおよびEKSはインフラ管理Serviceです。ユーザーがデプロイインフラ（タスク定義、Service、クラスター、スケーリングポリシー）を定義・運用し、継続的な運用上の意思決定を担います。 一方、Elastic BeanstalkはアプリケーションManagement Serviceです。ユーザーがソースコードまたはDockerイメージを提供すれば、AWSが本番環境のプロビジョニングと継続的な運用を担います。 同等の信頼性を実現しながら、運用責任がプロバイダー側に移ることで継続的なメンテナンスコストを削減できます。
どちらのモデルもIaC（CDK、CloudFormation、Terraform）をサポートしています。 違いはツールの選択ではなく、デプロイ後のライフサイクルを誰が管理するかにあります。
Lambda/サーバーレスはまったく別の軸です。「サーバーを管理したくない」は「サーバーレスが欲しい」を意味しません。 Elastic Beanstalkもサーバー管理を不要にしつつ、標準的なアプリケーションプログラミングモデル（常駐プロセス、持続的接続、スレッド、ローカルステート）を維持します。 サーバーレスはステートレス関数・コールドスタート・イベント駆動の呼び出し・15分の実行上限という特定のプログラミングモデルを強制します。 Lambdaへルーティングするのは、ユーザーが明示的にサーバーレスを求めている場合か、ワークロードがネイティブにイベント駆動（例: S3トリガー、セッションステートなしのAPI Gatewayリクエスト/レスポンス）である場合のみにしてください。
このSkillは、deploySkillがElastic Beanstalkをデプロイターゲットとして選択した後に呼び出されます。 コードベースの分析とコスト見積もりはdeploySkillが担当し、このSkillはEB固有の設定を担当します:
| 設定項目 | 開発環境 | 本番環境 |
|---|---|---|
| 環境タイプ（Web） | ロードバランシング（min=1, max=1） | ロードバランシング、マルチAZ |
| 環境タイプ（Worker） | Auto Scalingグループ（min=1, max=1） | Auto Scalingグループ（min=2, max=4） |
| インスタンス | t3.small | t3.medium 以上 |
| デプロイ方式 | All-at-once | Rolling with additional batch |
| ヘルスレポート | Enhanced | Enhanced |
| マネージドアップデート | 有効（週次） | 有効（メンテナンスウィンドウ） |
| HTTPS（Webのみ） | ACM証明書 + ALB | ACM証明書 + ALB |
ユーザーが「production」または「prod」と指定しない限り、開発環境をデフォルトとします。
WebサーバータイプにはロードバランシングEnvironmentを常に使用してください。 これにより、インスタンスはALBの背後のプライベートサブネットに配置され、HTTPSはACMによって自動的にターミネートされ、 後でスケールアップする際も環境タイプの移行ではなく設定変更で対応できます。 min=max=1の開発環境デプロイは、デプロイ時に短時間のダウンタイムが発生します（シングルインスタンス、All-at-once）。 ゼロダウンタイムが必要な場合はmin=1, max=2のRollingを使用してください。
Worker環境にはロードバランサーがありません。SQSからジョブを受け取り、Auto Scalingグループの設定でスケーリングします。
| コードベースのシグナル | 環境タイプ |
|---|---|
| HTTPリスナー、Webフレームワーク、APIルート | Webサーバー |
| キューベースのコンシューマー、SQS処理、HTTPサービングなし | Worker |
| HTTPサービング + キューベースのバックグラウンド処理 | Webサーバー + 別のWorker環境 |
Worker環境はElastic BeanstalkがマネージドするSQSキューを通じてジョブを受け取ります。
EBのSQSデーモンが設定可能なパス（デフォルト: POST /）へHTTP POSTリクエストをアプリケーションに送信します。
各メッセージを処理するために、アプリケーションはこのHTTPエンドポイントを公開する必要があります（SQS SDKの統合は不要）。
Worker環境はcron.yamlを使用した定期タスクもサポートしており、スケジュールジョブを実行できます
（ユーザーがすでにEBを使用している場合のEventBridge + Lambdaの代替手段）。
アプリがインプロセスのバックグラウンドスレッドや非同期タスク（キューベースでないもの）を使用している場合は、 単一のWebサーバー環境で十分です。別のWorkerは作成しないでください。
デフォルト: AWS CLI — 追加ツールのインストール不要。Agentが以下の複数ステップのワークフローを統括します:
aws elasticbeanstalk create-storage-location → S3バケットを返す
（冪等性あり — バケットが既存の場合は既存のものを返す）aws elasticbeanstalk create-applicationaws elasticbeanstalk create-application-versionaws elasticbeanstalk create-environmentに--option-settingsを付けて実行
（Web: --tier Name=WebServer,Type=Standard、Worker: --tier Name=Worker,Type=SQS/HTTP）aws elasticbeanstalk wait environment-updatedupdate-environmentを実行--solution-stack-nameはaws elasticbeanstalk list-available-solution-stacksを実行し、
検出されたプラットフォーム（例: ".NET" + "Amazon Linux 2023"）でフィルタリングして解決してください。
またはaws elasticbeanstalk list-platform-versionsから--platform-arnを使用することもできます。
カスタマイズには.ebextensions/とプラットフォームフックを使用してください。
コマンドの詳細なドキュメントはAWS CLI EBリファレンスを参照してください。
オーバーライド: CDK（TypeScript） — ユーザーが既存のCDKプロジェクトを持っている場合、 再現可能なIaCを求めている場合、または明示的に要求された場合:
CfnApplication、CfnEnvironment、CfnConfigurationTemplateオーバーライド: Terraform — ユーザーのリポジトリにすでにTerraformがある場合:
aws_elastic_beanstalk_application、aws_elastic_beanstalk_environmentCDKおよびTerraformのテンプレートはデプロイ前にcfn-nag/checkovでスキャン可能です。
以下を自動的に適用してください:
AmazonBedrockRuntimeClient → bedrock:InvokeModel、
AmazonS3Client → 特定バケットへのs3:GetObject/s3:PutObject）暗号化、VPCの配置、IAMパターンについては、deploySkillのセキュリティデフォルトを参照してください。
Elastic Beanstalk自体のサービス料金はありません。コスト = 使用するAWSリソースの料金です。 リージョン別の正確な見積もりはawspricingMCPサーバーに問い合わせてください。 us-east-1のおおよその料金目安:
| 構成 | 推定月額コスト |
|---|---|
| 開発Web（t3.small × 1 + ALB） | 約 $35〜40 |
| 開発Worker（t3.small × 1、ALBなし） | 約 $15〜20 |
| 本番Web（t3.medium × 4 + ALB、マルチAZ） | 約 $150〜200 |
データベースが含まれる場合はRDS/Auroraのコストを別途加算してください。
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).
Elastic Beanstalk is the right choice when:
Elastic Beanstalk is NOT the right choice when:
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).
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:
| 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.
| 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 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.
Default: AWS CLI — no extra tooling to install. The agent orchestrates the multi-step workflow:
aws elasticbeanstalk create-storage-location → returns the S3 bucket
(idempotent — returns existing bucket if already created)aws elasticbeanstalk create-applicationaws elasticbeanstalk create-application-versionaws elasticbeanstalk create-environment with --option-settings (web:
--tier Name=WebServer,Type=Standard, worker: --tier Name=Worker,Type=SQS/HTTP)aws elasticbeanstalk wait environment-updatedupdate-environmentResolve 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, CfnConfigurationTemplateOverride: Terraform when the user's repo already has Terraform:
aws_elastic_beanstalk_application, aws_elastic_beanstalk_environmentCDK and Terraform templates are scannable by cfn-nag/checkov pre-deploy.
Apply these automatically:
AmazonBedrockRuntimeClient → bedrock:InvokeModel,
AmazonS3Client → s3:GetObject/s3:PutObject on specific buckets)See the deploy skill's security defaults for encryption, VPC placement, and IAM patterns.
Elastic Beanstalk has no service fee. Cost = underlying AWS resources. Query the awspricing MCP server for region-accurate estimates. Approximate us-east-1 pricing:
| Configuration | Estimated Monthly Cost |
|---|---|
| Dev web (1x t3.small + ALB) | ~$35-40 |
| Dev worker (1x t3.small, no ALB) | ~$15-20 |
| Production web (4x t3.medium + ALB, Multi-AZ) | ~$150-200 |
Add RDS/Aurora costs separately if database is included.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。