mcpField
A
aws-compute

aws-compute

github.com/awsクラウド・DevOps3.3k5.7k 回インストール1 日前に更新
リポジトリ

aws-compute について

aws-compute は、AWS のコンピューティングワークロードを担当する人向けに、Amazon EC2 のインスタンス選定、プロビジョニング、スケーリング、管理を案内するスキルです。運用手順やトラブルシューティングを含み、AWS MCP server と併用することも、AWS CLI のみで使うこともできます。

主な機能

  1. 01インスタンスファミリーとサイズの選定案内
  2. 02起動テンプレートとプロビジョニングの案内
  3. 03Auto Scaling グループの管理
  4. 04Systems Manager によるインスタンス管理
  5. 05AMI 管理とトラブルシューティング

活用シーン

  1. 01ワークロードに合う EC2 インスタンスタイプの選定
  2. 02自動スケーリングする Web フリートの構築
  3. 03インスタンス更新による新しい AMI の展開
  4. 04接続、容量、ステータスチェック障害の調査

MCP 対応

このスキルは AWS MCP server との併用を推奨しますが、必須ではなく AWS CLI のみでも利用できます。MCP サービスを提供するとは記載されていません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-compute

インストール後、Claude Code で/aws-computeを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
ami-management.md
auto-scaling.md
instance-selection.md
provisioning.md
systems-manager.md
troubleshooting.md

詳細

Amazon EC2 コンピューティング

AWS MCP サーバーを使用すると最適なエクスペリエンスが得られます。AWS CLI のみでも利用でき、どちらにも強く依存しません。

重大な警告

起動設定は非推奨です。現在の EC2 インスタンスタイプをサポートしておらず、新しいアカウントでは作成できません。新しい Auto Scaling グループには、すべて起動テンプレートを使用してください。詳しくは auto-scaling.md を参照してください。

ASG はデフォルトで ELB ヘルスチェックを無視します：Auto Scaling グループは --health-check-type ELB を設定しない限り、EC2 ステータスチェックのみを使用します。設定しないと、ロードバランサーのヘルスチェックに失敗したインスタンスが、いつまでもサービス対象のままになります。詳しくは auto-scaling.md を参照してください。

IMDSv2 のホップリミットはコンテナを機能不全にします：デフォルトの HttpPutResponseHopLimit が 1 の場合、IMDSv2 トークンの PUT 応答がコンテナ化されたプロセスに届かず（ホップが 1 つ増えることで応答 TTL を超えるため）、トークンリクエストがタイムアウトします。ブリッジ／awsvpc コンテナワークロードでは HttpPutResponseHopLimit=2 を設定してください。（IMDSv2 が必須の場合、その後のトークンなし GET は 401 を返します。任意の場合は、IMDSv1 にサイレントにフォールバックします。）詳しくは provisioning.md を参照してください。

T3／T3a／T4g はデフォルトで無制限モードになります：T2（standard）とは異なり、これらのインスタンスはスロットリングなしでバーストしますが、CPU の 24 時間平均使用率がベースラインを超えると、超過した CPU クレジット分が課金されます。これは気づきにくいコスト増加につながります。詳しくは instance-selection.md を参照してください。

インスタンスストアは一時的なストレージです：インスタンスストアボリューム上のデータは、停止、休止、終了、インスタンスタイプの変更、ホスト障害によって失われます。再起動した場合にのみ保持されます。永続化が必要なデータは EBS／EFS／S3 に保存してください。詳しくは instance-selection.md を参照してください。

どの情報が必要ですか？

検討している内容...ガイダンス
インスタンスファミリー／サイズ／Graviton／GPU／バースト可能なインスタンスinstance-selection.md — まずワークロード→ファミリーの表を確認してください
インスタンスを一度定義して再利用する方法（起動テンプレート）provisioning.md
多数のインスタンスを自動スケーリングして実行する方法auto-scaling.md
SSH キーを使わずにインスタンスにアクセス／パッチ適用／管理する方法systems-manager.md

クイックナビゲーション

やりたいこと...参照先
インスタンスタイプ、Graviton と x86 の比較、バースト可能なインスタンスのクレジット、GPU、インスタンスストアと 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）を作成し、それを参照する ASG を --health-check-type ELB とターゲット追跡ポリシー付きで作成します。auto-scaling.md を参照してください。パブリックな入口には、以下のセキュリティ上の考慮事項と auto-scaling.md のロードバランサーに関する注意事項に従って、ロードバランサーをセキュリティ保護してください（TLS/ACM、WAF、セキュリティレスポンスヘッダー）。ロードバランサー自体の構築は aws-networking の担当です。

「フリートに新しい AMI を展開する」 → 新しい起動テンプレートバージョンを作成し、インスタンスリフレッシュを実行します。ロールバックできるよう、数値の起動テンプレートバージョンを指定してください。auto-scaling.md を参照してください。

「踏み台サーバーを使わずにプライベートインスタンスへ接続する」 → インスタンスに SSM の権限（AmazonSSMManagedInstanceCore を持つインスタンスプロファイル、またはアカウントレベルの DHMC）とネットワーク経路を設定してから、セッションマネージャーを使用します。systems-manager.md を参照してください。

「EC2 のコストを削減する」 → 適切なサイズを選び（バースト可能型と固定パフォーマンス型を比較）、アプリが Arm64 に対応している場合は Graviton を使用し、フォールトトレラントなフリートには price-capacity-optimized を指定してスポットインスタンスを利用し、未使用の Elastic IP を解放します。instance-selection.md を参照してください。

トラブルシューティング

症状考えられる原因簡単な修正方法
SSH の「Connection timed out」ネットワーク経路（SG/NACL/ルート/パブリック IP がない）自分の IP からの TCP 22 を許可します。IGW へのルートを確認し、パブリック IP を検証してください。troubleshooting.md を参照してください
SSH の「Connection refused」ホスト側：sshd が停止中、または起動中起動を待ちます。セッションマネージャーまたはシリアルコンソールから sshd とポートを確認してください
InsufficientInstanceCapacityAWS にその AZ で該当タイプのキャパシティがない（クォータではありません）別の AZ／インスタンスタイプを試すか、再試行してください。クォータ引き上げはリクエストしないでください
InstanceLimitExceededvCPU クォータに到達（これはクォータです）インスタンスファミリーの Service Quotas 引き上げをリクエストしてください
ASG が LB のヘルスチェックに失敗したインスタンスを置き換えないヘルスチェックタイプがまだ 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 を開放する必要がなく、キー管理も不要で、セッション API 呼び出しの記録が CloudTrail に残ります。Session Manager のセッションログ記録を有効にして CloudWatch Logs/S3 に保存します（デフォルトでは無効）。これにより、セッション中に実行されたコマンド自体を記録できます。詳しくは systems-manager.md を参照してください。
  • インスタンスプロファイルを使用し、認証情報を埋め込まないでください。ロールの権限は最小限にします。
  • EBS/AMI を暗号化します。暗号化された AMI をアカウント間で共有するには、カスタマー管理の KMS キーで再暗号化します（デフォルトの aws/ebs キーは共有できません）。
  • すべてのリージョンで CloudTrail を有効化して EC2/ASG/SSM API のアクティビティを監査し、機密性の高い操作（セキュリティグループの変更、予期しないプリンシパルによる RunInstances/TerminateInstances）に対してアラームを設定し、不正な変更を検知できるようにします。
  • インターネットに公開する Web フリートでは、ロードバランサーの HTTPS リスナーに ACM 証明書を設定して通信を暗号化し、一般的な Web 攻撃に対する多層防御として AWS WAF を追加します。ロードバランサー/WAF 自体の設定については aws-networking を参照してください。
  • このガイダンスを超えるセキュリティ強化については、AWS EC2 security best practices と、ゲスト OS の CIS ベンチマークを参照してください。

このスキルの対象外

  • ベストプラクティスのデフォルト設定で、単一のインスタンスを起動する → launching-ec2-instance-with-best-practices スキルを使用してください
  • EC2 用の IAM ロール/インスタンスプロファイルを作成する → setting-up-ec2-instance-profiles スキルを使用してください
  • 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

コメント

Markdown 対応