EC2 と RDS、パッチは誰が当てる?共通責任モデルの境界線を整理する
AWS の共通責任モデルで意外と混乱しやすいのが、EC2 と RDS のパッチ責任の違いです。
どちらも AWS 上で動くサービスなので、「どちらも AWS が面倒を見てくれるのでは?」と雑に理解すると、試験でも実務でも普通に事故ります。特に運用設計の場面では、責任範囲を曖昧にしたまま進めると、パッチ未適用やメンテナンス手順漏れの温床になります。
この記事では、EC2 はなぜ利用者責任が重く、RDS はなぜ AWS 側の責任が増えるのかを、共通責任モデルの観点から整理します。試験対策だけでなく、実務で「誰が何をやるのか」を線引きしたい人にも効く内容です。
まず結論
先に結論を書くと、答えはかなりシンプルです。
- Amazon EC2:OS やミドルウェアのパッチ適用は基本的に利用者責任
- Amazon RDS:基盤 OS やデータベースエンジンの保守運用は AWS 側が広く担う
つまり、同じ AWS のサービスでも、抽象度が低い EC2 は自分で守る範囲が広く、抽象度が高い RDS は AWS に任せられる範囲が増えるということです。
なぜ混同されやすいのか
混乱の原因は、「どちらもインスタンスっぽく見える」からです。
- EC2 は仮想サーバー
- RDS もデータベースインスタンス
見た目が似ているので、責任範囲まで同じに見えてしまいます。ですが、実際にはサービスの層が違います。
- EC2 は IaaS に近い
- RDS は PaaS に近い
この差が、そのままパッチ責任の差になります。
EC2 は「OS の中身」まで自分で面倒を見る
EC2 は仮想マシンを借りるサービスです。AWS が管理するのは、物理データセンター、電源、ネットワーク、ハイパーバイザーなどのインフラ寄りの層です。
一方で、利用者は EC2 上に入れた OS やミドルウェア、アプリケーションを管理する必要があります。
たとえば、EC2 では次のような���業が利用者責任になります。
- OS のセキュリティパッチ適用
- Web サーバーやランタイムの更新
- アンチウイルスやエージェント管理
- IAM ロールやセキュリティグループ以外の OS 内設定
- アプリケーション依存パッケージの脆弱性対応
EC2 でありがちな事故
たとえば、EC2 上で運用している Linux サーバーに OpenSSL の脆弱性が出たとします。このとき AWS は自動では直してくれません。利用者側で AMI 更新、OS パッケージ更新、再起動計画、EBS スナップショット取得などを考える必要があります。
sudo yum update -y
sudo reboot
もちろん実務では、単純に手で実行するのではなく、SSM Patch Manager や Auto Scaling、Blue/Green デプロイと組み合わせることが多いです。ですが本質は同じで、EC2 の OS パッチ責任は利用者側です。
RDS は「データベースを使うこと」に集中しやすい
一方、Amazon RDS はマネージドデータベースサービスです。利用者が見るのは DB の利用やパラメータ設計、バックアップ方針、接続制御などであり、基盤の保守運用は AWS 側にかなり寄せられています。
RDS では、たと���ば次のような領域で AWS の責任が大きくなります。
- 基盤 OS の保守
- DB エンジンのパッチ適用支援
- バックアップ機構の提供
- Multi-AZ フェイルオーバー基盤の運用
- EBS ベースのストレージ基盤管理
ただし、ここで誤解してはいけないのは「全部 AWS 任せではない」ということです。
RDS でも利用者は次を考える必要があります。
- メンテナンスウィンドウの設計
- メジャーバージョンアップの可否判断
- DB パラメータの最適化
- 接続元制御や IAM 認証の設計
- アプリケーション互換性確認
つまり、RDS は基盤運用の一部を AWS に任せられるが、運用判断そのものが不要になるわけではないということです。
表で整理するとこうなる
| 項目 | Amazon EC2 | Amazon RDS |
|---|---|---|
| サービス層 | IaaS 寄り | PaaS 寄り |
| OS パッチ | 利用者責任 | AWS 側が広く担う |
| DB エンジン保守 | 自前構築なら利用者責任 | AWS が保守支援 |
| アプリ互換性確認 | 利用者責任 | 利用者責任 |
| バックアップ基盤 | 自前設計 | AWS が機構提供 |
| フェイルオーバー基盤 | 自前設計 | Multi-AZ で AWS が提供 |
この表を見ると、責任範囲の差はかなり分かりやすくなります。
試験での見分け方
AWS 認定試験では、この論点はかなり素直に問われます。
パターン 1:OS パッチの責任者は誰か
- EC2 が主語なら → 利用者責任
- RDS が主語なら → AWS 側が広く担う
パターン 2:運用負荷を減らしたい
- DB サーバーを自前で EC2 に立てるより、RDS を選ぶ方が運用責任を減らせる
パターン 3:高可用性と責任分界
- EC2 では EBS、AMI、ALB、Auto Scaling などを組み合わせて自前設計
- RDS では Multi-AZ を使ってマネージドに寄せやすい
ここで「AWS のサービスだから AWS がパッチを当てる」と短絡すると外します。
実務で事故を防ぐチェックポイント
実務では、責任分界を口頭で理解しているだけでは不十分です。運用設計書や Runbook に落として初めて効きます。
たとえば次の観点を最初に決めておくと、事故がかなり減ります。
- EC2 のパッチ適用頻度はどうするか
- 再起動を伴う更新のメンテナンス時間はいつか
- RDS の自動マイナーアップグレードを許可するか
- EBS スナップショットやバックアップの復元訓練をしているか
- 本番反映前にアプリ互換性をどう検証するか
たとえばこう考える
- EC2:SSM Patch Manager で月次パッチを回す
- RDS:メンテナンスウィンドウを業務影響の少ない時間帯に設定する
- 両方共通:変更前に復旧計画を確認する
このあたりを曖昧にすると、「AWS がやると思っていた」「いやそこは利用者責任です」で簡単に揉めます。
まとめ
EC2 と RDS の違いは、単なるサービス名の違いではありません。どこまで自分で��用責任を負うかの違いです。
- EC2:OS やミドルウェアのパッチは利用者責任
- RDS:基盤や DB エンジン運用は AWS に大きく寄せられる
この切り分けを理解しておくと、共通責任モデルの問題はかなり安定して解けますし、実務でも責任分界を言語化しやすくなります。
「同じ AWS だから同じ責任」ではなく、サービスの抽象度が責任範囲を決める。ここを押さえておくのが本質です。