Well-Architected Framework

AWS Well-Architected Frameworkとは何か？

AWS Well-Architected Frameworkは、クラウドアーキテクトがセキュアで高パフォーマンス・高回復力・高効率なワークロードを構築するのを支援するために、Amazon Web Servicesが策定した公式のベストプラクティス集・設計原則集・レビュー設問集である。AWS Well-Architected Frameworkは、Operational Excellence・Security・Reliability・Performance Efficiency・Cost Optimization・Sustainabilityという6つのWell-Architectedピラーにガイダンスを整理し、アーキテクチャを評価して継続的に改善するための共通語彙を提供する。

CLF-C02受験者にとって、AWS Well-Architected Frameworkはドメイン1タスクステートメント1.2「AWSクラウドの設計原則を特定する」の下で出題される。試験はWell-Architected Reviewを実際に行うことを求めないが、ビジネスシナリオを正しいWell-Architectedピラーに対応させること・6つのWell-Architectedピラーを列挙すること・AWS Well-Architected Frameworkが推進する設計原則を想起することは、確実にテストされる。本章では、すべてのピラー・すべての設計原則・直近のCLF-C02受験者が報告するすべてのシナリオ照合の罠を詳解する。

やさしい解説: Well-Architected Framework

AWSの認定試験が抽象的に感じられる場合、AWS Well-Architected Frameworkを内面化する最も効果的な方法は、3つの日常的な類比を通じることである。AWS Well-Architected Frameworkは購入できる製品ではなく、チェックリストと語彙の集合体であるため、物理世界のシステムと比較することで6つのWell-Architectedピラーがはるかに直感的になる。

類比1 — 保健所の検査チェックリスト

AWS Well-Architected Frameworkを、保健所の検査官が飲食店を訪問する際に持参する衛生検査チェックリストとして考えてほしい。検査官はあなたの代わりに料理はしない。代わりに、食品安全（Security）・冷蔵の信頼性（Reliability）・調理スピード（Performance Efficiency）・食材のコスト管理（Cost Optimization）・厨房のワークフロー（Operational Excellence）・食品廃棄物の削減（Sustainability）をカバーする標準化された評価基準を渡す。6つのWell-Architectedピラーはまさにそれだ。ピラーごとに評価を進め、あなたの「厨房」、すなわちAWSワークロードがプロの基準を満たしているかを確認する6つの評価軸である。

類比2 — 公開されている試験の参考書

AWS Well-Architected Frameworkはまた、自分自身のアーキテクチャのための公開された試験の参考書でもある。AWSは設問を公開しており（それらはWell-Architected Toolの中に「改善設問」として文字通り収録されている）、受験者は自分自身のワークロードについて誠実に回答することが奨励されている。合否判定のある試験とは異なり、AWS Well-Architected Frameworkは継続的な公開参考書レビューであり、毎四半期に参考書を見直し・リスクをHigh/Medium/Noneとしてマークし・反復改善する。これがAWS Well-Architected Frameworkがクラウド文化に適している理由だ。アーキテクチャが進化するにつれて、Well-Architectedピラーの「評点」が向上する。

類比3 — クラウドアーキテクトのためのスイスアーミーナイフ

最後に、AWS Well-Architected Frameworkは6枚の刃を持つスイスアーミーナイフのように機能する。各刃（ピラー）は独立したツールだ。Operational Excellenceは日常業務のためのドライバー、Securityは不正アクセスを防ぐ刃、Reliabilityは障害からの回復のためのバンデージ、Performance Efficiencyは適正サイジングのための定規、Cost Optimizationは予算管理のためのハサミ、Sustainabilityは環境負荷を測るゲージである。すべての作業でナイフのすべての刃が必要なわけではないが、本物のクラウドアーキテクトは常にナイフ全体をポケットに持ち歩く。なぜならワークロードは変化し、昨日のCost Optimizationの問題が明日のReliabilityのインシデントになる可能性があり、AWS Well-Architected Frameworkはその6つすべての関心をカバーする唯一のマルチツールだからである。

中核的な仕組み：6つのWell-Architectedピラーの詳細

AWS Well-Architected Frameworkは、クラウドに関するすべてのガイダンスを6つのWell-Architectedピラーのいずれかに整理している。各ピラーには正式な定義・設計原則（AWSはピラーごとに4〜7の原則を公開）・ベストプラクティスのフォーカス領域・Well-Architected Tool内の改善設問が存在する。CLF-C02試験はこれらのWell-Architectedピラーをコンセプト領域の中で最も重要なものとして扱う。タスク1.2は明示的にAWSの設計原則を特定することに関するものであり、AWS Well-Architected Frameworkはそれらの原則の権威ある情報源である。

ピラー1 — Operational Excellence

定義： AWS Well-Architected FrameworkのOperational Excellenceピラーは、ビジネス価値を提供するためにシステムを運用・監視し、継続的にプロセスと手順を改善することに焦点を当てる。Operational ExcellenceピラーはCLF-C02の設問でReliabilityと最も混同されやすいピラーである。

主な設計原則：

• 運用をコードとして実行する — インフラ・ランブック・手順をバージョン管理されたコードとして扱い、ビジネスに合わせて運用をスケールさせる。AWS CloudFormationがこの原則に対するOperational ExcellenceのサービスとしてCLF-C02で代表的に用いられる。
• 頻繁で小規模かつ可逆的な変更を行う — 影響範囲を縮小し、フィードバックを加速させる。これがAWS Well-Architected Frameworkでブルー/グリーンデプロイとカナリアリリースが推奨される理由である。
• 障害を予期し、運用イベントから学ぶ — 本番前環境に意図的に障害を注入する「ゲームデー」を実施して手順を改善する。

具体的なAWSサービスの例： Amazon CloudWatch（メトリクス・ログ・アラーム・ダッシュボード）とAWS Systems Manager（ランブック・パッチ管理）がCLF-C02におけるOperational Excellenceピラーの代表的なサービスである。

ピラー2 — Security

定義： AWS Well-Architected FrameworkのSecurityピラーは、リスクアセスメントと軽減戦略を通じてビジネス価値を提供しながら、データ・システム・資産を保護する方法を説明する。AWS Well-Architected FrameworkにおけるSecurityはAWS Shared Responsibility Modelの上に位置し、すべてのWell-Architectedピラーにわたって最小権限の原則を強化する。

主な設計原則：

• 強固なアイデンティティ基盤を実装する — 最小権限の原則を適用し、アイデンティティを一元管理し、長期的な認証情報を排除する。
• トレーサビリティを有効にする — AWS CloudTrailですべてのアクションをログ・監査し、Amazon CloudWatchで監視する。
• すべてのレイヤーにセキュリティを適用する — 多層防御：ネットワーク・ホスト・アプリケーション・データ・アイデンティティの各レイヤーに独自の制御を設ける。
• セキュリティのベストプラクティスを自動化する — セキュリティ制御をコード化してCI/CDパイプラインに組み込む。
• 転送中および保存中のデータを保護する — 転送には TLS、保存にはAWS KMSとS3のデフォルト暗号化を使用する。

具体的なAWSサービスの例： AWS IAM・AWS KMS・Amazon GuardDuty・AWS Security Hubが組み合わさって、AWS Well-Architected FrameworkのSecurityピラーを体現している。

ピラー3 — Reliability

定義： AWS Well-Architected FrameworkのReliabilityピラーは、インフラまたはサービスの中断から回復する能力を含め、ワークロードが期待される時に正しく一貫して機能を実行する能力に焦点を当てる。Reliabilityは、試験作成者がPerformance Efficiencyと対比させるのが好きなWell-Architectedピラーである。

主な設計原則：

• 自動的に障害から回復する — ヘルスチェック・自動フェイルオーバー・自己修復アーキテクチャ。「自動的に回復する」はCLF-C02のReliabilityピラーに関するシナリオ設問のキーワード第1位である。
• 回復手順をテストする — 従来のITではフェイルオーバーのテストは稀だったが、AWSではスケジュールに従ってテストする。Amazon Route 53ヘルスチェックとElastic Load Balancingがこれを日常的なものにする。
• 水平スケールでワークロードの総合的な可用性を高める — 単一の大きなリソースを複数の小さなリソースで置き換え、1つの障害でワークロード全体が停止しないようにする。
• 容量の見積もりをやめる — AWS Well-Architected Frameworkは、キャパシティ不足がReliabilityインシデントを引き起こすことを教える。クラウドのエラスティシティがその解決策である。
• 変更を自動化で管理する — 本番環境への手動変更を避ける。

具体的なAWSサービスの例： Amazon Route 53（ヘルスチェックつきDNSフェイルオーバー）・Amazon RDS Multi-AZ・AWS Auto Scaling・AWS BackupがすべてReliabilityピラーを体現している。

ピラー4 — Performance Efficiency

定義： AWS Well-Architected FrameworkのPerformance Efficiencyピラーは、システム要件を満たすためにコンピューティングリソースを効率的に使用し、需要の変化と技術の進化に合わせて効率性を維持することに焦点を当てる。このWell-Architectedピラーは適切な種類とサイズのリソースを使用することに関するものであり、CLF-C02が頻繁にCost Optimizationと対比させる罠を設ける理由でもある。

主な設計原則：

• 高度な技術を民主化する — ゼロから構築する代わりに、マネージドサービス（Amazon Aurora・Amazon Bedrock・Amazon SageMaker）を消費する。
• 数分でグローバル展開する — Amazon CloudFront・AWS Global Accelerator・Amazon Route 53レイテンシーベースルーティングを使用して、数クリックで複数のAWS Regionにデプロイする。
• サーバーレスアーキテクチャを使用する — AWS Lambda・AWS Fargate・Amazon DynamoDBはサーバーを管理する必要をなくし、チームがビジネスロジックに集中できるようにする。
• より頻繁に実験する — クラウドエコノミクスにより、新しいインスタンスタイプやストレージクラスのA/Bテストが安価になり、AWS Well-Architected Frameworkのデータ駆動の意思決定原則をサポートする。
• メカニカルシンパシーを考慮する — 達成しようとしていること（例：汎用型の代わりに目的別データベース）に最も適した技術的アプローチを使用する。

具体的なAWSサービスの例： AWS Auto Scaling・AWS Lambda・Amazon CloudFront・「適切なストレージサービスを選択する」パターン（S3 vs EBS vs EFS）がすべてAWS Well-Architected FrameworkのPerformance Efficiencyピラーを体現している。

ピラー5 — Cost Optimization

定義： AWS Well-Architected FrameworkのCost Optimizationピラーは、ビジネス価値を最大化しながら不必要なコストを避け、時間の経過とともに支出を把握し、資金配分を管理することに焦点を当てる。Cost OptimizationはPerformance Efficiencyとは別物である — 試験のためにこれを覚えておくこと。

主な設計原則：

• クラウド財務管理を実装する — 組織内にFinOpsのチームまたは機能を設置する。
• 消費モデルを採用する — ピークキャパシティではなく、使用した分だけ支払う。
• 全体的な効率性を測定する — 支出に対するビジネスアウトプットを追跡する。
• 差別化されない重労働への支出をやめる — データセンターの運営・データベースパッチ・サーバーのラッキングをAWSに任せ、チームが顧客価値に集中できるようにする。
• 支出を分析・帰属させる — コスト配分タグ・AWS Cost Explorer・AWS Budgetsにより支出を可視化する。

具体的なAWSサービスの例： AWS Cost Explorer・AWS Budgets・AWS Trusted Advisorのコスト最適化チェック・Savings Plans・Reserved InstancesがすべてAWS Well-Architected FrameworkのCost Optimizationピラーの体現である。

ピラー6 — Sustainability（2021年11月追加）

定義： AWS Well-Architected FrameworkのSustainabilityピラーは、クラウドワークロードの運用が環境に与える影響を最小化することに焦点を当てる。Sustainabilityは2021年のAWS re:InventでAWSが追加した最新のWell-Architectedピラーであり、調査結果によれば2025〜2026年のCLF-C02試験での出題頻度が増加している。

主な設計原則：

• 自分の影響を理解する — AWS Customer Carbon Footprint Toolを使用してワークロードのカーボンフットプリントを測定する。
• サステナビリティの目標を設定する — ビジネスアウトプット単位あたりの長期削減目標（例：ユーザーセッションあたりのCO2e）を設定する。
• 使用率を最大化する — インスタンスを適正サイジングする。遊休サーバーも電力を消費する。ワークロードをより少ない、より高稼働のホストに統合する。
• より効率的な新しいハードウェアとソフトウェアの提供を予期・採用する — AWS Graviton（ARMベース）インスタンス・新しいEC2世代・より効率的にインフラを共有するマネージドサービスにアップグレードする。
• マネージドサービスを使用する — AWSは単一の顧客が実現できないスケール効率で運営している。
• クラウドワークロードのダウンストリームへの影響を削減する — データ転送を最適化し・Amazon CloudFront経由で積極的にキャッシュし・クライアントデバイスのエネルギー使用量を削減する。

具体的なAWSサービスの例： AWS Graviton搭載インスタンス・AWS Customer Carbon Footprint Tool・サーバーレスオプション（AWS Lambda・AWS Fargate）がAWS Well-Architected FrameworkのSustainabilityピラーにおける代表的なサービスである。

AWSクラウドの設計原則（CLF-C02タスク1.2）

CLF-C02タスクステートメント1.2は明確に「AWSクラウドの設計原則を特定せよ」と求めている。これらは、6つのWell-Architectedピラーのどれに焦点を当てているかに関わらず、AWS Well-Architected Frameworkが推進する横断的な原則である。これら6つを暗記すること。ドメイン1だけでなく試験全体でひっかけの選択肢として登場する。

原則1 — キャパシティニーズの推測をやめる

オンプレミスの世界では、1年前にどれだけのキャパシティをプロビジョニングすべきかを推測する必要があった。AWSクラウドでは、現在必要なものをプロビジョニングし、AWS Auto Scalingまたはサーバーレスコンピューティングを使用して数分でスケールアップ（またはダウン）できる。キャパシティの推測をやめることは、最も頻繁に引用されるAWS Well-Architected Frameworkの設計原則の一つであり、ReliabilityとCost Optimization両方のWell-Architectedピラーに直接結びついている。

原則2 — 本番規模でシステムをテストする

AWS Well-Architected Frameworkの時代以前は、本番規模での負荷テストは財政的に不可能だった。AWSでは、本番規模のテスト環境を数時間起動し・テストを実行し・終了させることができる。これによりReliabilityの信頼度が低コストで大幅に向上する。

原則3 — アーキテクチャの実験をより容易にするために自動化する

自動化 — AWS CloudFormation・AWS CDK・AWS Systems Manager経由の — はアーキテクチャの変更を安価で安全に実験できるものにする。AWS Well-Architected Frameworkは自動化を他のすべてのWell-Architectedピラーの実現手段として位置づけている。

原則4 — 進化するアーキテクチャを許容する

従来のアーキテクチャはデザインを完成した成果物として扱った。AWS Well-Architected Frameworkはアーキテクチャを継続的に進化するものとして扱う。Well-Architected Toolはワークロードを定期的に再レビューして進化させるのを支援する。

原則5 — データを使ってアーキテクチャを推進する

Amazon CloudWatch・AWS X-Ray・AWS Cost Explorer・AWS Trusted Advisorを活用し、データがアーキテクチャの意思決定を導くようにする。意見主導のアーキテクチャはAWS Well-Architected Frameworkの対極にある。

原則6 — ゲームデーを通じて改善する

「ゲームデー」とは、障害またはトラフィックスパイクを意図的にスケジュールしたシミュレーションである。AWS Well-Architected Frameworkはゲームデーを第一級のReliabilityプラクティスとして扱う。回復手順をテストし・システムにカオスエンジニアリングを適用し・弱点がどこに潜んでいるかを学ぶ。

主な利用場面：Well-Architected Reviewのプロセス

AWS Well-Architected Frameworkは、Well-Architected Reviewと呼ばれるプロセスを通じて提供され、AWSマネジメントコンソールの無料のAWS Well-Architected Toolがそれを支援する。Well-Architected Reviewにより、6つのWell-Architectedピラーが理論から実際のワークロードを形成するものへと変わる。

ステップ1 — ワークロードのスコープを定義する

ワークロード（例：「顧客向けEコマースのチェックアウトサービス」）とそのAWS Regionを選択する。AWS Well-Architected Frameworkはアカウントや組織レベルではなく、ワークロードレベルで機能する。

ステップ2 — ピラーの設問を進める

6つのWell-Architectedピラーのそれぞれについて、Well-Architected Toolは一連の改善設問を提示する。「Xは行っているが、Yは行っていない」と誠実に回答し、AWS Well-Architected Frameworkはその回答をリスクにマッピングする。

ステップ3 — 高リスク問題（HRI）と中リスク問題（MRI）を特定する

AWS Well-Architected Toolはギャップを高リスク・中リスク・なしとしてラベルづけする。高リスク問題を最優先に処置する。各HRIはAWS Well-Architected Frameworkのホワイトペーパーの改善策を説明するセクションにリンクしている。

ステップ4 — 改善計画を作成する

Well-Architected Toolはマイルストーンベースの改善計画を作成する。HRIを最初に修正し・各マイルストーンでワークロードを再レビューし・6つのWell-Architectedピラー全体の改善を時間をかけて追跡する。

ステップ5 — AWS Well-Architected Lensを適用する

AWS Well-Architected Frameworkのコアは汎用的だが、AWSはまたWell-Architected Lens — Serverless・SaaS・IoT・機械学習・データ分析・金融サービスなどのドメイン固有のオーバーレイ — も公開している。各Lensはそのドメインに関連する追加のピラー設問を加える。CLF-C02はLensの内容を深くテストしないが、コンセプトに言及することがある。

ピラー対ピラー：混同しやすいペアの解説

シナリオ照合はCLF-C02のWell-Architected Framework設問において罠の第1位である。6つのWell-Architectedピラーの名前を暗記した受験者でも、2つのWell-Architectedピラーが似て聞こえるためにシナリオ設問の20〜30%を取り逃がす。以下のH2セクションでは、最も混同されやすいピラーのペアを1つずつ解説する。

Operational Excellence vs Reliability

これはCLF-C02で最も混同されるピラーのペアであり、コミュニティデータによって確認されている。

• Operational Excellence = プロセスの運営と改善。 日々のワークロード運営においてチームがどれだけうまく機能しているかに関する。ランブック・デプロイメントパイプライン・監視ダッシュボード・インシデント事後レビュー。キーワードは「運用を改善する」。
• Reliability = ワークロードが障害から回復すること。 ワークロード自体が元に戻ることに関する。Multi-AZフェイルオーバー・自動リトライ・ヘルスチェック駆動のDNS・バックアップ。キーワードは「回復する」または「障害に耐える」。

シナリオテスト： 「アプリケーションが1つのAZ障害時に正常なAvailability Zoneへ自動的にトラフィックを転送する」→ Reliabilityピラー（ワークロード自体が回復する）。対照： 「チームがCloudFormationを介してインフラ変更をロールバック付きで自動デプロイする」→ Operational Excellenceピラー（プロセスが自動化されている）。

Cost Optimization vs Performance Efficiency

これは2番目に混同されやすいWell-Architectedピラーのペアである。

• Cost Optimization = 要件を満たしながらできる限り低コストで支払う。 キーワードは「コストを最小化する」「無駄を避ける」「使用した分だけ支払う」。サービス：AWS Cost Explorer・Savings Plans・Reserved Instances。
• Performance Efficiency = 仕事に対して適切なリソースの種類とサイズを使用する。 キーワードは「適正サイジング」「サーバーレス」「レイテンシ」「マネージドサービス」。サービス：AWS Lambda・CloudFront・Auto Scaling。

シナリオテスト： 「チームが未使用のCPUへの支払いを避けるためにEC2インスタンスを適正サイジングする」→ 一見両方に見えるが、試験作成者は通常「支払いを避ける」というフレーミングを強調するためCost Optimizationを意図している。フレーミングが「最適なスループットのために正しいインスタンスファミリーに合わせる」であれば、答えはPerformance Efficiencyとなる。

Security vs Reliability

• Security = 悪意のある行為者と不正アクセスに対して保護する。 キーワード：暗号化・最小権限・IAM・コンプライアンス。
• Reliability = 偶発的な障害とキャパシティイベントに対して保護する。 キーワード：Multi-AZ・Auto Scaling・バックアップ・ディザスタリカバリ。

ランサムウェア攻撃は両方のWell-Architectedピラーを引き起こすが、予防制御はSecurityに、回復制御はReliabilityに位置する。

Sustainability vs Cost Optimization

両方のWell-Architectedピラーは適正サイジングとマネージドサービスを推奨するが、最適化する目的が異なる。

• Sustainability = 環境への影響を最小化する（ビジネスアウトプットあたりのCO2e）。
• Cost Optimization = ビジネスアウトプットあたりのコストを最小化する。

両者は整合しているが同一ではない。Gravitonベースのインスタンスは両方で優位になることが多いが、一部のCost Optimizationの戦術（例：古いインスタンスファミリーを100%稼働率で運用する）は、新世代と比較してハードウェアのエネルギー効率が低い場合にSustainabilityの観点からはマイナスになりうる。

深掘り：Sustainabilityピラー — CLF-C02で増加する出題対象

Sustainabilityピラーは独自のH2を設けて解説に値する。調査結果によれば、テキストブックでの扱いに比べて最近のCLF-C02練習試験において不均衡に多く出題されているからだ。旧来のCLF-C01の教材で学習した受験者が最もリスクにさらされている。

CLF-C02でSustainabilityが重要な理由

AWSは2021年11月にAWS Well-Architected FrameworkにSustainabilityピラーを追加した。CLF-C02が2023年9月に始まって以来、試験ブループリントは明示的に6ピラー版のAWS Well-Architected Frameworkを含んでいる。5つのWell-Architectedピラーしか言及しない古い教材は、複数のコミュニティの合格報告書で記録されている既知の罠である。

Sustainabilityピラーの主な設計原則

AWS Well-Architected FrameworkのSustainabilityピラーが推進する原則：

1. 自分の影響を理解する — AWS Customer Carbon Footprint ToolでCO2eを測定する。
2. サステナビリティの目標を設定する — 長期的なユニットあたりの削減目標を設定する。
3. 使用率を最大化する — 遊休EC2インスタンスも電力を消費する。ワークロードを統合する。
4. より効率的なハードウェアとソフトウェアを予期・採用する — Gravitonプロセッサ・新しい世代・効率的なストレージクラス。
5. マネージドサービスを使用する — AWSは単一の顧客が実現できないより高い使用率でスケールを達成する。
6. ダウンストリームへの影響を削減する — Edgeでキャッシュする（CloudFront）・圧縮する・クライアントデバイスの作業を削減する。

SustainabilityピラーをサポートするAWSサービス

• AWS Gravitonプロセッサ — 同等のx86インスタンスと比較して最大60%優れたエネルギー効率を持つARMベースのEC2インスタンス。
• AWS Customer Carbon Footprint Tool — AWS使用量に起因する過去のCO2eを示す請求コンソールの無料ツール。
• AWS LambdaとAWS Fargate — 遊休インフラを排除する、使用量に応じた支払いのサーバーレス。
• Amazon S3 Intelligent-TieringとGlacier — コールドデータをより低エネルギーのティアに移動する。
• Amazon CloudFront — Edgeロケーションでキャッシュしてオリジンサーバーの負荷を削減する。

暗記すべき数字と事実

CLF-C02では、これらのAWS Well-Architected Frameworkに関する事実を暗記すること。穴埋め問題のひっかけとして登場する。

• 6つのWell-Architectedピラー（5つでも7つでもない）：Operational Excellence・Security・Reliability・Performance Efficiency・Cost Optimization・Sustainability。
• AWSクラウドの6つの一般設計原則：キャパシティの推測をやめる・本番規模でテストする・自動化する・アーキテクチャを進化させる・データ駆動・ゲームデー。
• Sustainabilityピラーは2021年11月にAWS re:Inventで追加された。
• AWS Well-Architected Toolは無料であり、すべてのAWSアカウントで利用可能。
• Well-Architected LensはServerless・SaaS・IoT・機械学習・データ分析・金融サービス向けに存在する。
• AWS Well-Architected Frameworkホワイトペーパーが正規の情報源：https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
• リスクは高リスク（HRI）・中リスク（MRI）・なしとして分類される。

CLF-C02試験での頻出の罠

AWS Well-Architected Frameworkはピラー名が複数のシナリオでもっともらしく聞こえるため、試験の罠の温床となっている。以下は最近のCLF-C02受験者が報告する最も高頻度の罠である。

罠1 — 6つではなく5つのWell-Architectedピラーを列挙する

古いCLF-C01の教材は5つのWell-Architectedピラーを記載している。CLF-C02は6つを求める。Sustainabilityを省略している答えは誤りである。

罠2 — 「自動的に障害から回復する」をOperational Excellenceにマッピングする

「自動的に障害から回復する」はReliabilityピラーに属し、Operational Excellenceではない。Operational Excellenceはシステムを運営することに関し、Reliabilityはシステムがサバイバルすることに関する。

罠3 — Cost OptimizationとPerformance Efficiencyの混同

コストのための適正サイジング = Cost Optimization。スループット/レイテンシのための適正サイジング = Performance Efficiency。シナリオの問題文を注意深く読むこと。

罠4 — AWS Well-Architected Frameworkを有料のサービスとして扱う

AWS Well-Architected Frameworkは無料のホワイトペーパーであり、AWS Well-Architected Toolは無料のコンソール機能である。CLF-C02の複数の練習問題では、Businessプランのサポートやライセンスがあるかのようなひっかけの選択肢が含まれている。

罠5 — 「Well-Architected Framework」と「AWS Cloud Adoption Framework (CAF)」の混同

AWS Well-Architected Framework = ワークロードレベルの設計ベストプラクティス（6つのWell-Architectedピラー、技術的なフォーカス）。AWS Cloud Adoption Framework (CAF) = 組織レベルの採用戦略（6つのCAFパースペクティブ：Business・People・Governance・Platform・Security・Operations）。両方に「6つの何か」がある — それがまさに罠だ。

罠6 — スケーラビリティ・エラスティシティ・アジリティをピラーと呼ぶ

これらはAWSクラウドのメリットであり、Well-Architectedピラーではない。「スケーラビリティ」や「エラスティシティ」をピラーの選択肢として提示するCLF-C02の設問は、それをひっかけとして使用している。

罠7 — Well-Architected Toolが問題を自動的に修正すると仮定する

Well-Architected Toolはリスクを特定するものであり、自動的に改善するものではない。顧客は引き続き改善計画を所有する。

類似コンセプトとの対比

AWS Well-Architected Framework vs AWS Cloud Adoption Framework (CAF)

AWS Well-Architected Framework vs AWS Service Catalog

AWS Service Catalogにより管理者は事前承認済みの製品テンプレートを公開できる。これは提供の仕組みであり、設計哲学ではない。AWS Well-Architected Frameworkは Service Catalogの製品に何を入れるかを情報提供するかもしれないが、それらは全く異なるツールである。

AWS Well-Architected Framework vs AWS Trusted Advisor

AWS Trusted Advisorは自動リアルタイムチェックエンジン（セキュリティ・コスト・耐障害性・サービス制限・パフォーマンス）である。AWS Well-Architected Frameworkは人間主導のアーキテクチャレビュープロセスである。両者は相互補完的である。Trusted Advisorが戦術的な問題を見つけ、AWS Well-Architected Frameworkが戦略的な問題を見つける。

AWS Well-Architected Framework vs AWS Architecture Center

AWS Architecture Centerはリファレンスアーキテクチャとダイアグラムのギャラリーである。AWS Well-Architected Frameworkはあらゆるアーキテクチャに適用する原則の集合体である。一方はギャラリーであり、他方は評価基準である。

練習設問のパターン（タスク1.2試験との対応）

CLF-C02タスク1.2のWell-Architected Framework設問は以下のパターンに従うことを想定しておく。

パターンA — ピラーとシナリオの照合

「企業がインフラ障害から自動的に回復したい。どのWell-Architectedピラーが適用されるか？」→ Reliability。

「企業がクラウドのカーボンエミッションを削減したい。どのWell-Architectedピラーが適用されるか？」→ Sustainability。

「企業が各ワークロードに最も適切なデータベーステクノロジーを使用したい。どのWell-Architectedピラーが適用されるか？」→ Performance Efficiency。

「企業がランブックにインフラストラクチャ・アズ・コードを実装したい。どのWell-Architectedピラーが適用されるか？」→ Operational Excellence。

パターンB — 設計原則の特定

「どのAWSクラウド設計原則が、ローンチ前にフルスケールのテスト環境を起動することを奨励するか？」→ 本番規模でシステムをテストする。

「どのAWSクラウド設計原則が、リハーサルで意図的に障害を注入することに関するか？」→ ゲームデーを通じて改善する。

パターンC — ピラーの数のひっかけ

「AWS Well-Architected Frameworkには何個のピラーがあるか？」→ 6つ。誤った答えは4・5・7を含む。

パターンD — ピラー名のひっかけ

選択肢に「スケーラビリティ」「エラスティシティ」「アジリティ」が偽のピラー名として含まれることがある。これらはAWSクラウドのメリットであり、Well-Architectedピラーではない。

参考資料と公式リファレンス

• AWS Well-Architected Frameworkホワイトペーパー — 6つのWell-Architectedピラーすべての正規の情報源。
• Sustainabilityピラーホワイトペーパー — 第6のWell-Architectedピラーの詳細解説。
• AWS Well-Architected Tool — Well-Architected Reviewを実施するための無料のコンソールツール。
• AWS Well-Architected Lens — ドメイン固有のオーバーレイ。
• AWS CLF-C02試験ガイド — タスクステートメント1.2がAWS Well-Architected Frameworkを参照している。

FAQ — Well-Architected Framework よくある質問

Q1. 2026年現在、AWS Well-Architected Frameworkには何個のピラーがあるか？

AWS Well-Architected Frameworkには6つのWell-Architectedピラーがある：Operational Excellence・Security・Reliability・Performance Efficiency・Cost Optimization・Sustainability。Sustainabilityピラーは2021年11月に追加され、CLF-C02の試験範囲に完全に含まれている。

Q2. AWS Well-Architected FrameworkとAWS Cloud Adoption Frameworkの違いは何か？

AWS Well-Architected Frameworkは6つのWell-Architectedピラーに整理されたワークロードレベルの技術的なベストプラクティスのセットである。AWS Cloud Adoption Framework (CAF)は6つのパースペクティブ（Business・People・Governance・Platform・Security・Operations）に整理された組織レベルの採用戦略である。両方に6つのカテゴリがある — 混同しないこと。

Q3. AWS Well-Architected Toolは無料で使えるか？

はい。AWS Well-Architected Toolは無料であり、サポートプランに関係なくすべてのAWSアカウントのAWSマネジメントコンソールで利用できる。料金なしで何度でもWell-Architected Reviewを実施できる。

Q4. 「自動的に障害から回復する」をカバーするのはどのWell-Architectedピラーか？

Reliabilityピラーが障害の自動回復をカバーする。「自動的に」が運用的に聞こえるためOperational Excellenceを誤って選ぶ受験者がいるが、AWS Well-Architected Frameworkは明確に障害回復をReliabilityに割り当てている。

Q5. CLF-C02タスク1.2でテストされるAWSクラウドの設計原則は何か？

AWSクラウドの6つの一般設計原則：（1）キャパシティの推測をやめる、（2）本番規模でシステムをテストする、（3）実験をより容易にするために自動化する、（4）進化するアーキテクチャを許容する、（5）データを使ってアーキテクチャを推進する、（6）ゲームデーを通じて改善する。これらの原則がすべての6つのWell-Architectedピラーを支えている。

Q6. ワークロードはどのくらいの頻度でWell-Architected Reviewを受けるべきか？

AWSは少なくとも年1回、そしてワークロードが大きな変更（新しいRegion・主要な機能リリース・アーキテクチャのリファクタリング）を受けるたびにWell-Architected Reviewを実施することを推奨している。多くの組織は重要なワークロードについて四半期ごとにWell-Architected Reviewを実施している。

Q7. CLF-C02のためにSustainabilityを学習する価値はあるか？

ある。AWS Well-Architected FrameworkのSustainabilityピラーは、コミュニティから報告される設問シグナルに基づいて出題頻度が上昇している試験のターゲットである。6つの設計原則を暗記し、AWS Graviton・Lambda・Fargate・AWS Customer Carbon Footprint Toolがその代表的なサービスであることを把握しておくこと。

まとめ

AWS Well-Architected Frameworkは、CLF-C02ドメイン1タスク1.2において最も重要なアーキテクチャのコンセプトである。6つのWell-Architectedピラー（Operational Excellence・Security・Reliability・Performance Efficiency・Cost Optimization・Sustainability）・それぞれの設計原則・AWSクラウドの一般設計原則を把握し、何よりも混同しやすいピラーのペアに対するシナリオ照合を練習すること。AWS Well-Architected Frameworkは、シナリオの問題文を読み・限定的なキーワードを見つけ・二の足を踏まずに正しいWell-Architectedピラーを選べる受験者に報いる。