この記事で押さえるポイント（AWS Certified Cloud Practitioner 向け）
- 可用性（Availability）は「止めない仕組み」を指し、試験ではどこまでAWSが面倒を見るか（＝責任範囲）が頻出です。
- 「マネージド／アンマネージド」は、公式用語というより運用責任の寄り方を説明する実務用語として出てきやすい概念です。
- 混乱しやすい点は、Shared Responsibility Model（責任共有モデル）で整理すると一気に解像度が上がります。
可用性（Availability）とは（試験での扱い）
可用性は「サービスが求められるときに使える状態を保つこと」です。AWSでは、可用性を高める基本手段として 複数Availability Zone（AZ）への分散や障害時のフェイルオーバー、自動復旧などが定番です。 ️
公式ベストプラクティスとしては、Well-Architected Framework（Reliability Pillar）に「複数AZ/複数リージョンへ展開」「健全なリソースへフェイルオーバー」などが明記されています。 https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
- 複数ロケーション（AZ/リージョン）への展開： https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html
- 健全なリソースへのフェイルオーバー： https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_failover2good.html
マネージドサービスとアンマネージドサービス：可用性の観点での違い
結論：違いは「可用性を作るための運用タスクを、誰が担うか」
- マネージド（Managed）寄り：AWSが運用タスクの一部〜多くを担う（例：自動フェイルオーバー、バックアップ、パッチ適用の仕組み提供など）
- アンマネージド（Unmanaged / Self-managed）寄り：利用者が運用タスクを担う比率が高い（例：OS/ミドルの管理、冗長化構成の組み立て、障害対応手順など）
「責任共有モデル」で整理すると迷わない
AWSは責任共有モデルを公式に示しており、AWS側と利用者側で責任が分かれます。 これを「可用性」に当てはめると、どこまでAWSが運用を持ってくれるかが見えてきます。 https://aws.amazon.com/compliance/shared-responsibility-model/
可用性に直結する“運用タスク”を分解して比較
| 可用性に関わるタスク | マネージド寄り（例：RDS Multi-AZ など） | アンマネージド寄り（例：EC2上で自前構築） |
|---|---|---|
| 冗長化（AZ分散） | 機能として提供されることが多い（設定で有効化） | 設計・構築を自分で行う（複数AZ/複数台配置など） |
| 障害検知と自動復旧 | サービス側が自動で検知・切替する設計が多い | 監視・復旧手順・自動化を自分で用意 |
| OS/ミドルのパッチ | サービスによりAWS側が多くを担う（または仕組み提供） | 基本的に利用者責任（OS更新・パッチ適用） |
| バックアップ | 自動バックアップ等の機能が用意されていることが多い | バックアップ方式の選定・運用・検証まで自分で担う |
試験で鉄板の具体例：EC2（アンマネージド寄り） vs RDS Multi-AZ（マネージド寄り）
EC2：OSの管理（更新・パッチ）は利用者側の責任
Well-Architected（Security Pillar）の共有責任説明では、EC2利用者はゲストOSの管理（更新やセキュリティパッチ）や、インスタンス上のアプリケーション管理などが責任範囲であると明記されています。 https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html
つまり、EC2で可用性を上げるには「複数AZにインスタンスを置く」「ヘルスチェックで自動置換する」「障害時の切替を自動化する」などを、必要なサービス（例：ロードバランサー、Auto Scaling、監視）と組み合わせて設計します。
RDS Multi-AZ：一般的な障害に対して自動フェイルオーバーが提供される
RDS Multi-AZは、障害時の自動フェイルオーバーなどを含む高可用性機能として提供されています（どのイベントでフェイルオーバーが起きるか等も公式に記載）。 https://aws.amazon.com/rds/features/multi-az/
また、フェイルオーバー時間の目安（一般に60〜120秒など）も公式ドキュメントで説明されています（実際の時間は状況により変動）。 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html
試験対策：よく出る「責任はどっち？」の判断フロー
- サービスの種類を見抜く（IaaS寄り＝自分の責任が増える / Managed寄り＝AWSが肩代わりする範囲が増える）
- Shared Responsibility Modelで切る（AWSの責任＝クラウド“の”セキュリティ、利用者の責任＝クラウド“で”の設定とデータ）
- 可用性タスクに落とす（パッチ、バックアップ、冗長化、フェイルオーバー、監視のどれが問われているか）
責任共有モデルの全体像はAWS公式ページが最も確実です。 https://aws.amazon.com/compliance/shared-responsibility-model/
用語の注意（不確かな点の扱い）
(1) 確実に言えること
- 責任共有モデル（Shared Responsibility Model）はAWSが公式に提示しており、AWS側と利用者側の責任分界を理解することが試験でも重要です。 https://aws.amazon.com/compliance/shared-responsibility-model/
- EC2では利用者がゲストOSの更新やパッチ適用などを担う、という説明が公式にあります。 https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html
- RDS Multi-AZは高可用性の機能として自動フェイルオーバー等が公式に説明されています。 https://aws.amazon.com/rds/features/multi-az/
(2) 推測（確度と根拠）
- 「マネージド／アンマネージド」という言い方は、AWS公式の単一の定義語というより、責任共有モデルやサービス形態（IaaS/PaaS/サーバレスなど）を実務上わかりやすく説明するラベルとして使われることが多い、という理解が一般的です（確度：高め）。 根拠：AWS公式にあるのは責任共有モデルやWell-Architectedの指針であり、それらを踏まえた“運用責任の寄せ方”の説明として「managed/self-managed」が使われやすい。
(3) 不明点（追加で確認すべき点）
- すべてのAWSサービスを「マネージド／アンマネージド」の二択で厳密に分類する公式の一覧は、（少なくとも一般に参照される形では）見つけにくいことがあります。試験対策としては、各サービスの公式ドキュメント（責任範囲、可用性機能、SLA/機能説明）を参照して判断するのが安全です。
直前チェック（暗記より“判断”を優先）
- 「OSパッチは誰？」 → EC2なら基本的に利用者側（公式根拠あり）
- 「自動フェイルオーバーが標準？」 → RDS Multi-AZなどは機能として提供（公式根拠あり）
- 「複数AZに置くべき？」 → Well-Architected Reliabilityが推奨（公式根拠あり）
追加で可用性設計（Multi-AZ / Multi-Regionの考え方）をイメージで掴みたい場合、AWSのイベント資料も参考になります（一次情報：AWS配布資料）。 https://d1.awsstatic.com/events/jp/2021/summit-online/AWS-53_AWS_Summit_Online_2021_Thinking-about-Availability.pdf
まとめ
- 可用性は「止めない仕組み」。AWS試験では責任範囲とセットで問われやすい。
- 迷ったら責任共有モデルで整理：AWS側と利用者側の境界を把握する。 https://aws.amazon.com/compliance/shared-responsibility-model/
- EC2（アンマネージド寄り）は利用者責任が厚く、RDS Multi-AZ（マネージド寄り）は可用性機能が組み込まれやすい。