はじめに
前回はCommon Practice Requirementsについて解説しました。
シリーズ最終回となる今回は、Common Cust Example Reqs（共通顧客事例要件） への対応方法を解説します。
Common Cust Example Reqsとは
実際の顧客案件で技術・運用のベストプラクティスを実践しているかを問う要件です。
「組織として仕組みを持っている」だけでなく、「実際の顧客案件でベストプラクティスを実践した証拠」が求められます。
※重要： 過去18ヶ月以内の4社分の顧客事例でエビデンスを示す必要があります。
対象となる要件
SMB Cust Ex Reqs（SMB顧客事例要件）
| ID | 要件名 |
|---|---|
| SMBCTEX-001 | Design Document（設計ドキュメント） |
| SMBCTEX-002 | Solution Configuration Document（構成ドキュメント） |
| SMBCTEX-003 | Expert Design Review（有資格者レビュー） |
| SMBCTEX-004 | Migration Capability（マイグレーション能力） |
Common Cust Example Reqs（共通顧客事例要件）
| カテゴリ | ID | 要件名 |
|---|---|---|
| Documentation | DOC-001 | Architecture Diagram（アーキテクチャ図） |
| Account | ACCT-001 | Secure AWS Account Governance（アカウントガバナンス） |
| ACCT-002 | IAM Best Practice（IAMベストプラクティス） | |
| Operations | OPE-001 | Workload Health KPIs（ワークロードKPI） |
| OPE-002 | Runbook/Playbook（運用手順書） | |
| OPE-003 | Deployment Readiness（デプロイ準備） | |
| Security – Networking | NETSEC-001 | VPC Security（VPCセキュリティ） |
| NETSEC-002 | Data Encryption（データ暗号化） | |
| Reliability | REL-001 | Infrastructure as Code（IaC） |
| REL-002 | Disaster Recovery / RTO・RPO | |
| Cost | COST-001 | TCO Analysis（コスト分析） |
上記のうち、私が担当したのは以下でしたので、以下に絞って解説します。
- SMBCTEXすべて
- DOC-001
- ACCT-001,002
- OPE-001,002,003
- NETSEC-001,002,003
- REL-001,002
- COST-001
SMB Cust Ex Reqs
SMBCTEX-001~002: Design Document（設計ドキュメント）
要件
AWS Partner delivers a design document for SMB Customers that includes the following components: Customer business requirements, Mapping of business requirements to functional requirements, Mapping of functional requirements to design specifications, Architectural details, Dataflow diagram, Non-functional requirements approach, Security requirements incorporation.
AWS Partner delivers a solution configuration document for SMB Customers that includes the following components: Designation of solution and environment, Network architecture, Component layout diagram, Table of configuration values.
確認ポイント
- 顧客事例の基本設計書・詳細設計書に以下が含まれていること
- 顧客のビジネス要件
- ビジネス要件と機能要件のマッピング
- 機能要件と設計仕様／実装のマッピング
- ソリューションのアーキテクチャ詳細
- データフロー図
- 非機能要件をサポートするためのアプローチ
- セキュリティ要件の組み込み
- ソリューションと環境の指定
- ネットワークアーキテクチャ
- コンポーネントレイアウト図
- 構成値表
提示したエビデンス
- 基本設計書
- 詳細設計書
SMBCTEX-003: Expert Design Review（有資格者レビュー）
要件
AWS Partner has a policy that all designs are certified by a qualified designer (AWS Certified Solutions Architect – Associate or AWS Certified Solutions Architect – Professional).
確認ポイント
- すべての設計が有資格者によって認定されるポリシーを持つこと
- 認められる資格：AWS Certified Solutions Architect – Associate / Professional
提示したエビデンス
- 4社分の顧客事例ごとに：
- 有資格者による署名済み設計書
- 本番稼働日時点で有効な資格証明
SMBCTEX-004: Migration Capability（マイグレーション能力）
要件
AWS Partner has a standard migration methodology that covers resource discovery, migration pattern identification, landing zone design and deployment, cut over planning, application testing, and rollback planning.
確認ポイント
- オンプレミス/他クラウドからAWSへの移行能力があること
- 以下を含む必要があります：
- リソースの検出
- 移行パターンの特定（リフト＆シフト、リホスト、リプラットフォーム、リファクタリングなど）
- ランディングゾーンの設計と展開
- カットオーバー計画
- アプリケーションテスト
- ロールバック計画
提示したエビデンス
- 上記項目をカバーする2社分の移行計画書
Common Cust Example Reqs
DOC-001: Architecture Diagram（アーキテクチャ図）
要件
AWS Partner must submit architecture diagrams depicting the overall design and deployment of its AWS Partner solution on AWS as well as any other relevant details of the solution for the specific customer in question.
The submitted diagrams are intended to provide context to the AWS Solutions Architect conducting the Technical Validation. It is critical to provide clear diagrams with an appropriate level of detail that enable the AWS Solutions Architect to validate the other requirements listed below.
確認ポイント
- 高可用性・スケーラビリティを考慮したアーキテクチャ図を提出すること
- 提出するアーキテクチャには以下を含む必要があります：
- 使用されているすべての AWS サービス
- VPC、アベイラビリティゾーン、サブネット、AWS 外部のシステムへの接続など、AWS サービスのデプロイ方法
- AWS 外部にデプロイされた要素（オンプレミスのコンポーネントやハードウェアデバイスなど）
- 設計の自動スケーリング（Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda などの使用）
- マルチ AZ またはマルチリージョンデプロイによる高可用性を実現する設計
審査時には、提案資料と構成図を見せながら、ソリューションに対して適切な構成がとれているかどうかの説明をしました。
提示したエビデンス
- アーキテクチャ図（4社分）
- 提案資料
- 基本設計書
ACCT-001: Secure AWS Account Governance（アカウントガバナンス）
要件
AWS expects all Services Partners to be prepared to create AWS accounts and implement basic security best practices. Even if most of your customer engagements do not require this, you should be prepared in the event you work with a customer who needs you to create new accounts for them.
確認ポイント
- AWSアカウント作成時のセキュリティベストプラクティスをSOPとして整備されていること
- 以下を含む必要があります：
- ルートユーザーの使用制限
- ルートユーザーへのMFA有効化
- 連絡先を企業メール/電話に設定
- 全リージョンでCloudTrail有効化、専用S3バケットに保存
提示したエビデンス
- AWSアカウント作成SOP
- 基本設計書
ACCT-002: IAM Best Practice（IAMベストプラクティス）
要件
Define standard approach to access customer-owned AWS accounts, including:
- Both AWS Management Console access and programmatic access using the AWS Command Line Interface or other custom tools.
- When and how to use temporary credentials such as IAM roles
- Leverage customer’s existing enterprise user identities and their credentials to access AWS services through Identity Federation or migrating to AWS Managed Active Directory
Establish best practices around AWS Identity and Access Management (IAM) and other identity and access management systems, including:
- IAM principals are only granted the minimum privileges necessary. Wildcards in Action and Resource elements should be avoided as much as possible.
- Every AWS Partner individual who accesses an AWS account must do so using dedicated credentials
確認ポイント
- IAMベストプラクティスをSOPとして整備されていること
- 以下を含む必要があります：
- AWS管理コンソールアクセスとプログラムアクセス（AWS CLIやカスタムツール）の推奨方法
- 最小権限の原則
- 標準ロールテンプレート
例:
- マネジメントコンソールへのアクセスはAWS Identity Centerを使用する
- CLIは一時認証情報を使用する
- IAMユーザーを作成せずに、AssumeRoleを使用する
- アイデンティティフェデレーションはSAML2.0を使用する
- Admin、Developer、ReadOnlyロールを標準とする
提示したエビデンス
- IAM運用SOP
- 基本設計書
OPE-001: Workload Health KPIs（ワークロードKPI）
要件
AWS Partner has defined metrics for determining the health of each component of the workload and provided the customer with guidance on how to detect operational events based on these metrics.
確認ポイント
- ワークロードの健全性を測るKPI定義が存在すること
- 監視項目に対して、どのように閾値でアラートが設定されているかも明記されていること
- KPIの設定プロセスが明記されていること
- ログ、メトリクスの方針について明記されていること
例:
| リソース | 監視項目 |
|---|---|
| EC2 | CPU使用率、メモリ使用率、ディスク使用率、ネットワーク使用率 |
| RDS | CPU使用率、データベース接続数、解放可能メモリ率、読み取り/書き込みレイテンシー、ReplicaLag |
| Lambda | 同時実行数、エラー、スロットリング、処理期間 |
- 全てのリソース設定は、ビジネス要件から導出された具体的な数値に基づいて行う
- 標準系の閾値から外れる場合、パラメータシートに書き込んで管理する
- メトリクスの収集はCloudWatchを使用し、標準メトリクスで収集できないものはCloudWatchエージェントを使用
- 閾値超過時の対応方法（ランブック/プレイブックの参照先）を明記
提示したエビデンス
- KPI定義書
- 基本設計書
- メトリクス分析結果の顧客共有メール
OPE-002: Runbook/Playbook（運用手順書）
要件
Create a runbook to document routine activities and guide issue resolution process with a list of operational tasks and troubleshooting scenarios covered that specifically addresses the KPI metrics defined in OPE-001.
確認ポイント
- ランブック/プレイブックに以下が含まれていること：
- システム重要度定義（Criticalなら30分以内に対応開始など）
- 標準的なL1向け初動手順（ダッシュボード確認→影響範囲特定→エスカレーション）
- エスカレーション時の連絡テンプレート
- 各リソースに対する標準対応手順
- 日常運用のタスク
- セキュリティインシデント対応
提示したエビデンス
- ランブック/プレイブック
OPE-003: Deployment Readiness（デプロイ準備）
要件
Deployments are tested or otherwise validated before being applied to the production environment. For example, DevOps pipelines used for the project for provisioning resources or releasing software and applications.
確認ポイント
- 本番デプロイ前の標準的なプロセスがあること
- 本番デプロイ前のテストチェックリストがあること
例: デプロイプロセス
**1. コードの変更コミット**
– Feature branch等からのコミット
**2. CI/CDパイプライントリガー**
– GitHub Actions（推奨）、Jenkins等
**3. 自動ビルド＆テスト**
– 単体テスト
– 統合テスト
– 自動機能テスト（Selenium、Cypress等）
– APIテスト（Postman/Newman等）
– セキュリティスキャン（Amazon Inspector）
– 負荷テスト（JMeter、K6等）
– パフォーマンステスト
– 災害復旧テスト
– ロールバック手順の検証
**4. 承認プロセス**
– レベル1（開発リード）: コード品質・テスト結果の検証
– レベル2（QAマネージャー）: テストカバレッジ・品質基準の確認
– レベル3（インフラチーム）: インフラ変更の影響評価・セキュリティ要件の確認
– レベル4（プロダクトオーナー）: ビジネス要件・リリースタイミングの承認
**5. Production環境へのデプロイ**
– Blue/Greenデプロイメント
– Canaryデプロイメント（5% → 25% → 50% → 100%）
例: テストチェックリスト
**コード管理**
– バージョン管理システム（Git等）でコードを管理
– feature branchからmain branchへのマージ前にコードレビューを実施
**環境構成**
– 最低でもStaging → Production の環境構成を準備
– 各環境は独立したAWSアカウントで構成
– Staging環境は本番環境と同一構成で構築
**ビジネス承認**
– プロダクトオーナー承認：機能要件満足
– 運用チーム承認：運用準備完了
– セキュリティチーム承認：セキュリティ基準クリア
**ドキュメント確認**
– リリースノート：更新内容明記
– ランブック更新：新機能の運用手順追加
– アーキテクチャ図更新：最新構成反映
**ロールバック準備**
– バックアップ確認：スナップショットの作成
– ロールバック手順確認：文書化と検証完了
– ダウンタイム通知：関係者への連絡完了
– モニタリング強化：アラート閾値の一時的な調整
**テスト検証**
– 単体テスト、統合テスト、セキュリティテスト、負荷テスト、機能テストの実施と成功
提示したエビデンス
- デプロイチェックリスト
NETSEC-001: VPC Security（VPCセキュリティ）
要件
Establish internal processes regarding how to secure traffic within VPC, including:
- Security Groups to restrict traffic between Internet and Amazon VPC
- Security Groups to restrict traffic within the Amazon VPC
- Network ACL to restrict inbound and outbound traffic
- Other AWS security services to protect network security
確認ポイント
- VPCセキュリティのベストプラクティスをSOPとして整備すること
提示したエビデンス
- ネットワークセキュリティに関するSOP
- 基本設計書
例:
- 多層防御を実装している
- パブリックサブネットにインターネットからアクセス不要なリソースを置かない
- マルチAZ構成にする
- ACLやSGは必要最低限に絞る
- ALBやCloudFrontのようなインターネットにさらされるリソースにはWAFをアタッチする
NETSEC-002: Data Encryption（データ暗号化）
要件
Establish internal processes regarding a data encryption policy used across all customer projects
- Summary of any endpoints exposed to the Internet and how traffic is encrypted
- Summary of processes that make requests to external endpoints over the Internet and how traffic is encrypted
- Enforcing encryption at rest. By default you should enable the native encryption features in an AWS service that stores data unless there is a reason not to.
All cryptographic keys are stored and managed using a dedicated key management solution
確認ポイント
- データ暗号化ポリシーをSOPとして整備すること
提示したエビデンス
- データ暗号化SOP
- 基本設計書
例:
- 転送中データの暗号化方針：インターネットに公開されているリソースへのHTTPSの強制
- 保存中データの暗号化方針：特別な理由がない限り、全てのAWSリソースに対しAWSが提供する暗号化機能をデフォルトで有効化
- 証明書の管理方法：ACMを利用して管理
REL-001: Infrastructure as Code（IaC）
要件
Changes to infrastructure are automated for customer implementation
- Tools like AWS CloudFormation, the AWS CLI, or other scripting tools were used for automation.
- Changes to the production environment were not done using the AWS Management Console.
確認ポイント
- IaCを活用したインフラ自動化がSOPとして定義されていること
提示したエビデンス
- 開発SOP
- 基本設計書
例:
- Infrastructure as Codeの使用を前提とし、マネジメントコンソールからの手動変更を行わない
- アプリケーションのデプロイ時はCI/CDパイプラインを使用する
- 環境はstg、prodをアカウントで分離する
REL-002: Disaster Recovery / RTO・RPO
要件
Incorporate resilience discussion and advise a RTO&PRO target when engaging with customer. Customer acceptance and adoption on RTO/RPO is not required.
- Establish a process to establish workload resilience including:
- RTO & RPO target
- Explanation of the recovery process for the core components of the architecture
- Customer awareness and communication on this topic
確認ポイント
- RTO/RPOの標準プロセスが定義されていること
提示したエビデンス
- RTO/RPO定義書
例:
- 目標値（RTO: 4時間、RPO: 1時間など）
- 要件変更プロセス
- 復旧プロセス
COST-001: TCO Analysis（コスト分析）
要件
Determine solution costs using right sizing and right pricing for both technical and business justification.
Conducted TCO analysis or other form of cost modelling to provide the customer with an understanding of the ongoing costs including all the following 3 areas:
- Description of the inputs used to estimate the cost of the solution
- Summary of the estimates or cost model provided to the customer before implementation
- Business value analysis or value stream mapping of AWS solution
確認ポイント
- SOPに以下が定義されていること
- TCOの分析方法・分析手順
- TCOの分析に使用するツール
- 顧客事例として以下を提示できること
- TCOの分析
- AWSソリューションのビジネス価値分析またはバリューストリームマッピング
提示したエビデンス
- TCOの分析に関するSOP
- 提案資料（コスト分析、ビジネスバリューと課題のマッピング）
例: TCO分析のSOP内容
**■ TCO分析の基本要素**
| 分類 | 項目 |
|——|——|
| 初期コスト | アーキテクチャ設計費用、移行作業費用、初期構築費用、テスト・検証費用 |
| 運用コスト | AWSサービス利用料、運用保守人件費、ライセンス費用、サポート契約費用 |
**■ 分析手順**
1. **現状分析**: 現在のインフラストラクチャのコストを把握
2. **運用費試算**: AWS Pricing Calculatorを使用
3. **比較分析**: 既存構成とAWS導入後のコストを比較、ROI算出
4. **ビジネスバリュー分析**: AWS導入による新たなビジネスバリューを提示
**■ ビジネスバリューの例**
| カテゴリ | 内容 |
|———|——|
| 開発・デプロイの高速化 | SageMaker、Bedrock等でAI機能の迅速な実装 |
| ビジネス成長への柔軟な対応 | Auto Scalingによる需要変動対応、CloudFrontでグローバル展開 |
| イノベーションの実現 | IoT、Lambda、ECS・EKSによるモダンアーキテクチャ採用 |
| 事業継続性の向上 | マルチAZ/マルチリージョン、ISO・SOC・PCI-DSS準拠 |
| データドリブン経営 | Redshift、Athena、Kinesis、QuickSightの活用 |
まとめ
Common Cust Example Reqsのポイント：
- 4社分の顧客事例でエビデンスを示す
- SOPだけでなく実践の証拠が必要
- 設計書、構成書は再実装可能なレベルの詳細度
- 有資格者による設計レビューと資格証明が必須
- すべての要件で具体的なエビデンス（スクリーンショット、ドキュメント等）が必要
シリーズ一覧
- 第1回: プロジェクト概要と進め方
- 第2回: SMB Practice Requirements
- 第3回: Common Practice Requirements
- 第4回: Common Cust Example Reqs（本記事）