# PaaS と IaaSとは

クラウドの利用形態の分類です。IaaSは仮想サーバーなどの基盤を利用してOSから上を自社で管理し、PaaSはOSと実行環境まで事業者が管理し、自社はアプリケーションを用意します。

## PaaSとIaaSとは

IaaS（Infrastructure as a Service）とPaaS（Platform as a Service）は、クラウドの事業者に管理を委託する範囲による分類です。IaaSでは事業者が提供する処理能力、保存容量、ネットワークを利用し、その上に[OSを含む任意のソフトウェアを導入して稼働させます](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf)。PaaSでは事業者が用意した言語と開発ツールで作成したアプリケーションを事業者の基盤に配置して稼働させ、[その下のサーバー、OS、保存装置は利用者が管理しません](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf)。

例えば受注を処理する社内のWebシステムをクラウドで稼働させるとします。IaaSのAmazon EC2では仮想サーバーを利用し、OS、Webサーバーのソフトウェア、プログラムを稼働させるための実行環境を自社で導入して更新します。PaaSのAzure App Serviceでは、作成したプログラムを配置すると、[OSとアプリケーションの実行環境はAzureが管理します](https://learn.microsoft.com/en-us/azure/app-service/overview-patch-os-runtime)。

どちらも、機器を購入せずに業務システムを稼働させられる点は共通です。両者の違いは、OSと実行環境の更新を自社で担うか事業者に委託するかにあります。飲食店の厨房の例では、IaaSは空の厨房を賃借して調理器具の調達と点検を自社で行う形で、PaaSは器具の点検まで含む厨房を賃借して調理だけを担う形です。

![アプリ、実行環境、OS、サーバーと保存装置の4層のうち、IaaSではサーバーと保存装置だけを事業者が担い、PaaSではOSと実行環境も事業者が担う。アプリはどちらも自社が用意する](https://media.marketing.kdotdev-tunnel.org/glossary-paas-iaas-98530f4cde23aa9ea3850ced7abff8a538176e1d29b711b803f1fd39a2ae9f69.png)

完成した業務アプリケーションをそのまま利用するSaaSとは、アプリケーションを自社で用意するかどうかが異なります。データベースのような特定の機能を事業者が運用するマネージドサービスと、利用量に応じて実行環境を事業者が増減するサーバーレスは、PaaSに含める場合も、別の分類にする場合もあります。

## 自社のサーバーで稼働させる場合の負担

自社の設備でサーバーを稼働させると、機器の調達と設置、故障時の交換、数年ごとの機器の更新が発生します。IaaSは、このうち機器と設備の管理を事業者に移管する形です。EC2の利用者は、[OSの更新とセキュリティパッチ、導入したソフトウェア、ファイアウォールの設定を管理します](https://aws.amazon.com/compliance/shared-responsibility-model/)。機器の管理が不要になっても、OSから上の作業は引き続き自社の担当です。

PaaSはOSと実行環境の更新も事業者に移管する形です。Azure App Serviceでは、[物理サーバーと仮想マシンの両方のOSに、毎月の定例の更新を自動で適用します](https://learn.microsoft.com/en-us/azure/app-service/overview-patch-os-runtime)。自社が担うのは、アプリケーションの不具合の修正、データ、利用者の権限です。

| 担当の範囲 | 自社のサーバー | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| 設備、物理サーバー、物理ネットワーク | 自社 | 事業者 | 事業者 | 事業者 |
| OS | 自社 | 自社 | 事業者 | 事業者 |
| ネットワークの制御 | 自社 | 自社 | 分担 | 事業者 |
| アプリケーション | 自社 | 自社 | 分担 | 分担 |
| データ、利用者と権限、設定 | 自社 | 自社 | 自社 | 自社 |

この表は、Microsoftの[責任分担の表](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility)から主な行を抜粋したものです。PaaSのアプリケーションが分担になっているのは、事業者が実行環境を管理しても、プログラムの安全性と設定は利用者の責任だからです。

![IaaS、PaaS、SaaSの順に、事業者が担う層が機器からOSと実行環境、アプリの分担へと下から増加する。データと権限はどの形態でも自社が担う](https://media.marketing.kdotdev-tunnel.org/glossary-paas-iaas-ce29e339adcf3b36f3fd146b631e8bccb9b1fb245314e51b6d28677c3d12bd0b.png)

## IaaSの自由度と自社が担う作業

### IaaSの効果

- OSの種類とバージョン、導入するソフトウェアを自由に選択できる
- 自社のサーバーの構成をほぼそのままクラウドへ移行できる。AWSは、アプリケーションを変更せずに移行する方式を[リホストと呼び、大規模な移行で一般的な方式の1つとしている](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html)
- 監視の常駐ソフトや特殊な機器のドライバなど、OSに直接導入するソフトウェアも稼働できる
- 機器の調達が不要になる。仮想サーバーは目安として数分程度で追加できる

### IaaSのコストとリスク

- OSと、データベースやWebサーバーのソフトウェアの更新を自社で継続する。Windowsのように[OSの更新が毎月提供される](https://learn.microsoft.com/en-us/windows/deployment/update/release-cycle)場合は、更新の適用、再起動の時間帯の調整、適用後の動作確認が毎月発生する
- OSの提供期限ごとに、後継のバージョンへの移行を自社で計画する
- 監視、バックアップ、障害時の切替の仕組みを自社で用意し、試験する
- LinuxやWindowsの運用に精通した担当者が必要になり、担当者が1人だと休暇や退職で更新が停止する
- 処理の少ない時間帯にも仮想サーバーの稼働時間に応じた料金が発生する
- 自社で購入したWindows ServerやSQL Serverのライセンスを移管して利用する場合、[利用の可否は製品ごとのMicrosoftの条件で決定し、ライセンスの管理は利用者の責任になる](https://aws.amazon.com/windows/faq/)

![IaaSでは更新の適用と再起動の時間帯の調整、動作の確認を自社が毎月反復する](https://media.marketing.kdotdev-tunnel.org/glossary-paas-iaas-5bf848277093a6de23f9305f3c984a3db1910fbd0c7d2aa95c6aa662a5070ba3.png)

## PaaSで移管できる作業と利用上の制約

### PaaSの効果

- OSと実行環境の更新を事業者が担うため、自社の担当者の都合で更新が遅延しにくい。Azure App Serviceでは、[OSの更新が毎月自動で適用される](https://learn.microsoft.com/en-us/azure/app-service/overview-patch-os-runtime)
- アプリケーションの登録だけで公開でき、台数の増減も設定で完了する
- 運用の専任の担当者がいない会社でも、開発に人手を充当しやすい

### PaaSのコストとリスク

- 利用できる言語とバージョンは事業者が用意した範囲に限られる。Azure App Serviceでは、[言語の細かいバージョンは事業者が決定し、特定の版に固定するには利用者がコンテナを用意する](https://learn.microsoft.com/en-us/azure/app-service/language-support-policy)
- 事業者による実行環境の更新で、アプリケーションの挙動が変化することがある。言語の更新を既存の環境に上書きで適用する場合、Azure App Serviceでは[アプリケーションは自動で更新後の版で稼働する](https://learn.microsoft.com/en-us/azure/app-service/overview-patch-os-runtime)
- 言語のバージョンの提供期限は言語の開発元が決定する。Azure App Serviceでは、[期限後のバージョンにはセキュリティパッチが提供されず、サポートの対象になるには後継のバージョンへの対応が必要になる](https://learn.microsoft.com/en-us/azure/app-service/language-support-policy)。この対応のためのアプリケーションの改修は自社の作業である
- OSの設定の変更やソフトウェアの追加は事業者が許可する範囲に限られ、障害の原因調査も事業者が提供するログと管理画面の範囲で行う
- 待機中の料金はIaaSと同様に発生することが多い。App Serviceの専用のプランでは、[確保した仮想マシンの台数に応じて課金される](https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans)。利用がない間に[実行環境を0台まで縮小する](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)のは、Cloud Runなど一部のサービスに限られる
- 既存のアプリケーションがOSの設定やファイルの保存先を前提にしていると、そのままでは稼働しないことがあり、移行の前に改修が発生する
- 設定の書き方や連携の仕組みが事業者ごとに異なり、事業者固有の機能を多く利用するほど他の事業者への移行に改修が必要になる

![PaaSでは事業者がOSと実行環境を更新し、言語のバージョンの提供期限を通知する。期限前に後継のバージョンへアプリケーションを改修するのは自社の作業になる](https://media.marketing.kdotdev-tunnel.org/glossary-paas-iaas-9284336f980cb2f8c20e45148a6c89b444b484ff74f863b8dade75ce460c355e.png)

## 業務システムをIaaSとPaaSのどちらで稼働させるか

新規に開発する業務システムは、PaaSとマネージドサービスで構成できるかを先に検討し、構成できない部分だけをIaaSにします。判断の分かれ目は、OSに直接ソフトウェアを導入する必要があるかどうかと、OSの更新を毎月継続できる体制があるかどうかです。体制の目安は、OSの更新と障害の一次対応を担当できる人が常時2名以上いることです。1名だけの体制では、その人の休暇や退職のときに更新と障害対応が停止しやすくなります。

次のいずれかに該当する部分はIaaSを選択します。

- 業務パッケージの提供元が、OSの種類とバージョンや、OSへの導入を前提にした構成を指定している
- 業務パッケージに付属してOSに常駐するデータ連携のソフトや、機器のドライバのように、PaaSでは稼働しないソフトウェアが必要である
- 自社のサーバーの保守期限が近く、アプリケーションを改修する時間がない。この場合はまずIaaSへ移行し、移行後にPaaSへの移行を計画する

![OSに直接導入するソフトウェアがなければPaaSとマネージドサービスで構成する。そうしたソフトウェアがある場合は、OSの更新を毎月継続できる体制の有無を確認する。体制があればそのソフトウェアだけをIaaSで稼働させて残りはPaaSで構成し、体制がなければ常時2名以上の担当を確保してからIaaSを利用する](https://media.marketing.kdotdev-tunnel.org/glossary-paas-iaas-713f2d3aa3943b32770195cb08e23e614ae9ab8525ca4b9565624f4929ffab97.png)

デジタル庁の[政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619_resources_standard_guidelines_guideline_08.pdf)は政府情報システムを対象とする方針です。同基本方針は、インフラだけを先にクラウドへ移行する場合、アプリケーションを含む刷新を次の段階として当初から計画するよう求めています。

1つのシステムを両方に分割して構成する方法もあります。例えば受注のWeb画面と処理はPaaSで稼働させ、OSへの常駐が必要なデータ連携のソフトだけをIaaSの仮想サーバーで稼働させます。IaaSの部分が少ないほど、OSの更新を担う範囲は縮小します。

アプリケーションをコンテナに格納して登録するサービスも、IaaSとPaaSの中間の選択肢になります。Cloud Run、Amazon ECSのFargate、App Serviceのコンテナの機能が該当します。Fargateでは、[事業者が基盤のパッチを適用し、コンテナイメージは利用者が管理します](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-shared-model.html)。イメージに含めた言語やライブラリの更新は自社の作業です。Cloud Runには、Googleが提供するベースイメージを利用する場合に、[イメージの基盤になるOSと言語の部分を事業者が自動で更新する設定](https://docs.cloud.google.com/run/docs/configuring/services/automatic-base-image-updates)もあります。

停止の許容範囲も構成の判断材料になります。単独のEC2の仮想サーバーの稼働率の目標は[月99.5%で、複数のアベイラビリティーゾーンに分散して配置すると月99.99%](https://aws.amazon.com/compute/sla/)です。App Serviceは、[複数のゾーンに分散するプランを選択するとSLAの稼働率が向上します](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service)。どちらの形態も、1台の構成ではその1台の停止がシステム全体の停止になります。

PaaSを利用する前に、次の点を確認します。

- 利用する言語のバージョンが提供されているか。提供期限はいつで、期限前の改修を誰が担うか
- ログの保存期間と保存先が、障害の調査と監査の要件を満たすか
- 社内ネットワークや閉域の接続が必要な場合、そのプランで接続できるか。App Serviceでは、[仮想ネットワークへの接続はBasic以上の専用のプランで利用する機能である](https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration)
- 台数の増加の上限と、1台あたりの処理能力の上限が、繁忙期の処理量を満たすか
- SLAの稼働率の目標と、それを得るための構成の条件

試作や数週間の検証で、終了後に環境を削除するものは、どちらを選択しても運用の負担の差は小さいことが多く、担当者が使い慣れている形でかまいません。差が拡大するのは数年にわたり稼働させる業務システムです。

## よくある誤解

### PaaSを利用すればセキュリティの対策は事業者が担う

事業者が担うのはOSと実行環境の更新までです。[Microsoftの責任分担の表](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility)では、PaaSでもデータ、利用者と権限、設定は利用者の責任で、アプリケーションの安全性も利用者が担います。プログラムの脆弱性や設定の誤りによる公開は、PaaSでも自社で対策します。

### IaaSに移行すればサーバーの運用は事業者が担う

IaaSで事業者が担うのは機器と設備です。[AWSの責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、EC2の利用者がOSの更新とセキュリティパッチを管理します。自社のサーバーをそのまま移行した場合、OSから上の運用の作業は移行前と同じです。

### PaaSかIaaSかの分類だけで担当の範囲が確定する

利用するサービスごとに、OS、実行環境のバージョン、バックアップを誰が担うかを確認します。Google CloudのPaaSでも、事業者が担う範囲は[利用するサービスと機能によって異なります](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate)。

判断の材料が不足する場合はPaaSを起点にし、OSに直接導入するソフトウェアがある部分と、改修の時間を確保できない既存の構成だけをIaaSにします。