はじめに
本記事は、AWS Certified Cloud Practitioner（CLF-C02）の学習に際して筆者が間違えやすい・混同しやすいなと感じた箇所を、試験要綱のジャンルごとに整理していく連載の第1回です。今回のテーマは要綱の ドメイン1「クラウドの概念」 です。
CLF はサービス名を広く浅く問われますが、実際に失点しやすいのは「知らない用語」より「似ているけど違う用語の取り違え」だと感じています。筆者自身も学習中、弾力性とスケーラビリティ、可用性と耐久性、CAF と Well-Architected といったペアを何度も混同しました。本記事ではこの手の「ひっかけポイント」を、AWS の一次情報ベースで対比形式にまとめます。
対象読者は、これから CLF を受けるエンジニア・インフラ初学者です。各項目は「混同しやすいポイント → 正しい理解 → ひっかけ例」の順で進めます。
1. スケーラビリティ と 弾力性（Elasticity）
最初の関門がこのペアです。どちらも「需要に応じてリソースを増やせる」イメージで語られるため混同しがちです。
- スケーラビリティ（拡張性）：需要の増加に対してリソースを拡張できる能力そのもの。垂直スケール（インスタンスを大きくする）と水平スケール（台数を増やす）がある。
- 弾力性（Elasticity）：需要の増減に合わせてリソースを自動的に増やしたり減らしたりすること。クラウドならではの特性で、Auto Scaling が代表例。
ポイントは「弾力性は『減らせる』『自動』までを含む」ことです。スケーラビリティが「増やせる土台」なら、弾力性は「需要に追従して自動で増減する運用」と捉えると区別しやすくなります。
ひっかけ例：「アクセスが急増・急減するワークロードに対し、リソースを自動で増減させる特性」は 弾力性。単に「将来の負荷増に備えてリソースを足せること」はスケーラビリティ寄り。
2. 可用性（Availability） と 耐久性（Durability）
S3 の説明で必ず出てくるペアで、数字まで含めて取り違えやすいです。
- 可用性（Availability）：システムやデータにアクセスできる時間の割合。「落ちていない度合い」。例：99.99% など。
- 耐久性（Durability）：保存したデータが失われない度合い。「消えない度合い」。S3 標準は 99.999999999%（イレブンナイン） の耐久性を掲げる。
「イレブンナイン（9が11個）は耐久性の話であって、可用性ではない」というのが頻出のひっかけです。可用性は「いつでも読み書きできるか」、耐久性は「保存したものが残っているか」と、評価している対象が違う点を押さえます。
3. リージョン / アベイラビリティーゾーン / エッジロケーション
グローバルインフラの3階層も、粒度を取り違えやすい代表格です。
- リージョン：地理的に分離された領域。複数の AZ で構成される。
- アベイラビリティーゾーン（AZ）：1つ以上のデータセンターのまとまり。AZ をまたいで配置することで高可用性を確保する。
- エッジロケーション：CloudFront などがコンテンツをユーザーの近くから配信するための拠点。数はリージョンや AZ よりはるかに多く、用途が「低レイテンシ配信」である点が別物。
ひっかけ例：「ユーザーに近い場所からコンテンツを配信してレイテンシを下げる拠点」は エッジロケーション。「単一障害点を避けるために冗長化する単位」は AZ。
4. CapEx と OpEx（固定費から変動費へ）
クラウドのエコノミクスで問われる考え方です。
- CapEx（資本的支出）：データセンターやサーバーを前もって購入する固定的な投資。
- OpEx（運用的支出）：使った分だけ支払う変動費。
AWS が掲げる「クラウドコンピューティングの6つの利点」の1つ目が、まさに 「Trade capital expense for variable expense（固定費を変動費に置き換える）」 です。「初期投資を抑えられる＝CapEx を OpEx に変える」という対応関係で覚えます。なお6つの利点は次のとおりです。
- Trade capital expense for variable expense（固定費を変動費へ）
- Benefit from massive economies of scale（規模の経済の恩恵）
- Stop guessing capacity（キャパシティ予測が不要に）
- Increase speed and agility（速度と俊敏性の向上）
- Stop spending money running and maintaining data centers（データセンター運用から解放）
- Go global in minutes（数分で世界展開）
5. 最大のひっかけ：CAF（クラウド導入フレームワーク） と Well-Architected フレームワーク
両方とも要素が6つあり、名前も似た雰囲気のため、CLF で最も取り違えやすいペアだと筆者は感じています。役割がまったく違うので、ここははっきり分けて覚えます。
- AWS CAF（Cloud Adoption Framework）：組織がクラウドへ移行・導入する旅路を支援するフレームワーク。「ビジネス／人材／ガバナンス／プラットフォーム／セキュリティ／オペレーション」の6つの視点（perspectives）で構成される。→ 組織変革・移行計画 の話。
- AWS Well-Architected Framework：個々のワークロード（システム）をうまく設計・運用するための指針。「運用上の優秀性／セキュリティ／信頼性／パフォーマンス効率／コスト最適化／持続可能性」の6本柱（pillars）で構成される。→ アーキテクチャ設計品質 の話。
| 観点 | AWS CAF | Well-Architected |
|---|---|---|
| 目的 | クラウド導入・移行を組織として進める | ワークロード設計の品質を高める |
| 単位 | 組織・ビジネス全体 | 個々のシステム |
| 6要素 | ビジネス/人材/ガバナンス/プラットフォーム/セキュリティ/オペレーション | 運用上の優秀性/セキュリティ/信頼性/パフォーマンス効率/コスト最適化/持続可能性 |
| 呼び方 | 6つの「視点(perspectives)」 | 6つの「柱(pillars)」 |
ひっかけ例：「組織のクラウド移行を、ビジネスや人材の観点も含めて支援する」は CAF。「設計済みシステムを信頼性やコスト最適化の観点で評価する」は Well-Architected。
補足：Well-Architected の6本目の柱「持続可能性（Sustainability）」は 2021年12月に追加されたもので、当初の5本柱で覚えていると古い情報です。現在は 6本柱が正解です。
6. 信頼性（Reliability） と パフォーマンス効率（Performance Efficiency）
Well-Architected の柱の中でも紛らわしいペアです。
- 信頼性：障害から回復し、期待どおり機能し続ける能力（冗長化、復旧、需要変化への対応）。
- パフォーマンス効率：リソースを効率的に使い、要求性能を満たすこと（適切なインスタンス選定、スケーリング）。
「落ちても回復できるか＝信頼性」「速く効率よく動くか＝パフォーマンス効率」という軸の違いで切り分けます。
まとめ：混同ペア早見表
| 混同しやすいペア | ざっくり区別の軸 |
|---|---|
| スケーラビリティ / 弾力性 | 「増やせる土台」か「自動で増減する運用」か |
| 可用性 / 耐久性 | 「アクセスできるか」か「データが消えないか」か |
| リージョン / AZ / エッジ | 「地理領域」か「DC群（冗長化単位）」か「配信拠点」か |
| CapEx / OpEx | 「前払いの固定費」か「従量の変動費」か |
| CAF / Well-Architected | 「組織の移行(6視点)」か「設計品質(6本柱)」か |
| 信頼性 / パフォーマンス効率 | 「回復できるか」か「効率よく速いか」か |
CLF のドメイン1は、用語そのものより「何を評価している概念なのか（対象軸）」を意識すると一気に解きやすくなります。選択肢で迷ったら、「これは『アクセス可否』の話か『データ保全』の話か？」のように、軸に立ち返って消去法を使うのがおすすめです。
次回（第2回）は ドメイン2「セキュリティとコンプライアンス」の責任共有モデル を、間違えやすい「どっちが守る範囲か」を中心に整理する予定です。