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

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

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