AWS Well-Architected Framework 2020/07 の更新点まとめ

2020/7/10 のアップデートで「AWS Well-Architected Framework」が更新されました。
ホワイトペーパーの更新履歴いわく 「ほとんどの質問と回答を見直して書き換えました」 というくらいの、大々的な更新のようです。
一体何が変わったのかをまとめ、執筆時点において、AWS を利用する場合に重視すべきことは何かを紐解いてみます。

定義

「AWS Well-Architected フレームワークの柱」 は5本ありますが、これらの定義が微妙に変わっています。

• 運⽤上の優秀性
  • (旧) ビジネス価値を提供し、サポートのプロセスと⼿順を継続的に向上させるためにシステムを稼働およびモニタリングする能⼒
  • (新) 開発をサポートし、ワークロードを効率的に実⾏し、運⽤に関する洞察を得て、ビジネス価値をもたらすためのサポートプロセスと⼿順を継続的に改善する能⼒
• セキュリティ
  • (旧) リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能
  • (新) データ、システム、資産を保護して、クラウドテクノロジーを活⽤し、セキュリティを向上させる機能
• 信頼性
  • (旧) インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や⼀時的なネットワークの問題といった中断の影響を緩和する能⼒
  • (新) 期待されるタイミングで、意図した機能を正確かつ⼀貫して実⾏するワークロードの能⼒で、ライフサイクル全体を通じてワークロードを運⽤およびテストする機能を含む
• パフォーマンス効率 (変更なし)
  • システムの要件を満たすためにコンピューティングリソースを効率的に使⽤し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能⼒
• コスト最適化 (変更なし)
  • 最も低い価格でシステムを運⽤してビジネス価値を実現する能力

また、製品ライフサイクルにおける、マイルストーンの定義が変更されています。

• マイルストーン
  • (旧) 設計、テスト、サービス開始、運⽤
  • (新) 設計、テスト、ゴーライブ、本番

フレームワークの5本の柱

次に5本の柱にフォーカスしますと、それぞれの柱の定義が変わったことから、柱を構成する各項目の定義にも変化が見られます。

運用上の優秀性

設計原則

「設計原則」 が6つ→5つに変わり、ドキュメント作成を自動化して注釈をつける原則がなくなりました。

• (旧) 運⽤をコードとして実⾏する、ドキュメントに注釈を付ける、定期的に・⼩規模な・元に戻すことができる変更を適⽤する、障害を予想する、運⽤上のすべての障害から学ぶ
• (新) 運⽤をコードとして実⾏する、⼩規模かつ可逆的な変更を頻繁に⾏う、運⽤⼿順を定期的に改善する、障害を予想する、運⽤上のすべての障害から学ぶ

定義

ベストプラクティスの分野に 「組織」 が追加され、4つとなりました。

• (旧) 準備、運⽤、進化
• (新) 組織、準備、運⽤、進化

ベストプラクティス

前述の通り 「組織」 が追加されています。

• (新) 組織
  • チームは、ビジネスの成功を実現する優先順位を設定するために、ワークロード全体、その役割、共有されるビジネス⽬標に関する理解を共有する必要がある
  • 優先順位を明確に定義する
  • 社内外の顧客のニーズを評価し、重点領域を決定する
  • 顧客ニーズを評価する
  • 組織のガバナンスに基づくガイドライン、義務、規制コンプライアンス要件、業界標準などの外部要因を認識する
  • 内部ガバナンスおよび外部コンプライアンス要件への変更を識別するメカニズムを検証する
  • 優先順位を定期的に確認する
  • ビジネスに対する脅威を評価して管理する
  • 競合する利益のトレードオフや代替アプローチを評価する
  • メリットとリスクを管理し、⼗分な情報に基づいて重点領域に関する意思決定を下す
  • チームはビジネスの成果を達成するうえでの役割を理解する
  • 他のチームの役割を理解し、⽬標を共有する
  • アプリケーション、ワークロード、プラットフォーム、インフラストラクチャの各コンポーネントの所有者を特定する
  • 各プロセスと⼿順の定義を担当する所有者、パフォーマンスに責任を持つ所有者を特定する
  • イノベーションを制約しないように、追加、変更、例外をリクエストするメカニズムを備える
  • チームの相互サポート方法、ビジネスの成果に関するチーム間の合意を定義する
  • チームの上級リーダーは、ベストプラクティスの採⽤と組織の進化の協賛者、⽀持者、および推進者であるべき
  • インシデントやリスクがあるとチームメンバーが考える場合に、意思決定者や利害関係者にエスカレーションすることを推奨
  • チームメンバーが関⼼と当事者意識を持ち続けるために、学習を加速するための実験を奨励
  • AWS クラウドコンプライアンスが提供するリソースを使⽤して、優先順位に与える影響を判別できるようにチームを教育する
  • チームを教育するため、AWS サポート (AWS ナレッジセンター、AWS ディスカッションフォーラム、AWS サポートセンター) および AWS ドキュメントが提供するリソースを使⽤する
  • AWS Organizations など、アカウント間で環境を集中管理できるツールまたはサービスを使⽤して、運⽤モデルの管理に役⽴てる

また、他のベストプラクティスの定義も加筆されています。
主に加筆されているポイントは以下のとおりです。

• 準備
  • 品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにする
  • 失敗を予測し、必要に応じて⼿順を作成する
  • 組織、原価計算、アクセスコントロールのリソースにタグを付け、⾃動化された運⽤アクティビティの実⾏を意図する
• 進化
  • 顧客に影響を与えるすべてのイベントについて、インシデント後の分析を実⾏すること
  • 反復を制限または防⽌する要因と予防措置を特定すること
  • AWS のサービスを活用してログを保管すること
    • ログデータを Amazon S3 にエクスポート
    • ログを直接 Amazon S3 に送信して、⻑期保存
    • AWS Glue を使⽤して、S3 上ログに関連するメタデータを AWS Glue データカタログに保存
    • Amazon Athena と Glue で、ログデータを分析
    • Amazon QuickSight のようなビジネスインテリジェンスツールを使⽤して、データの可視化、調査、分析

セキュリティ

設計原則

若干ですが、セキュリティの設計原則の定義が変更されています。

• 強⼒なアイデンティティ基盤の実装
  • (旧) 権限の管理を⼀元化し、⻑期的な認証情報への依存を軽減あるいは解消する
  • (新) アイデンティティ管理を⼀元化し、⻑期にわたる静的な認証情報に依存しないようにすることを⽬的とする
• セキュリティイベントへの備え
  • (旧) ご所属の組織の要件に合わせたインシデント管理プロセスにより、インシデントに備える
  • (新) 組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導⼊し、インシデントに備える

定義

セキュリティのベストプラクティス定義が5つ→6つに増えています。
アイデンティティ管理とアクセス管理は、Identity and Access Management (そのまま)、発⾒的統制は検出にリネームされました。

• (旧) アイデンティティ管理とアクセス管理、発⾒的統制、インフラストラクチャ保護、データ保護、インシデント対応
• (新) セキュリティ、Identity and Access Management、検出、インフラストラクチャ保護、データ保護、インシデント対応

広い意味での 「セキュリティ」 が加えられました。

• (新) セキュリティ
  • セキュリティのすべての領域に包括的なベストプラクティスを適⽤する
  • 運⽤上の優秀性で定義した要件とプロセスを抽出し、ベストプラクティスをすべての領域に適⽤する
  • AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つ
  • セキュリティプロセス、テスト、検証を⾃動化する

また、他のベストプラクティスの定義も加筆されています。
主に加筆されているポイントは以下のとおりです。

• Identity and Access Management
  • (新) お客様が意図した⽅法で承認、認証されたユーザーおよびコンポーネントのみがリソースにアクセスできるようにする

信頼性

設計原則

設計原則の項目は変わりませんが、過去項目の定義が微妙に変更されています。
分かりづらかった KPI の定義が、文書上で明確になったようです。
また、後ほども登場しますがサービスクォータの管理が重視されています。

• 障害から⾃動的に復旧する
  • (新) KPI は、サービスの運⽤の技術的側⾯ではなく、ビジネス価値に関する指標である必要がある
• キャパシティーを推測しない
  • (旧) クラウドでは、需要とシステムの使⽤率をモニタリングしてリソースの追加や削除を⾃動化し、需要を満たすために最適なレベルを維持できる
  • (旧) プロビジョニングが超過または不⾜することはありません。
  • (新) クラウドでは、需要とワークロード使⽤率をモニタリングし、リソースの追加と削除を⾃動化することで、プロビジョ⼆ングが過剰にも過⼩にもならない、需要を満たせる最適なレベルを維持できる
  • (新) 制限はまだあるが、制御および管理できるクォータもある

定義

ベストプラクティスの項目が3つ→4つに増えました。
ワークロードアーキテクチャについては、障害を防⽌および軽減するように設計する必要があると定められています。

• (旧) 基盤、変更管理、障害の管理
• (新) 基盤、ワークロードアーキテクチャ、変更管理、障害の管理

ベストプラクティス

ワークロードアーキテクチャに関する定義が追加されています。

• (新) ワークロードアーキテクチャ
  • ソフトウェアとインフラストラクチャの両⽅について事前に設計を決定する
  • 開発者は使⽤する⾔語とテクノロジーを選択する
  • AWS SDK は、AWS のサービス⽤に⾔語固有の API を提供することで、コーディングの複雑さを排除する
  • SDK と⾔語の選択により、信頼性のベストプラクティスを実装できる

一部変更があり、主にサービスクォータに関する記述が追加されています。
主に加筆されているポイントは以下のとおりです。

• 基盤
  • サービスクォータ (サービスの制限) を管理する
  • サービスクォータは誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使⽤から保護することを目的として、API 操作のリクエスト頻度を制限する
  • サービスクォータは、すべてのワークロード環境でモニタリングおよび管理する
  • 計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する

パフォーマンス効率

設計原則

大きな変更はなく、引き続き以下のポイントです。

• 最新テクノロジーの標準化、わずか数分でグローバル展開する、サーバーレスアーキテクチャを使⽤する、より頻繁に実験する、システムに対する精通の程度を考慮する

定義

ベストプラクティスの定義にも変更はなく、以下の4点です。

• 選択、レビュー、モニタリング、トレードオフ

ベストプラクティス

ワークロードに関する考慮が追加されたこと、コストが考慮されたこと、情報の吟味による意思決定が重視されたことなどの変更点がありました。
また、反復的な見直しが全体的に重視されていることを踏まえ、各ベストプラクティスの説明はより詳細となっています。

• 選択

  • コンピューティング
    • (旧) アーキテクチャに対して適切でないコンピューティングソリューションを選択すると、パフォーマンス効率が低下する場合がある
    • (新) コンピューティングオプションを評価するときは、ワークロードのパフォーマンスの要件とコスト要件に留意し、これを使⽤して⼗分な情報に基づいて意思決定を⾏う
    • (新) コンテナに関する詳細説明が追加
      • ECS の起動タイプ: コンピューティング環境のインストール、設定、および管理を制御する必要がある場合に EC2 を選択
  • ストレージ
    • (新) オブジェクト、ブロック、ファイルストレージの選択基準が追記
      • オブジェクトストレージは、ユーザーが⽣成したコンテンツ、アクティブなアーカイブ、サーバーレスコンピューティング、ビッグデータストレージ、またはバックアップと復旧のために、任意のインターネットの場所からデータへのアクセスを可能にする
        • Amazon S3
      • ブロックストレージは、仮想ホストごとに、⾼可⽤性かつ⼀貫性のある低レイテンシーのブロックストレージで、永続的なストレージを必要とするワークロード向け
        • Amazon EBS
      • ファイルストレージは、複数のシステムにまたがる共有ファイルシステムへのアクセスを提供
        • Amazon EFS
        • Amazon FSx
  • データベース
    • (新) 近年新たに登場したデータベースに関する追記
      • リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、および台帳データベースを含めた複数の専⽤データベースエンジンから選択
  • ネットワーク
    • (新) 近年新たに登場したネットワークサービスに関する追記
      • 拡張ネットワーク、Amazon EBS 最適化インスタンス、Amazon S3 Transfer Acceleration、動的 Amazon CloudFront など、ネットワークトラフィックを最適化するための製品機能
      • Amazon Route 53 のレイテンシールーティング、Amazon VPC エンドポイント、AWS Direct Connect、および AWS Global Accelerator などの、ネットワーク距離を縮め、ジッターを削減するネットワーキング機能

• レビュー

  • (新) ワークロードコンポーネントに対する変更を継続的に評価して検討し、パフォーマンスとコストの⽬標を確実に満たすようにする
  • (新) アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導⼊することで、デミングの PDCA (計画 ‒ 実施 ‒ 評価 ‒ 改善) サイクルを適⽤して反復的な改善を促す

• モニタリング

  • (新) AWS X-Ray を使⽤すると、アプリケーションの動作に関する洞察を得て、根本原因を検出し、パフォーマンスのボトルネックを特定可能

• トレードオフ

  • (新) ワークロードに変更を加えた後、メトリクスを収集して評価し、それらの変更の影響を判断する
  • (新) システムおよびエンドユーザーに対する影響を測定して、トレードオフがワークロードにどのような影響を与えるかを理解する
  • (新) 負荷テストなどの体系的なアプローチを使⽤して、トレードオフによってパフォーマンスが向上するかどうかを調べる

コスト最適化

全体的に大きく見直され、コスト最適化に向けた組織や体制があるかどうかが、大変重視されるようになっています。
以下を読んでいくと勘付きますが、具体的な言葉はないものの、CCoE の重要性が AWS Well-Architected Framework の中で言及されたとも言えます。

設計原則

定義が見直されています。

• (旧) 消費モデルを導⼊する、全体的な効率を測定する、データセンター運⽤のための費⽤を排除する、費⽤を分析し帰結させる、アプリケーションレベルのマネージドサービスを使⽤して所有コストを削減する
• (新) クラウド財務管理の実装、消費モデルを導⼊、全体的な効率を測定する、差別化につながらない⾼負荷の作業に費⽤をかけるのをやめる、費⽤を分析および属性化する

新しい原則として加わった 「クラウド財務管理の実装」 は以下のとおりです。

• (新) クラウド財務管理の実装
  • 組織は、テクノロジーと使⽤状態の管理という新しい領域における能⼒を獲得するために、時間とリソースを投⼊する必要がある
  • コスト効率の⾼い組織になるには、セキュリティまたはオペレーションの能⼒と同様、知識の積み上げ、プログラム、リソース、プロセスを通じて能⼒を構築する必要がある

定義

ベストプラクティスの定義がガラッと変わっています。

• (旧) 費⽤認識、費⽤対効果の⾼いリソース、需要と供給を⼀致させる、⻑期的な最適化
• (新) クラウド財務管理を実践する、経費⽀出と使⽤量の認識、費⽤対効果の⾼いリソース、需要を管理しリソースを供給する、経時的な最適化

ベストプラクティス

定義が変わったため、内容も大きく変わっています。

• (新) クラウド財務管理を実践する
  • 合意された⼀連の財務⽬標に整合するように組織を調整し、それらを満たすメカニズムを組織に提供することで、より効率的な組織を構築する
  • AWS Cost Explorer およびオプションで Amazon Athena と Amazon QuickSight をコストと使⽤状況レポート (CUR) とともに使⽤して、組織全体のコストと使⽤状況を把握する
  • AWS ブログで、新しいサービスリリースの最新の状況を常に知る
  • コスト最適化機能を構築するときは、メンバーを引き⼊れるとともに、CFM および CO エキスパートでチームを補完することも検討する
  • 組織にコスト意識を浸透させようとする際には、既存のプログラムおよびプロセスを改善または構築することを検討する
    • 新しいプロセスおよびプログラムを構築するよりも、既存のものに追加する⽅がはるかに迅速で、結果を得るまでの時間が⼤幅に短縮される

• (新) 経費⽀出と使⽤量の認識

  • AWS Organizations または AWS Control Tower を使⽤してアカウント構造を作成すると、組織単位を分離でき、コストおよび使⽤量の配分に役⽴つ
  • AWS Cost Explorer を使⽤してコストと使⽤状況を可視化するか、Amazon Athena と Amazon QuickSight でカスタマイズされたダッシュボードと分析を作成する
  • 詳細な分析と検査を⾏うには、AWS Cost Explorer で時間単位の粒度を使⽤するか、コストと使⽤状況レポート (CUR) を使⽤して時間単位の粒度で Amazon Athena と Amazon QuickSight を使⽤する

• 費⽤対効果の⾼いリソース

  • (新) Savings Plans とリザーブドインスタンスは、オンデマンド料⾦に対して最⼤ 75% の割引を提供する

• (新) 需要を管理し、リソースを供給する

  • スロットル、バッファ、またはキューを使⽤して、需要を滑らかにし、少ないリソースで供給することで、コストを削減したり、後でバッチサービスで処理したりできる
  • Amazon API Gateway を使⽤してスロットリングを実装するか、Amazon SQS を使⽤してワークロードにキューを実装する

• (新) 経時的な最適化

  • 新しい機能またはリソースタイプを実装し、変更の実装に必要な労⼒を最⼩限に抑え、ワークロードを段階的に最適化する
  • 新しいサービスを使⽤して、ワークロードに新しいコンポーネントを置き換えたり、追加したりする

まとめ

今回のアップデートで具体的に変わり、新たに意識すべき点は、以下のポイントに集約されます。
これらのポイントは、密接に関連していました。

• 組織作り
• ワークロードに応じた情報収集と選択、反復的な見直し
• コスト最適化

なぜなら、AWS を推進する上での体制(組織)が準備されていれば、アーキテクチャなどを継続的かつ反復的に見直すことができ、コスト最適化に繋がるからです。

また、反復的な見直しは、セキュリティを改善する上でも有効であり、これも Well-Architected の柱に関連してきます。
日本国内では殆ど言及がありませんでしたが、6月に改訂された「AWS Security Incident Response Guide」の中でも、セキュリティに対応できる組織を生成しスタッフを継続的に教育すること、小規模から始めて反復的な見直しを続けることなどの言及があります。

確かに、AWS を利用する上で、今この瞬間、技術的に優れたアーキテクチャであることは大事ですが、継続的に見直すための仕組みがなければ、未来において、そのアーキテクチャは過去のものになると言えます。

新たに追記された AWS Well-Architected Framework の考え方・心得を胸に留め、常に新鮮なアーキテクチャを追い求め、ベストを尽くしていると言えるようにしていきたいものです。

参考文献

• AWS Well-Architected Framework (2020/07) ※PDF
• AWS Well-Architected
• AWS Security Incident Response Guide (2020/06)