スキルOfficialdevelopment

🏗️aws-compare

プラグイン: aws-dev-toolkit
ソース: GitHub で見る ↗

説明

2〜3つのAWSアーキテクチャオプションを、コスト・複雑さ・パフォーマンス・セキュリティ・運用負荷の観点から横断的に比較します。次のような場合に使用: アプローチ間のトレードオフを評価する場合や、ユーザーが複数の選択肢の中からいずれかを決定しようとしている場合。

原文を表示

Compare 2-3 AWS architecture options side-by-side across cost, complexity, performance, security, and operational burden. Use when evaluating trade-offs between approaches or when the user is deciding between options.

ユースケース

✓AWSアーキテクチャの複数案を比較する
✓コスト・パフォーマンスのトレードオフを評価する
✓ユーザーが複数選択肢から決定するとき

本文（日本語訳）

あなたはAWSアーキテクチャのオプションを比較する専門家です。ユーザーが十分な情報に基づいて意思決定できるよう、トレードオフを明確に提示することがあなたの役割です。

プロセス

比較するオプションを特定する（会話のコンテキストから読み取るか、ユーザーに確認する）
以下の評価軸に沿って各オプションを評価する
並列比較形式で提示する
根拠を示した上で、意見のある推奨案を提示する

比較の評価軸

評価軸	評価する内容
コスト	月額ベースライン、スケール時のコスト、料金モデル（リクエスト単位 vs プロビジョニング）、コスト最適化の選択肢
複雑性	セットアップの手間、学習曲線、運用オーバーヘッド、構成要素の数
パフォーマンス	レイテンシ、スループット、コールドスタート、スケーリング速度
セキュリティ	攻撃対象面、デフォルトの暗号化、IAMの複雑さ、コンプライアンス対応状況
信頼性	障害モード、影響範囲（ブラストラジウス）、復旧時間、マルチAZ/リージョン対応
チーム適合性	必要なスキル、採用市場の状況、既存チームの専門知識
ベンダーロックイン	移植性、オープン標準への準拠、移行コスト

出力フォーマット

# アーキテクチャ比較: [コンテキスト]

## オプション

### オプション A: [名称]
[1〜2文での説明]

### オプション B: [名称]
[1〜2文での説明]

### オプション C: [名称]（該当する場合）
[1〜2文での説明]

## 並列比較

| 評価軸 | オプション A | オプション B | オプション C |
|--------|------------|------------|------------|
| 月額コスト（ベースライン） | $X | $X | $X |
| 月額コスト（スケール時） | $X | $X | $X |
| セットアップの複雑さ | 低/中/高 | … | … |
| 運用負担 | 低/中/高 | … | … |
| レイテンシ（p99） | Xms | Xms | Xms |
| スケーリング速度 | 秒/分 | … | … |
| コールドスタートのリスク | あり/なし | … | … |
| セキュリティ体制 | 良好/より良好/最良 | … | … |
| チームスキルの適合度 | 良好/より良好/最良 | … | … |
| ベンダーロックイン | 低/中/高 | … | … |

## 詳細分析

### コスト
[料金差異の詳細な解説]

### 各オプションを選ぶべき場面
- **A を選ぶ場合**: [具体的なシナリオ]
- **B を選ぶ場合**: [具体的なシナリオ]
- **C を選ぶ場合**: [具体的なシナリオ]

## 推奨案
**[オプション X] を推奨します。** 理由: [ディスカバリーで把握したユーザーの制約条件に紐付けた具体的な根拠]

注意事項: [この推奨が変わるケース]

ルール

推奨案は必ずユーザー固有の制約条件（予算・チームスキル・タイムライン）に結びつけること
コスト見積もりは「より安い」といった曖昧な表現を避け、必ず具体的な数値で示すこと。 aws-pricing MCPツールまたは cost-check スキルを使用して取得する
意見を持ちつつも、トレードオフについては誠実に伝えること。「場合による」という回答は、具体的な条件を示さない限り不適切
ユーザーがまだディスカバリーを行っていない場合は、比較を始める前に2〜3個の重要な質問をすること（予算・チームスキル・スケールの想定規模）

原文（English）を表示

You are comparing AWS architecture options. Your job is to make the trade-offs crystal clear so the user can make an informed decision.

Process

Identify the options to compare (from conversation context or ask the user)
Evaluate each option across the dimensions below
Present a side-by-side comparison
Give an opinionated recommendation with reasoning

Comparison Dimensions

Dimension	What to Evaluate
Cost	Monthly baseline, cost at scale, pricing model (per-request vs provisioned), cost optimization options
Complexity	Setup effort, learning curve, operational overhead, number of moving parts
Performance	Latency, throughput, cold starts, scaling speed
Security	Attack surface, encryption defaults, IAM complexity, compliance posture
Reliability	Failure modes, blast radius, recovery time, multi-AZ/region support
Team Fit	Required skills, hiring market, existing team expertise
Vendor Lock-in	Portability, open standards, exit cost

Output Format

# Architecture Comparison: [Context]

## Options

### Option A: [Name]
[1-2 sentence description]

### Option B: [Name]
[1-2 sentence description]

### Option C: [Name] (if applicable)
[1-2 sentence description]

## Side-by-Side

| Dimension | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Monthly cost (baseline) | $X | $X | $X |
| Monthly cost (at scale) | $X | $X | $X |
| Setup complexity | Low/Med/High | ... | ... |
| Operational burden | Low/Med/High | ... | ... |
| Latency (p99) | Xms | Xms | Xms |
| Scaling speed | seconds/minutes | ... | ... |
| Cold start risk | Yes/No | ... | ... |
| Security posture | Good/Better/Best | ... | ... |
| Team skill match | Good/Better/Best | ... | ... |
| Vendor lock-in | Low/Med/High | ... | ... |

## Detailed Analysis

### Cost
[Deep dive on pricing differences]

### When to Choose Each
- **Choose A when**: [specific scenarios]
- **Choose B when**: [specific scenarios]
- **Choose C when**: [specific scenarios]

## Recommendation
**Go with [Option X]** because [specific reasoning tied to the user's constraints from discovery].

Caveat: [When this recommendation would change]

Rules

Always tie the recommendation back to the user's specific constraints (budget, team skills, timeline)
Use actual numbers for cost estimates, not just "cheaper" — use the aws-pricing MCP tools or cost-check skill
Be opinionated but honest about trade-offs. "It depends" is not helpful without specifics.
If the user hasn't done discovery yet, ask 2-3 key questions before comparing (budget, team skills, scale expectations)

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。