AWS FTRとは
AWS FTR（Foundational Technical Review）とは、AWSパートナー企業がAWS上でサービスを提供する際、その環境がAWSのベストプラクティスに沿って設計・構築・運用されているかを評価するプログラムです。レビューを通過するとAWS認定ソフトウェアとなり、該当製品に「AWS Qualified Software」ソリューションバッジを利用できるなどの特典があります。
この度、AWS環境上で開発・リリースしたSaaS製品において、AWS FTRを取得することができました。本記事では、「取得までの流れ」「事前に行った準備」「取得した感想」といった内容を記載をしたいと思います。
事前準備
こちらにFTR取得のための5つのステップの説明があります。「ステップ3」以外は主に登録・申請関連となるため、下記からは「ステップ3」について記載します。
- ステップ 1: APN に参加する
- ステップ 2: ソフトウェアパートナーパスに登録する
- ステップ 3: アーキテクチャと運用方法の見直し
- ステップ 4: オポチュニティを共有する
- ステップ 5: FTR をリクエストする
セルフチェックシートの記入
AWSから公開されているセルフチェックシート（Excel形式）に沿って自己評価を行いました。AWSのWell-Architected Frameworkは下記6つの柱で構成されています。
- 運用上の優秀性の柱
- セキュリティの柱
- 信頼性の柱
- パフォーマンス効率の柱
- コスト最適化の柱
- 持続可能性の柱
FTRのセルフチェックシートの質問項目はこのうち、「運用上の優秀性の柱」「セキュリティの柱」「信頼性の柱」をベースに構成されています。レビューに通過するには全ての項目をクリアする必要があります。チェックシートには複数の種類がありますが、今回は「Partner-Hosted on AWS」を使用しています。
質問項目の例
質問項目は多数ありますが、下記に3つほど質問の例と対応内容を記載します。
ARC-005 インシデント管理計画を作成する。
運用設計の一部として対応を行いました。「アラートの一覧化」や「アラート毎の重要度の定義」「重要度に応じた対応フローの定義」等の文書化を行っています。
BAR-002 定期的にデータを復元し、バックアッププロセスの整合性を検証する。
データベースなどのバックアップ・リストア試験を実施し、事前に定義したRTO・RPOの範囲で復旧できることを確認しました。また、「定期的に」という言葉にある通り、継続的な対応が必要となります。バックアップ・リストア検証をアーキテクチャの変更時や年間の運用計画への組み込みを行いました。
上記の様に、運用観点の質問も多くありましたが、普段Slerで顧客向けのシステムを設計していることもあり、割合スムーズに対応することが出来ました。
IAM-006 最小権限のアクセスを付与する
IAMポリシー設計では、利用するサービス・操作の権限のみを付与する方針としました。ここはFullAccessを設定したくなるところですが、この項目もクリア出来ないとレビュー通に過できません。「最小権限のアクセス」を意識して設計することが出来たのはレビューを受けて良かったと思えるポイントの一つです。
Well-Architectedレビュー
こちらのブログページにも記載のある通り、事前にWell-Architectedレポートの提出が必要となります。
AWS Well-Architected レポートやアーキテクチャ図、セルフアセスメントシートなど必要書類を準備できること
対象アカウントのAWSコンソールからAWS Well-Architected Toolを使用することによって、Well-Architectedレビューを行うことが可能です。6つの柱の項目を順番に回答していきますが、下記にある通り質問数が結構沢山あり大変です。質問への回答とメモ欄にその解答を選択した理由などを記入していきました。全て回答後、PDF形式でレポートをエクスポートすることが可能となります。
下記は3年ほど前に記載した記事になります。Well-Architectedは「技術的な視点」が必要になるもの以外にも「ビジネス的視点」・「組織的な視点」が必要になるものなど、様々な観点から考える必要があります。
下記は運用上の優秀性の柱の組織の箇所になりますが、「外部環境、内部環境を分析して組織としての優先順位を決める」、「それを実現していくための最適な組織モデルを選択して責任範囲を定義する」というフェーズになります。
ベストプラクティスであるため、全てを書いてある通りに実施する必要は無いかと思いますが、例えば「ベストプラクティスA」というものがあって、それを実装していない場合、下記の2つのパターンでは大きく意味合いが異なります。
- 「ベストプラクティスA」を知らなくて実装していない
- 「ベストプラクティスA」を検討をしたが、要件・環境などから不要と判断し実装していない
上の場合はただ実装していないだけですが、下の場合は「実装しないという設計がされた」ことになります。
レビュー当日
セルフチェックシートに沿って、約2時間ほどのレビューを受けました。レビューでは、各項目に対して実際の対応内容をもとに、詳細な質問が行われます。要件を満たしていればそのまま問題ありませんが、不足がある場合は後日対応を行い、メールベースで再確認を受ける形となります。技術関連以外の質問も多くありましたが、事前準備をしっかり行っていたこと、また本プロダクトの開発は企画から設計・開発・プロモーション・法務関連等全ての範囲に関わっていたため、多くの質問にはスムーズに答えることができました。いくつか追加対応が必要な項目はあったものの、後日対応を実施し全ての項目に対応することが出来ました。
感想
普段からベストプラクティスを意識して、環境構築や運用設計を行っていますが、今回のFTRレビューを通じて、改めて自分たちの環境を客観的に見直す良い機会となりました。今後、他の製品を開発する際にも、FTRを一つの基準として積極的に取得していきたいと考えています。また、FTRチェックリストの中には「定期的に（少なくとも年1回）アーキテクチャレビューを行う」といった項目も含まれています。そのため、今後も AWS Well-Architected Tool を活用しながら、定期的なレビューを継続していく予定です。