【AWS DevOps Competency】Validation Checklist(VCL:検証チェックリスト)の新バージョン（version 3.0）と旧バージョン（version 2.0）の差分

概要

AWSコンピテンシープログラムの一つである『AWS DevOpsコンピテンシー』認定を取得する際に必要な Validation Checklist(VCL：検証チェックリスト) について変更があり、2023年1月に新バージョン（3.0）がリリースされました。本投稿では新バージョンと旧バージョン（2.0）のValidation Checklistを比較して、その差分を記載します。

※Validation Checklistは、公式サイトのSelf-assessment Spreadsheetからダウンロードできます。

AWSコンピテンシープログラムとは？

AWS に関する技術的な専門知識とカスタマーサクセスを実証した AWS パートナーを評価する制度です。AWS パートナー企業が AWS コンピテンシーの認定を受けるには、AWS パートナーネットワーク（APN）プログラムの技術要件だけでなく、専門分野におけるスキルに関する審査・認定を受ける必要があります。

AWS DevOpsコンピテンシーとは？

開発者（Dev）と運用者（Ops）が協調することで高品質なソフトウェアを迅速に開発・提供するための継続的な取り組みである「DevOps」において、豊富な実績を持ち、優れたソリューションを提供するパートナーを認定するものです。
監査は外部の監査機関（AWSではない）によって実施されますが、公式サイトに記載してある前提条件と各要件をすべて満たす必要があります。
また、すべての要件についてエビデンスが必要です（説明しないさいという要件であってもエビデンスが必要）
AWS DevOpsコンピテンシーパートナーに認定されている企業は、今のところ日本国内で6社のみです（2023年2月時点）。
私の所属する会社でも、2022年8月に『AWS DevOpsコンピテンシー』認定を取得しました。　https://www.iret.co.jp/news/20220810.html

DevOpsのプラクティス要件

DevOps Practice Requirements

・差分のある項目：1項目のみ

Security

【セキュリティ】

PRSEC-001

DevSecOps ベスト プラクティスの伝達

差分(原文)

【Version2.0】
Communication of DevSecOps Best Practices
AWS Partner ensures customers understand AWS security processes and technologies as outlined in (https://aws.amazon.com/whitepapers/awssecurity-best-practices)

Evidence must be in the form of onboarding and educational documents provided to customers that specifically cover customer security considerations in the AWS Partner’s environment. In addition, evidence must be provided that the AWS Partner helps encourage “shift-left” of security practices, i.e., incorporating security guidelines and best practices early in development and as an ongoing part of the development and operations process.

【Version3.0】
Communication of DevSecOps Best Practices
AWS Partner ensures customers understand AWS security processes and technologies as outlined [here](https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all).

Evidence must be in the form of onboarding and educational documents provided to customers that specifically cover customer security considerations in the AWS Partner’s environment. In addition, evidence must be provided that the AWS Partner helps encourage “shift-left” of security practices, i.e., incorporating security guidelines and best practices early in development and as an ongoing part of the development and operations process.

差分(翻訳)

【Version2.0】
DevSecOps ベスト プラクティスの伝達
AWS パートナーは、(https://aws.amazon.com/whitepapers/awssecurity-best-practices) で概説されているように、お客様が AWS のセキュリティ プロセスとテクノロジーを確実に理解できるようにします。

証拠は、AWS パートナーの環境における顧客のセキュリティに関する考慮事項を具体的にカバーする、顧客に提供されるオンボーディングおよび教育文書の形式である必要があります。 さらに、AWS パートナーがセキュリティ プラクティスの「シフトレフト」を促進するのに役立つという証拠を提供する必要があります。

【Version3.0】
DevSecOps ベスト プラクティスの伝達
AWS パートナーは、[こちら] (https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all) で概説されているように、お客様が AWS のセキュリティ プロセスとテクノロジーを理解できるようにします。

証拠は、AWS パートナーの環境における顧客のセキュリティに関する考慮事項を具体的にカバーする、顧客に提供されるオンボーディングおよび教育文書の形式である必要があります。 さらに、AWS パートナーがセキュリティ プラクティスの「シフトレフト」を促進するのに役立つという証拠を提供する必要があります。

一般的なAWSパートナープラクティス要件

Common AWS Partner Practice Requirements

差分なし

DevOpsの顧客要件例

DevOps Customer Example Requirements

差分なし

一般的な顧客事例の要件

Common Customer Example Requirements

・差分のある項目：多数（全体的に大幅に変更されています）

要件概要

差分(原文)

【Version2.0】
All of the following requirements must be met by each submitted customer example.

【Version3.0】
All of the following requirements must be met by at least one of the four submitted customer examples. See specific evidence for each control.

差分(翻訳)

【Version2.0】
提出された各顧客事例は、次のすべての要件を満たす必要があります。

【Version3.0】
提出された4つの顧客事例のうち少なくとも1つが、次のすべての要件を満たす必要があります。 各コントロールの特定の証拠を参照してください。

Documentation

【ドキュメンテーション】
このカテゴリの要件は、各顧客の例に対して提供されるドキュメントに関連しています。

DOC-001

スケーラビリティと高可用性を考慮して設計されたアーキテクチャ図を提供

差分(原文)

【Version2.0】
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.

Each architecture diagram must show:
* The major elements of the architecture, and how they combine to provide the AWS Partner's solution to customers.
* All of the AWS services used, using the appropriate AWS service icons.
* How the AWS services are deployed, including virtual private clouds (VPCs), availability zones, subnets, and connections to systems outside of AWS.
* Elements deployed outside of AWS, e.g. on-premises components, or hardware devices.

【Version3.0】
Provide Architecture diagram designed with scalability and high availability
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.

Each architecture diagram must show:
* All of the AWS services used
* How the AWS services are deployed, including virtual private clouds (VPCs), availability zones, subnets, and connections to systems outside of AWS.
* Elements deployed outside of AWS, e.g. on-premises components, or hardware devices.
* how design scales automatically - Solution adapts to changes in demand. The architecture uses services that automatically scale such as Amazon S3, Amazon CloudFront, AWS Auto Scaling, and AWS Lambda.
* how design has high availability with multi-AZ or multi-region deployment. When intentional tradeoffs have been made (e.g. to optimize cost in favor of high availability), please explain the customer's requirements.

Please provide the following as evidence (required for all provided customer examples):

* An architecture diagram depicting the overall design and deployment of your solution on AWS.
* Explanation of how the major solutions elements will keep running in case of failure/outage.
* Description of how the major solutions elements scale up automatically.

差分(翻訳)

【Version2.0】
アーキテクチャ図
AWS パートナーは、AWS での AWS パートナー ソリューションの全体的な設計とデプロイを示すアーキテクチャ図、および問題の特定の顧客向けのソリューションのその他の関連する詳細を提出する必要があります。

提出された図は、技術的検証を実施する AWS ソリューション アーキテクトにコンテキストを提供することを目的としています。 AWS ソリューション アーキテクトが以下に示すその他の要件を検証できるように、適切な詳細レベルの明確な図を提供することが重要です。

各アーキテクチャ ダイアグラムには、次のものが表示されている必要があります。
* アーキテクチャの主要な要素と、それらを組み合わせて AWS パートナーのソリューションを顧客に提供する方法。
* 適切な AWS サービス アイコンを使用して、 使用されるすべての AWS サービス。
* 仮想プライベート クラウド (VPC)、アベイラビリティ ゾーン、サブネット、AWS 外のシステムへの接続など、AWS のサービスをデプロイする方法。
* AWS の外部にデプロイされた要素。 オンプレミス コンポーネント、またはハードウェア デバイス。

【Version3.0】
スケーラビリティと高可用性を考慮して設計されたアーキテクチャ図を提供
AWS パートナーは、AWS での AWS パートナー ソリューションの全体的な設計とデプロイを示すアーキテクチャ図、および問題の特定の顧客向けのソリューションのその他の関連する詳細を提出する必要があります。

提出された図は、技術的検証を実施する AWS ソリューション アーキテクトにコンテキストを提供することを目的としています。 AWS ソリューション アーキテクトが以下に示すその他の要件を検証できるように、適切な詳細レベルの明確な図を提供することが重要です。

各アーキテクチャ ダイアグラムには、次のものが表示されている必要があります。
* 使用されるすべての AWS サービス
* 仮想プライベート クラウド (VPC)、アベイラビリティ ゾーン、サブネット、AWS 外のシステムへの接続など、AWS のサービスをデプロイする方法。
* AWS の外部にデプロイされた要素。 オンプレミス コンポーネント、またはハードウェア デバイス。
* 設計が自動的にスケーリングされる方法 - ソリューションは需要の変化に適応します。 このアーキテクチャは、Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda など、自動的にスケーリングするサービスを使用します。
* マルチ AZ またはマルチリージョン配置で設計が高可用性を実現する方法。 意図的なトレードオフが行われた場合 (高可用性を優先してコストを最適化するなど)、お客様の要件を説明してください。

証拠として以下を提供してください (提供されたすべてのお客様の例で必須):

* AWS でのソリューションの全体的な設計とデプロイを示すアーキテクチャ図。
* 障害や停止が発生した場合に主要なソリューション要素がどのように稼働し続けるかについての説明。
* 主要なソリューション要素が自動的にスケールアップする方法の説明。

Secure Customer AWS Account Governance and Access

お客様の AWS アカウントのガバナンスとアクセスを保護

カテゴリ名

差分(原文)

【Version2.0】
AWS Account Configuration
【Version3.0】
Secure Customer AWS Account Governance and Access

差分(翻訳)

【Version2.0】
AWS アカウントの設定
【Version3.0】
お客様の AWS アカウントのガバナンスとアクセスを保護

Secure Customer AWS Account Governance and Access

【お客様の AWS アカウントのガバナンスとアクセスを保護】
お客様に代わって AWS パートナーが作成した AWS アカウント、または AWS パートナーが契約の一環として管理する AWS アカウントは、次の要件を満たす必要があります。

ACCT-001

安全な AWS アカウント ガバナンスのベスト プラクティスを定義する

差分(原文)

【Version2.0】
The root user is secured
All of the following must be implemented:
* IAM Users or IAM Roles are created and used for all routine activities. The root user is only used for tasks that require it. [Click here to see AWS Tasks That Require Root User](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html).
* Access keys are not assigned to the root user.
* Multi-Factor Authentication (MFA) is enabled on the root user.

Please provide the following as evidence:

* Describe the process in place to secure root users.

【Version3.0】
Define Secure AWS Account Governance Best Practice
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.

Establish internal processes regarding how to create AWS accounts on behalf of customers when needed, including:
* When to use root account for workload activities
* Enable MFA on root
* Set the contact information to corporate email address or phone number
* Enable CloudTrail logs in all region and protect CloudTrail logs from accidental deletion with a dedicated S3 bucket

Please provide the following as evidence:

* Documents describing Security engagement SOPs which met all the 4 criteria defined above. Acceptable evidence types are security training documents, internal wikis, or standard operating procedures documents.
* Description of how Secure AWS Account Governance is implemented in one (1) of the submitted customer examples.

差分(翻訳)

【Version2.0】
root ユーザーは保護されています
次のすべてを実装する必要があります。
* IAM ユーザーまたは IAM ロールが作成され、すべての日常的なアクティビティに使用されます。 root ユーザーは、それを必要とするタスクにのみ使用されます。 [ルートユーザーが必要な AWS タスクを表示するには、ここをクリックしてください](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)。
* root ユーザーにはアクセスキーは割り当てられません。
* root ユーザーで多要素認証 (MFA) が有効になっています。

証拠として次のものを提供してください。

* root ユーザーを保護するためのプロセスを説明してください。

【Version3.0】
安全な AWS アカウント ガバナンスのベスト プラクティスを定義する
AWS は、すべてのサービス パートナーが AWS アカウントを作成し、基本的なセキュリティのベスト プラクティスを実装する準備ができていることを期待しています。 ほとんどの顧客エンゲージメントでこれが必要ない場合でも、新しいアカウントを作成する必要がある顧客と協力する場合に備えて準備する必要があります。

必要に応じて顧客に代わって AWS アカウントを作成する方法に関する内部プロセスを確立します。これには以下が含まれます。
* ワークロード アクティビティにルート アカウントを使用する場合
* ルートで MFA を有効にする
*連絡先情報を会社のメールアドレスまたは電話番号に設定します
* すべてのリージョンで CloudTrail ログを有効にし、CloudTrail ログを専用の S3 バケットで誤って削除しないように保護します

証拠として次のものを提供してください。

* 上記で定義された 4 つの基準をすべて満たしたセキュリティ エンゲージメント SOP を説明するドキュメント。 許容される証拠の種類は、セキュリティ トレーニング ドキュメント、内部 wiki、または標準操作手順ドキュメントです。
* 提出された顧客事例の 1 つに、セキュアな AWS アカウント ガバナンスがどのように実装されているかの説明。

ACCT-002

IAM を活用してお客様の環境にアクセスする方法に関する ID セキュリティのベスト プラクティスを定義する

差分(原文)

【Version2.0】
Account contact information is set The Operations, Billing, and Security contact email addresses are set, and all account contact information, including the root user email address, is set to a corporate email address or phone number. Personal contact information may not be used for accounts owned by a company or organization.

Please provide the following as evidence:

* Describe the process in place to set the contact information.

【Version3.0】
Define identity security best practice on how to access customer environment by leveraging 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

Please provide the following as evidence:

* Security engagement SOPs which met all the 2 criteria defined above. Acceptable evidence types are: security training documents, internal wikis, standard operating procedures documents. Written descriptions in the self-assessment excel is not acceptable.
* Description of how IAM best practices are implemented in one (1) of the submitted customer examples.

差分(翻訳)

【Version2.0】
アカウントの連絡先情報が設定されています
運用、請求、およびセキュリティの連絡先の電子メール アドレスが設定され、ルート ユーザーの電子メール アドレスを含むすべてのアカウントの連絡先情報が、会社の電子メール アドレスまたは電話番号に設定されます。 個人の連絡先情報は、会社または組織が所有するアカウントには使用できません。

証拠として次のものを提供してください。

* 連絡先情報を設定するプロセスを記述します。

【Version3.0】
IAM を活用してお客様の環境にアクセスする方法に関する ID セキュリティのベスト プラクティスを定義する

以下を含む、顧客所有の AWS アカウントにアクセスするための標準的なアプローチを定義します。
* AWS マネジメント コンソール アクセスと、AWS コマンド ライン インターフェイスまたはその他のカスタム ツールを使用したプログラム アクセスの両方。
* IAM ロールなどの一時認証情報をいつ、どのように使用するか
* お客様の既存のエンタープライズ ユーザー ID とその認証情報を活用して、Identity Federation を介して AWS サービスにアクセスするか、AWS Managed Active Directory に移行する

以下を含む、AWS Identity and Access Management (IAM) およびその他の ID およびアクセス管理システムに関するベストプラクティスを確立します。
* IAM プリンシパルには、必要最小限の権限のみが付与されます。 Action 要素と Resource 要素でのワイルドカードの使用は、できる限り避ける必要があります。
* AWS アカウントにアクセスするすべての AWS パートナーは、専用の認証情報を使用してアクセスする必要があります

証拠として次のものを提供してください。

* 上記で定義された 2 つの基準をすべて満たしたセキュリティ エンゲージメント SOP。 許容される証拠の種類は、セキュリティ トレーニング ドキュメント、内部 wiki、標準操作手順ドキュメントです。 自己評価エクセルへの記述は不可。
* 提出されたお客様の例の 1 つに、IAM のベスト プラクティスがどのように実装されているかの説明。

ACCT-003（項目削除）

AWS CloudTrail が有効になっています

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
AWS CloudTrail is enabled
All of the following must be implemented:
* AWS CloudTrail is enabled in all AWS Regions.
* CloudTrail log file integrity validation is enabled.
* CloudTrail logs are stored in a separate administrative domain (i.e. a separate AWS account that is only intended for log storage and limited access or an equivalent solution).
* CloudTrail logs are protected from accidental deletion using MFA Delete or versioning on the Amazon Simple Storage Service (Amazon S3) bucket that stores the logs, or an equivalent solution.

Please provide the following as evidence:

* Description of the system used to retain CloudTrail logs if not using Amazon S3

【Version3.0】
なし

差分(翻訳)

【Version2.0】
AWS CloudTrail が有効になっています
次のすべてを実装する必要があります。
* AWS CloudTrail はすべての AWS リージョンで有効です。
* CloudTrail ログ ファイルの整合性検証が有効になっています。
* CloudTrail ログは別の管理ドメインに保存されます (つまり、ログ ストレージと制限付きアクセスまたは同等のソリューションのみを目的とした別の AWS アカウント)。
* CloudTrail ログは、ログを保存する Amazon Simple Storage Service (Amazon S3) バケットでの MFA 削除またはバージョニング、または同等のソリューションを使用して、偶発的な削除から保護されます。

証拠として次のものを提供してください。

* Amazon S3 を使用しない場合に CloudTrail ログを保持するために使用されるシステムの説明

【Version3.0】
なし

Operational Excellence

【オペレーショナルエクセレンス】
このカテゴリの要件は、AWS パートナーとお客様がシステムを実行および監視してビジネス価値を提供し、サポートプロセスと手順を継続的に改善する能力に関連しています。

OPE-001

顧客のワークロードの健全性 KPI を定義、監視、分析する

差分(原文)

【Version2.0】
Metrics are defined for understanding the health of the workload
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.

Please provide the following as evidence:

* Description of the metrics used to determine the health of each component of the workload.

【Version3.0】
Define, monitor and analyze customer workload health KPIs
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.

Establish the capability to run, monitor and improve operational procedure by:
* Defining, collecting and analyzing workload health metrics w/ AWS services or 3rd Party tool
* Exporting standard application logs that captre errors and aid in troubleshooting and response to operational events.
* Defining threshold of operational metrics to generate alert for any issues

Please provide the following as evidence:

* Standardized documents or guidance on how to deveop customer workload health KPIs with the three components above
* Description of how workload health KPIs are implemented in (1) of the submitted customer examples.

差分(翻訳)

【Version2.0】
ワークロードの健全性を理解するための指標が定義されている
AWS パートナーは、ワークロードの各コンポーネントの正常性を判断するためのメトリクスを定義し、これらのメトリクスに基づいて運用イベントを検出する方法に関するガイダンスを顧客に提供しました。

証拠として次のものを提供してください。

* ワークロードの各コンポーネントの正常性を判断するために使用されるメトリックの説明。

【Version3.0】
顧客のワークロードの健全性 KPI を定義、監視、分析する
AWS パートナーは、ワークロードの各コンポーネントの正常性を判断するためのメトリクスを定義し、これらのメトリクスに基づいて運用イベントを検出する方法に関するガイダンスを顧客に提供しました。

以下により、運用手順を実行、監視、改善する能力を確立します。
* AWS サービスまたはサードパーティ ツールを使用したワークロード ヘルス メトリクスの定義、収集、分析
* エラーを捕捉し、トラブルシューティングや運用イベントへの対応に役立つ標準アプリケーション ログのエクスポート。
* 問題が発生した場合にアラートを生成するための運用メトリックのしきい値の定義

証拠として次のものを提供してください。

* 上記の 3 つのコンポーネントを使用して顧客のワークロードの正常性 KPI を開発する方法に関する標準化されたドキュメントまたはガイダンス
* 提出されたお客様の例の (1) で、ワークロードの正常性 KPI がどのように実装されているかについての説明。

OPE-002

運用タスクをガイドする顧客のランブック/プレイブックを定義する

差分(原文)

【Version2.0】
Workload health metrics are collected and analyzed
Workload health metrics are collected and analyzed. The configuration and deployment of metrics collection and alerting does not have to be done by the AWS Partner, but the AWS Partner should provide guidance and assistance to the customer to ensure they are able to successfully integrate the AWS Partner solution into their own operational processes and tools.

Please provide the following as evidence:

* Description of the systems or applications used to collect and analyze workload health metrics

【Version3.0】
Define a customer runbook/playbook to guide operational tasks
Workload health metrics are collected and analyzed. The configuration and deployment of metrics collection and alerting does not have to be done by the AWS Partner, but the AWS Partner should provide guidance and assistance to the customer to ensure they are able to successfully integrate the AWS Partner solution into their own operational processes and tools.

Use runbook to document routine activities and guide issue resolution process with a list of operational tasks and troubleshooting scenarios covered

Please provide the following as evidence:
* Standardized documents or runbook met the criteria defined above.

差分(翻訳)

【Version2.0】
ワークロードの健全性指標が収集され、分析されます
ワークロードの正常性指標が収集され、分析されます。 メトリクスの収集とアラートの設定と展開は、AWS パートナーが行う必要はありませんが、AWS パートナーは、顧客が AWS パートナー ソリューションを自社の運用プロセスにうまく統合できるように、ガイダンスと支援を提供する必要があります。 ツール。

証拠として次のものを提供してください。

* ワークロードの正常性指標の収集と分析に使用されるシステムまたはアプリケーションの説明

【Version3.0】
運用タスクをガイドする顧客のランブック/プレイブックを定義する
ワークロードの正常性指標が収集され、分析されます。 メトリクスの収集とアラートの設定と展開は、AWS パートナーが行う必要はありませんが、AWS パートナーは、顧客が AWS パートナー ソリューションを自社の運用プロセスにうまく統合できるように、ガイダンスと支援を提供する必要があります。 ツール。

ランブックを使用して日常的な活動を文書化し、対象となる運用タスクとトラブルシューティング シナリオのリストを使用して問題解決プロセスをガイドします

証拠として次のものを提供してください。
* 標準化されたドキュメントまたはランブックは、上記の基準を満たしています。

OPE-003

一貫したプロセス (チェックリストなど) を使用して、展開の準備状況を評価する

差分(原文)

【Version2.0】
Operational enablement
AWS Partner ensures operational personnel are capable of supporting the solution. They must conduct a handover to ensure the personnel responsible for ongoing operations, whether that be the customer or the AWS Partner, understand how to monitor the workload, backup and restore data, patch and upgrade operating systems and application components, and troubleshoot common problems.

Please provide the following as evidence:

* Description of the operational handover process.
* List of operational tasks and troubleshooting scenarios covered.

【Version3.0】
Use consistent processes (e.g. checklist) to assess 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.

Use a consistent approach to deploy to customers including:
* A well-defined testing process before launching in production environment
* Automated testing components

Please provide the following as evidence:

* A deployment checklist example or written descriptions met all the criteria defined above.

差分(翻訳)

【Version2.0】
運用の有効化
AWS パートナーは、運用担当者がソリューションをサポートできることを保証します。 継続的な運用を担当する担当者 (顧客であるか AWS パートナーであるかを問わず) が、ワークロードの監視方法、データのバックアップと復元、オペレーティング システムとアプリケーション コンポーネントのパッチとアップグレード、および一般的な問題のトラブルシューティングの方法を理解していることを確認するために、引き継ぎを実施する必要があります。

証拠として次のものを提供してください。

* 運用引き継ぎプロセスの説明。
* 対象となる操作タスクとトラブルシューティング シナリオのリスト。

【Version3.0】
一貫したプロセス (チェックリストなど) を使用して、展開の準備状況を評価する
デプロイメントは、実稼働環境に適用される前にテストまたはその他の方法で検証されます。 たとえば、プロジェクトでリソースをプロビジョニングしたり、ソフトウェアやアプリケーションをリリースしたりするために使用される DevOps パイプラインです。

次のような一貫したアプローチを使用して顧客に展開します。
* 本番環境での起動前に明確に定義されたテスト プロセス
* 自動テスト コンポーネント

証拠として次のものを提供してください。

* 導入チェックリストの例または記述された説明は、上記で定義されたすべての基準を満たしています。

OPE-004（項目削除）

展開のテストと検証

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
Deployment testing and validation
Deployments are tested or otherwise validated before being applied to the production environment.

Please provide the following as evidence:

* Description of the testing and validation process

【Version3.0】
なし

差分(翻訳)

【Version2.0】
展開のテストと検証
デプロイメントは、実稼働環境に適用される前にテストまたはその他の方法で検証されます。

証拠として次のものを提供してください。

* テストおよび検証プロセスの説明

【Version3.0】
なし

OPE-005（項目削除）

コード資産はバージョン管理されています

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
Code assets are version controlled
Version control is used to manage code assets including application code, deployment scripts, infrastructure templates, etc. The version control system used can be owned and managed by the AWS Partner or the customer.

Please provide the following as evidence:

* Version control system used for the project

【Version3.0】
なし

差分(翻訳)

【Version2.0】
コード資産はバージョン管理されています
バージョン管理は、アプリケーション コード、デプロイ スクリプト、インフラストラクチャ テンプレートなどを含むコード資産を管理するために使用されます。使用されるバージョン管理システムは、AWS パートナーまたは顧客が所有および管理できます。

証拠として次のものを提供してください。

* プロジェクトに使用されるバージョン管理システム

【Version3.0】
なし

OPE-006（項目削除）

アプリケーションとワークロードのテレメトリ

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
Application and workload telemetry
Solution components emit information that allows operators to understand their internal state. This telemetry information should at a minimum consist of standard application logs that capture errors and aid in troubleshooting and response to operational events.

Please provide the following as evidence:

* Description of the key metrics, logs, and traces emitted by the AWS Partner solution components

【Version3.0】
なし

差分(翻訳)

【Version2.0】
アプリケーションとワークロードのテレメトリ
ソリューション コンポーネントは、オペレーターが内部状態を理解できるようにする情報を出力します。 このテレメトリ情報は、少なくとも、エラーをキャプチャし、トラブルシューティングや運用イベントへの対応に役立つ標準的なアプリケーション ログで構成する必要があります。

証拠として次のものを提供してください。

* AWS パートナー ソリューション コンポーネントによって出力される主要なメトリクス、ログ、およびトレースの説明

【Version3.0】
なし

Security - Identity and Access Management（カテゴリ削除）

【セキュリティ - ID およびアクセス管理】
このカテゴリの要件は、AWS Identity and Access Management (IAM) および AWS パートナーが所有するその他の ID およびアクセス管理システムに関するベストプラクティスに焦点を当てています。

・Version3.0ではカテゴリごと削除されています。

Security - Networking

【セキュリティ - ネットワーキング】
このカテゴリの要件は、Virtual Private Cloud (Amazon VPC) のセキュリティのベスト プラクティスとその他のネットワーク セキュリティの考慮事項に焦点を当てています。

NETSEC-001

Virtual Private Cloud (Amazon VPC) およびその他のネットワーク セキュリティに関する考慮事項のセキュリティのベスト プラクティスを定義します。

差分(原文)

【Version2.0】
Security groups are tightly scoped.
All security groups should restrict access to the greatest degree possible. This includes at least:

1. Implementing Security Groups to restrict traffic between Internet and Amazon VPC
2. Implementing Security Groups to restrict traffic within the Amazon VPC
3. In all cases, allow only the most restrictive possible settings.

Please provide the following as evidence:

* An example security group configuration for a major component of the architecture.

【Version3.0】
Define security best practices for Virtual Private Cloud (Amazon VPC) and other network security considerations.
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

Please provide the following as evidence:

* Written descriptions/documents on network security best practices met the criteria defined above.
* Description of how network security is implementation in one (1) of the submitted customer examples.

差分(翻訳)

【Version2.0】
セキュリティ グループの範囲は厳密に限定されています。
すべてのセキュリティ グループは、可能な限りアクセスを制限する必要があります。 これには、少なくとも以下が含まれます。

1. インターネットと Amazon VPC 間のトラフィックを制限するためのセキュリティ グループ の実装
2. Amazon VPC 内のトラフィックを制限するためのセキュリティ グループ の実装
3. いずれの場合も、可能な限り制限の厳しい設定のみを許可してください。

証拠として次のものを提供してください。

* アーキテクチャの主要コンポーネントのセキュリティ グループ構成の例。

【Version3.0】
Virtual Private Cloud (Amazon VPC) およびその他のネットワーク セキュリティに関する考慮事項のセキュリティのベスト プラクティスを定義します。
以下を含む、VPC 内のトラフィックを保護する方法に関する内部プロセスを確立します。
* インターネットと Amazon VPC 間のトラフィックを制限するためのセキュリティ グループ
* Amazon VPC 内のトラフィックを制限するためのセキュリティ グループ
* インバウンドおよびアウトバウンド トラフィックを制限するためのネットワーク ACL

証拠として次のものを提供してください。

* ネットワーク セキュリティのベスト プラクティスに関する記述/文書は、上記の基準を満たしています。
* 提出された顧客事例の 1 つに、ネットワーク セキュリティがどのように実装されているかの説明。

NETSEC-002

保管中および転送中のデータのデータ暗号化ポリシーを定義する

差分(原文)

【Version2.0】
Data that traverses the Internet is encrypted in transit.
All Internet-facing endpoints must use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) or another standard mechanism to encrypt data that leaves the AWS Partner's network. Any connections between an Amazon VPC where the solution is deployed and any other private network outside of AWS must also be encrypted.

Please provide the following as evidence:

* Summary of any endpoints exposed to the Internet and how traffic is encrypted
* Explanation of how private keys are stored and distributed for any SSL/TLS endpoints
* Summary of processes that make requests to external endpoints over the Internet and how traffic is encrypted

【Version3.0】
Define data encryption policy for data at rest and in transit
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

Please provide the following as evidence:

* Data encryption and key management policy met the criteria defined above.
* Description of how data encryption is implementation in one (1) of the submitted customer examples.

差分(翻訳)

【Version2.0】
インターネットを通過するデータは、転送中に暗号化されます。
インターネットに接続するすべてのエンドポイントは、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) または別の標準メカニズムを使用して、データを暗号化する必要があります。 AWS パートナーのネットワークを離れます。 ソリューションがデプロイされている Amazon VPC と、AWS 外の他のプライベート ネットワークとの間の接続も暗号化する必要があります。

証拠として次のものを提供してください。

* インターネットに公開されているエンドポイントの概要とトラフィックの暗号化方法
* SSL/TLS エンドポイントの秘密鍵がどのように保管および配布されるかについての説明
* インターネット経由で外部エンドポイントにリクエストを送信するプロセスとトラフィックの暗号化方法の概要

【Version3.0】
保管中および転送中のデータのデータ暗号化ポリシーを定義する
すべての顧客プロジェクトで使用されるデータ暗号化ポリシーに関する内部プロセスを確立する
* インターネットに公開されているエンドポイントの概要とトラフィックの暗号化方法
* インターネット経由で外部エンドポイントにリクエストを送信するプロセスとトラフィックの暗号化方法の概要
* 保存時の暗号化を強制します。 デフォルトでは、特に理由がない限り、データを保存する AWS サービスのネイティブ暗号化機能を有効にする必要があります。

すべての暗号化キーは、専用のキー管理ソリューションを使用して保存および管理されます

証拠として次のものを提供してください。

* データ暗号化とキー管理ポリシーは、上記で定義された基準を満たしています。
* 提出された顧客事例の 1 つに、データ暗号化がどのように実装されているかの説明。

NETSEC-003（項目削除）

データ ストアはプライベート サブネットにあります。

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
Data stores are in private subnets.
Any data stores (e.g. databases, internal caches, search clusters, etc.) within an Amazon VPC must either exist in a private subnet (i.e. a subnet with no route to an Internet Gateway) or use AWS Signature Version 4 with AWS IAM for authenticating requests (e.g. Amazon DynamoDB, Amazon S3, Amazon Elasticsearch Service).

Please provide the following as evidence:

* An architecture diagram attached to the customer example that accurately depicts the Amazon VPC topology and all data stores. This can be the same diagram(s) used to fulfill the DOC-001 requirement.

Alternatively, if no diagram is available depicting the detailed Amazon VPC topology, you may provide the following as evidence:

* A list of all data stores in the architecture and the routes (destinations and targets) associated with the subnet(s) where each data store resides.

【Version3.0】
なし

差分(翻訳)

【Version2.0】
データ ストアはプライベート サブネットにあります。
Amazon VPC 内のすべてのデータ ストア (データベース、内部キャッシュ、検索クラスターなど) は、プライベート サブネット (つまり、インターネット ゲートウェイへのルートがないサブネット) に存在するか、認証のために AWS IAM で AWS 署名バージョン 4 を使用する必要があります。 リクエスト (Amazon DynamoDB、Amazon S3、Amazon Elasticsearch Service など)。

証拠として次のものを提供してください。

* Amazon VPC トポロジとすべてのデータ ストアを正確に表す、お客様の例に添付されたアーキテクチャ図。 これは、DOC-001 要件を満たすために使用される同じ図である可能性があります。

または、詳細な Amazon VPC トポロジを示す図がない場合は、証拠として以下を提供できます。

* アーキテクチャ内のすべてのデータ ストアと、各データ ストアが存在するサブネットに関連付けられたルート (宛先とターゲット) のリスト。

【Version3.0】
なし

Security - IT Operations（カテゴリ削除）

【セキュリティ - IT 運用】
このカテゴリの要件は、ロギング、監視、インシデント対応、データ分類などの IT セキュリティ運用のベスト プラクティスに焦点を当てています。

・Version3.0ではカテゴリごと削除されています。

AWS API Integration（カテゴリ削除）

【AWS APIインテグレーション】
このカテゴリの要件は、AWS API の呼び出しに関するベスト プラクティスを扱います。

・Version3.0ではカテゴリごと削除されています。

Reliability

【信頼】
このセクションの要件は、AWS パートナー ソリューションが障害を防止し、障害から迅速に回復して、ビジネスおよび顧客の需要を満たす能力に焦点を当てています。

REL-001

開発を自動化し、コードとしてのインフラストラクチャ ツールを活用します。

差分(原文)

【Version2.0】
Deployment automation.
Changes to infrastructure are automated using tools like AWS CloudFormation, the AWS CLI, or other scripting tools. Changes to the production environment should not be made using the AWS Management Console.

Please provide the following as evidence:

* Description of the deployment process.

【Version3.0】
Automate Development and leverage infrastructure-as-code tools.
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.

Please provide the following as evidence:

* Written description of deployment automation and an example template (e.g., CloudFormation templates, architecture diagram for CI/CD pipeline) met the criteria defined above.

差分(翻訳)

【Version2.0】
展開の自動化。
インフラストラクチャへの変更は、AWS CloudFormation、AWS CLI、またはその他のスクリプト ツールなどのツールを使用して自動化されます。 本番環境への変更は、AWS マネジメント コンソールを使用して行うべきではありません。

証拠として次のものを提供してください。

* 導入プロセスの説明。

【Version3.0】
開発を自動化し、コードとしてのインフラストラクチャ ツールを活用します。
インフラストラクチャへの変更は、お客様の実装のために自動化されています

* 自動化には、AWS CloudFormation、AWS CLI、またはその他のスクリプト ツールなどのツールが使用されました。
* AWSマネジメントコンソールによる本番環境の変更は行っておりません。

証拠として次のものを提供してください。

* デプロイの自動化とサンプル テンプレート (例: CloudFormation テンプレート、CI/CD パイプラインのアーキテクチャ図) の書面による説明は、上記で定義された基準を満たしています。

REL-002

ディザスター リカバリーを計画し、RTO と RPO を推奨します。

差分(原文)

【Version2.0】
Availability requirements are defined for the solution.
A recovery time objective (RTO) and recovery point objective (RPO) have been defined in the event of both individual node failure and availability zone disruption. The solution is architected to achieve the defined RTO and RPO.

Please provide the following as evidence:

* RTO and RPO for each failure scenario.
* Explanation of the recovery process for the core components of the architecture.

【Version3.0】
Plan for disaster recovery and recommend RTO and 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 estalish 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

Please provide the following as evidence:

* Descriptions or documents on workload resilience guidance met the three criteria defined above
* Description of how resilience is implementation in one (1) of the submitted customer examples including reasons for exception when RTO&RPO is not defined

差分(翻訳)

【Version2.0】
ソリューションの可用性要件が定義されています。
個々のノードの障害とアベイラビリティ ゾーンの中断の両方が発生した場合に備えて、目標復旧時間 (RTO) と目標復旧時点 (RPO) が定義されています。 このソリューションは、定義された RTO と RPO を達成するように設計されています。

証拠として次のものを提供してください。

* 各障害シナリオの RTO と RPO。
* アーキテクチャのコア コンポーネントの回復プロセスの説明。

【Version3.0】
ディザスター リカバリーを計画し、RTO と RPO を推奨します。
レジリエンスに関する話し合いを組み込み、お客様とのやり取りの際に RTO と PRO の目標をアドバイスします。 RTO/RPO に関する顧客の承認と採用は必要ありません。

* 以下を含む、ワークロードの回復力を確立するためのプロセスを確立します。
* RTO と RPO の目標
* アーキテクチャのコア コンポーネントの回復プロセスの説明
* このトピックに関する顧客の認識とコミュニケーション

証拠として次のものを提供してください。

* ワークロード レジリエンス ガイダンスに関する説明またはドキュメントが、上記で定義した 3 つの基準を満たしている
* RTO&RPO が定義されていない場合の例外の理由を含む、提出された顧客の例の 1 つにレジリエンスがどのように実装されているかの説明

REL-003（項目削除）

AWS パートナー ソリューションは、需要の変化に適応します。

・Version3.0では項目ごと削除されています。

差分(原文)

【Version2.0】
The AWS Partner solution adapts to changes in demand.
The process for how the AWS Partner solution adapts to changes in demand is defined and automated when possible. When possible, the architecture uses services that automatically scale such as Amazon S3, Amazon CloudFront, AWS Auto Scaling, and AWS Lambda. In some cases automated scaling may not be possible due to software licensing restrictions or legacy application architecture limitations.

Please provide the following as evidence:

* Description of how resources are procured when demand increases.
* Explanation of technical or business blockers that prevent automated resource procurement

【Version3.0】
なし

差分(翻訳)

【Version2.0】
AWS パートナー ソリューションは、需要の変化に適応します。
AWS パートナー ソリューションが需要の変化に適応する方法のプロセスが定義され、可能な場合は自動化されています。 可能な場合、アーキテクチャは、Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda などの自動的にスケーリングするサービスを使用します。 場合によっては、ソフトウェア ライセンスの制限またはレガシー アプリケーション アーキテクチャの制限により、自動スケーリングができない場合があります。

証拠として次のものを提供してください。

* 需要が増加した場合のリソースの調達方法の説明。
* 自動化されたリソース調達を妨げる技術的またはビジネス上の阻害要因の説明

【Version3.0】
なし

Cost Optimization

【コストの最適化】
このカテゴリの要件は、最低価格でビジネス価値を提供するシステムを顧客が実行できるようにする AWS パートナーの能力に関連しています。

COST-001

総所有コスト分析またはコスト モデリングの開発

差分(原文)

【Version2.0】
Total cost of ownership (TCO) analysis or cost modeling was done.
AWS Partner conducted some level of TCO analysis or other form of cost modeling to provide the customer with an understanding of the ongoing costs to run the AWS Partner solution in the customer's environment. This does not need to be delivered as a formal document, but the AWS Partner must have discussed the anticipated load and other factors with the customer and provided cost estimates based on those assumptions.

Please provide the following as evidence:

* 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

【Version3.0】
Develop total cost of ownership analysis or cost modelling
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

Please provide the following as evidence:

* Description of how to develp cost analysis or modeling with the critical components defined above
* Cost analysis example in one (1) of the submitted customer examples. Acceptable evidence types are: price calculator link, reports or presentations on business values analysis

差分(翻訳)

【Version2.0】
総所有コスト (TCO) 分析またはコスト モデリングが行われました。
AWS パートナーは、お客様の環境で AWS パートナー ソリューションを実行するための継続的なコストをお客様に理解してもらうために、ある程度の TCO 分析またはその他の形式のコスト モデリングを実施しました。 これは正式な文書として提出する必要はありませんが、AWS パートナーは、予想される負荷やその他の要因について顧客と話し合い、それらの仮定に基づいてコストの見積もりを提供している必要があります。

証拠として次のものを提供してください。

* ソリューションのコストを見積もるために使用されるインプットの説明
* 実装前に顧客に提供された見積もりまたはコスト モデルの概要

【Version3.0】
総所有コスト分析またはコスト モデリングの開発
技術的正当性とビジネス上の正当性の両方について、適切なサイジングと適切な価格設定を使用して、ソリューションのコストを決定します。

TCO 分析またはその他の形式のコスト モデリングを実施して、次の 3 つの領域すべてを含む継続的なコストをお客様に理解してもらいます。

* ソリューションのコストを見積もるために使用されるインプットの説明
* 実装前に顧客に提供された見積もりまたはコスト モデルの概要
* AWS ソリューションのビジネス価値分析またはバリュー ストリーム マッピング

証拠として次のものを提供してください。

* 上記で定義した重要なコンポーネントを使用してコスト分析またはモデリングを開発する方法の説明
* 提出された顧客事例のうちの 1 つ (1) のコスト分析事例。 許容される証拠の種類は次のとおりです: 価格計算機のリンク、ビジネス価値分析に関するレポートまたはプレゼンテーション

最後に

認定を取得することで、社外にDevOpsのケイパビリティを示すことができると同時に、
認定を取得するための準備をとおして、改善点や今後の取り組み、体制のヒントにもなりました。
今後もアップデートはチェックしていきたいと思います。