AWS Certified Cloud Practitioner (CLF-C02) #3 Domain 1-2 クラウド設計 — Well-Architected の 6 本柱
#2 でクラウドの価値提案・CAF・グローバルインフラを押さえました。ドメイン 1 の後半として Well-Architected Framework の 6 本柱 を整理します。
Well-Architected は単なるチェックリストではなく、AWS が長年の実務事例から抽出した設計原則の集合 です。CLF-C02 試験ではシナリオが提示され、「このシナリオが強調する柱は何か」または「この柱のベストプラクティスは何か」という形で出題されます。
6 本柱を一目で #
| # | 柱 | 一言定義 | 中心語彙 |
|---|---|---|---|
| 1 | Operational Excellence | システムを運用し、監視し、改善する能力 | 自動化、IaC、CloudFormation、CloudWatch |
| 2 | Security | データ・システム・資産を保護する能力 | IAM、暗号化、最小権限、KMS |
| 3 | Reliability | 意図した機能を正確に遂行し、障害から復旧する能力 | Multi-AZ、バックアップ、Auto Scaling、フェイルオーバー |
| 4 | Performance Efficiency | コンピュートリソースを効率的に使う能力 | 適切なインスタンスタイプ、キャッシュ、スケーリング |
| 5 | Cost Optimization | コスト効率を持続的に維持する能力 | Reserved Instance、Spot、Trusted Advisor |
| 6 | Sustainability | ワークロードの環境影響を最小化 | リソース活用度、効率的なリージョン選択 |
この 6 本の順番は覚える必要がありません。ただし 各柱が捉えようとするトレードオフの軸 は頭に入れておく必要があります。たとえばコスト最適化とパフォーマンス効率はしばしば衝突し、信頼性を高めるとコストが増えます。試験問題は どの柱の視点から正解を選ぶべきか をまず把握する力を問います。
1) Operational Excellence — 運用上の優秀性 #
運用上の優秀性は システムを安定的に運用し、継続的に改善する能力 です。一度きりのセットアップではなく 再現可能なプロセス を作ることに重点を置きます。
設計原則 #
- 運用をコードとして実行する (IaC) — 手動設定ではなく CloudFormation / Terraform のようなコードで
- 小さく頻繁に、戻せる変更を行う — 一度の大きな変更ではなく小さな変更を頻繁に
- 運用手順を頻繁に改善する — Game day のような演習で手順を検証
- 障害を予期し学ぶ — Postmortem 文化
対応サービス #
| サービス | 役割 |
|---|---|
| AWS CloudFormation | IaC、インフラを YAML / JSON コードとして管理 |
| AWS Systems Manager | 運用自動化、Patch Manager・Run Command |
| AWS CloudTrail | API 呼び出しの監査ログ |
| Amazon CloudWatch | メトリクス・ログ・アラーム |
| AWS Config | リソース構成変更の追跡 |
試験の出題パターン #
「手動でインフラを構築しており、環境が一貫しない — どの柱を強調すべきか?」 → Operational Excellence (正解の補助キーワード: IaC、CloudFormation)。
2) Security — セキュリティ #
セキュリティの柱は試験で最もよく出題されます。データ・システム・資産を安全に保つ 能力です。
設計原則 #
- 強力な ID 基盤 (Strong Identity Foundation) — IAM で最小権限、MFA
- すべての層にセキュリティを適用 — VPC・サブネット・インスタンス・アプリの各層に
- 転送中・保存中のデータを暗号化 — TLS / KMS
- イベントに備える — 自動応答の手順
- 人とデータの距離を取る — 人が直接データに触れず、自動化ツールを使う
- 監査の追跡 — CloudTrail、Config
対応サービス #
| サービス | 役割 |
|---|---|
| AWS IAM | ユーザー・ロール・ポリシー |
| AWS KMS | 暗号化キー管理 |
| AWS WAF | Web アプリケーションファイアウォール |
| AWS Shield | DDoS 防御 |
| Amazon GuardDuty | 脅威検出 |
| AWS Secrets Manager | シークレット認証情報の管理 |
試験の出題パターン #
「機密データを S3 に保存しつつセキュリティを強化するには?」 → 保存中の暗号化 (encryption at rest with KMS)。
「VPC 内のインスタンスへ SSH 鍵の代わりに安全なアクセス方法を使いたい」 → AWS Systems Manager Session Manager (Security または Operational Excellence のどちらも正解候補)。
3) Reliability — 信頼性 #
信頼性は システムが意図した動作を正確に行い、障害から自動的に復旧 できる能力です。
設計原則 #
- 復旧手順を自動でテストする — 手動ではなく定期的な自動テスト
- 水平にスケールして可用性を高める — 1 台の大きなサーバーよりも複数の小さなサーバー
- キャパシティの推測をやめる — Auto Scaling で自動調整
- 変更を自動化する — 人為的ミスではなくコードで
対応サービス #
| サービス | 役割 |
|---|---|
| Auto Scaling | 負荷に応じた自動増減 |
| Elastic Load Balancing | 複数インスタンスへの負荷分散 |
| Amazon Route 53 | DNS フェイルオーバー |
| AWS Backup | 統合バックアップ管理 |
| Multi-AZ deployment | RDS・EFS などで可用性を向上 |
| AWS CloudFormation | 災害復旧のためのインフラ再生成 |
試験の出題パターン #
「1 つの AZ がダウンしてもサービスが継続稼働する必要がある」 → Multi-AZ デプロイ (Reliability)。
「トラフィックが予測不能でリソースが不足することがある」 → Auto Scaling (Reliability + Performance Efficiency の両方の候補)。
Reliability vs Performance Efficiency #
この 2 つはよく混同されます。シンプルな区別:
- Reliability — 「障害が起きても動くか?」
- Performance Efficiency — 「リソースを効率的に使えているか?」
同じ Auto Scaling でも、「障害に耐える側面」なら Reliability、「トラフィック増加にコスト効率良く対応する側面」なら Performance Efficiency に分類されます。
4) Performance Efficiency — パフォーマンス効率 #
リソースを 効率的に使ってシステム要件を満たし、技術が進化するにつれてその効率を維持する能力です。
設計原則 #
- 高度な技術の民主化 — 自前で構築せず AWS サービスを活用する (例: Lambda の代わりに自前のコンテナオーケストレーションを構築しない)
- 数分でグローバル展開 — ユーザーに近いリージョンへデプロイ
- サーバーレスを活用 — インフラ運用の負担を AWS に委ねる
- 頻繁に実験する — 適切なインスタンスタイプを定期的に再評価
対応サービス #
| サービス | 役割 |
|---|---|
| Amazon CloudFront | Edge キャッシュで応答時間を短縮 |
| ElastiCache | キャッシュ (Redis / Memcached) |
| AWS Lambda | サーバーレスコンピューティング |
| EC2 インスタンスタイプ選択 | ワークロードに合うファミリー (M・C・R・T) |
試験の出題パターン #
「世界中のユーザーに高速な応答時間を提供するには?」 → CloudFront。
「データベースの応答時間が遅くなった — 頻繁に参照されるデータの性能を高めるには?」 → ElastiCache。
5) Cost Optimization — コスト最適化 #
不要なコストなしで システムを運用する能力です。
設計原則 #
- クラウド財務管理 (Cloud Financial Management) — コストを継続的にモニタリング
- 使用量ベースの消費モデル — 必要な分だけ
- 全体効率の測定 — ビジネス成果に対するコスト
- 差別化されない重い運用負担の排除 — データセンター運用のような部分を AWS に委ねる
- コストを分析・配分 — タグ付けで部門別・プロジェクト別の請求
対応サービス #
| サービス | 役割 |
|---|---|
| AWS Cost Explorer | コスト推移の可視化 |
| AWS Budgets | 予算超過アラート |
| AWS Trusted Advisor | コスト最適化チェック |
| AWS Pricing Calculator | 事前のコスト試算 |
| Cost and Usage Report (CUR) | 詳細な請求データ |
| Savings Plans / Reserved Instances | 1〜3 年契約の割引 |
| Spot Instances | 最大 90% 割引 |
試験の出題パターン #
「開発環境のコストを抑えたい — どの価格モデルが最も適切か?」 → Spot Instances (開発は中断許容)。
「3 年間 EC2 を安定的に運用する予定 — どのモデルが最も安いか?」 → Reserved Instances または Savings Plans (3 年 + All Upfront が最も安い)。
詳しい価格モデルは #8 で扱います。
6) Sustainability — 持続可能性 #
2021 年 12 月に追加された 6 番目の柱 です。ワークロードの 環境影響 (エネルギー使用、炭素排出) を最小化する能力に焦点を当てます。
設計原則 #
- 影響の測定 — ワークロードの環境影響を定量化
- 持続可能性目標の設定 — ビジネス KPI に環境指標を含める
- 活用度の最大化 — リソースの無駄を減らす (小さなインスタンスを多数置くより、適切なサイズの大きなインスタンスを 1 つ)
- ハードウェア効率の追跡 — 新しい EC2 ファミリー (Graviton など) に移行
- マネージドサービスの活用 — AWS の効率的なインフラを使う
- ダウンストリーム影響の削減 — データ転送量を減らす
対応サービス #
| サービス | 役割 |
|---|---|
| AWS Customer Carbon Footprint Tool | ワークロードの炭素排出量を可視化 |
| AWS Graviton インスタンス | ARM ベース、ワットあたり性能に優れる |
| Spot Instances | アイドルリソースの活用 |
| S3 Intelligent-Tiering | 自動階層遷移でリソース効率を高める |
試験の出題パターン #
「クラウド利用に伴う炭素排出を削減するには?」 → Graviton インスタンスへの移行 または アイドルリソースの特定と整理 (Sustainability)。
「既存の EC2 でより少ないリソースで同等の性能を出すには?」 → Right-sizing (Sustainability + Cost Optimization の両方の候補)。
6 本柱のトレードオフ #
柱どうしはしばしば衝突します。試験はこのトレードオフを意識できているかを見ます。
| トレードオフ | 例 |
|---|---|
| Reliability ↔ Cost | Multi-AZ は高価だがより安定 |
| Performance ↔ Cost | 大きなインスタンスは高速だがより高価 |
| Security ↔ Operational Excellence | 強い統制はデプロイ速度を遅くしうる |
| Sustainability ↔ Performance | より小さなインスタンスは環境に優しいが応答が遅くなりうる |
選択肢が 2 つとも正しく見えるときは 問題が強調する柱の視点 で答えを絞り込みます。
Well-Architected Tool #
AWS Well-Architected Tool は、自分のワークロードを 6 本柱の基準で点検する無料サービスです。コンソールでワークロードを登録し、質問票に回答すると改善の推奨事項が出ます。試験では「Well-Architected Tool は何のためのサービスか?」程度のシンプルな問いで出題されます。
Lens — Well-Architected の変形 #
Well-Architected は一般のワークロード向けですが、特定のワークロードタイプ向けの変形 (Lens) も用意されています。
- Serverless Lens — Lambda ベースのワークロード
- SaaS Lens — マルチテナント SaaS
- Machine Learning Lens — ML ワークロード
- Financial Services Lens — 金融サービス
- IoT Lens — IoT ワークロード
試験で Lens が直接出題される頻度は低いですが、「特殊なワークロードに Well-Architected を適用するには?」の選択肢として登場することがあります。
よく出会う落とし穴 #
1) 5 本柱で覚える #
最も多いミスです。6 本 です。2021 年 12 月に Sustainability が追加されました。古い書籍やブログが 5 本のまま記述されていることが多いので注意。
2) Reliability と Availability を同じ語として扱う #
Reliability は システムが意図した動作を正確に行う能力 + 障害復旧 です。Availability (可用性) はその一部 — 利用可能な時間の割合 です。試験で Availability は通常 99.9% のような数値で表現されます。
3) Performance と Reliability の混同 #
先ほど扱った区別を覚えておく:
- Reliability = 「障害が起きても動くか?」
- Performance Efficiency = 「リソースを効率的に使えているか?」
4) 「セキュリティが最優先」という単純な答え #
選択肢に「Security を最優先にする」があるからといって、それが常に正解とは限りません。問題が強調するシナリオ に合わせる必要があります。コストを問う問題でセキュリティを正解に選ぶのは誤答です。
5) Sustainability を無視する #
比重が低く見えてスキップする受験者が多いですが、試験で Sustainability を直接問う問題が 1〜2 問はほぼ必ず出題されます。6 本柱と Carbon Footprint Tool くらいは覚えておきます。
まとめ #
この記事で押さえたこと:
- Well-Architected Framework は 6 本柱 — Operational Excellence / Security / Reliability / Performance Efficiency / Cost Optimization / Sustainability
- 各柱は 設計原則 + 対応サービス + 試験の出題パターン で覚える
- トレードオフ — 1 つの柱を強化すると別の柱が弱まりうる。試験はそのうちどの柱を優先するかを選ばせる
- Well-Architected Tool は、自分のワークロードを 6 本柱の基準で点検するコンソールサービス
- Lens は特殊なワークロード (Serverless・SaaS・ML など) 向けの変形
- 落とし穴 — 5 本柱で覚える / Reliability と Availability の混同 / Performance と Reliability の混同 / Security 最優先の罠 / Sustainability の無視
次へ — Domain 2 セキュリティ #
ドメイン 1 が終わりました。次は 試験比重 30% の最大ドメイン — Security and Compliance です。
#4 Domain 2-1 セキュリティ — 責任共有モデル、IAM の基礎 では、AWS と顧客の責任がどこで分かれるか (サービスモデルによって異なる)、IAM の 4 つのコア (ユーザー・グループ・ロール・ポリシー)、MFA、そして試験で落とし穴としてよく出る root ユーザーの運用ガイドまで整理します。