はじめに
私はクラウド経験がまだ約1年半で、これまでの案件ではIaaS（主にEC2などの仮想サーバー）を中心とした設計・構築を行ってきました。しかし最近、初めてアーキテクチャ検討の段階からPaaS系サービスを前提に構成を考える機会があり、その際に、次のような疑問が浮かび上がりました。
・なぜ IaaS ではなく PaaS を選ぶのか？
・AWSにおける「PaaS」とは、具体的にどのサービスを指すのか？
これらの疑問を自分なりに整理する必要があり、本記事では私と同じようなクラウド初心者の方に向けて、AWSにおけるPaaSの考え方と、よく使われるサービスを分かりやすくまとめます。
まずは IaaS / PaaS / SaaS のおさらい
クラウドを学び始めた頃に「クラウドは IaaS / PaaS / SaaS の3種類」と聞いた方も多いと思います。
| モデル | 代表例 | 利用者の管理範囲 |
|---|---|---|
| IaaS | EC2 | OS以上を利用者が管理 |
| PaaS | RDS、Lambda | OS・ミドルウェアはAWSが管理 |
| SaaS | Slack、Zoom | ほぼ全てを提供側が管理 |
ポイントは、どこまでをクラウド事業者に任せるかです。
CaaS？FaaS？
まず、何？と思う？
CaaS：プロバイダーがクラウド上でコンテナオーケストレーションを提供するサービスを指しています。
AWSで代表的なサービスはAmazon ECS（Elastic Container Service）やAmazon EKS（Elastic Kubernetes Service）です。
FaaS：クラウドコンピューティングサービスの形態の一つで、開発者は関数と呼ばれる小規模なコードを実行する環境を利用します。AWSで代表的なサービスとしてAWS Lambdaです。
アーキテクチャを検討する際に、どちらを採用するかについては、下記の記事で解説しています。ご興味があればご参照ください。
個人的に、PaaSを広い意味で使うケースが多く、CaaS(ECS/Fargate)やFaaS (Lambda)を含めて「PaaS的なサービス」として扱われることも多いと感じています。
なぜ IaaS ではなく PaaS を選ぶのか？
IaaSを選択した場合、利用者側で以下の対応が必要となります。
- OSのパッチ適用
- ミドルウェアの管理
- 冗長構成の設計
- 障害対応・復旧設計
👉 自由度は高いが、運用負荷も高い
PaaSを選ぶ理由（実務での実感）
PaaSを選定する主な理由は次の通りです。
- OSやミドルウェア管理をAWSに任せられる
- マルチAZ構成やバックアップが標準提供される
- インフラ構築・運用を短期間で実現できる
- インフラ専門スキルへの依存を減らせる
👉「インフラを作ること」よりも
「サービスを安定して提供すること」を重視する場合に特に有効です。
どうやって IaaS / PaaS を選ぶのか？（考え方）
👉 「どこまでをAWSに任せたいか」
OSやミドルウェアまで自分たちで制御したい → IaaS
運用負荷を減らし、早く安定稼働させたい → PaaS
一方で、機密性が非常に高くクラウド利用が難しいといったケースでは、オンプレミスを選択する場合もあります。
おまけ：AWS、AzureのPaaSサービス
※ 本内容は、AWS および Azure における 代表的な PaaS サービスを理解するための参考整理です。
※ 実際のサービス名称や分類は、クラウドベンダーのアップデートにより今後変更される可能性があります。
※ 最新の正式名称や仕様については、各クラウドベンダーの公式ドキュメントをご確認ください。
※ Analytics / AI / IoT / AO 系サービスなどは対象外としています。
アプリケーション実行基盤（Compute）
| 分類 | AWS | Azure | 特徴・補足 |
|---|---|---|---|
| WebアプリPaaS | Elastic Beanstalk | Azure App Service | コードをデプロイするだけで実行環境を提供 |
| コンテナPaaS | ECS（Fargate） | Azure Container Apps | ノード管理不要、PaaS寄りのコンテナ実行 |
| Kubernetes（PaaS寄り） | EKS（Fargate） | AKS | コントロールプレーンはマネージド |
| サーバレス（FaaS） | AWS Lambda | Azure Functions | 実行基盤は完全マネージド |
データベース（DB）
| 分類 | AWS | Azure | 特徴・補足 |
|---|---|---|---|
| RDB | Amazon RDS | Azure SQL Database | OS・バックアップ・パッチ管理不要 |
| 高可用RDB | Amazon Aurora | Azure SQL Managed Instance | 高可用・スケールを意識せず利用可能 |
| NoSQL | DynamoDB | Cosmos DB | フルマネージド・自動スケール |
API・連携・認証
| 分類 | AWS | Azure | 特徴・補足 |
|---|---|---|---|
| API管理 | API Gateway | Azure API Management | REST / HTTP API の集約 |
| 認証 | Amazon Cognito | Microsoft Entra ID | ユーザー管理・認証基盤 |
| メッセージング | SQS / SNS | Service Bus | 非同期処理・疎結合構成 |
その他PaaS系サービス
| 分類 | AWS | Azure | 特徴・補足 |
|---|---|---|---|
| アプリ実行簡易PaaS | App Runner | Azure App Service | コンテナ・Webアプリ向け |
| CI/CD連携 | CodePipeline | Azure DevOps | PaaSと親和性が高い |
| ログ・監視 | CloudWatch | Azure Monitor | 基本監視は標準提供 |
どちらでも、AWS / Azure ともに PaaS の考え方は共通していると言えるでしょう。
- OS・ミドルウェア管理はクラウド側
- 利用者は「アプリとデータ」に集中
注意事項：
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。