EC2 と RDS、パッチは誰が当てる？共通責任モデルの境界線を整理する
AWS の共通責任モデルを学ぶとき、多くの人が一度は迷うのが EC2 と RDS の責任分界 です。
どちらも AWS 上で動くサービスですが、運用責任は同じではありません。特に OS やミドルウェア、データベースエンジンの保守を誰が担うのかを曖昧にすると、試験では誤答しやすく、実務では運用事故につながります。
この記事では、EC2 はなぜ利用者責任が重く、RDS はなぜ AWS 側の責任が増えるのかを、共通責任モデルの観点から整理します。
結論：抽象度が上がるほど、AWS に任せられる範囲は広がる
先に結論を書くと、次のように整理できます。
- Amazon EC2:OS やミドルウェアのパッチ適用は利用者責任
- Amazon RDS:基盤 OS や DB エンジン保守は AWS 側が広く担う
要するに、IaaS に近い EC2 は自分で守る範囲が広く、PaaS に近い RDS は運用責任を AWS に寄せやすいということです。
なぜ EC2 と RDS は混同されやすいのか
両方とも「インスタンス」という言葉が出てくるため、責任範囲まで似ているように感じやすいのが原因です。
しかし、実際には見ているレイヤーが違います。
- EC2 は仮想サーバーそのものを提供するサービス
- RDS はデータベース利用を主目的にしたマネージドサービス
この違いが、そのまま共通責任モデルの差になります。
Amazon EC2 の責任範囲
EC2 では、AWS は物理インフラ、ネットワーク、ハイパーバイザーなどの下位レイヤーを担当します。
一方で、ゲスト OS より上の層は基本的に利用者責任です。
利用者が担う代表例
- OS のセキュリティパッチ適用
- Web サーバーやミドルウェアの更新
- アプリケーション実行環境の保守
- EBS 上のデータ運用設計
- IAM ロール以外の OS 内ユーザー管理
たとえば EC2 上でアプリケーションを動かしている場合、OpenSSL や Apache の脆弱性が出たら、利用者側で対応計画を立てる必要があります。
sudo yum update -y
sudo reboot
もちろん、実務では Systems Manager Patch Manager や AMI 更新、自動化パイプラインと組み合わせることが多いですが、本質は変わりません。
EC2 の OS パッチは AWS が自動で面倒を見てくれるものではないのです。
Amazon RDS の責任範囲
RDS はマネージドサービスであり、利用者はデータベース利用に集中しやすくなっています。
AWS 側が広く担う領域には、たとえば次のものがあります。
- 基盤 OS の保守
- DB エンジンのパッチ適用支援
- バックアップ機構の提供
- ストレージ基盤の運用
- Multi-AZ 構成の基盤制御
これにより、EC2 上で自前運用する場合に比べて、運用負荷をかなり減らせます。
ただし、RDS でも利用者責任が消えるわけではありません。
利用者が考えるべき代表例
- メンテナンスウィンドウの設定
- DB パラメータグループの設計
- メジャーバージョンアップの判断
- 接続制御や認証方式の設計
- アプリケーション互換性確認
つまり、RDS は「運用を丸投げできるサービス」ではなく、基盤保守を AWS に寄せつつ、設計判断は利用者が担うサービスです。
比較表で見ると分かりやすい
| 項目 | EC2 | RDS |
|---|---|---|
| サービスの性質 | IaaS 寄り | PaaS 寄り |
| OS パッチ | 利用者責任 | AWS 側が広く担う |
| DB エンジン保守 | 利用者責任 | AWS が支援 |
| バックアップ基盤 | 自前設計 | AWS が提供 |
| 高可用構成 | 自前構築 | Multi-AZ で管理しやすい |
| アプリ互換性確認 | 利用者責任 | 利用者責任 |
この表のように、責任分界はかなり明確です。
試験での見分け方
AWS 認定試験では、次の切り分けがよく問われます。
-
OS パッチ責任を問う問題
- EC2 → 利用者責任
- RDS → AWS 側が広く担う
-
運用負荷を下げたいという要件
- DB を EC2 に自前構築するより RDS の方が適切
-
高可用性の実装方法
- EC2 では EBS、AMI、ALB、Auto Scaling などを組み合わせる
- RDS では Multi-AZ のようなマネージド機能を使いやすい
「どちらも AWS だから同じ責任」と考えると、ここでかなりの確率で外します。
実務で事故を防ぐための観点
試験だけなら暗記でも何とかなる場面はありますが、実務では責任分界をドキュメント化して初めて意味があります。
たとえば、次の観点を決めておくと運用事故を減らせます。
- EC2 のパッチ適用頻度
- 再起動を伴う更新の実施手順
- RDS の自動マイナーアップグレードを許可するか
- EBS スナップショットや DB バックアップの復元訓練をしているか
- メンテナンス時の業務影響をどう抑えるか
責任分界を曖昧にしたまま進めると、「そこは AWS がやると思っていた」という典型的な事故が起きます。
まとめ
EC2 と RDS の違いは、単なる機能差ではありません。どこまでを利用者が管理し、どこからを AWS に任せるかの違いです。
- EC2:OS やミドルウェアのパッチは利用者責任
- RDS:基盤運用は AWS 側が広く担う
この切り分けを理解しておくと、共通責任モデルの問題はかなり安定して解けますし、実務でも責任範囲を説明しやすくなります。
AWS では、サービスの抽象度が責任範囲を決める。この感覚を持てると、EC2・RDS 以外のサービスでも判断がしやすくなります。