皆さん、こんにちは。ITサービス＆エンジニアリング事業本部（以下、ITS＆E）クラウドプラットフォーム事業部に所属している五味 なぎさです。今回初めて私のブログを読んでくださる方に向けて、自己紹介をさせてもらいます。私が所属する部署はクラウドサービス事業の拡大をミッションとしており、当社が提供するマネージドクラウドサービスabsonne（アブソンヌ）の企画・運営・提案・導入や、Amazon Web Services（以下、AWS）、Microsoft Azure、Google Cloud Platform、Oracle Cloud Infrastructure等のパブリッククラウドサービスを利用したシステムの提案・設計・導入を推進しています。皆様がAWSをより深く活用するためのノウハウを定期的に発信していきたいと思いますので、よろしくお願いします。 なお、これまで掲載された、re:Invent2023の参加レポートやAWSにおけるIPv6対応の基礎に関するブログも、ご興味があればぜひ読んでみてください！
さて今回は、AWS Well-Architected Frameworkについてです。私自身がAWS主催のAWS Well-Architected Partner Program Bootcampに参加することになったため、その予習も兼ねて内容をまとめ、前後編に渡ってお伝えしていきます。主にAWSの導入をご検討中の方、これから設計を進められようとしている方に読んでいただくとお役に立つのではと思います。AWS Well-Architected Frameworkはかなり重厚なドキュメントで、初めて触れる方は少しとっつきにくいかもしれませんので、本ブログを入口として理解を深めていっていただけたら幸いです。
AWS Well-Architected Frameworkは、クラウド上でワークロードを設計・実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスに関するフレームワークで、以下の6つの柱から成り立ちます。
これから、各柱の概要と特徴についてまとめていきます。
なお、本ブログでは詳細なベストプラクティスの内容にまでは踏み込んでいないため、興味がある方はそれぞれ記載の参考リンクから、各柱の詳細を見てみることをお勧めします。
Amazonでは、運用上の優秀性を「優れたカスタマーエクスペリエンスを着実に提供しながら、ソフトウェアを正しく構築するために取り組むこと」と定義しています。設計原則としては、以下の7つが挙げられます。
ここで興味深いのは、クラウド技術を利用する前段階の「ビジネス目標の定義」まで言及されている点です。他の柱の中でもビジネス目標との関連性について書かれていますが、ビジネス上のKPIの評価方法など、最も色濃く書かれています。技術を利用することが目的になり、結局何を実現したいのか不明確になってしまうケースはしばしばあると思いますが、フレームワークに沿って考えていくことで、ビジネス目標から組織が要件と優先順位を理解し、ビジネスの成果を達成するためのクラウド利用について考えることができるようになります。そのため、運用検討段階で役に立つだけでなく、クラウド導入を考える際に大変参考になります。
参考：運用上の優秀性の柱 - AWS Well-Architected フレームワーク - 運用上の優秀性の柱 (amazon.com)
この柱では、AWSで安全なワークロードを設定するための考え方と詳細なベストプラクティスが提供されています。設計原則としては、以下の7つが挙げられます。
上記の設計を進める上で、基本の考え方として重要になるのが以下2点です。
まず、責任共有モデルについて、このような絵を見たことがある方は多いのではないでしょうか？AWSとユーザ側の責任分解点が表されており、上段の「お客様」に該当する範囲は、ユーザ側で意識して対応する必要があります。
AWS 責任共有モデル
出典：AWS Well Architected Framework内 「責任共有モデル」（2024/3/26引用）
なお、例えばIaaSサービスであるAmazon EC2やAmazon S3、およびAmazon DynamoDBなど、よりAWS管理範囲の広いサービスを利用した場合では、ユーザごとに対応すべき範囲が変わる点も考慮しなければなりません。他の柱に対しても言えることですが、「どの範囲がマネージドとなり、ユーザ側で考慮する必要があるのか」を考えてアーキテクチャを設計することが重要です。
次にガバナンスについてですが、セキュリティの柱内では「セキュリティガバナンスは、全体的なアプローチのサブセットとして、リスク管理を支援するためのポリシーと管理目標を定義することによって、ビジネス目標をサポートすることを目的とする」と書かれており、組織でポリシーと管理目標を定め、階層的にアプローチすることで、リスク管理を達成します。
以下の表は、縦軸が過去の発生頻度に基づくリスク発生の可能性、横軸がイベントの金銭的、風評的、時間的コストに基づくリスク結果をそれぞれ示しています。
リスクレベルの可能性マトリクス
出典：AWS Well Architected Framework内「ガバナンス」（2024/3/26引用）
組織でセキュリティの管理目標やポリシーを決める際は、上記のようなマトリクスで整理し、より重要なものから優先的に対処する考え方となっていることが必要と言えます。
参考：セキュリティの柱 - AWS Well-Architected Framework - セキュリティの柱 (amazon.com)
いかがでしたでしょうか？今回は AWS Well-Architected Frameworkの概要と、運用上の優秀性の柱およびセキュリティの柱の概要と特徴についてお伝えしました。後編では残りの信頼性の柱、パフォーマンス効率の柱、コスト最適化の柱、持続可能性の柱に触れていく予定ですので、後編も楽しみにお待ちください！
