AWS Energy Competency

Partner Offering Validation Checklist

January 2024 - 1.3

This AWS Energy Competency Checklist updated to version (1.3) has gone into effect on January 1, 2024. Partners may choose to use the previous checklist version (1.1) until March 31, 2024 when the checklist will no longer be in effect. All applications submitted after March 31, 2024 are required to comply with the current Validation Checklist requirements.

Introduction

The goal of the AWS Specialization Programs is to recognize AWS Partner Network Partners (“AWS Partners”) who demonstrate technical proficiency and proven customer success in specialized solution areas. The AWS Competency Partner Validation Checklist (“Checklist”) is intended for AWS Partners who are interested in applying for an AWS Specialization. This Checklist provides the criteria necessary to achieve the specialization as a software partner. AWS Partners undergo an audit of their capabilities upon applying for a specific specialization. AWS leverages in-house expertise and/or a third-party firm to facilitate the audit. AWS reserves the right to make changes to this document at any time.

Expectation of Parties

It is expected that AWS Partners will review this document in detail before applying for the AWS Competency Program, even if all of the prerequisites are met. If items in this document are unclear and require further explanation, please contact your AWS Partner Development Representative (“PDR”) or AWS Partner Development Manager “(PDM”) as the first step. Your PDR/PDM will contact the program office if further assistance is required.

AWS Partners should complete the Self-Assessment Spreadsheet linked at the top of this page, prior to submitting a program application. Once completed, AWS Partners must submit an application in APN Partner Central. Visit the AWS Competency Program guide for step-by-step instructions on how to submit an application.

AWS will review and aim to respond back with any questions within five business days. Incomplete applications will not be considered until all requirements are met. If complete, AWS will send the application to in-house solution architect (SA) experts to complete a Technical Validation. A validation call may be required once the AWS SA has reviewed the self-assessment offline. The AWS SA will reach out directly if additional information is required, or to schedule a validation call.

AWS Partners should prepare for the audit by reading the Checklist, completing a self-assessment using the Checklist, and gathering and organizing objective evidence to share with the auditor on the day of the audit.

AWS recommends that AWS Partners have individuals who are able to speak in-depth about how the solution meets the requirements

described in this document during the audit. The best practice is for the AWS Partner to make the following personnel available for the audit: one or more highly technical AWS certified engineers/architects, an operations manager who is responsible for the operations and support elements, and a business development executive to conduct the overview presentation. AWS Partners should ensure that they have the necessary consents to share with the auditor (whether AWS or a third-party) all information contained within the objective evidence or any demonstrations prior to scheduling the audit.

AWS may revoke an AWS Partner’s Competency designation if, at any time, AWS determines in its sole discretion that such AWS Partner does not meet its AWS Competency Program requirements. If an AWS Partner’s Competency designation is revoked, such AWS Partner will (i) no longer receive benefits associated with its designation, (ii) immediately cease use of all materials provided to it in connection with the applicable Competency designation and (iii) immediately cease to identify itself as an AWS Partner of such AWS Competency.

AWS Energy Definition and Competency Categories

AWS Partners who have demonstrated technical proficiency and proven customer success in specialized Energy industry solutions defined by categories. Categories are aligned to specific industry markets to help our customers identify and find partners and as a mechanism to identify, validate and map partners into categories.

AWS Energy Competency solutions fall into one of the following categories:

Upstream: Solutions for managing upstream activities involved in searching for and producing crude oil and natural gas.

Midstream: Platforms for managing the gathering, processing, transportation and storage of crude oil, natural gas, refined products, and petrochemicals.

Downstream: Solutions for managing the operations and processes involved in converting oil and natural gas, and the marketing and distribution of derived products.

Health, Safety, Environment: Solutions for managing safety, occupational health, environment and sustainable development.

New Energies: Solutions for managing activities involved in developing and distributing renewable/clean energy sources.

Data Analytics and Insights: Platforms providing market and reference data, information insights and analytics, data management solutions.

Core Energy Business Applications: Manage the day-to-day business activities such as accounting, procurement, project management, security and supply chain.

AWS Energy Competency Program Prerequisites

The following items will be validated by the AWS Competency Program Manager; missing or incomplete information must be addressed prior to scheduling of the Technology Validation Review.

  1. 1.0APN Program Membership

    1. 1.1Program Guidelines

      The AWS Partner must read the Program Guidelines and Definitions before applying to the AWS Energy Competency Program. Click here for Program details.

    2. 1.2Software Path Membership

      Partner must be at the Validated or Differentiated stage within the Software Path. SI Partners should talk to their PDR/PDM on how to join the Software Path.

    3. 1.3Foundational Technical Review

      The AWS Partner solution must have a valid AWS Foundational Technical Review. FTRs completed for other solutions in the AWS Partner’s portfolio do not fulfill this requirement.

    4. 1.4Solution Category

      The AWS Partner must identify the specific AWS Energy category and deployment model for their solutions. Deployment models must be one of:

      • SaaS on AWS
      • Customer deployed
  2. 2.0Example AWS Customer Deployments

    1. 2.1Production AWS Customer Case Studies

      The AWS Partner must privately share with AWS details about four (4) unique examples of Energy projects executed for four (4) unique AWS customers. Each case study must demonstrate how the partner offering was used by a customer to solve a specific Energy customer challenge using AWS.

      In addition to the required case study details provided in AWS Partner Central, the partner must also provide architecture diagrams of the specific customer deployment and information listed in the technical requirements sections of this validation checklist.

      The information provided for these case studies will be used by AWS for validation purposes only. The partner is not required to publish these details publicly.

      AWS Partner can reuse the same case study across different AWS Specialization designations as long as the case study and implementation scope are relevant to those designations. The partner should make sure the existing case study clearly explains the relevance to each designation they are applying for.

      AWS will accept one case study per customer. Each customer must be a separate legal entity to qualify. The partner may use an example for an internal or affiliate company of the partner if the offering is available to outside customers.

      All case studies must describe deployments that have been performed within the past 18 months and must be for projects that are in production with customers, rather than in a ‘pilot’ or proof of concept stage.

      All case studies provided will be examined in the Documentation Review of the Technical Validation. The partner offering will be removed from consideration if the partner cannot provide the documentation necessary to assess all case studies against each relevant validation checklist item, or if any of the validation checklist items are not met.

    2. 2.2Publicly Available Case Studies

      At least two (2) of the provided case studies must be publicly available examples describing how the partner used AWS to help solve a specific customer challenge related to Energy. These publicly available examples may be in the form of formal customer case studies, white papers, videos, or blog posts. The partner will provide the publicly available URL (published by the partner) in the AWS Partner Central ‘Case Study URL’ field, which must include the following details:

      • AWS Customer name
      • AWS Partner name
      • AWS Customer challenge that aligns with the scope of the competency and selected category
      • Using both high-level and technical details, describe how AWS was leveraged as part of the partner solution
      • Outcome(s) and/or quantitative results
    3. 2.3Anonymized Public Case Studies

      In cases where the partner cannot publicly name customers due to the sensitive nature of the customer engagements, the partner may choose to anonymize the public case study. Anonymized public case study details will be published by AWS, but the customer name will remain private. The partner must provide the AWS Customer name in the ‘Company name’ field of the AWS Partner Central case study for validation purposes, but it will not be published by AWS. The case study fields that will be published to Partner Solutions Finder (PSF) by AWS include the ‘Title’, ‘Case Study Description’, and ‘Case Study URL’. The partner will provide the publicly available URL (published by the partner) in the AWS Partner Central ‘Case Study URL’ field, which must include the following details:

      • AWS Customer Description (e.g. a top 5 US retailer, a Fortune 500 financial institution, etc.).
      • AWS Partner name
      • AWS Customer challenge that aligns with the scope of the competency and selected category
      • Using both high-level and technical details, describe how AWS was leveraged as part of the partner solution
      • Outcome(s) and/or quantitative results

      For best practices on how to write an accepted public case study see the Public Case Study Guide.

  3. 3.0Business Requirements

    1. 3.1Field-Ready Toolkits

      AWS Partner has field-ready documentation and a seller toolkit that enable their field sellers to articulate a clear product value proposition to AWS customers.

      Evidence must be in the form of sales collateral including a customer presentation, one-pager, and customer success stories.

    2. 3.2Product Support/Help Desk

      AWS Partner offers product support via web chat, phone, or email support to customers.

      Evidence must be in the form of description of support offered to customers for their product or solution.

    3. 3.3AWS Marketplace Listing

      If the solution is available via AWS Marketplace, AWS Partner must provide a link to the AWS Marketplace listing in their application.

      An AWS Marketplace listing is not mandatory to achieve the AWS Competency.

  4. 4.0AWS Partner Self-Assessment

    1. 4.1AWS Partner Self-Assessment

      AWS Partner must conduct a self-assessment of their compliance to the requirements of the AWS Energy Technology Partner Validation Checklist. A version of this Checklist is available in spreadsheet format. Links to the appropriate self-assessment spreadsheet can be found at the top of this page.

      • AWS Partner must complete all sections of the Checklist.
      • Completed self-assessment should be uploaded via the AWS Competency application in AWS Partner Central. It is recommended that AWS Partner has their Partner Solutions Architect (PSA), Partner Development Representative (PDR), or Partner Development Manager (PDM) review the completed self-assessment before submitting to AWS. The purpose of this is to ensure the AWS Partner’s AWS team is engaged and working to provide recommendations prior to the review and to help ensure a productive review experience.

Energy Technical Requirements

The following requirements apply to all AWS Energy Services Competency technology solutions.

Category Fit

  • ETC-001 - DevOps enablement and category fit

    Applies to: SaaS | Customer Deployed

    The AWS Partner solution meets the definition of the category specified in the application. See the AWS Energy Definition and Competency Categories for category definitions. Evidence AWS Partner is part of Energy vertical.

Common Technical Requirements

The following requirements apply to all AWS Competency technology solutions. This section of the requirements are WAIVED if the AWS Partner has achieved another AWS Software Competency within the last 12 months for the associated offering.

Support

  • SUP-001 - Enable AWS Business Support (or greater) on all production AWS accounts

    Applies to: SaaS | Customer Deployed

    AWS Support provides a mix of tools and technology, people, and programs designed to proactively help you optimize performance, lower costs, and innovate faster. AWS Business Support provides additional benefits including access to AWS Trusted Advisor and AWS Personal Health Dashboard and faster response times.

    For SaaS solutions, subscribing to AWS Business Support or greater for all production accounts is a requirement to successfully complete the validation for Competency Program. For customer deployed solutions, the Partner must subscribe to premium support for the AWS accounts which produce the solution.

  • SUP-002 - Product Support/Help Desk

    Applies to: SaaS | Customer Deployed

    AWS Partner offers product support via web chat, phone, or email support to customers.

    Evidence must be in the form of description of support offered to customers for their product or solution.

Documentation

The following requirements apply to all AWS Partner solutions.

  • DOC-001 - Architecture Diagram

    Applies to: SaaS | Customer Deployed

    AWS Partner must submit architectural diagrams depicting the overall design and deployment of the solution on AWS as well as any other relevant details of the solution.

    The provided diagrams are intended to provide context to the AWS Solutions Architect conducting the technical validation. These diagrams will be referenced during the validation call. It is critical to provide clear diagrams with an appropriate level of detail in order to enable an efficient conversation about the product architecture with respect to the other technical requirements described in this document.

    Each architecture diagram must show:

    • The major elements of the architecture, and how they combine to provide the AWS Partner Solution to customers
    • All of the AWS services used, using the appropriate AWS service icons.
    • How the AWS services are deployed, including, VPCs, Availability Zones (AZs), subnets, and connections to systems outside of AWS.
    • Includes elements deployed outside of AWS, e.g. on-premises components, or hardware devices.
  • DOC-002 - Deployment Guide

    Applies to: Customer Deployed

    The deployment guide must provide best practices for deploying the AWS Partner Solution on AWS, and include all of the sections outlined in the AWS Foundational Technical Review Guide

  • DOC-003 - Customer facing documentation

    Applies to: SaaS | Customer Deployed

    All customer facing documentation and artifacts to deploy, operate and maintain the solution must meet the following standards:

    • All references to AWS services must use the correct product names. (Please reference the official AWS product landing pages for the correct spelling and styling of product names)
    • Documentation must be generally free of typos and grammatical errors.

    Evidence: Provide a link to, or attach a copy of, your customer facing documentation.

  • DOC-005 - Field-Ready Toolkits

    Applies to: SaaS | Customer Deployed

    AWS Partner has field-ready documentation and a seller toolkit that enable their field sellers to articulate a clear product value proposition to AWS customers.

    Evidence must be in the form of sales collateral including a customer presentation, one-pager, and customer success stories.

  • DOC-005 - AWS Marketplace Listing

    Applies to: SaaS | Customer Deployed

    If the solution is available via AWS Marketplace, AWS Partner must provide a link to the AWS Marketplace listing in their application.

    An AWS Marketplace listing is not mandatory to achieve the AWS Competency.

Security - Identity and Access Management

Requirements in this category focus on best practices around AWS Identity and Access Management (IAM) and other identity and access management systems owned by the AWS Partner.

  • IAM-002 - Static AWS Access Keys only used by interactive users.

    Applies to: SaaS | Customer Deployed

    Static AWS Access Keys are not used, except in the following cases:

    1. Used by humans to access AWS services, and stored securely on a device controlled by that human.
    2. Used by a service to access AWS services, but only in cases where all of the following are true:
      • It is not feasible to use an Amazon EC2 instance role, ECS Task role or similar mechanism
      • The AWS Access Keys are rotated at least weekly
      • Associated IAM Policies are tightly scoped such that it only allows access to specific actions and resources.
      • An IAM policy is in place that denies access to all actions except when requests originate from an IP address owned by the AWS Partner (see Example IAM Identity-Based Policies).

    This requirement is applicable to internal processes running in the AWS Partner's AWS accounts as well as any components of the solution running in the customer's account. Customers must never be required to create IAM users in order to use any feature or capability of the solution. Partner-hosted or SaaS solutions must use cross-account IAM roles with external IDs to gain access to the customer's account. Customer deployed solutions must natively support using IAM roles associated with AWS compute resources.

  • IAM-005 - Mitigation of exposed credentials

    Applies to: SaaS

    All events from AWS Health with the service type "RISK" are handled within defined SLAs. APN Partner must implement all of the following:

    • Define an SLA for security operations staff to evaluate and mitigate AWS Health RISK events.
    • Implement automated integration with the primary internal issue tracking system such that a new issue is created for all events published by the AWS Health service with detail type "AWS Health Event" and service equal to "RISK". These events include "AWS_RISK_CREDENTIALS_COMPROMISED" and "AWS_RISK_CREDENTIALS_EXPOSED".
    • Implement alerting and notification to security operations staff for both new issues created and SLA breeches.
  • IAM-007 - Authenticate API or UI requests

    Applies to: SaaS

    All SaaS solutions must authenticate paid API or UI requests. The solution has specific technologies and mechanisms in place to mitigate the attacks described in the OWASP Top 10 Web Application Security Attacks

Security - Operating System and Application

Requirements in this category focus on best practices for securing operating systems (OS) and applications owned by the AWS Partner.

  • OSSEC-001 - Implement an automated mechanism to harden all operating systems and container images used to host your solution.

    Applies to: SaaS

    A hardened configuration based on CIS or equivalent benchmark has been defined for operating systems and containers used to host the solution. There are automated mechanisms in place to ensure this hardened configuration is applied to all compute resources (e.g., persisting the configuration to an immutable Amazon Machine Image [AMI]).

Security - IT Operations

Requirements in this category focus on IT security operations best practices including logging, monitoring, incident response, and data classification.

  • SECOPS-001 - Implement automated mechanisms to detect changes in compute resources and store logs related to changes in a separate service.

    Applies to: SaaS

    Protect your compute resources (e.g., instances, containers, functions, etc.) from unauthorized activity. This may include detecting any changes to the OS or application files and storing these changes in a durable location to allow for future forensic investigation. The mechanism employed for this purpose must at least:

    • Detect any changes to the OS or application files in the compute resources used in the solution.
    • Store data recording these changes in a durable location, external to the compute resources.
  • SECOPS-004 - Implement a secure encryption key management strategy.

    Applies to: SaaS | Customer Deployed

    All cryptographic keys are encrypted at rest and in transit, and access to use the keys is controlled using an AWS solution such as AWS Key Management Service (AWS KMS) or an AWS Partner solution such as HashiCorp Vault.

  • SECOPS-006 - Implement a security ticketing system or similar tool to manage and track reported and detected security issues with the solution.

    Applies to: SaaS | Customer Deployed

    A purpose-built ticketing system or similar tool is used by the security team to manage and track the ownership and resolution of any reported or detected security issues with the solution. This system should at a minimum track externally or internally reported security concerns about the solution. Additionally, for partner hosted/SaaS solutions, this system should track security operations tasks such as host patching as well as the analysis and remediation of any alerts raised by other detective measures.

    This can be the same system used to fulfill OPE-005.

  • SECOPS-007 - Automatically detect and alert on anomalous activity based on AWS CloudTrail logs, and integrate alerting mechanisms with your security issue tracking system (SECOPS-006).

    Applies to: SaaS

    AWS CloudTrail logs are actively monitored using automated tools (e.g. Amazon GuardDuty) to detect suspicious or anomalous behavior, and alerting is configured to notify security operations staff in the event such behaviors are detected. Alerting must be integrated with the security ticketing system referenced in SECOPS-006.

  • SECOPS-008 - Automatically detect and alert on anomalous network activity for production VPCs, and integrate alerting mechanisms with your security issue tracking system (SECOPS-006).

    Applies to: SaaS

    Network activity for production VPCs is actively monitored using automated tools (e.g. Amazon GuardDuty) to detect suspicious or anomalous behavior, and alerting is configured to notify security operations staff in the event such behaviors are detected. Alerting must be integrated with the security ticketing system referenced in SECOPS-006.

  • SECOPS-009 - For resources whose configuration is controlled by the AWS control plane, implement infrastructure configuration guardrails and enforce compliance to guardrails.

    Applies to: SaaS

    The AWS Partner has defined a set of configuration policies for their AWS infrastructure (e.g. all Amazon Elastic Block Store (EBS) volumes must be encrypted), and these policies are enforced or monitored using automated tooling such as AWS Config or other comparable tools. This does not require automated remediation of policy violations, but detected violations must be automatically logged in a centralized ticketing system to ensure they are properly resolved by human operators.

  • SECOPS-011 - Use a certificate management system to maintain SSL/TLS certificates in production.

    Applies to: SaaS

    Automated mechanisms are in place to prevent certificates from expiring unexpectedly.

Tenant Isolation

The requirements in this section apply to all components of a solution that are hosted in the AWS Partner's account and handle data related to specific customers or tenants.

  • TI-001 - Model multi-tenant components on tenant identity in the software layer.

    Applies to: SaaS

    Any components that are deployed to infrastructure shared across multiple tenants must model tenant identity in the software layer. The code for the component implements controls to ensure that tenants are isolated from one another and data is not leaked across tenant boundaries.

  • TI-002 - Deploy single-tenant components to tenant-specific Amazon VPCs.

    Applies to: SaaS

    Any components which are not explicitly designed to isolate multiple tenants at the software layer are deployed to tenant-specific compute resources in tenant-specific VPCs. (In this context "tenant" refers to tenants of the AWS Partner solution.)

    Supporting existing, legacy customers who may already be deployed to shared VPCs is acceptable as long as this model is completely deprecated and all new customers are deployed using a VPC-per-tenant model. There must be multiple active customers in production using the VPC-per-tenant model.

  • TI-003 - Use dedicated IAM roles with least privilege access for single-tenant components.

    Applies to: SaaS

    All single-tenant components must use dedicated IAM roles per tenant. These roles must limit access to only that tenant's resources using Resource and Condition statements within the attached policies.

    Evidence must be provided in the form of a description of the roles used per tenant and an example of the IAM policies attached to those roles which provide explicit resource isolation.

AWS API Integration

The requirements in this section deal with best practices around calling AWS APIs.

  • AWSAPI-001 - Use an official AWS SDK to make calls to AWS API endpoints or implement error retries with exponential backoff for all AWS API calls.

    Applies to: SaaS | Customer Deployed

    The solution uses an official AWS SDK for all calls made to AWS API endpoints, or alternatively the solution implements retries with exponential backoff and jitter for all AWS API calls.

  • AWSAPI-002 - Implement rate limiting on API calls to any AWS service in customer accounts to prevent throttling.

    Applies to: SaaS | Customer Deployed

    Measures are in place to rate limit calls to AWS APIs in the customer's account in order to prevent API throttling.

  • AWSAPI-003 - Only poll AWS control plane APIs when necessary.

    Applies to: SaaS | Customer Deployed

    The solution uses methods such as ingesting AWS CloudTrail logs, consuming Amazon EventBridge events, or integrating with AWS Config to avoid polling AWS APIs wherever possible.

    AWS Partner must describe what AWS resources state the solution tracks (if any), and how that resource state is discovered. In cases where there is no alternative to polling, AWS Partner must provide a detailed description of how they avoid causing API throttling issues.

  • AWSAPI-004 - If you are offering a solution that customers host in their own AWS accounts, implement support for Amazon EC2 Instance Metadata Service Version 2 (IMDSv2).

    Applies to: Customer Deployed

    All components of the solution that are hosted in the customer's account support the ability for the customer to disable Instance Metadata Service Version 1 (IMDSv1). The solution must support the use of IAM roles associated with Amazon EC2 instances in conjunction with IMDSv2 for getting credentials to make calls to AWS APIs. Legacy support for static IAM access keys must be clearly deprecated.

    AWS Partner must provide the specific version of the official AWS SDK used by the latest generally available version of the solution. The version of the AWS SDK in use must have been released after November 20th 2019.

    If the solution accesses AWS APIs without using an official AWS SDK, AWS Partner must describe the steps taken to ensure IMDSv2 is supported.

Reliability

The reliability pillar focuses on the ability to prevent, and quickly recover from failures to meet business and customer demand. Key topics include foundational elements around setup, cross project requirements, recovery planning, and how we handle change.

  • REL-001 - Establish highly available network connectivity.

    Applies to: SaaS

    Network connectivity to the solution must be highly available. If using VPN or Direct Connect to connect to customer networks, the solution must support redundant connections, even if the customers do not always implement this.

  • REL-002 - Continuously monitor workload health and implement alerting on any issues.

    Applies to: SaaS

    Logs and metrics for each component of the system are actively monitored. Critical metrics and thresholds are defined for each components and alarms are configured to notify operators in the event those thresholds are breached.

    Evidence must be provided in the form of a list of the metrics and thresholds defined for each system component and a description of the tools used to surface alarms to operators.

  • REL-003 - Manage AWS and application logs centrally.

    Applies to: SaaS

    All log information from the application, and from the AWS infrastructure, must be consolidated into a single system.

  • REL-004 - Manage AWS and application monitoring and alarms centrally.

    Applies to: SaaS

    The application and the AWS infrastructure must be monitored centrally, with alarms generated and sent to the appropriate operations staff.

  • REL-005 - Automate infrastructure provisioning and management.

    Applies to: SaaS

    The solution must use an automated tool such as AWS CloudFormation or Terraform to provision and manage the AWS infrastructure. The AWS Management Console must not be used to make routine changes to the production AWS infrastructure.

Performance Efficiency

The Performance Efficiency pillar includes the ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.

  • PRF-001 - Define Key Performance Indicators (KPIs).

    Applies to: SaaS | Customer Deployed

    Key Performance Indicators (KPIs) that indicate whether the product is performing as expected from the perspective of the customer have been defined. The definition of these KPIs must include how to measure the indicator as well as the acceptable threshold.

    For example, p99 roundtrip response latency for API methods X, Y, and Z must be less than 200ms as measured by the TargetResponseTime AWS CloudWatch metric.

    Partner must provide a list of KPIs and the defined acceptable thresholds as evidence.

  • PRF-002 - Conduct performance testing before deployments or releases.

    Applies to: SaaS | Customer Deployed

    Performance test suites (either automated or manual) are run before major releases or production deployments in order to ensure new versions meet defined performance targets.

Operational Excellence

The operational excellence pillar focuses on running and monitoring systems to deliver business value, and continually improving processes and procedures. Key topics include managing and automating changes, responding to events, and defining standards to successfully manage daily operations.

  • OPE-001 - Automate code and configuration deployments.

    Applies to: SaaS

    The solution must use an automated method of deploying code and configuration to the AWS infrastructure. Interactive SSH or RDP sessions must not be used to deploy updates in the AWS infrastructure.

  • OPE-002 - Develop runbooks to document standard procedures and escalation steps in response to different application and AWS events.

    Applies to: SaaS

    Runbooks must be developed to define the standard procedures used in response to different application and AWS events. An escalation process must be defined to deal with alerts and alarms generated by the system, and to respond to customer-reported incidents. The escalation process must also include escalating to AWS Support where appropriate.

  • OPE-003 - Perform peer-to-peer code reviews before each release or deployment.

    Applies to: SaaS | Customer Deployed

    Code is peer reviewed before being released or deployed to production.

  • OPE-004 - Execute automated functional tests of the solution before each release or deployment.

    Applies to: SaaS | Customer Deployed

    Automated functional test suites exist and are automatically run before software is released or deployed to production.

  • OPE-005 - Use an issue tracking system to manage product backlogs, feature requests, defects, and identified operational issues.

    Applies to: SaaS | Customer Deployed

    A purpose-built issue tracking tool or set of tools is used to manage product backlogs, feature requests, defects and identified operational issues.

  • OPE-006 - Establish a formal issue tracking process.

    Applies to: SaaS | Customer Deployed

    A process is established to track and remediate all customer reported product bugs as well as operational incidents that cause customer impact.

Resources