AWS Certified Cloud Practitioner認定の学習をしている中で
類似したサービスや用語が出てきて少し苦労したので勉強がてらまとめてみました。

もし要望があれば追加しようと思うのでコメントなどいただけますと幸いです。
いいねとストックも励みになりますので是非！

記事作成の効率化と推敲のため、この記事は一部Claude（生成AI）を使用して生成した箇所があります。
自分が理解した内容と公式ドキュメントなどをもとに内容のチェックはしていますが、正確性を欠く内容が含まれる可能性もございますので必ず原典を併せて確認するようにしてください。

思想（フレームワーク）

AWS クラウド導入フレームワーク (AWS CAF)
AWS Well-Architected Framework

問題を解く際、この2つでまず混乱しました。
しかもフレームワークということで具体的なサービスや事例をイメージしにくいという点で覚えるのが大変です。

特に「6つのパースペクティブ」「6つの柱」この辺りは覚え辛いですし、量も多いのでしんどい部分です。
しかし、頻出の内容なので頑張って覚えましょう！

AWS クラウド導入フレームワーク (AWS CAF)

組織がクラウド導入を効果的に計画し実行するための包括的なガイドライン

AWS CAFというフレームワークに則ることで、クラウド導入の複雑さを軽減し、ビジネス成果を最大化することができるというものです。

クラウドを導入していなかった組織がこれから「クラウドに移行するぞ〜」という時に使うもの、というイメージで自分は覚えています。

6つのパースペクティブ

AWS CAFは、クラウド導入を6つの主要な観点（パースペクティブ）から考察します。
それぞれの観点における機能とステークホルダーは以下の通りです。

	機能	主要ステークホルダー
ビジネス	クラウド投資とデジタルトランスフォーメーションの成功を結びつける	CEO, CFO, COO, CIO, CTO
人材	組織文化、構造、スキルを進化させ、クラウド導入を加速する	CIO, COO, CTO, クラウドディレクター, 部門横断リーダー
ガバナンス	クラウド導入の利益最大化とリスク最小化をバランス良く管理する	CTO, CIO, CFO, CDO, CRO
プラットフォーム	スケーラブルなクラウドプラットフォームの構築とワークロードの最適化を行う	CTO, テクノロジーリーダー, アーキテクト, エンジニア
セキュリティ	クラウド環境でのデータとワークロードの保護を確保する	CISO, CCO, 内部監査リーダー, セキュリティアーキテクト, エンジニア
オペレーション	ビジネスニーズに合わせたクラウドサービスの効率的な運用を実現する	インフラ・オペレーションリーダー, SRE, ITサービスマネージャー

AWS Well-Architected Framework

アーキテクチャに関するベストプラクティスを提供するフレームワーク

AWS Well-Architected Frameworkは、いくつかの基本的な質問に答えると、アーキテクチャでクラウドのベストプラクティスがどの程度実践できているかを知り、改善のためのガイダンスを得ることができるというものです。

後ほど両フレームワークの違いを説明しますが、
AWS Well-Architected Frameworkは個別のワークロードやシステムの設計に焦点を当てているという点でAWS CAFと違います。

6つの柱

AWS Well-Architected Frameworkには6つの柱という、安定した効率的なシステムを作成するための観点があります。

柱	焦点	キーポイント
運用上の優秀性 (Operational Excellence)	ビジネス価値を提供するシステムの実行とモニタリング	• プロセスと手順の自動化 • 変更管理 • 障害対応
セキュリティ (Security)	情報、システム、資産の保護	• データ保護 • アクセス管理 • インシデント対応 • コンプライアンス
信頼性 (Reliability)	システムの回復力と可用性の確保	• 障害からの自動回復 • スケーリング • 変更管理
パフォーマンス効率 (Performance Efficiency)	コンピューティングリソースの効率的な使用	• 適切なリソースの選択 • モニタリング • 需要に応じたスケーリング
コスト最適化 (Cost Optimization)	不要なコストの回避と最小限のリソース使用	• 適切なリソースタイプとサイズの選択 • 需要と供給の管理 • 支出の分析
持続可能性 (Sustainability)	環境への影響の最小化	• エネルギー効率の高いリソースの使用 • 使用量の最適化 • 持続可能な実践の採用

AWS CAF と AWS Well-Architected Frameworkの違い

AWS CAFはより広範な組織的視点を提供し、AWS Well-Architected Frameworkはより詳細な技術的ガイダンスを提供している

それぞれの特徴は以下の表でまとめています。

特徴	AWS CAF	AWS Well-Architected Framework
主な目的	クラウド導入の全体的な戦略とプロセスをガイド	クラウド上のアーキテクチャの設計と運用のベストプラクティスを提供
焦点	組織全体のクラウド戦略と変革	個別のワークロードやシステムの最適化
適用範囲	ビジネス、人材、ガバナンスなど組織全体	主に技術的な側面（運用、セキュリティ、パフォーマンスなど）
主な構成要素	6つのパースペクティブ（ビジネス、人員、ガバナンス、プラットフォーム、セキュリティ、オペレーション）	6つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）
適用タイミング	クラウド導入の計画段階から実行、最適化まで	主にアーキテクチャの設計、実装、運用段階
主なユーザー	経営陣、IT部門のリーダー、プロジェクトマネージャー	アーキテクト、開発者、運用チーム
評価方法	組織のクラウド導入の準備状況や成熟度を評価	具体的なワークロードやアーキテクチャを評価

自動化

次は、AWS上の環境構築の自動化サービスについてです。

Elastic Beanstalk
OpsWorks
CloudFormation

初見ではこれらのサービスが少しややこしいと思いました。

Elastic Beanstalk

アプリケーションのデプロイと管理の簡素化

AWS Elastic Beanstalkを使うことで、アプリケーションのデプロイを自動的に、かつ簡単に行うことができるようになります。
WEBアプリケーションのコーディングに時間を割くため、インフラ構築を短時間で行いたい場合などで重宝されます。

OpsWorks

アプリケーションとサーバの構成管理

AWS OpsWorksはサーバの構成管理サービスです。

ChefやPuppetというマネージド型インスタンスを利用してより詳細な構成管理を行うことができ、CloudFormationとElastic Beanstalkの中間的な位置づけのサービスになります。

CloudFormation

インフラ構築のコード化と管理

AWS CloudFormationを使えば、インフラストラクチャをコードとして扱い管理することができます。
コード化ができるため、テンプレートしておくことで同じ環境何度も手軽に構築ができます。

Elastic BeanstalkやOpsWorksと異なり、CloudFormationではほとんど全てのAWSのリソースの構築や設定を行えるので、最も自由度が高いサービスとなります。

セキュリティ

AWS WAF
AWS Shield
Amazon GuardDuty

あとは

セキュリティグループ
ネットワークACL

辺りが個人的に混乱しがちなポイントでした。それぞれ違いをまとめます。

AWS WAF

Webアプリケーションを特定の攻撃 （DDoS、SQLインジェクション、クロスサイトスクリプティングなど）から保護

AWS WAFはWebアプリケーションファイアウォールと呼ばれるセキュリティサービスで、Webアプリケーションを特定の攻撃から保護します。

AWS Shield

マネージド型のDDoS保護サービスで、AWSで実行しているアプリケーションを保護

AWS Shieldは、DDoS攻撃からアプリケーションを保護するセキュリティサービスです。

AWS Shieldのプランとして、AWS Shield StandardとAWS Shield Advancedの2種類があります（AWS Shield Standardは無料で使用可能）。

AWS Shield と AWS WAFの違い

どちらもアプリケーションを保護するものなので混同しがちですが、
AWS ShieldとAWS WAFは以下のように機能するレイヤーと攻撃の対象が異なります。

これらのサービスは併用が可能なので、必要に応じて組み合わせて多層防御を実現することができます。

	AWS Shield	AWS WAF
レイヤー	レイヤー3 レイヤー4 レイヤー7(AWS Shield Advancedのみ)	レイヤー7
対象攻撃	DDos攻撃	DDos攻撃 SQLインジェクションクロスサイトスクリプティングなど

※ AWS Shieldとは？AWS WAFとの違いやAdvancedの使い方を解説より抜粋

Amazon GuardDuty

AWS環境全体で悪意のあるアクティビティや不正な動作を継続的に監視する脅威検出サービス

Webアプリケーションの保護はAmazon GuardDutyの対象外です。
この辺りがAWS ShieldやAWS WAFと異なる点と認識しておけば良いと思います。

セキュリティグループとネットワークACL

セキュリティグループはインスタンスレベル、ネットワークACLはサブネットレベルで動作する
セキュリティグループはステートフル、ネットワークACLはステートレス

セキュリティグループはパケットの通過を許可するかどうかのある種のメモリーを持っており（＝ステートフル）、
ネットワークACLは境界を通過する全てのパケット1つ1つをチェックします（＝ステートレス）。

セキュリティグループ	ネットワークACL
インスタンスレベルで動作	サブネットレベルで動作
インスタンスと関連付けられている場合にのみインスタンスに適用	関連付けられているサブネットにデプロイされているすべてのインスタンスに適用
ルールの許可のみサポート	ルールの許可と拒否がサポート
トラフィックを許可するかどうかを決める前に、すべてのルールを評価	トラフィックを許可するかどうかを決定する際は、最も低い番号のルールから順にルールを評価
ステートフル: ルールに関係なく、リターントラフィックが許可される	ステートレス: リターントラフィックは、ルールで明示的に許可する必要がある

※ セキュリティグループとネットワークACLを比較するより引用

さいごに

以上、個人的に混同してしまいがちなAWSのサービスについてまとめてみました。

ただ説明書きを覚えるだけではイメージがし辛く定着もしないので、
各サービスの相違点を意識して覚えるように意識するとより覚えやすくなると思いました！