![Mind Map: AWS Well-Architected フレームワーク](https://www.mindmeister.com/image/xlarge/1738845343/mind-map-aws-well-architected.png)
1. W-A パフォーマンス効率 の柱
1.1. 設計原則
1.1.1. 高度なテクノロジーの民主化: 複雑なタスクをクラウドベンダーに委託する
1.1.2. わずか数分でグローバルに展開する
1.1.3. サーバーレスアーキテクチャを使用する
1.1.4. より頻繁に実験する
1.1.5. メカニカルシンパシーを重視する
1.2. 定義
1.2.1. ベストプラクティスの領域
1.2.1.1. 選択
1.2.1.1.1. PERF 1. パフォーマンスアーキテクチャの選択
1.2.1.1.2. PERF 2. コンピューティングアーキテクチャの選択
1.2.1.1.3. PERF 3. ストレージアーキテクチャの選択
1.2.1.1.4. PERF 4. データベースアーキテクチャの選択
1.2.1.1.5. PERF 5. ネットワークアーキテクチャの選択
1.2.1.2. 確認
1.2.1.2.1. PERF 6. ワークロードを進化させて新しいリソースを活用する
1.2.1.3. モニタリング
1.2.1.3.1. PERF 7. リソースをモニタリングして、それらが期待通りに機能していることを確認する
1.2.1.4. トレードオフ
1.2.1.4.1. PERF 8. トレードオフを使用してパフォーマンスを向上させる
2. W-A セキュリティ の柱
2.1. 設計の原則
2.1.1. 強力なアイデンティティ基盤を実装する
2.1.2. トレーサビリティを実現する
2.1.3. すべてのレイヤーでセキュリティを適用する
2.1.4. セキュリティのベストプラクティスを自動化する
2.1.5. 伝送中および保管中のデータを保護する
2.1.6. データに人の手を入れない
2.2. 定義
2.2.1. SEC 1. ワークロードを安全に運用する
2.2.1.1. ワークロードを安全に運用する
2.2.1.1.1. 脅威モデルを使用してリスクを特定し、優先順位をつける
2.2.1.1.2. 管理目標を特定および検証する
2.2.1.1.3. セキュリティ脅威に関する最新情報を入手する
2.2.1.1.4. セキュリティのレコメンデーションに関する更新情報を入手する
2.2.1.1.5. 新しいセキュリティサービスと機能を定期的に評価および実装する
2.2.1.1.6. パイプラインのセキュリティコントロールのテストと検証を自動化する
2.2.1.2. AWSアカウントの管理と分離
2.2.1.2.1. アカウントを使用してワークロードを分ける
2.2.1.2.2. AWS アカウントを保護する
2.2.1.2.3. アカウントを一元的に管理する
2.2.1.2.4. 制御を一括設定する
2.2.1.2.5. サービスとリソースを一括設定する
2.2.2. ベストプラクティスの領域
2.2.2.1. アイデンティティとアクセスの管理
2.2.2.1.1. SEC 2. アイデンティティ管理
2.2.2.1.2. SEC 3. 権限管理
2.2.2.2. SEC 4. 検出
2.2.2.2.1. 設定
2.2.2.2.2. 調査
2.2.2.3. インフラストラクチャの保護
2.2.2.3.1. SEC 5. ネットワークの保護
2.2.2.3.2. SEC 6. コンピューティングの保護
2.2.2.4. データ保護
2.2.2.4.1. SEC 7. データ分類
2.2.2.4.2. SEC 8. 保管中のデータの保護
2.2.2.4.3. SEC 9. 伝送中のデータの保護
2.2.2.5. SEC 10. インシデントへの対応
2.2.2.5.1. クラウドレスポンスの設計目標
2.2.2.5.2. 教育
2.2.2.5.3. 準備
2.2.2.5.4. シミュレーション
2.2.2.5.5. イテレーション
3. W-A 運用上の優秀性 の柱
3.1. 設計原則
3.1.1. 運用をコードとして運用
3.1.2. 定期的に、小規模な、元に戻すことができる変更を適用する
3.1.3. 運用手順を定期的に改善する
3.1.4. 障害を予想する
3.1.5. あらゆる運用上の障害から学ぶ
3.2. 定義
3.2.1. ベストプラクティスの領域
3.2.1.1. 組織
3.2.1.1.1. OPS 1. 組織の優先順位
3.2.1.1.2. 運用モデル
3.2.1.1.3. OPS 3. 組織カルチャー
3.2.1.2. 準備
3.2.1.2.1. OPS 4. テレメトリを設計する
3.2.1.2.2. OPS 5. 運用のための設計
3.2.1.2.3. OPS 6. デプロイのリスクを緩和する
3.2.1.2.4. OPS 7. 運用準備状況
3.2.1.3. 運用
3.2.1.3.1. OPS 8. ワークロードの状態の把握
3.2.1.3.2. OPS 9. 運用状態の把握
3.2.1.3.3. OPS 10. イベントへの対応
3.2.1.4. 進化
3.2.1.4.1. OPS 11. 学習、共有、改善
4. AWS Well-Architected フレームワーク - AWS Well-Architected フレームワーク
5. W-A コスト最適化 の柱
5.1. 設計の原則
5.1.1. クラウド財務管理を実装する
5.1.2. 消費モデルを導入する
5.1.3. 全体的な効率を測定する
5.1.4. 差別化につながらない高負荷の作業に費用をかけるのをやめる
5.1.5. 費用を分析し帰属関係を明らかにする
5.2. 定義
5.2.1. ベストプラクティスの領域
5.2.1.1. COST 1. クラウド財務管理を実践する
5.2.1.1.1. 機能オーナーシップ
5.2.1.1.2. 財務とテクノロジーのパートナーシップ
5.2.1.1.3. クラウドの予算と予測
5.2.1.1.4. コスト意識の高いプロセス
5.2.1.1.5. コスト意識を持つ文化
5.2.1.1.6. コスト最適化によるビジネス価値の数値化
5.2.1.2. 経費支出と使用量の認識
5.2.1.2.1. COST 2. ガバナンス
5.2.1.2.2. COST 3. コストと使用量のモニタリング
5.2.1.2.3. COST 4. リソースを削除する
5.2.1.3. 費用対効果の高いリソース
5.2.1.3.1. COST 5. サービスを選択する際にコストを評価する
5.2.1.3.2. COST 6. 正しいリソースタイプ、リソースサイズ、リソース数を選択する
5.2.1.3.3. COST 7. 最適な料金モデルを選択する
5.2.1.3.4. COST 8. データ転送を計画する
5.2.1.4. COST 9. 需要の管理とリソースの提供
5.2.1.4.1. ワークロードの分析
5.2.1.4.2. 需要の管理
5.2.1.4.3. 動的供給
5.2.1.5. COST 10. 継続的最適化
5.2.1.5.1. 新しいサービスを確認して実装する
6. W-A 信頼性 の柱
6.1. 設計の原則
6.1.1. 障害から自動的に復旧する
6.1.2. 復旧手順をテストする
6.1.3. 水平方向にスケールしてワークロード全体の可用性を高める
6.1.4. キャパシティーを推測することをやめる
6.1.5. オートメーションで変更を管理する
6.2. 定義
6.2.1. ベストプラクティスの領域
6.2.1.1. 基盤
6.2.1.1.1. REL 1. Serviice Quotas の管理と制約
6.2.1.1.2. REL 2. ネットワークトポロジを計画する
6.2.1.2. ワークロードのアーキテクチャ
6.2.1.2.1. REL 3. お客様のワークロードサービスアーキテクチャを設計する
6.2.1.2.2. REL 4. 障害を防ぐために分散システムでの操作を設計する
6.2.1.2.3. REL 5. 障害を軽減または耐えるために分散システムでの操作を設計する
6.2.1.3. 変更の管理
6.2.1.3.1. REL 6. ワークロードリソースをモニタリングする
6.2.1.3.2. REL 7. 需要の変化に適応するようにワークロードを設計する
6.2.1.3.3. REL 8. 変更を実装する
6.2.1.4. 障害の管理
6.2.1.4.1. REL 9. データをバックアップする
6.2.1.4.2. REL 10. 障害部分を切り離してワークロードを保護する
6.2.1.4.3. REL 11. コンポーネントの障害に耐えられるようにワークロードを設計する
6.2.1.4.4. REL 12. 信頼性をテストする
6.2.1.4.5. REL 13. 災害対策(DR)を計画する
6.2.2. 回復力(弾力性)、および信頼性のコンポーネント
6.2.2.1. 回復力
6.2.2.2. その他
6.2.2.2.1. 運用上の優秀性
6.2.2.2.2. セキュリティ
6.2.2.2.3. パフォーマンス効率
6.2.2.2.4. コスト最適化
6.2.3. 可用性
6.2.3.1. リクエストに基づいて可用性を計算する
6.2.3.2. ハードな依存関係を持つ可用性を計算する
6.2.3.3. 冗長コンポーネントの可用性を計算する
6.2.3.4. 依存するシステムの可用性を計算する
6.2.3.5. 可用性のコスト
6.2.4. 目標復旧時間(RTO)と目標復旧時点(RPO)
6.2.4.1. RTO
6.2.4.2. RPO
6.3. 可用性に対するニーズの理解
6.3.1. データプレーン
6.3.2. コントロールプレーン
6.4. 可用性目標の実装例
6.4.1. 単一リージョンのシナリオ
6.4.2. 複数リージョンのシナリオ