# 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 の脆弱性が出たら、利用者側で対応計画を立てる必要があります。

```bash

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 以外のサービスでも判断がしやすくなります。