MENU

【AWS Certified Cloud Practitioner】クラウドの基礎を一気に整理(特徴/IaaS・PaaS・SaaS/伸縮性/TCO/移行・設計の考え方)

本記事は AWS Certified Cloud Practitioner の学習で頻出となる「クラウドの基礎概念」を、初学者〜直前復習者が短時間で整理できるようにまとめた解説です。

目次

確度と前提(誤解を防ぐための整理)

(1) 確実に言えること

  • クラウドの基本概念(特徴、IaaS/PaaS/SaaS、展開モデル、従量課金、ビジネス上の利点、伸縮性、TCO、障害前提設計、移行の考え方、導入フレームワーク)は、AWS公式一次情報に明確な説明があります。
  • 本記事は、その一次情報に基づいて一般化した解説を行います。

(2) 推測(根拠つき)

  • 試験では、用語の丸暗記よりも「概念の分類(例:PaaSとSaaSの違い)」「目的に合う考え方(例:障害前提設計)」を問う形式が多い傾向があります(CLFの試験ガイドが示す出題領域が“クラウド概念・価値・設計の考え方”中心であるため)。

一次情報(試験ガイド):https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.pdf

(3) 不明点(追加で確認すべき点)

  • 実際の試験問題の選択肢の文言(ひっかけ表現、用語の言い換えの癖など)は公開されないため、本記事では断定的に「この言い回しが出る」とは述べません。理解の軸(分類・原則)を持って選択肢を見分けることを目的にしています。

1. クラウドコンピューティングの特徴(“クラウドらしさ”の定義)

クラウドの特徴を体系立てて覚えるなら、NISTが示す「5つの必須特性」が基準として扱いやすいです。試験では特に伸縮性計測(従量課金)がセットで問われやすい点が重要です。

  • オンデマンド自己サービス:必要なときに利用者が自分で迅速にリソースを用意できる
  • 広範なネットワークアクセス:ネットワーク越しに様々な端末から利用できる
  • リソースプーリング:共有基盤を複数利用者(マルチテナント)で利用する
  • 迅速な伸縮性(Elasticity):需要に応じて増減できる
  • 計測サービス(Measured service):利用量が測定され、課金や最適化に活用される

一次情報(NIST SP 800-145):https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf


2. IaaS / PaaS / SaaS(“何を提供しているか”で見分ける)

分類問題のコツは「自分たちはどこまで責任を持つのか」をイメージすることです。

  • IaaS:仮想サーバーやネットワーク等のインフラ部品を提供(OS以上は利用者側の管理範囲になりやすい)
  • PaaS:アプリを動かすための実行基盤(運用基盤を含む)まで提供(利用者はアプリ開発に集中しやすい)
  • SaaS:完成したアプリそのものをサービスとして利用(利用者は設定・運用が中心)

一次情報:https://aws.amazon.com/types-of-cloud-computing/

例(短いイメージ)

  • IaaS:サーバー(VM)を借りて、自分でOS設定・ミドルウェア設定を行う
  • PaaS:アプリを置けば動く“土台”が用意されており、基盤側の運用負担が軽い
  • SaaS:完成済みアプリを契約してすぐ使う(勤怠、メール、CRMなど)

3. 展開モデル(クラウドを“どう使い分けるか”)

展開モデルは、クラウド環境の“持ち方・使い方”の分類です。試験では「オンプレミスとクラウドを併用する」などの典型的な説明から名称を判別させることが多いです。

  • ハイブリッド:オンプレミスとクラウドを組み合わせて利用
  • マルチクラウド:複数のクラウドを併用(目的は要件次第)

一次情報(AWS Overview):https://docs.aws.amazon.com/whitepapers/latest/aws-overview/types-of-cloud-computing.html


4. 従量課金(Pay-as-you-go)とクラウドのビジネス上の利点

従量課金(基本の考え方)

クラウドは「使った分だけ払う」モデルが基本です。ここで重要なのは、利用量が計測できることで最適化(無駄を減らす)がしやすい点です。

一次情報:https://aws.amazon.com/pricing/

AWSが整理する “クラウドの6つの利点”

CLFでは「クラウドを使うと何が嬉しいか」が頻出です。AWSは代表的な利点を6つに整理しています。

  • 初期投資(CapEx)を変動費(OpEx)へ
  • 規模の経済によるコスト低減
  • キャパシティ見積もり不要
  • 俊敏性(迅速にリソースを用意できる)
  • データセンター運用負担の削減
  • グローバル展開が容易

一次情報:https://docs.aws.amazon.com/whitepapers/latest/aws-overview/six-advantages-of-cloud-computing.html


5. 伸縮性(Elasticity)とTCO(総所有コスト)の考え方

伸縮性:需要に合わせて増減できる

伸縮性は「アクセス増に耐えるために常に大きなサーバーを買っておく」発想から、「必要なときだけ増やし、落ち着けば減らす」発想へ切り替える概念です。

TCO:購入費だけでなく“運用コスト”も含めて考える

TCO(Total Cost of Ownership)は、購入費に加えて保守・運用・更新・人件費などの総コストを含めた考え方です。クラウドでは、初期投資の圧縮運用負担の削減が効きやすい点が理解の軸になります。

一次情報(利点の整理として):https://docs.aws.amazon.com/whitepapers/latest/aws-overview/six-advantages-of-cloud-computing.html


6. Design for failure(障害前提で設計する)

クラウド設計で重要なのは「障害をゼロにする」よりも「障害が起きても影響を最小化し、復旧できる」ことです。AWS Well-Architected Framework の信頼性(Reliability)では、障害を前提にした設計原則が整理されています。

  • 単一障害点(SPOF)を避ける(冗長化、分散)
  • 障害検知と自動復旧を組み込む
  • 障害を想定したテストと運用手順の整備

一次情報(Reliability Design Principles):https://docs.aws.amazon.com/wellarchitected/latest/framework/rel-dp.html


7. 移行・導入を支える“公式の指針”と代表サービス

AWS Prescriptive Guidance(規範ガイダンス)を使う意味

AWS Prescriptive Guidance は、移行・運用・設計の実践的なパターンや手順を公式にまとめたコンテンツ群です。学習としては「ベストプラクティスを参照できる」だけでなく、実務でも“抜け漏れを減らす”観点で有用です。

一次情報:https://docs.aws.amazon.com/prescriptive-guidance/

オンプレ資産の検出:AWS Application Discovery Service

移行前に「オンプレに何があるのか」を把握する用途で、AWS Application Discovery Service のようなサービスが利用されます。

一次情報:https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html

移行戦略(例:SaaSへ置き換える=Repurchase)

移行の考え方として、いわゆる移行戦略(7R)が整理されています。既存アプリをSaaSへ置き換えるケースは、一般に Repurchase(置換) として説明されます。

一次情報(Migration strategies):https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html

AWS Cloud Adoption Framework(AWS CAF):導入を体系的に進める枠組み

AWS CAF は、クラウド導入を技術だけでなく組織・ガバナンス・運用まで含めて整理し、計画的に進めるためのフレームワークです。

一次情報:https://aws.amazon.com/cloud-adoption-framework/


直前復習:迷いやすい“境界”だけチェック

  • PaaS vs SaaS:自分でアプリを作って載せる(PaaS)/完成済みアプリを使う(SaaS)
  • 伸縮性 vs 可用性:伸縮性=需要に合わせた増減/可用性=止まりにくさ(冗長化・復旧)
  • 障害前提設計:障害ゼロの主張より、検知・自動復旧・冗長化・テストの主張が適切になりやすい
  • 置換(Repurchase):既存アプリを改修して移すのではなく、SaaSへ“置き換える”発想
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次