AWS Well-Architected Framework の変更（2023年4月10日版）のまとめ

こんにちは！
最近長女が小学校に入学して、生活パターンの変化に追従しようと頑張っているかめでございます。
このたび、以下のブログにてアナウンスがあったとおり、2023年4月10日に AWS Well-Architected Framework が大幅に更新されました！

Announcing updates to the AWS Well-Architected Framework

今回は、この変更に関して見ていきたいと思います。

AWS Well-Architected Framework とは

まず、そもそも AWS Well-Architected Frameworkとは何かをおさらいしてみます。
そんなもんわかってるよ、って方はこの章はスキップしていただいて構いません。

AWS Well-Architected Frameworkは、Amazon Web Services（AWS）が設計したベストプラクティス、ガイドライン、原則のセットで、安全、高パフォーマンス、弾力性、効率性の高いクラウドインフラとアプリケーションを構築できるよう支援してくれるナレッジ集となります。このフレームワークは、以下の5つの「柱」を中心に構築されています。

• オペレーショナルエクセレンス（運用上の優秀性）
• セキュリティ
• 信頼性
• パフォーマンス効率
• コスト最適化
• 持続可能性

AWS Well-Architected Frameworkに従うことで、ワークロードはクラウドに最適化されたシステムを構築・維持し、パフォーマンス、セキュリティ、効率性を向上することができます。
また、対応できていない項目があったとしても、それに応じたワークロードの抱えるリスク（高、中、低）も可視化することができます。

AWS Well-Architected Frameworkは定期的に更新されるのですが、今回比較的大きな変更が入ったため、本ブログではそれを調査してみました。

変更（2023年4月10日版）の概要

Announcing updates to the AWS Well-Architected Framework

のブログによると、それぞれの柱で以下のような変更が行われているとありました。（日本語訳）
パフォーマンスについては概要では触れられていませんが、小さな変更が入っています。

オペレーショナルエクセレンスの柱には、本番ワークロードのサポートプランの有効化に関する新しいベストプラクティスがあります。また、この柱では、停電時の顧客とのコミュニケーションプランの定義についても、大幅に更新されています。

セキュリティの柱では、新しいベストプラクティス領域であるアプリケーションセキュリティ（AppSec）が追加されました。AppSecは、お客様がソフトウェアを開発、テスト、リリースする際に、ソフトウェア開発に使用するツール、テスト、組織的アプローチを考慮するためのガイダンスを提供する8つの新しいベストプラクティスで完結します。

信頼性の柱では、可用性目標と稼働率サービスレベル合意（SLA）を満たすためのワークロードのアーキテクチャに関するベストプラクティスを新たに追加しました。また、「レジリエンス共有責任モデル」を導入セクションに追加しました。

コスト最適化の柱では、コスト最適化のための業務の自動化やデータ保持ポリシーの徹底に関するベストプラクティスを新たに追加しました。

サステナビリティの柱では、リージョンを選択するための明確なプロセスや、サービスをライトサイジングしてAWSクラウドのリソース全体の利用率を向上させるためのツールを紹介しました。

それでは、具体的にどういうベストプラクティスの変更が入ったのか見ていきたいと思います。

共通の変更点

今回のアップデートで変更があった各ベストプラクティスには、共通して以下の変更がなされています。

• 「望ましい結果」が新規追加され、具体的にどう状態になっていれば良いのかのイメージが付きやすくなった。
• 「一般的なアンチパターン」「このベストプラクティスを確立する利点」がより詳しく具体的な記載になった。
• 「実施案内」にお客様事例と実装手順と実施計画の労力のレベルが新規追加された。

これらの変更により、よりそれぞれのベストプラクティスに対してどう対処すれば良いのかが事例も含めて記載されており、とても理解しやすくなっていると感じました。
逆に、変更の無かったベストプラクティスに関しては上記情報の追記はありません。

（全ベストプラクティスにもこのような情報が追記されると非常にうれしいのですが、、、、）

それでは、次に各柱個別に変更点を見ていきたいと思いますが、上記のように共通の変更がなされている以上に比較的大きな変更が入っていると思われるものを中心に解説していきたいと思います。

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

OPS07-BP06

新規となります。
項目名は「本番ワークロードのサポートプランを作成する」です。
内容としては、ワークロードが依存している外部ソフトウェア、外部サービスを可視化したうえで、それらに問題が発生した場合にサービスのニーズを満たすように優良のサポートプランのようなオプトインでのサポートプランの利用も含めて計画を立てるという内容になります。

OPS10-BP05

述べられている内容のスコープに若干の変更が見られます。
旧版の項目名は「プッシュ通知を有効にする」であったのに対し、更新版は「停止のための顧客コミュニケーション計画を定義する」となっています。
旧版でははワークロードに対して異常が発生したときに気づけるレベルを目指していたのが、更新版では、より広範囲にお客様に対するコミュニケーション方法・計画にまでスコープを広げています。

セキュリティの柱

SEC01-BP02

述べられている内容の方向性に若干の変更が見られます。
項目名が旧版「安全な AWS アカウント」から更新版「アカウントの root ユーザーとプロパティを保護する」となり、元はAWSアカウント（Organizations含む）全体の安全性向上を目的とするベストプラクティスであったのが、更新版ではrootアカウントの安全性向上にスコープが絞られています。
特にAWS Config の AWS Well-Architected Security Pillar コンフォーマンス パックやControtTowerで利用できる「強く推奨されるコントロール」の利用が推奨されるなど、より強くrootアカウントの安全性が保証されるような内容となっています。

SEC01-BP07

述べられている内容の方向性に若干の変更が見られます。
項目名が旧版「脅威モデルを使用してリスクを特定し、優先順位を付ける」から更新版「脅威モデルを使用して脅威を特定し、軽減策に優先順位を付ける」となり、表現としてリスクよりも脅威そのものに重点を置かれたような印象です。
内容としては、旧版では曖昧だった「脅威モデリング」の手法についても触れられており、より具体的に脅威分析が出来るようになっています。

SEC03-BP09

新規追加されています。
項目名は「第三者とリソースを安全に共有する」となり、組織外のAWSアカウントと安全にリソース共有を行う際のベストプラクティスが述べられています。
例えばIAMロールを使用し、外部IDを併用する、といった内容です。

SEC11-BP01

新規追加されています。
項目名は「アプリケーション セキュリティのトレーニング」となり、開発計画の早期の段階でシフトレフト的にセキュリティ要件に関して分析を進めるよう推奨されています。

SEC11-BP02

新規追加されています。
項目名は「開発およびリリースのライフサイクル全体でテストを自動化する」となり、開発およびリリースのライフサイクル全体でセキュリティテストを自動化することが推奨されています。

SEC11-BP03

新規追加されています。
項目名は「定期的な侵入テストを実施する」となり、定期的にブラックボックス的に侵入テストを実行することにより、自動テストや手動テスト、およびコードレビューでは発見できないような、セキュリティリスクを発見することが出来ます。
対策できない場合のリスクレベルは高となります。

SEC11-BP04

新規追加されています。
項目名は「手動コードレビュー」となり、コードレビュープロセスを経ることでコードの品質向上や、レビューイのスキルアップに役立てることが出来ます。
今回はセキュリティの柱に入っていますが、信頼性やパフォーマンスにも影響する重要なベストプラクティスであると思います。

SEC11-BP05

新規追加されています。
項目名は「パッケージと依存関係のサービスを一元化する」となり、ソフトウェアの利用パッケージの可視化について述べられています。
近年米国大統領令によって注目されているSBOMの利用などにも関わるでしょう。

SEC11-BP06

新規追加されています。
項目名は「プログラムによるソフトウェアの展開」となり、デプロイが失敗したり、人為的エラーによって予期しない問題が発生したりするリスクを低減・回避出来ます。
セキュリティ面で言うと人が作業を行うことによる「記録に残り難い作業」をなくすことにより、セキュリティリスクを低減できるものと考えられます。
対策できない場合のリスクレベルは高となります。

SEC11-BP07

新規追加されています。
項目名は「パイプラインのセキュリティ プロパティを定期的に評価する」となり、CI/CDパイプラインにおける、一種のサプライチェーンリスクマネジメントになります。
具体的な内容としては、AWS IAM Access Analyzer を用いたパイプラインに対する最小権限IAMポリシーの割り当てが一つの例として挙げられています。
対策できない場合のリスクレベルは高となります。

SEC11-BP08

新規追加されています。
項目名は「ワークロード チームにセキュリティのオーナーシップを組み込むプログラムを構築する」となります。
セキュリティのオーナシップを組み込むって何？と考えてしまいましたが、端的に言うと、セキュリティに関する設計はセキュリティチームのような専門部隊にお任せするのでは無く、一般の開発者レベルで行えるようにしましょう、という内容と読めます。
これは私も思うところがあり、セキュリティチーム、ワークロードチーム、という風に分かれてしまうと、セキュリティチームはワークロードに関する要件の理解が薄く、対してワークロードチームはセキュリティに関する知見が薄いため、双方ともベストなセキュリティ対策が検討できないと言う状況になってしまいがちかと思います。
ワークロードチームが要件およびセキュリティに対する知識両方を持ちうることで、ベストなセキュリティ設計を目指しましょう、という内容なのだと思います。

信頼性の柱

REL11-BP07

新規となります。
項目名は「可用性の目標と稼働時間のサービス レベル アグリーメント (SLA) を満たすように製品を設計する」となり、SLAを設定することにより、ビジネスおよび顧客の期待を満たすことができるとあります。

REL13-BP02

内容に大きな変化はありませんが、難易度の高いであろうDR戦略に関して、具体的なアーキテクチャ設計事例が追加されています。
特に、比較的新しいサービスであるElastic Disaster Recovery（DRS）の利用についても触れられていますため、旧来のAWSのDR対策アーキテクチャはDRSを用いるとするとどう変化するか？は頭に入れておいた方が良さそうです。

パフォーマンス効率の柱

PERF02-BP06

内容に大きな変化はありませんが、項目名が旧版「メトリックに基づいてコンピューティングのニーズを再評価する」から更新版「メトリックに基づいてコンピューティングのニーズを継続的に評価する」と変更されており、継続的に評価することを推奨するという内容に変更されています。

コスト最適化の柱

COST03_BP02

項目名が旧版「コスト属性カテゴリを特定する」から更新版「コストと使用量に組織情報を追加」と変更されていますが、具体的に組織としてコストを特定できるようなベストプラクティスである全体的な方向性は変わらないようです。
他、事例は具体化されており、わかりやすくなっています。

COST03_BP04, COST03_BP05

COST03_BP04については、項目名が旧版「請求およびコスト管理ツールの構成」に対し更新版「組織の指標を確立する」となっています。
COST03_BP05については、項目名が旧版「コストと使用量に組織情報を追加」に対し更新版「請求およびコスト管理ツールを構成する」となっています。
旧版に記載されているベストプラクティスとしては、Cost ExplorerとBudgetsを構成するという内容であったのに対し、更新版ではよりその目的に近いような記載となっています。
旧版でのベストプラクティスであったCost ExplorerとBudgetsの利用に関しては、COST03_BP05に移動しています。
旧版のCOST03_BP04とCOST03_BP05を合わせたときに達成できる内容は、更新版でもCOST03_BP04とCOST03_BP05でトータルとしては同じ内容にはなっていると思いますが、更新版の書き方として、COST03_BP04として達成すべき目標、COST03_BP05としてその手段、といったように明確に分かれているような記載になっています。
また、旧版のCOST03-BP05のリスクレベルは低であったのに対し、更新版のリスクレベルは高となっています。

COST04_BP05

新規追加されています。
項目名は「データ保持ポリシーを実施する」で、いわゆるデータのライフサイクルを定義し、それに合わせて削除処理を実施するという内容のベストプラクティスとなっています。

COST11_BP01

新規追加されています。
項目名は「運用の自動化を行う」で、AWSサービス利用量だけではなく運用にかかる人的コスト・リスクも含めて、いわゆるTCO最適化を行いましょう、といった内容となっています。
具体的には、AWS BackupやCloudFormation、EventBridge、Lambda、・・・といったマネージドサービスを積極的に利用することで、運用にかかるリスクとコストを低減させる、といったものとなります。

持続可能性の柱

SUS01_BP01

項目名が旧版「アマゾンの再生可能エネルギー プロジェクトの近くの地域、および他の場所 (または地域) よりも低い炭素強度がグリッドで公開されている地域を選択します」に対し更新版「ビジネス要件と持続可能性の目標の両方に基づいて地域を選択する」となっています。
更新版は、旧版では考慮されていないビジネス要件も考慮すべきという内容となっています。
旧版は単にアマゾンの再生可能エネルギー プロジェクトの近くのリージョンを選択すべきという内容であったため、さすがにビジネス要件を考慮した上でないといけないということで、あるべき姿になったという印象です。

SUS02_BP06

新規追加されています。
項目名は「需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する」で、内容としてはワークロードの時系列的な負荷を平滑化することでリソースのプロビジョニング容量を最小化するような設計をすべき、ということが述べられています。
ワークロードの負荷が大きく変動すると、最大の負荷をサポートするためにリソースのプロビジョニング容量を大きくしがちですが、要件によってはリクエストをキューイングし非同期化することでワークロードの負荷を平滑化することが出来ます。これによってプロビジョニング容量を低く抑えることができ、結果として環境への負荷を低減させることが出来ます。

SUS04_BP04

項目名が旧版「ブロック ストレージのオーバー プロビジョニングを最小限に抑える」から更新版「弾力性と自動化を使用して、ブロック ストレージまたはファイル システムを拡張する」に変更されています。
旧版では、最初から大きなストレージ容量をプロビジョニングするのでは無く、定期的に見直し行いストレージのプロビジョニング容量をその時点での最小とするよう進められていたのですが、更新版ではEBS Elastic Volumesを用いる等で自動化しよう、という内容になります。

SUS05_BP04

項目名が旧版「GPU の使用を最適化する」から更新版「ハードウェア ベースのコンピューティング アクセラレータの使用を最適化する」に変更されています。
旧版では内容がGPUの利用のみ述べられていたのに対し、更新版ではGPUだけではなく、FPGAやTitanium、 Inferentiaなど、ワークロードの特性に応じてより最適化されたインスタンスを用いることが推奨されています。

新旧ドキュメント リンク

参考までに、変更のあったベストプラクティスに対する、新旧の各ドキュメントに対するリンクをまとめてみました。

まとめ

今回行われた変更では、近年のワークロードを取り巻く状況の変化に加えて、比較的新しく登場したAWSサービスの利用もベストプラクティスとして推奨されるようになっています。
今後もこのWell-Architected Frameworkを積極的に活用して、品質の高いワークロードの構築を目指していきたいと思います！

kame