目次
はじめに
近年、クラウドサービスは私たちの生活やビジネスに欠かせない存在となりました。
スマートフォンで利用するアプリから、企業の基幹システムまで、その裏側にはクラウドが当たり前のように活用されています。
中でも、Amazonが提供する AWS（Amazon Web Services） は、世界中の企業に利用されている代表的なクラウドプラットフォームです。
クラウドサービスには大きく分けて SaaS・PaaS・IaaS という3つの形態があります。
これらは「どの範囲を自分で管理し、どこからをクラウド事業者に任せるか」という考え方で整理され、利用者の立場や目的によって選ぶべき形態が異なります。
この記事では、AWSを例にとりながら SaaS・PaaS・IaaSの違いや特徴 を解説します。
クラウドをこれから学びたい方、仕事で導入を検討している方にとっても役立つ内容になるはずです。
SaaS / PaaS / IaaSとは
クラウド側が提供する範囲
SaaS（Software as a Service）
- 定義：ソフトウェアをインターネット経由で提供する形態。ユーザーはアプリケーションをインストールする必要なく、Webブラウザや専用アプリから直接利用できます。
- AWSでの例：Amazon WorkMail、Amazon Chime など。
- イメージ：GmailやOffice 365のように、完成されたソフトを「そのまま」使える。
- メリット：導入が簡単、メンテナンス不要、利用開始が早い。
- デメリット：カスタマイズ性が低い、サービス提供者に依存する。
PaaS（Platform as a Service）
- 定義：アプリケーション開発や実行環境をクラウド上で提供する形態。ユーザーはサーバーやネットワークの管理を意識せず、アプリ開発に集中できます。
- AWSでの例：AWS Elastic Beanstalk、AWS Lambda（サーバーレスも含む）。
- イメージ：土台となるプラットフォームを借りて、その上に自分のアプリを構築する。
- メリット：開発スピードの向上、運用負担の軽減。
- デメリット：利用できるプログラミング言語や環境に制限があることが多い。
IaaS（Infrastructure as a Service）
- 定義：サーバーやストレージ、ネットワークなどのインフラをクラウド上で提供する形態。ユーザーは自由度が高く、OSやミドルウェアを選んで構築できます。
- AWSでの例：Amazon EC2、Amazon S3、Amazon VPC。
- イメージ：クラウド上に「仮想のデータセンター」を丸ごと借りられる。
- メリット：柔軟性が高い、あらゆる構成を自分で組める。
- デメリット：運用・管理の責任はユーザー側に残る。
３つのサービス形態の特徴と比較
1. コントロール範囲の違い
- SaaS：ユーザーはアプリを使うだけ。OSやインフラは全てAWSが管理。
- PaaS：アプリのコードは自分で書くが、インフラはAWSが管理。
- IaaS：ハードウェアはAWSが提供するが、それ以外は自分で構築・管理。
2. 利用者の対象
- SaaS：ITリテラシーが高くなくても利用可能。一般ユーザー向け。
- PaaS：アプリ開発者・スタートアップ・Webサービス運営者に向いている。
- IaaS：インフラ管理に慣れたエンジニアや大規模システムの構築に適している。
3. コストの考え方
- SaaS：月額や利用量課金が多く、初期費用が少ない。
- PaaS：アプリ稼働リソースに応じて課金される。
- IaaS：使った分のサーバーリソースに応じて課金。無駄な設計をすると高額になるリスクも。
AWS責任共有モデル（Shared Responsibility Model）の説明
AWS責任共有モデルは、クラウド利用において「AWSと利用者のどちらが、何について責任を持つのか」を明確にする枠組みです。
- AWS の責任（Security of the Cloud）
AWSが担うのは、クラウド基盤そのものの安全性です。データセンター設備、ハードウェア、ネットワーク、仮想化レイヤーを含むインフラ全体を管理・保護します。 - 利用者の責任（Security in the Cloud）
利用者は、クラウド上に配置するOS、アプリケーション、データ、アクセス制御などを自身で管理・保護する必要があります。例えば、EC2インスタンスを利用する場合は、OSの更新・パッチ適用やファイアウォール設定も利用者の責任です。
このモデルのポイントは、サービス形態（IaaS / PaaS / SaaS）によって、責任の範囲が変わる点です。
この図を基本として提供されるサービスによってこのよう（下図）に違いがあります。
オンプレミス / IaaS / PaaS / SaaS の責任範囲比較
| 項目 | オンプレミス （自社運用） | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| 物理インフラ管理 | 利用者が担当（サーバー購入・設置・保守） | AWSが担当 | AWSが担当 | AWSが担当 |
| 仮想化レイヤー | 利用者が担当 | AWSが担当 | AWSが担当 | AWSが担当 |
| OS管理 | 利用者が担当（導入・更新・パッチ適用） | 利用者が担当 | AWSが担当 | AWSが担当 |
| ミドルウェア管理 | 利用者が担当（DB・Webサーバーなどを構築） | 利用者が担当 | AWSが担当 | AWSが担当 |
| アプリケーション | 利用者が開発・運用 | 利用者が開発・運用 | 利用者が開発・運用 | AWSが提供 |
| データ管理 | 利用者が責任 | 利用者が責任 | 利用者が責任 | 利用者が責任（入力・利用範囲の適正管理） |
| アクセス制御 | 利用者が責任 | 利用者が責任 | 利用者が責任 | 利用者が責任（ユーザー管理、認証情報など） |
| セキュリティ教育 | 利用者が責任（社員教育・運用ルール策定も含む） | 利用者が責任 | 利用者が責任 | 利用者が責任 |
🔑 補足ポイント
オンプレミス：すべてを自社で管理・運用。自由度は高いが、コスト・リソース・セキュリティリスクもすべて自社負担。
IaaS：ハード・インフラ部分はAWSが担当。OSやミドルウェア以降は自分で管理する必要あり。
PaaS：アプリ開発に専念でき、運用負担を大幅に削減。
SaaS：利用者は「使うだけ」。責任はデータ利用とアクセス管理に集中。
AWS責任共有モデル：共有される管理領域の例
| 項目 | AWSの責任 | 利用者の責任 |
|---|---|---|
| パッチ管理 | インフラ（ハードウェア・仮想化基盤）に対するパッチを適用 | ゲストOS、ミドルウェア、アプリケーションに対するパッチを適用 |
| 設定管理 | クラウドインフラの基本構成（物理サーバー、ネットワークなど）を管理 | OSやデータベース、アプリケーションの設定を適切に行う |
| セキュリティ教育 | AWSスタッフへのセキュリティトレーニングを実施 | 自社の社員や利用者へのセキュリティ教育を実施し、適切な運用ルールを徹底する |
このように、責任共有モデルを理解することで、「何を自分で行い、何をAWSに任せられるのか」が一目瞭然になります。
それにより、セキュリティリスクの軽減はもちろん、効率的かつ安心してクラウドを活用できるようになります。
押さえるポイント
- どのサービスがどの分類に属するか。
- 「EC2」はIaaS、「Elastic Beanstalk」はPaaS、「WorkSpaces」はSaaS。
- 責任共有モデルの理解が重要。
- SaaSではユーザーの責任範囲はデータ利用やアクセス管理に限られる。
- IaaSではOS・アプリ・ミドルウェアの管理はユーザー側。
- ユースケースをイメージできるかどうか。
- 「Webアプリをすぐに開発したい → PaaS」
- 「メールをすぐに使いたい → SaaS」
- 「自由度高く基盤を作りたい → IaaS」
まとめ：自分に合ったクラウドサービスを選ぶ
SaaS・PaaS・IaaSはそれぞれ役割が異なり、使いどころも異なります。
資格試験では「分類」や「責任範囲」を問われますが、実務では「自分の目的に合うものを選べるかどうか」がポイントです。
- SaaS：完成されたアプリをそのまま利用
- PaaS：開発のためのプラットフォームを利用
- IaaS：インフラから自由に設計
AWSはこの3つを網羅しているため、目的に応じて柔軟に選択できます。
資格学習の一環として学ぶだけでなく、実際の業務でどのように活用できるかを想定しておくと、理解が一段と深まるでしょう。
試験風の例題にチャレンジ
例題1：サービス分類問題
次のAWSサービスを、SaaS・PaaS・IaaSのいずれかに分類してください。
- Amazon EC2
- AWS Elastic Beanstalk
- Amazon WorkSpaces
- Amazon S3
- Amazon Chime
解答例
- IaaS：Amazon EC2, Amazon S3
- PaaS：AWS Elastic Beanstalk
- SaaS：Amazon WorkSpaces, Amazon Chime
例題2：責任範囲に関する問題
次のうち、IaaSを利用する場合にユーザーが責任を負う範囲として正しいものはどれでしょうか？
A. ネットワークインフラの物理セキュリティ
B. データベースのパッチ適用
C. ハードウェアの電源管理
D. データセンターの空調管理
解答例
- 正解：B
IaaSでは、AWS側がハードやデータセンターを管理します。ユーザーはOSやアプリケーション、データベースの管理責任を負います。
例題3：ユースケース選択問題
ある企業が「独自開発したWebアプリをすぐにリリースしたい。
ただしインフラの構築や管理には人員を割けない」と考えています。
最も適したサービス形態はどれでしょうか？
A. SaaS
B. PaaS
C. IaaS
解答例
- 正解：B（PaaS）
→ 開発に専念できるプラットフォームが提供されるため、インフラ運用負担を軽減できます。
学習のコツ
1. 「責任共有モデル」を図で理解する
AWSの試験では、ユーザーとAWSの責任範囲を問う設問が頻出です。文章で暗記するよりも、図にして「SaaS → ほぼAWSに任せる」「IaaS → ユーザーの責任が大きい」と視覚的に覚えるのが効果的です。
2. AWS公式ドキュメントを活用
- AWSのホワイトペーパー（特に「クラウドの責任共有モデル」）は必読。
- 試験は公式文書の表現に沿った問題が多いため、教科書だけでなくAWS公式資料にも目を通すことが合格の近道になります。
3. 模擬問題を繰り返す
AWS認定試験は「用語暗記」ではなく「状況判断」を問うケースが多いです。
- 例えば「A社が○○したい。このときどのサービスを選ぶべきか？」というシナリオ形式。
- 模擬問題を解きながら「このシナリオならSaaS/PaaS/IaaSのどれが適切か」を判断できる力を養いましょう。
4. 実際に触れてみる
- Amazon EC2でサーバーを立てる（IaaS体験）
- Elastic Beanstalkで簡単なアプリをデプロイする（PaaS体験）
- WorkSpacesを使って仮想デスクトップを利用する（SaaS体験）
机上の知識だけでは記憶に残りにくいので、実際に手を動かして違いを体感することが重要です。
5. 試験直前は比較表で整理
- SaaS・PaaS・IaaSの違いを「管理範囲」「対象ユーザー」「AWSサービス例」といった切り口で一覧表にしておくと、試験直前の確認がスムーズになります。
総まとめ：試験と実務の両方で役立つ知識に
SaaS・PaaS・IaaSは資格試験の定番テーマですが、単なる暗記ではなく「ユースケース」「責任範囲」「AWSの具体例」と結びつけて理解すると応用力が身につきます。
- 試験対策：分類・責任範囲・ユースケースを整理して覚える
- 実務活用：実際に触ってみて感覚的に違いを理解する
このように両輪で学ぶことで、合格だけでなく実務に直結する知識を獲得できます。
AWSフルコースが秀逸。転職支援も充実していて39歳未経験でのインフラ企業への転職実績あり。
余談：他のクラウドも責任共有モデルは共通の考え方
- AWS：「Security of the Cloud（AWSの責任）」と「Security in the Cloud（利用者の責任）」を明確に区別。
- Azure：同様に「クラウド基盤はMicrosoftが責任、アプリやデータは利用者が責任」と明記。セキュリティ資料では「Shared Responsibility Model」としてAWSとほぼ同じフレームワークを提示。
- GCP：Googleも同じく責任分担を公式ドキュメントで定義。インフラはGoogleが守り、OS・アプリ・データは利用者が守るスタンス。
👉 つまり、どのクラウドでも「IaaSほど利用者の責任が重く、SaaSほど軽い」 という構造は共通です。
1. サービス例の違い
クラウド3大サービスの比較（AWS / Azure / GCP）
| サービス形態 | AWS（Amazon Web Services） | Azure（Microsoft） | GCP（Google Cloud Platform） | 利用者の責任範囲（共通） |
|---|---|---|---|---|
| IaaS （基盤提供） | EC2（仮想サーバー） S3（ストレージ） VPC（ネットワーク） | Virtual Machines（仮想サーバー） Azure Storage Virtual Network | Compute Engine（仮想サーバー） Cloud Storage VPC Network | OSの管理（パッチ適用・更新） ミドルウェアの設定 アプリ開発・運用 データ・アクセス制御 |
| PaaS （開発基盤提供） | Elastic Beanstalk Lambda（サーバーレス） AWS RDS | App Service Azure Functions Azure SQL Database | App Engine Cloud Functions Cloud SQL | アプリ開発・運用 データ管理 アクセス制御 |
| SaaS （完成サービス提供） | WorkSpaces（仮想デスクトップ） Chime（コミュニケーション） | Microsoft 365（Word, Excel, Teams） Dynamics 365 | Google Workspace（Gmail, Docs, Meet） | データ利用の適正管理 ユーザー管理（アカウント・認証） |
- AWS
- IaaS：EC2、S3
- PaaS：Elastic Beanstalk、Lambda
- SaaS：WorkSpaces、Chime
- Azure
- IaaS：Azure Virtual Machines、Azure Storage
- PaaS：Azure App Service、Azure Functions
- SaaS：Microsoft 365、Dynamics 365
- GCP
- IaaS：Compute Engine、Cloud Storage
- PaaS：App Engine、Cloud Functions
- SaaS：Google Workspace（Gmail、Docs、Meet など）
オンプレミス vs AWS / Azure / GCP 責任範囲比較
| 項目 | オンプレミス（自社運用） | AWS | Azure | GCP |
|---|---|---|---|---|
| 物理インフラ管理 | 利用者が担当（サーバー購入・設置・保守） | AWSが担当 | Microsoftが担当 | Googleが担当 |
| 仮想化レイヤー | 利用者が担当 | AWSが担当 | Microsoftが担当 | Googleが担当 |
| OS管理 | 利用者が担当 | EC2などIaaSは利用者が担当 PaaS/SaaSはAWSが担当 | Virtual Machinesは利用者が担当 App Service/DynamicsはMicrosoftが担当 | Compute Engineは利用者が担当 App Engine/WorkspaceはGoogleが担当 |
| ミドルウェア管理 | 利用者が担当（DB・Webサーバー等） | IaaSは利用者、PaaS以降はAWS | IaaSは利用者、PaaS以降はMicrosoft | IaaSは利用者、PaaS以降はGoogle |
| アプリケーション | 利用者が開発・運用 | 利用者（IaaS/PaaS）、AWS（SaaS） | 利用者（IaaS/PaaS）、Microsoft（SaaS） | 利用者（IaaS/PaaS）、Google（SaaS） |
| データ管理 | 利用者が責任 | 利用者 | 利用者 | 利用者 |
| アクセス制御 | 利用者が責任 | 利用者 | 利用者 | 利用者 |
| コスト構造 | CAPEX中心（初期投資・保守コスト大） | OPEX中心（従量課金・スケーラブル） | OPEX中心（従量課金・統合ライセンス多め） | OPEX中心（従量課金・柔軟性が高い） |
👉 それぞれのクラウドが提供する具体的なサービスは異なりますが、分類の枠組み自体は共通しています。
2. 違いが出るポイント
- 用語の表現
AWSは「責任共有モデル」と明言、Azureは「Shared Responsibility」、GCPは「Shared Fate」という言い方をする場合もあり、表現に差があります。 - セキュリティの強調点
- AWS：責任境界の明示を重視
- Azure：ゼロトラストモデルとの関連を強調
- GCP：デフォルトのセキュリティ機能（暗号化やゼロトラスト）を前面に出す
まとめ
複数クラウドを扱う人（マルチクラウド戦略や資格試験を受ける人）は、この共通点と違いを押さえると強いです。
大枠（SaaS / PaaS / IaaSの違い、責任共有モデル）は3社とも同じ。
サービス名やセキュリティ哲学に細かな違いがある。
