Amazon API Gateway

Service Delivery Validation Checklist

January 2024 - 3.0

Introduction

AWS Specialization Program recognizes AWS Partner Network (APN) Partners who demonstrate successful customer delivery and expertise in specific AWS services. This AWS Service Delivery Validation Checklist outlines the criteria necessary to achieve the Amazon API Gateway designation under the AWS Service Delivery Program.

Expectations of Parties

It is expected that AWS Partners will review this document in detail before submitting an AWS Service Delivery Program application, even if AWS Partners believe that all pre-requisites are met. If items in this document are unclear AWS Partners should contact their Partner Development Representative (PDR) or Partner Development Manager (PDM). AWS reserves the right to make changes to this document at any time.

When ready to submit a program application, AWS Partners must complete the self-assessment spreadsheet available for download at the top of this page. Upon completion of the self-assessment spreadsheet, AWS Partners must submit an application in AWS Partner Central. For more information on how to submit an application, view the Program Guide or contact your PDR or PDM.

Once an AWS Partner’s application has been submitted through the AWS Partner Central, AWS will review for completeness and for compliance with the requirements. 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 experts to complete a Technical Validation.

The Technical Validation will be completed offline. AWS Partners should prepare for the Technical Validation by reading the Checklist, completing and submitting a self-assessment for each Case Study, and submitting all relevant objective evidence with the application, including architecture diagrams.

Upon completion of the Technical Validation, AWS Partners will receive a final status for the submitted application either confirming or denying acceptance into the AWS Service Delivery Program. AWS Partners may attain one or more AWS Service Delivery designations. Please note that attaining one AWS Service Delivery designation does not guarantee approval into additional AWS Service Delivery designations. If the AWS Partner is denied acceptance for the desired AWS Service Delivery designation, the AWS Partner may re-apply via AWS Partner Central after the AWS Partner has remediated all outstanding action items.

AWS may revoke an AWS Partner’s AWS Service Delivery designation if, at any time, AWS determines in its sole discretion that such AWS Partner does not meet its AWS Service Delivery Program requirements. If an AWS Partner’s AWS Service Delivery 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 AWS Service Delivery designation and (iii) immediately cease to identify or hold itself out as a Partner of such AWS Service Delivery.

AWS Service Delivery Program Prerequisites

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

  1. 1.0APN Program Requirements

    1. 1.1Program Guidelines

      The AWS Partner must read the Program guidelines and Definitions before submitting the application. Click here for Program details.

    2. 1.2Services Path Membership

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

  2. 2.0AWS Customer Case Studies

    1. 2.1Production AWS Customer Case Studies

      AWS Partner must privately share with AWS details about two (2) unique examples of Amazon API Gateway projects executed for two (2) unique AWS customers. Each case study must demonstrate how the partner offering was used by a customer to solve a specific problem related to the AWS service.

      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. AWS 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.

      In cases where a case study is used across multiple AWS Partner Specialization applications, the partner must attach a completed self-assessment spreadsheet for each Specialization with all service-specific details provided.

      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.

      Note: Public-facing case studies are encouraged over private case studies, as they may be used by AWS for marketing purposes and will be featured in Partner Solution Finder. Evidence of a publicly referenceable case study must be provided in the form of a case study, white paper, blog post, or equivalent. 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. For best practices on how to write an accepted public case study see the Public Case Study Guide.

    2. 2.2Architecture Diagrams

      Submitted case studies must include architecture diagrams.

      • Architecture diagrams must detail how the solution interacts with the AWS Cloud; specifically, what AWS tools and services are used in the solution
      • Diagrams must also include evidence of AWS best practices for architecture and security

      Note: Click here for best practices on how to build an acceptable Architecture Diagram.

  3. 3.0AWS Partner Self-Assessment

    1. 3.1Program Validation Checklist Self-Assessment

      AWS Partner must conduct a self-assessment of their compliance to the requirements of the Amazon API Gateway Service Delivery using the Self-Assessment Spreadsheet linked at the top of this page. All sections of the Self-Assessment Spreadsheet must be completed for each case study and spreadsheet must be attached to the associated application in AWS Partner Central.

      It is recommended that AWS Partners have their Solutions Architect, PDR, or 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 technical validation and to help ensure a positive technical validation experience.

Amazon API Gateway Customer Reference Requirements

The following requirements relate to how Amazon API Gateway was used in each provided customer reference.

Amazon API Gateway Expertise

The following requirements relate to the AWS Partner's ability to demonstrate deep expertise with Amazon API Gateway in the context of the provided customer references.

  • APIGW-001 - API type selection

    The API type(s) (HTTP, REST, or WebSocket) used appropriately balance cost and functionality tradeoffs.

    Please provide the following as evidence:

    • Explanation of the required features for each API in the solution
  • APIGW-002 - AWS integrations

    AWS integrations (i.e. integrations that send requests directly to other AWS service APIs) are preferred over AWS Lambda integrations when no additional validation or business logic is required. Lambda functions should not be used to simply pass data from a RESTful API to another AWS service without executing additional logic that is not possible to express in a mapping template.

    Please provide the following as evidence:

    • Brief explanation of the responsibilities of any Lambda functions with a single downstream service integration
  • APIGW-003 - Endpoint types

    Endpoint types (i.e. Edge-optimized, Regional, or Private) for REST APIs are selected to optimize cost, performance, and security.

    Please provide the following as evidence:

    • The endpoint type and selection considerations for each API in the solution
  • APIGW-004 - Load management

    APIs are configured to protect downstream integrations from excessive load. Even in cases where all upstream API clients are trusted, internal services, the API layer should have mitigations in place to limit request volumes or otherwise handle excessive load.

    Please provide the following as evidence:

    • Description of the Amazon API Gateway features (e.g. throttling, usage plans, caching, asynchronous executions, AWS WAF integration, etc.) and other approaches used to manage excessive request load.
    • Description of the approach used to determine the correct settings for throttles, quotas, cache time to live (TTL), etc.
  • APIGW-005 - API monitoring

    The responses to OPE-001 and/or OPE-002 must include the specific Amazon CloudWatch metrics emmitted by Amazon API Gatway used to determine the health and status of the API.

  • APIGW-006 - Amazon API Gateway features and design patterns

    Each provided customer reference demonstrates the AWS Partner's deep expertise with Amazon API Gateway to solve complex technical problems. Each reference must include the use of at least one of the following features or design patterns, and at least two unique features or patterns must be used across all submitted references.

    • API Gateway Lambda authorizers
    • AWS Integrations
    • WebSocket APIs
    • API Caching
    • Custom domains with AWS Certificate Manager integration
    • Mapping templates
    • Developer portal
    • Cross-origin resource sharing (CORS) configuration
    • AWS WAF integration
    • Private API endpoints

    Please provide the following as evidence:

    • List of features from the list above used in the solution
    • Brief description of how and why each feature was used

Common Customer Reference Requirements

All of the following requirements must be met by at least one of the submitted customer references. See specific evidence for each control.

Documentation

Requirements in this category relate to the documentation provided for each customer example.

  • DOC-001 - 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.
    • Description of how the major solutions elements scale up automatically.

Secure Customer AWS Account Governance and Access

Any AWS accounts created by the AWS Partner on behalf of the customer or AWS accounts that the AWS Partner administers as part of the engagement must meet the following requirements.

  • ACCT-001 - 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.
  • ACCT-002 - 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 Standard Operation Procedure (SOP) 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.

Operational Excellence

Requirements in this category relate to the ability of the AWS Partner and the customer to run and monitor systems to deliver business value and to continually improve supporting processes and procedures.

  • OPE-001 - 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 capture 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 develop customer workload health KPIs with the three components above
    • Description of how workload health KPIs are implemented in (1) of the submitted customer examples.
  • OPE-002 - Define a customer runbook/playbook to guide operational tasks

    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.

    Please provide the following as evidence:

    • Standardized documents or runbook met the criteria defined above.
  • OPE-003 - 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.

Security - Networking

Requirements in this category focus on security best practices for Virtual Private Cloud (Amazon VPC) and other network security considerations.

  • NETSEC-001 - 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
    • Other AWS security services to protect network security

    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.
  • NETSEC-002 - 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.

Reliability

Requirements in this section focus on the ability of the AWS Partner solution to prevent, and quickly recover from failures to meet business and customer demand.

  • REL-001 - Automate Deployment 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.
  • REL-002 - Plan for disaster recovery and recommend Recoverty Time Objective (RTO) and Recoverty Point Objective (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

    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

Cost Optimization

Requirements in this category relate to the AWS Partner's ability to help customers run systems that deliver business value at the lowest price point.

  • COST-001 - 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 develop 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

Resources