Amazon EC2（アマゾンのクラウドサーバー）の仮想マシン環境の構築・管理・運用に対応しています。 **対応する主な機能：** - インスタンスタイプの選択（Graviton/Arm64、バースト可能なT型、GPU、インスタンスストア対EBS） - 起動テンプレート - オートスケーリンググループ（スケーリングポリシー、インスタンスの一括更新、混合インスタンス、スポットインスタンス、ウォームプール、ライフサイクルフック） - IMDSv2（メタデータサービスのセキュア版） - 配置グループ - エラスティックIP - AMI（マシンイメージ）のライフサイクル管理 - Systems Manager フリート管理（セッションマネージャー、コマンド実行、パッチ適用） **次のような場合に使用：** EC2 インスタンスやフリート関連の質問、容量不足エラー、CPU クレジット・サージ料金、IMDSv2 認証エラー、「Pending:Wait」状態でのインスタンス停止、オートスケーリンググループが異常なインスタンスを置き換えない問題、ステータスチェック失敗、SSH 接続拒否/タイムアウト、Systems Manager の管理対象ノードに表示されないインスタンス **参考：** - 単一のセキュアなインスタンスを起動する場合は「launching-ec2-instance-with-best-practices」スキルが適切です - インスタンスプロファイルについては「setting-up-ec2-instance-profiles」を参照 - Image Builder については「amazon-ec2-image-builder」を参照 **対応外：** Lambda、ECS/Fargate、EKS、VPC/ALB/NLB の設計、IAM ポリシーの作成
Provisions, scales, and operates Amazon EC2 virtual-machine workloads: instance-type selection (Graviton/Arm64, burstable T credits, GPU, instance store vs EBS), launch templates, Auto Scaling groups (scaling policies, instance refresh, mixed instances, Spot, warm pools, lifecycle hooks), IMDSv2, placement groups, Elastic IPs, AMI lifecycle, and Systems Manager fleet operations (Session Manager, Run Command, Patch Manager). Applies to EC2 instance and fleet questions, InsufficientInstanceCapacity, CPU-credit/surplus charges, IMDSv2 401s, instances stuck in Pending:Wait, ASG not replacing unhealthy instances, status-check failures, SSH refused/timed out, or instances missing as SSM managed nodes. For a single secure instance launch, the launching-ec2-instance-with-best-practices skill is more appropriate; for instance profiles, see setting-up-ec2-instance-profiles; for Image Builder, see amazon-ec2-image-builder. Does NOT cover Lambda, ECS/Fargate, EKS, VPC/ALB/NLB design, or IAM policy authoring.
AWS MCP サーバー（クラウドサービス連携プロトコル）との組み合わせで最良の動作が得られます。AWS CLI だけでも利用できますが、どちらかが絶対に必要という依存関係はありません。
起動設定は廃止予定 で、現在の EC2 インスタンスタイプに対応していません。新しいアカウントでは作成できません。Auto Scaling グループ（自動スケーリング機能）を新規作成する場合は、必ず起動テンプレートを使用してください。詳細は auto-scaling.md を参照してください。
Auto Scaling グループはロードバランサーのヘルスチェックを無視します（デフォルト）。Auto Scaling グループは --health-check-type ELB を設定しない限り、EC2 ステータスチェックのみを使用します。この設定がないと、ロードバランサーのヘルスチェック不合格になったインスタンスが永遠にサービス中のままになります。詳細は auto-scaling.md を参照してください。
IMDSv2 ホップリミットがコンテナを破壊します。デフォルトの HttpPutResponseHopLimit が 1 に設定されていると、IMDSv2 トークン取得時のレスポンスが余分なホップによって TTL（有効期限）を超過し、コンテナ内プロセスに届きません。その結果、トークン取得タイムアウトが発生します。ブリッジ型・awsvpc 型のコンテナワークロード向けに HttpPutResponseHopLimit=2 を設定してください。（IMDSv2 が必須の場合、その後の認証なし GET リクエストは 401 を返します。オプション設定の場合は、自動的に IMDSv1 にフォールバックします。）詳細は provisioning.md を参照してください。
T3・T3a・T4g はデフォルトで無制限モード。T2（標準）と異なり、これらはスロットリングなしでバースト（瞬間的な性能向上）しますが、24 時間平均 CPU が基準値を超えた場合、余剰 CPU クレジットが課金されます。これは気付かない形で費用が膨らむ可能性があります。詳細は instance-selection.md を参照してください。
インスタンスストアは一時的。インスタンスストア（一時ストレージ）上のデータは、停止・休止・終了・インスタンスタイプ変更・ホスト障害で失われます。再起動時のみデータが残ります。永続性が必要なデータは EBS・EFS・S3 に保存してください。詳細は instance-selection.md を参照してください。
| こんなときは | 参考ガイド |
|---|---|
| インスタンスファミリー・サイズ・Graviton（ARM プロセッサ）・GPU・バースト型の選定 | instance-selection.md — ワークロードからファミリーを選ぶ表から始めてください |
| インスタンスを一度定義して何度も再利用する方法（起動テンプレート） | provisioning.md |
| 複数インスタンスを実行し、自動スケーリングさせる方法 | auto-scaling.md |
| SSH キーなしでインスタンスにアクセス・パッチ適用・管理する方法 | systems-manager.md |
| やりたいこと | ページ |
|---|---|
| インスタンスタイプを選ぶ、Graviton vs x86 比較、バースト型クレジット、GPU、インスタンスストア vs EBS | instance-selection.md |
| 起動テンプレートを作成、ユーザーデータ設定、キーペア、IMDSv2、配置グループ、Elastic IP | provisioning.md |
| Auto Scaling グループの設定・修正、スケーリングポリシー、インスタンスリフレッシュ、Spot インスタンス、ライフサイクルフック | auto-scaling.md |
| SSH 不要のアクセス、複数インスタンスへのパッチ適用、マネージドノード認識の問題解決 | systems-manager.md |
| AMI（マシンイメージ）の作成・共有・廃止（非推奨化・無効化・登録解除） | ami-management.md |
| 接続できない、ステータスチェック失敗、容量エラー、インスタンス停止など問題の解決 | troubleshooting.md |
「Web アプリケーション用の自動スケーリング構成を立ち上げたい」
→ 起動テンプレートを作成（AMI・タイプ・IMDSv2 設定）し、--health-check-type ELB と目標追跡型スケーリングポリシーを指定して Auto Scaling グループを作成します。詳細は auto-scaling.md を参照。公開エントリーポイント向けロードバランサーは、以下「セキュリティ上の考慮事項」およびこのスキルの auto-scaling.md に記載されたロードバランサー注記に従い、TLS・ACM・WAF・セキュリティレスポンスヘッダーで保護してください。ロードバランサーの構築自体は aws-networking スキルの範囲です。
「新しい AMI を既存フロートに展開したい」 → 起動テンプレートの新バージョンを作成し、インスタンスリフレッシュを実行します。ロールバック対応のため起動テンプレートのバージョン番号を固定してください。詳細は auto-scaling.md を参照。
「踏み台サーバーなしでプライベートインスタンスに接続したい」
→ インスタンスに SSM 権限を付与（AmazonSSMManagedInstanceCore が含まれるインスタンスプロファイル、またはアカウントレベルの DHMC（直接接続可能マネージドコア））し、ネットワークパスを確保した上で、Session Manager（セッション管理機能）を使用します。詳細は systems-manager.md を参照。
「EC2 の費用を削減したい」
→ 正しいサイズ選定（バースト型 vs 固定性能）、Arm64 対応アプリケーションでの Graviton 活用、障害耐性が必要なフロート向けに price-capacity-optimized を指定した Spot インスタンス利用、未使用 Elastic IP の開放。詳細は instance-selection.md を参照。
| 症状 | 考えられる原因 | 対処方法 |
|---|---|---|
| SSH「接続がタイムアウト」 | ネットワークパス（セキュリティグループ・ネットワーク ACL・ルート・公開 IP がない） | あなたの IP から TCP 22 を開く、IGW へのルートを確認、公開 IP の確認 — troubleshooting.md 参照 |
| SSH「接続が拒否された」 | ホスト側：sshd が停止中またはまだ起動中 | 起動完了を待つ、Session Manager やシリアルコンソール経由で sshd とポート状態を確認 |
InsufficientInstanceCapacity |
AWS がそのアベイラビリティーゾーン内でそのタイプの容量不足（クォータの問題ではない） | 別の AZ・インスタンスタイプを試す、リトライする、クォータ増加リクエストは不要 |
InstanceLimitExceeded |
vCPU クォータ上限に達した（これはクォータの問題） | Service Quotas からインスタンスファミリーの vCPU クォータ増加をリクエスト |
| Auto Scaling グループがロードバランサー不合格インスタンスを置き換えない | ヘルスチェックタイプが未だ EC2 のままになっている | --health-check-type ELB を設定 |
インスタンスが Pending:Wait で止まり、約 1 時間後に終了される |
ライフサイクルフック（起動・終了処理フック）が完了せず（ハートビート 3600 秒、デフォルト ABANDON） | complete-lifecycle-action で CONTINUE を指定するか、DefaultResult を CONTINUE に変更 |
| システムステータスチェック失敗 | AWS ホスト・ハードウェア障害 | 停止・起動して新しいハードウェアに移行（再起動では対応不可） |
| インスタンスステータスチェック失敗 | インスタンス OS・ネットワーク設定の問題 | 再起動する、または OS・ネットワーク設定を修正 |
完全な表と追加エラー情報は troubleshooting.md を参照してください。
IMDSv2 の強制適用 (HttpTokens=required)：起動テンプレートで SSRF（サイト間リクエスト偽造）によるクレデンシャル盗難をブロックします。リージョンごとにアカウントレベルのデフォルト設定を適用してください（新規起動にのみ適用）。
SSH インバウンドより Session Manager を優先：ポート 22 を開かず、キー管理も不要、CloudTrail にセッション API 呼び出し記録も残ります。Session Manager のログを CloudWatch Logs・S3 に保存する設定を有効化（デフォルト無効）すると、セッション内コマンドそのものも記録されます。詳細は systems-manager.md を参照。
インスタンスプロファイルを使用し、クレデンシャルを埋め込まない：ロール権限は最小権限原則に基づき範囲を限定します。
EBS・AMI を暗号化：暗号化された AMI をアカウント間で共有する場合は、カスタマー管理 KMS キーで再暗号化してください（デフォルトの aws/ebs キーは共有不可）。
すべてのリージョンで CloudTrail を有効化：EC2・Auto Scaling・SSM API アクティビティを監査し、セキュリティグループ変更・RunInstances・TerminateInstances など機密性の高いアクションについて、予期しないプリンシパル（実行者）からのアクセスアラームを設定し、無許可の変更を検知します。
公開 Web フロート向け：ロードバランサーの HTTPS リスナーで ACM 証明書を使用して通信を暗号化し、AWS WAF（ウェブアプリケーションファイアウォール）で一般的な Web 攻撃に対する多層防御を実装してください。ロードバランサー・WAF 設定自体は aws-networking スキル範囲です。
さらなる強化については、AWS EC2 セキュリティベストプラクティス および ゲスト OS 向け CIS Benchmark を参照してください。
単一インスタンスをベストプラクティスのデフォルト設定で起動 → launching-ec2-instance-with-best-practices スキルを使用してください
EC2 用の IAM ロール・インスタンスプロファイルを作成 → setting-up-ec2-instance-profiles スキルを使用してください
EC2 Image Builder パイプラインで AMI を構築 → amazon-ec2-image-builder スキルを使用してください
Lambda・サーバーレス → aws-serverless、ECS・Fargate → aws-containers、EKS・Kubernetes → kubernetes を使用してください
VPC・サブネット・ALB/NLB・エンドポイント → aws-networking またはビルトイン知識を参照
IAM ポリシーロジック・CloudWatch ダッシュボード・エージェント設定 → aws-iam、aws-observability を参照
Best experience with the AWS MCP server; also works with the AWS CLI alone — no hard dependency on either.
Launch configurations are deprecated and do not support current EC2 instance types; new accounts cannot create them. Use launch templates for every new Auto Scaling group. See auto-scaling.md.
ASGs ignore ELB health checks by default: An Auto Scaling group only uses EC2 status checks unless you set --health-check-type ELB. Without it, instances failing the load balancer's health check stay in service forever. See auto-scaling.md.
IMDSv2 hop limit breaks containers: the default HttpPutResponseHopLimit of 1 makes the IMDSv2 token PUT response fail to reach a containerized process (the extra hop exceeds the response TTL), so the token request times out. Set HttpPutResponseHopLimit=2 for bridge/awsvpc container workloads. (If IMDSv2 is required, a subsequent tokenless GET returns 401; if optional, it silently falls back to IMDSv1.) See provisioning.md.
T3/T3a/T4g default to unlimited mode: Unlike T2 (standard), these burst without throttling but bill surplus CPU credits when 24h-average CPU exceeds baseline — a silent cost leak. See instance-selection.md.
Instance store is ephemeral: Data on instance store volumes is lost on stop, hibernate, terminate, instance-type change, and host failure — it survives only a reboot. Put anything durable on EBS/EFS/S3. See instance-selection.md.
| If you're deciding... | Guidance |
|---|---|
| Instance family / size / Graviton / GPU / burstable | instance-selection.md — start with the workload→family table |
| How to define instances once and reuse (launch template) | provisioning.md |
| How to run many instances that scale automatically | auto-scaling.md |
| How to access/patch/manage instances without SSH keys | systems-manager.md |
| You want to... | Go to |
|---|---|
| Pick an instance type, Graviton vs x86, burstable credits, GPU, instance store vs EBS | instance-selection.md |
| Create a launch template, user data, key pairs, IMDSv2, placement groups, Elastic IPs | provisioning.md |
| Set up or fix an Auto Scaling group, scaling policies, instance refresh, Spot, lifecycle hooks | auto-scaling.md |
| Get SSH-less access, patch a fleet, or fix an instance not showing as a managed node | systems-manager.md |
| Create, share, or retire (deprecate/disable/deregister) an AMI | ami-management.md |
| Fix something broken (can't connect, status-check fail, capacity error, stuck instances) | troubleshooting.md |
"Stand up an autoscaling web fleet" → Create a launch template (AMI, type, IMDSv2), then an ASG referencing it with --health-check-type ELB and a target-tracking policy, see auto-scaling.md. For the public entry point, secure the load balancer (TLS/ACM, WAF, security response headers) per the Security Considerations below and the load-balancer notes in auto-scaling.md — the load-balancer build itself belongs to aws-networking.
"Roll out a new AMI to my fleet" → New launch template version → instance refresh; pin a numeric launch-template version so rollback works, see auto-scaling.md.
"Connect to a private instance without a bastion" → Give the instance SSM permissions (an instance profile with AmazonSSMManagedInstanceCore, or account-level DHMC) plus a network path, then use Session Manager, see systems-manager.md.
"Cut EC2 cost" → Right-size (burstable vs fixed-performance), Graviton where the app supports Arm64, Spot with price-capacity-optimized for fault-tolerant fleets, release idle Elastic IPs, see instance-selection.md.
| Symptom | Likely cause | Quick fix |
|---|---|---|
| SSH "Connection timed out" | Network path (SG/NACL/route/no public IP) | Open TCP 22 from your IP; check route to IGW; verify public IP — see troubleshooting.md |
| SSH "Connection refused" | Host: sshd down or still booting | Wait for boot; check sshd/port via Session Manager or serial console |
InsufficientInstanceCapacity |
AWS lacks capacity of that type in the AZ (NOT a quota) | Try another AZ / instance type / retry; don't request a quota increase |
InstanceLimitExceeded |
vCPU quota reached (this IS a quota) | Request a Service Quotas increase for the instance family |
| ASG never replaces LB-unhealthy instances | Health check type still EC2 | Set --health-check-type ELB |
Instances stuck in Pending:Wait, terminated after ~1h |
Lifecycle hook never completed (heartbeat 3600s, default ABANDON) | Call complete-lifecycle-action CONTINUE, or set DefaultResult CONTINUE |
| System status check failed | AWS host/hardware | Stop/start to migrate to new hardware (reboot won't) |
| Instance status check failed | Instance OS/network config | Reboot or fix the OS/network config |
Full tables and more errors in troubleshooting.md.
HttpTokens=required) on launch templates to block SSRF-based credential theft; set the account-level default per Region (applies to new launches only).aws/ebs key can't be shared).RunInstances/TerminateInstances from unexpected principals) so unauthorized changes surface.aws-networking.launching-ec2-instance-with-best-practices skillsetting-up-ec2-instance-profiles skillamazon-ec2-image-builder skillaws-serverless; ECS/Fargate → aws-containers; EKS/Kubernetes → kubernetesaws-networking or built-in knowledgeaws-iam, aws-observability原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。