AWS Well-Architected フレームワークが更新されました。2023年4月10日

2023.04.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

AWS Well-Architected フレームワークのドキュメントが大幅に更新されました。
113 のベストプラクティスが更新、14のベストプラクティスが新しく追加されました。
さらに今回は日本語を含めた英語以外のドキュメントも同時更新されています。翻訳に携わった方々ありがとうございます。

残念ながら、何が新規で何が更新かが判断できなかったので、私のほうで気になる更新をピックアップして紹介します。

オペレーショナルエクセレンスの柱

冒頭で紹介したアナウンスブログには以下のように記述されています。

The Operational Excellence Pillar has a new best practice on enabling support plans for production workloads. This Pillar also has a major update on defining a customer communication plan for outages.

OPS10-BP05 を指しているものと思われます。
OPS10-BP05 には、システム停止時に顧客やステークホルダーに対して継続的に情報を提供する重要性が説明されています。
計画されたメンテナンスから予期せぬ規模の障害まで、状況に合わせたコミュニケーション計画をします。顧客によからぬ憶測をされないよう透明度の高い情報を提供します。

項番 更新内容
OPS01-BP03 ガバナンス要件を評価する
OPS01-BP04 コンプライアンス要件を評価する
OPS02-BP01 リソースには特定の所有者が存在する
OPS02-BP06 追加、変更、例外をリクエストするメカニズムが存在する
OPS02-BP07 チーム間の責任は事前定義済みまたは交渉済みである
OPS03-BP04 タイムリーで明確、かつ実用的なコミュニケーション
OPS03-BP05 実験の推奨
OPS04-BP01 アプリケーションテレメトリーを実装する
OPS04-BP03 ユーザーアクティビティテレメトリーを実装する
OPS04-BP04 依存関係のテレメトリーを実装する
OPS04-BP05 トランザクショントレーサビリティを実装する
OPS05-BP02 変更をテストし、検証する
OPS05-BP06 設計標準を共有する
OPS05-BP07 コード品質の向上のためにプラクティスを実装する
OPS07-BP01 人材能力の確保
OPS07-BP05 システムや変更をデプロイするために十分な情報に基づいて決定を下す
OPS07-BP06 本稼働ワークロード用のサポートプランを有効にする
OPS08-BP02 ワークロードのメトリクスを定義する
OPS08-BP03 ワークロードメトリクスを収集および分析する
OPS08-BP04 ワークロードメトリクスのベースラインを設定する
OPS10-BP05 システム停止時の顧客コミュニケーション計画を定義する
OPS11-BP01 継続的改善のプロセスを用意する
OPS11-BP04 ナレッジ管理を実施する

オペレーショナルエクセレンスの柱

セキュリティの柱

アナウンスブログには以下のように記述されています。

In the Security Pillar, we added a new best practice area, Application Security (AppSec). AppSec is complete with eight new best practices to guide customers as they develop, test, and release software, providing guidance on how to consider the tools, testing, and organizational approach used to develop software.

AppSec が章として追加されています。SEC11 が該当します。
開発ライフサイクルにセキュリティを組み込む重要性や手法が解説されています。
先進的な取り組みをしているチームではすでに当たり前かもしれません。これから取り込むチームには必見の内容だと感じました。
この章だけでも1本ブログ書けそうです。(ちらっちらっ)

  • セキュリティのトレーニング
  • 開発ライフサイクルにおけるテスト自動化
  • ペネトレーションテスト定期実行
  • 人間のコードレビュー
  • コード管理
  • デプロイパイプラインの構築
  • パイプラインセキュリティの定期的な評価
  • 開発者によるセキュリティを許可
項番 更新内容
SEC01-BP01 アカウントを使用してワークロードを分ける
SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける
SEC02-BP01 強力なサインインメカニズムを使用する
SEC02-BP02 一時的な認証情報を使用する
SEC02-BP03 シークレットを安全に保存して使用する
SEC02-BP05 定期的に認証情報を監査およびローテーションする
SEC03-BP02 最小特権のアクセスを付与します
SEC03-BP04 アクセス許可を継続的に削減する
SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析
SEC03-BP08 組織内でリソースを安全に共有する
SEC03-BP09 サードパーティーとリソースを安全に共有する
SEC04-BP01 サービスとアプリケーションのログ記録を設定する
SEC05-BP01 ネットワークレイヤーを作成する
SEC06-BP01 脆弱性管理を実行する
SEC07-BP01 ワークロード内のデータを特定する
SEC08-BP02 保管中に暗号化を適用する
SEC08-BP04 アクセスコントロールを適用する
SEC09-BP02 伝送中に暗号化を適用する
SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する
SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する
SEC11-BP03 定期的にペネトレーションテストを実施する
SEC11-BP04 手動のコードレビュー
SEC11-BP05 パッケージと依存関係のサービスを一元化する
SEC11-BP06 ソフトウェアをプログラムでデプロイする
SEC11-BP07 パイプラインのセキュリティ特性を定期的に評価する
SEC11-BP08 ワークロードチームにセキュリティのオーナーシップを根付かせるプログラムを構築する

セキュリティの柱

信頼性の柱

アナウンスブログには以下のように記述されています。

The Reliability Pillar has a new best practice on architecting workloads to meet availability targets and uptime service-level agreements (SLAs). We also added the resilience shared responsibility model to its introduction section.

REL11-BP07 が該当すると考えています。
SLA 定義は相当な難易度です。このドキュメントを参照すると、AWS の特性を理解しながら、 SLA を作成する手助けになるはずです。
SLA がある設計、設計がある SLA が必要でこれを省くことはアンチパターンになると考えます。
SLA 目標設定 → アーキテクチャ設計 → 運用改善 → SLA 監視 のループを構築しましょう。

項番 更新内容
REL01-BP01 サービスクォータと制約を認識する
REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する
REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する
REL01-BP04 クォータをモニタリングおよび管理する
REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
REL02-BP01 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する
REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する
REL09-BP02 バックアップを保護し、暗号化する
REL09-BP03 データバックアップを自動的に実行する
REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
REL10-BP03 単一のロケーションに制約されるコンポーネントのリカバリを自動化する
REL10_BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する
REL11-BP07 可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たす製品を設計する
REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する
REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する

信頼性の柱

パフォーマンス効率の柱

パフォーマンス効率の柱は更新だけのようです。
面白そうな項目を紹介します。
PFRF04-BP04 ではアクセスパターンごとのデータベースソリューション選択方法が紹介されています。
パフォーマンス、運用上のオーバーヘッド削減、スケーリングの最適化などを実現するために、アクセスパターンごとにデータベースを使い分けることを検討します。

項番 更新内容
PERF02_BP04 適切なサイジングによって必要な設定を決定する
PERF02_BP05 利用可能な伸縮性のあるリソースを使用する
PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する
PFRF04-BP04 アクセスパターンに基づいてデータストレージを選択する
PERF05-BP02 使用可能なネットワーク機能を評価する
PERF05_BP03 ハイブリッドワークロード用に適切なサイズの専用接続または VPN を選択する
PERF05-BP04 ロードバランシングと暗号化のオフロードを活用する
PERF05-BP05 パフォーマンスを高めるネットワークプロトコルを選択する
PERF05-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する
PERF05-BP07 メトリクスに基づいてネットワーク設定を最適化する

パフォーマンス効率の柱

コスト最適化の柱

ドキュメントの更新履歴に更新内容が明記されていました。

Best practices updated with prescriptive guidance and new best practices added. Question COST 11 added with new best practice COST11-BP01.

COST11-BP01 は運用の自動化をして管理タスクと人的労力を削減する説明です。
運用にかかるタスクごとのコストを算出し、優先順位を付け、人的総コストを計算します。 その後管理タスクは自動化効果の高いものから順次自動化を行います。その辺りの進め方が記述されています。

項番 更新内容
COST02_BP01 組織の要件に基づいてポリシーを策定する
COST02_BP02 目標およびターゲットを策定する
COST02_BP03 アカウント構造を実装する
COST02_BP05 コストコントロールを実装する
COST03_BP02 コストと使用状況に組織情報を追加する
COST03_BP04 組織のメトリクスを確立する
COST03_BP05 請求およびコスト管理ツールを設定する
COST04_BP01 ライフタイム全体にわたってリソースを追跡する
COST04_BP02 削除プロセスを実装する
COST04_BP03 リソースを削除する
COST04_BP04 自動的にリソースを削除する
COST04_BP05 データ保持ポリシーを適用する
COST05_BP03 各コンポーネントの詳細な分析を実行する
COST05_BP05 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する
COST05_BP06 異なる使用量について経時的なコスト分析を実行する
COST06_BP01 コストモデリングを実行する
COST06_BP03 メトリクスに基づいて自動的にリソースタイプ、リソースサイズ、リソース数を選択する
COST07_BP01 料金モデルの分析を実行する
COST07_BP02 コストに基づいてリージョンを選択する
COST07_BP05 マスターアカウントレベルで料金モデル分析を実行する
COST09_BP03 リソースを動的に供給する
COST10_BP01 ワークロードレビュープロセスを開発する
COST10_BP02 このワークロードを定期的に見直し、分析する
COST11_BP01 オペレーションのオートメーションを実行する

コスト最適化の柱

持続可能性の柱

アナウンスブログには以下のように記述されています。

In the Sustainability Pillar, we introduced a clear process for selecting Regions, as well as tools for right-sizing services and improving the overall utilization of resources in the AWS Cloud.

持続可能性の柱は今回大きな更新が入ったように思います。
6本の柱の中では最も新しく、また、抽象度が比較的高い柱となっていますが、今回の更新でより実務的なガイダンスが提供されたものと感じました。

項番 更新内容
SUS01_BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する
SUS02_BP01 ワークロードインフラストラクチャを動的にスケールする
SUS02_BP02 SLA を持続可能性の目標に合わせる
SUS02_BP03 未使用アセットの創出と維持の停止
SUS02_BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する
SUS02_BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する
SUS02_BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
SUS03_BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する
SUS03_BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする
SUS03_BP03 時間やリソースを最も多く消費するコード領域を最適化する
SUS03_BP04 デバイスや機器への影響を最適化する
SUS03_BP05 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する
SUS04_BP01 データ分類ポリシーを実装する
SUS04_BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する
SUS04_BP03 ポリシーを使用してデータセットのライフサイクルを管理する
SUS04_BP04 伸縮性とオートメーションを使用してブロックストレージまたはファイルシステムを拡張する
SUS04_BP05 不要なデータや重複するデータを削除する
SUS04_BP06 共有ファイルシステムまたはストレージを使用して共通データにアクセスする
SUS04_BP07 ネットワーク間でのデータ移動を最小限に抑える
SUS04_BP08 データは再作成が難しい場合にのみバックアップする
SUS05_BP01 ニーズに合わせて最小限のハードウェアを使用する
SUS05_BP02 影響が最も少ないインスタンスタイプを使用する
SUS05_BP03 マネージドサービスを使用する
SUS05_BP04 ハードウェアベースのコンピューティングアクセラレーターの使用を最適化する
SUS06_BP01 持続可能性の改善を迅速に導入できる方法を採用する
SUS06_BP02 ワークロードを最新に保つ
SUS06_BP03 ビルド環境の利用率を高める
SUS06_BP04 マネージド型 Device Farm を使用してテストする

持続可能性の柱

まとめ

AWS Well-Architected フレームワークは、テクノロジーの進歩、理論の確立、お客様の需要に対応しながら、かなりの頻度で更新されています。
常時キャッチアップしていくのは大変難しいですが、設計を作るタイミング、更新するタイミングで読み直していただくことをお勧めします。

以上、吉井 亮 がお届けしました。