AWS認定 クラウドプラクティショナーで混同しがちなやつまとめ


[AWS Certified Cloud Practitioner認定](https://aws.amazon.com/jp/certification/certified-cloud-practitioner/)の学習をしている中で
類似したサービスや用語が出てきて少し苦労したので勉強がてらまとめてみました。

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

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

# 思想（フレームワーク）

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

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

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

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

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

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

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

https://aws.amazon.com/jp/cloud-adoption-framework/

### 6つのパースペクティブ

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

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

## AWS Well-Architected Framework

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

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

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

https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc

### 6つの柱

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

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

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/the-pillars-of-the-framework.html


### AWS CAF と AWS Well-Architected Frameworkの違い

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

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

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

# 自動化

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

* **Elastic Beanstalk**
* **OpsWorks**
* **CloudFormation**

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

## Elastic Beanstalk

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

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

https://aws.amazon.com/jp/elasticbeanstalk/

## OpsWorks

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

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

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

https://aws.amazon.com/jp/opsworks/

## CloudFormation

:::note info
**インフラ構築のコード化と管理**
:::

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


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

https://aws.amazon.com/jp/cloudformation/


# セキュリティ

* **AWS WAF**
* **AWS Shield**
* **Amazon GuardDuty**

あとは

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

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

## AWS WAF

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

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

https://aws.amazon.com/jp/waf/

## AWS Shield

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

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

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

https://aws.amazon.com/jp/shield/

### AWS Shield と AWS WAFの違い

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

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

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

※ [AWS Shieldとは？AWS WAFとの違いやAdvancedの使い方を解説](https://business.ntt-east.co.jp/content/cloudsolution/column-85.html) より抜粋


## Amazon GuardDuty

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

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

https://aws.amazon.com/jp/guardduty/

https://www.wafcharm.com/jp/blog/aws-security-measure/#:~:text=Amazon%20GuardDuty%E3%81%AE%E4%BF%9D%E8%AD%B7%E7%AF%84%E5%9B%B2,GuardDuty%E3%81%AE%E7%9B%A3%E8%A6%96%E5%AF%BE%E8%B1%A1%E3%81%A7%E3%81%99%E3%80%82

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

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

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

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

※ [セキュリティグループとネットワークACLを比較する](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/infrastructure-security.html#VPC_Security_Comparison) より引用

# さいごに

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

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