AWS FTRの認証を得るための活動

これまで、AWSを利用する多くの企業が「AWSパートナー」として活動してきました。これまでは、社内に一定数のAWS資格保有者が在籍し、パートナーとしての年会費を支払う（実際には年会費以上のクレジットがもらえるため、実質プラス）ことが主な条件でした。

パートナーとして認められると、自社サイトにAWS公式のパートナーバッジを掲載できたり、AWSと共同セミナーを開催できたりと、より深い関係を築けるメリットがありました。しかし、2025年にこのルールが大きく変わるというアナウンスがあったのです。

AWS パートナーの成功を加速 : 2025 年に向けた顧客価値を推進する新たな取り組み

公式ブログには詳細が伏せられていますが、昨年AWSから届いたメールを要約すると、以下のような内容でした。

「今後AWSパートナーのステータスを維持するには、少なくとも1つのソリューションを『Validated（検証済み）』にする必要があります」

急な通告に「何をすればいいのか……」と戸惑いましたが、まずはこの変更の背景から解説します。

なぜ「Validated」が必須になったのか

AWSがこの方針を打ち出した背景には、「パートナーの信頼性を企業単位ではなく、具体的なソリューションの品質で担保する」という戦略的なシフトがあります。

顧客が求めているのは「そのパートナーに資格者が何人いるか」ではなく、「提供されているソフトが安全に、正しく動くか」です。そのため、資格者の数だけでなく、実際に提供しているソフトウェア（サービス）がAWSの掲げる品質基準を満たしているかを重視するようになりました。「ただAWSを使っている」企業と、「AWSの設計思想に則った高品質なソフトを持つ」企業を明確に区別し、優良なパートナーにリソースを集中させる狙いがあるようです。

これまで得られていたパートナーの恩恵が失われるのは困るため、私は昨年、通常業務の合間を縫ってソリューションを「Validated」にするための活動を行っていました。

ソリューションを「Validated」にするために

「Validated」の状態にするには、AWSパートナーポータルに自社のソリューション（ソフトウェアやサービス）を登録し、AWSのレビューを受けて「ベストプラクティスを満たしている」と認証される必要があります。

まず前提として、今回説明するのは 「ソフトウェアパス (Software Path)」、つまりSaaSやパッケージソフトへの対応です。「サービスパス (Services Path)」ではないのでご注意ください。また、以下のケースは認証の対象外となります。

特定の1社向けに専用開発されたもの（不特定多数への提供が目的ではないもの）
外販の予定がないもの（社内ツールなどのクローズドなソフトウェア）

これらに該当しない「外販製品」があることがスタートラインです。

1. Well-Architected ツールを使って自己診断を行う

いきなりレビューを申請する前に、まずは「Well-Architected ツール」で自己診断を行うよう推奨されています。

AWS Well-Architected Frameworkとは、以下の「6つの柱」に基づいて、適切にAWSを活用するためのAWS謹製のフレームワークです。

運用上の優秀性
セキュリティ
信頼性
パフォーマンス効率
コスト最適化
サステナビリティ

これらを満たしていなければ門前払い、というわけですね。AWSのコンソール内には、自身のサービスがこれらにどれだけ準拠しているかセルフチェックできるサービスがあります。

AWS Well-Architected Tool コンソール

チェックリストに回答し、リスクがどれだけ存在するかを記録して、改善活動につなげる仕組みです。ただ、このツールの難点は、翻訳の影響か日本語の質問文が分かりにくい箇所があることです。2026年現在はGeminiなどのAIが活用できるため、それらに質問を噛み砕いてもらうのが得策です。AIがなかったら、とても期限内には終わらなかったでしょう。まさに「AIさまさま」です。

項目は100以上と膨大ですが、異なる「柱」で似たような質問をされることもあります。私が実際に「どう対応すればOKなのか」をAWSに確認した項目をいくつか共有します。

ネットワークトポロジの計画方法

VPC IP Address Manager (IPAM) などを用いた適切なIPアドレス管理を行う。

分散システムの障害設計

Amazon Data Firehoseなどの流量制限やバッファリングを行い、リミットを超えない設計にする。流量が多い場合はバックプレッシャー制御などを行う。

オブザーバビリティ / 分散トレーシング

AWS X-RayやDatadog、New Relicなどでエンドツーエンドのモニタリングを行う。

信頼性のテスト

AWS Fault Injection Service (FIS) 等を使い、AZ単位の障害テストを行っているか。

アクセスキーのローテーション

外部サービス（GitHub Actions等）からのデプロイにアクセスキーを使わず、OIDC (OpenID Connect) を利用したキーレスな認証を導入しているか。

データの分類

Confidential / Internal / Public といった定義を行い、どのリソースやテーブルにどのレベルのデータがあるかを表で管理しているか。

運用・ビジネスのKPI管理

レスポンスタイムやアクティブユーザー数、デプロイ時間、アラート対応時間といった「数字的な目標」を持ち、それを分析してインフラ構成やビジネスの改善に活かしているか。

クラウド財務管理

リソース別のコスト分析を行い、削減の検討やメンバーへのコスト意識の周知を行っているか。

2. APNポータルで FTR の申請を行う

自己診断が終わったら、いよいよAPN(AWS Partner Network)上でFTR (Foundational Technical Review / 基礎技術レビュー) の申請です。これは、自社のワークロードがAWSのベストプラクティスに沿っているかを検証するパートナー向けのプログラムです。パートナー向けと説明がされていますが、チェックリストは一般公開もされているので、個人のシステム品質向上にも役立ちます。

AWS FTR チェックリスト (Partner Hosted)

実は、Well-Architected ツールの全項目が「Yes」でなくても、FTRの申請自体は可能です。前述した「サステナビリティ（省電力など）」の一部項目などは、FTRの必須要件には含まれていないからです。多くはWell-Architectedツールと同じ質問が聞かれますが、ちょっとニュアンスが違う質問も出されます。以下が参考になります。

【Partner-Hosted 編】ファンデーショナルテクニカルレビュー (FTR) のチェックリスト解説

申請用にExcelファイルをアップロードすると、AIが内容を精査してくれます。すべて「Yes」で通るケースは稀で、一つでも「No」があれば、AWSの担当者と詳細を確認するミーティングが設けられます。そこで質疑応答を行い、解決策を提示したり「将来的な改善」を約束したりすることで、最終的に「Yes」と判断されれば、晴れてFTR認証（Validated）となります。

最後に

いかがだったでしょうか。今回初めてFTR認証に向けて動きましたが、分からないことだらけで非常に苦労しました。しかし、認証されたソリューションはAWS パートナーソリューションファインダーに自動掲載され、世界中の顧客に紹介されるチャンスが得られます。

同じような悩みを抱える担当者の方にとって、この記事が少しでも助けになれば幸いです。