AWS CAF 6つの視点を
やさしく読む
CAF は「会社」の話。
Well-Architected は「システム」の話。
は、正式には AWS クラウド導入フレームワークといいます。 と同じく、AWS が公開している読みものです。画面から作って使うサービスではありません。
2つはよく混同されます。どちらも AWS が出した考え方のガイドで、どちらも6つに分かれているからです。でも語っている対象がまったく違います。
| AWS CAF | Well-Architected | |
|---|---|---|
| 何の話か | 会社がクラウドを導入する準備と進め方 | 1つのシステムをどう設計・運用するか |
| 主語 | 会社、組織、部門 | システム、 |
| 6つの何 | ||
| 関わる人 | 、各部門のリーダー | アーキテクト、エンジニア |
本文の中で のように色が付いている言葉は、押すと画面の下に意味が出ます。知らない言葉で止まらずに読み進めてください。
＊引っ越しで考える
から AWS へ移ることを、今の家から新しい家へ引っ越すことに置き換えると、2つの違いがはっきりします。
CAF ＝ 引っ越し計画
家族が引っ越しをやり遂げるための段取りです。なぜ引っ越すのか、誰が何を担当するのか、予算はいくらか、どんな家にするのか、防犯はどうするのか、住み始めた後の手入れはどうするのか。
Well-Architected ＝ 家の設計基準
建てる家そのものが良い家かを測るものさしです。耐震、防犯、動線、省エネ、予算内かどうか、手入れのしやすさ。
引っ越し計画がしっかりしていても、家の設計が悪ければ住みにくくなります。逆に良い設計図があっても、家族の段取りができていなければ引っ越しは進みません。2つは対立するものではなく、役割が違うだけで、両方使います。
引っ越し計画にも「防犯」と「住んだ後の手入れ」が出てきますし、家の設計基準にも同じものが出てきます。同じように、セキュリティと運用は CAF と Well-Architected の両方にあります。この2語は見分けの決め手になりません。残りの4つで判定します。
＊6つの視点を1枚で
大事なのは、6つがビジネス系3つと技術系3つに分かれていることです。ここを押さえると混同がかなり減ります。
| 視点 | 代表的な問い | ひとことで |
|---|---|---|
| 1 ビジネス | クラウドで何の価値を生むのか | 戦略とお金の使いどころ |
| 2 人材 | 誰が、どんなスキルで動くのか | 人と文化 |
| 3 ガバナンス | 予算とリスクをどう統制するのか | ルールと管理 |
| 4 プラットフォーム | どんな基盤の上に作るのか | 作る側 |
| 5 セキュリティ | データと資産をどう守るのか | 守る体制 |
| 6 運用 | 安定して動かし続けるには | 回す側 |
順番に ビ・人・ガ ／ プ・セ・運。ビジネス、人材、ガバナンスがビジネス系。プラットフォーム、セキュリティ、運用が技術系です。前半は会社の上のほうの話、後半は実際に作って守って回す話だと思ってください。
日本語の問題文では、ビジネスが事業、人材が人員、運用が業務と書かれることがあります。「業務」と「事業」はまぎらわしいので注意してください。業務は運用、事業はビジネスです。
1ビジネス
クラウドを使って、会社は何を生み出すのか。
かみ砕くと
クラウドに投資したお金が、会社の目標につながっているかを見る視点です。技術の話ではなくもうけの話だと思ってください。新しいサービスを立ち上げて売上を伸ばす、データを分析して経営判断に使う、といったことがここに入ります。
関わるのは です。引っ越しで言えば「そもそも、なぜ引っ越すのか」を決めるところです。
この視点でやること
- クラウドで何を実現するかを決める
「とりあえず AWS を使ってみる」では、費用だけかかって成果が出ません。何を良くしたいのかを先に決めます。 - を見る
かけたお金に見合う戻りがあるかを判断します。ここが説明できないと、次の予算が付きません。 - データを価値に変える
集めただけのデータは費用でしかありません。分析して判断に使えて、はじめて価値になります。
この視点が弱いと
「クラウド化」そのものが目的になります。移行は終わったのに何が良くなったのか誰も説明できない、という状態です。
この言葉が出たらこの視点
2人材
誰が、どんなスキルで動くのか。
かみ砕くと
技術と文化の橋渡しをする視点です。クラウドは道具を入れ替えるだけでは使えるようになりません。使う人のスキルと、チームの動き方が変わって初めて回り始めます。
研修を受けている人にとっては、いちばん身近な視点かもしれません。研修そのものが、この視点の取り組みです。
この視点でやること
- スキルの差を埋める
今いる人が何をできて何をできないかを把握し、研修や実践の機会を用意します。 - チームの形を変える
作る人と動かす人が分かれていると、引き継ぎのたびに時間が失われます。同じチームで見る形（）に変えていきます。 - 変化への抵抗をやわらげる
やり方が変わることに不安を持つ人は必ずいます。押し切るのではなく、なぜ変えるのかを伝えて進めます。
この視点が弱いと
基盤だけが新しくなり、使い方が前のままになります。せっかく AWS に移したのに、結局これまでどおり手作業で運用している、という状態です。
この言葉が出たらこの視点
3ガバナンス
予算とリスクをどう統制するのか。
かみ砕くと
クラウド導入という取り組み全体に、ルールと歯止めをかける視点です。誰でも数分でサーバーを作れるのがクラウドの利点ですが、放っておけば費用も権限もばらばらになります。それを管理します。
ビジネス系に分類されますが、技術とビジネスを結びつける位置にあります。
この視点でやること
- お金の管理
誰がいくらまで使ってよいのか、想定を超えたときにどう気づくのかを決めます。 や はその道具です。 - リスクの管理
移行で何が起こりうるかを洗い出し、起きたときの備えを決めておきます。 - ルールを守れていることを示せるようにする
業界の規則や社内規程を守れている状態（）を保ち、それを記録で示せるようにします。 - データの扱いを決める
どのデータを誰が見てよいのか、どこに置いてよいのかを決めます。
この視点が弱いと
検証で作ったサーバーが消されずに残り、請求だけが増えていきます。誰が作ったものか分からず、消していいのかも判断できません。
この言葉が出たらこの視点
4プラットフォーム
どんな基盤の上に、どうやって作るのか。
かみ砕くと
ここから技術系です。会社が使う共通の土台を作る視点だと思ってください。個別のシステムをどう設計するかは Well-Architected の担当で、こちらは「その手前にある共通の基盤」を扱います。
この視点でやること
- 基盤の形を決める
ネットワークをどう区切るか、アカウントをどう分けるかといった、あとから変えにくい部分を決めます。 - 環境をコードで作れるようにする
手作業ではなく （ など）で作れる形にしておくと、同じ環境を何度でも用意できます。 - 直してから届くまでを自動にする
を整えると、書いたプログラムが自動で検査され、自動で反映されます。 - 古い作りを今のやり方に変える
そのまま移すだけ（）で終わらせず、などを使う形に変えていきます（）。
この視点が弱いと
チームごとにばらばらの作り方になります。人が異動するたびに一から覚え直しになり、共通の改善が全体に届きません。
この言葉が出たらこの視点
5セキュリティ
データと資産を、会社としてどう守るのか。
かみ砕くと
Well-Architected にも同じ名前の柱があります。違いは個別のシステムの設計ではなく、会社としての体制を作るところにあります。責任者は誰か、事故が起きたら誰がどう動くか、守れていることをどう確かめるか。そういう話です。
この視点でやること
- 誰が何にアクセスできるかを決める
の設定そのものより、誰に何の権限を渡す方針にするかを決めるのがこの視点です。 - 怪しい動きに気づけるようにする
のような仕組みを入れ、気づいたあと誰が対応するのかまで決めておきます。 - データを守る方針を決める
どのデータをするか、鍵を誰が管理するかを決めます。 - 事故のときの動き方を決めて、練習する
が起きてから考え始めると対応が遅れます。連絡先と手順を先に決め、一度試しておきます。
この視点が弱いと
システムごとにセキュリティの水準がばらばらになります。いちばん弱いところから破られるので、全体としては弱いところに合わせた強さしかありません。
この言葉が出たらこの視点
6運用
動かし続けるための体制を作る。
かみ砕くと
作ったものを、会社が求める水準で提供し続けるための視点です。プラットフォームが作る側なら、こちらは回す側です。
この視点でやること
- 今どうなっているかが見える状態にする
などで測り、想定外の問題も追える状態（）にしておきます。 - 障害が起きたときの流れを決める
誰が気づき、誰が動き、どこまで直したら終わりなのかを決めておきます。終わったらをします。 - 変更を管理する
いつ、誰が、何を変えるのかを決めた形で流します。もここに入ります。 - 止まったときに戻せるようにする
を取り、実際に戻せるかを試しておきます。どこまで守るかの物差しが です。
この視点が弱いと
障害のたびに人が集まって、その場のやり方で対応することになります。対応できる人が限られ、その人が休むと回りません。
この言葉が出たらこの視点
＊混同しやすい組み合わせ
6つの名前を覚えたあと、必ずここで詰まります。似た言葉が別の視点に出てくるからです。
ガバナンス ↔ 運用
ガバナンスはまだ動いていないものを、動かすまでの管理です。予算、リスク、進め方を決めます。運用はすでに動いているものを、止めないための管理です。監視、障害対応、パッチ。
お金とリスクと進め方ならガバナンス。監視と障害とパッチなら運用。
プラットフォーム ↔ 運用
プラットフォームは作る側。基盤を設計し、環境を用意し、開発の流れを整えます。運用は回す側。作ったものを見張り、変更を管理し、障害から戻します。
設計と構築と開発ならプラットフォーム。監視と維持と復旧なら運用。
ビジネス ↔ 人材
ビジネスは会社の目標の話。戦略、価値、収益。人材は働く人と組織の話。スキル、文化、チーム編成。
戦略と価値と収益ならビジネス。スキルと文化と研修なら人材。
CAF のセキュリティ ↔ Well-Architected のセキュリティ
CAF は会社としての体制。責任者を決め、方針を作り、対応の流れを整えます。Well-Architected はこのシステムの設計。権限の設計、暗号化、ログの取得。
セキュリティという語だけでは決められません。主語が会社か、システムかで決めます。
＋進め方は4つの段階
CAF は6つの視点だけでなく、どんな順番で進めるかも示しています。これをと呼び、4つの段階に分かれます。
| 段階 | やること | 問題文のヒント |
|---|---|---|
| 想像 | クラウドで実現したい成果を見つけ、優先順位を付ける | 目標を特定、機会の優先順位 |
| 整合 | 6つの視点を使って、足りないの差を見つける | 視点を用いてギャップを特定 |
| 発進 | を本番で実施し、価値を示す | パイロット、本番で実証 |
| 拡大 | うまくいったやり方を組織全体に広げる | 全社に展開、継続的に実現 |
6つの視点を実際に使うのは、2つ目の「整合」です。今の会社に何が足りないかを、6つの視点それぞれで確かめます。ここがつながると、視点が単なる暗記項目ではなくなります。
選択肢に「評価」「移行準備」「移行とモダナイズ」が混ざっていることがあります。これは AWS が別に示している移行の進め方で、CAF の4段階とは違うものです。CAF の段階を聞かれたら、想像・整合・発進・拡大の4つから選びます。
ついでに押さえる言葉
CAF にはとという言葉も出てきます。出題は多くありませんが、選択肢に混ざると視点と紛らわしくなります。視点は誰が考えるか、ドメインは何を変えるか、成果は何が得られるかと整理しておけば区別できます。
✓CAF か Well-Architected か
試験でも実務でも、いちばん問われるのがこの見分けです。次の順に見ていけば決められます。
| 順 | 見るところ | 結論 |
|---|---|---|
| 1 | 「柱」「ワークロード」「アーキテクチャのレビュー」がある | Well-Architected |
| 2 | 「視点」「クラウド導入」「移行の計画」「組織」がある | CAF |
| 3 | 選択肢に「人材」「ガバナンス」「プラットフォーム」「ビジネス」がある | CAF の視点 |
| 4 | 選択肢に「信頼性」「パフォーマンス効率」「コスト最適化」「持続可能性」がある | Well-Architected の柱 |
| 5 | 手がかりが「セキュリティ」「運用」しかない | 主語で決める。会社なら CAF、システムなら Well-Architected |
CAF だけにあるのはビジネス、人材、ガバナンス、プラットフォーム。Well-Architected だけにあるのは信頼性、パフォーマンス効率、コスト最適化、持続可能性。セキュリティと運用は両方にあるので、この2語で判定してはいけません。
Well-Architected の6本の柱については こちらの記事 で1本ずつ扱っています。あわせて読むと、この見分けが定着します。
✓総仕上げ：仕分け
シナリオを読んで、どの視点の話か、あるいはどちらのフレームワークの話かを選んでください。
この記事で出てきた言葉は、色の付いた部分を押せばいつでも読み返せます。