AWS Well-Architected Toolでベストプラクティス毎に適用できない理由を入力できるようになりました

AWS Well-Architected Toolでベストプラクティス毎に適用できない理由を入力できるようになりました

Clock Icon2021.08.06

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

中山(順)@リカバリー中 です

Well-Architected Toolでワークロードを評価する際、何らかの事情で適用できないベストプラクティスがあると思います。 従来は質問毎に用意されたテキストボックスに入力して管理する必要がありました。

先日、質問に含まれる個々のベストプラクティス毎に適用できない理由を入力できるようになりました。

Mark individual best practices as not applicable within the AWS Well-Architected Tool

やってみた

例えば、セキュリティに関する質問である "SEC 1. How do you securely operate your workload?" には、"Secure AWS account" というベストプラクティスがあります。

これの具体的な対策としては、ルートユーザーをMFAを使って保護することや連絡先を正しく設定する(Abuseの通知等を正しく受信できるようにする、など)ことが求められます。

SEC 1: How do you securely operate your workload?

弊社クラスメソッドはAWSアカウントのリセールを行っており、ルートユーザーは弊社側で管理を行っています。 連絡先などアカウントの設定も同様です。 そのため、実際のAWS利用者が管理できる部分ではなく、評価のスコープ外となるかと思います。

今回のアップデートでは、以下のような要領でベストプラクティスを適用できない理由(選択肢+フリーテキスト)を設定できます。

ちなみに、クラスメソッドにおけるセキュリティがどうなっているのか気になるという場合は個別にご相談ください。 セキュリティに関する基本方針などはホームページでも公開しています。

情報セキュリティ基本方針

まとめ

これまではベストプラクティスを適用できない理由を"Notes"(自由記入欄)に入力して管理する必要があり正直めんどくさかったですが、今回のアップデートによってきれいに管理できるようになりました。

こういった適用できない理由は担当者の交代などで失われがちな情報なので、構造化された情報としてきちんと管理していきたいですね。 また、適用できない理由は時間の経過と共に理由ではなくなることもありますので、過去にレビューしたことあるワークロドもたまには見直し/再レビューするのもよいのではないでしょうか?

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.