Partner Hosted Alternative Foundational Technical Review

To qualify for FTR your product must run entirely on AWS. This includes the application and control planes. The application plane can run in the seller's AWS account, the buyer's AWS account, or both. For more information, refer to the Control plane vs. application plane whitepaper. Third-party services used by the product to transmit, store, or process application data must also run entirely on AWS —except for content delivery networks (CDNs), domain name systems (DNSs), and corporate identity providers (IdPs).

Agents or gateways used by the product for security, monitoring, data replication, or migration can run on buyer-owned environments outside AWS, including on premises, but must send data only to AWS for storage and analysis.

You must include an architecture diagram for review. For more information, refer to Architecture diagram.

Listing on Marketplace is not required to complete a FTR.

It is recommended that you subscribe to the AWS Business Support tier or higher (including AWS Partner-Led Support) for all of your AWS production accounts. For more information, refer to Compare AWS Support Plans. If you don't have premium support, you must have an action plan to handle issues which require help from AWS Support. 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.

Conduct periodic architecture reviews of your production workload (at least once per year) using a documented architectural standard that includes AWS-specific best practices. If you have an internally defined standard for your AWS workloads, we recommend you use it for these reviews. If you do not have an internal standard, we recommend you use the AWS Well-Architected Framework.

Review the AWS Shared Responsibility Model for Security and the AWS Shared Responsibility Model for Resiliency. Ensure that your product’s architecture and operational processes address the customer responsibilities defined in these models. We recommend you to use AWS Resilience Hub to ensure your workload resiliency posture meets your targets and to provide you with operational procedures you may use to address the customer responsibilities.

Cross-account roles reduce the amount of sensitive information AWS Partners need to store for their customers.

The policy created for cross-account access in customer accounts must follow the principle of least privilege. The AWS Partner must provide a role-policy document or an automated setup mechanism (for example, an AWS CloudFormation template) for the customers to use to ensure that the roles are created with minimum required privileges. For more information, refer to the AWS Partner Network (APN) blog posts.

Depending on if you're using the AssumeRole API or AssumeRoleWithWebIdentity API, an external ID (AssumeRole) or dedicated issuer URL (AssumeRoleWithWebIdentity) must be used to access customer accounts. It allows the user that is assuming the role to assert the circumstances in which they are operating. It also provides a way for the account owner to permit the role to be assumed only under specific circumstances. The primary function of the external ID and dedicated issuer URL is to address and prevent the confused deputy problem. To implement the dedicated issuer URL for AssumeRoleWithWebIdentity API, refer to this documentation.

When configuring cross-account access using IAM roles, you must use a value you generate for the external ID or dedicated issuer URL, instead of one provided by the customer, to ensure the integrity of the cross-account role configuration. A partner-generated external ID or dedicated issuer URL ensures that malicious parties cannot impersonate a customer's configuration and enforces uniqueness and format consistency across all customers. If you are not generating an external ID or dedicated issuer URL today we recommend implementing a process that generates a random unique value (such as a Universally Unique Identifier) for the external ID or dedicated issuer URL that a customer uses to set up a cross-account role.

The external IDs or dedicated issuer URLs used must be unique across all customers. Re-using external IDs or dedicated issuer URLs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN and the external ID or dedicated issuer URL of customer B. To resolve this, we recommend implementing a process that ensures a random unique value, such as a Universally Unique Identifier, is generated for the external ID or dedicated issuer URL that a customer would use to setup a cross account role.

Customers must not be able to set or influence external IDs or dedicated issuer URLs. When the external ID or dedicated issuer URL is editable, it is possible for one customer to impersonate the configuration of another. For example, when the external ID or dedicated issuer URL is editable, customer A can create a cross account role setup using customer B’s role ARN and external ID or dedicated issuer URL, granting customer A access to customer B’s data. Remediation of this item involves making the external ID or dedicated issuer URL a view-only field, ensuring that the external ID or dedicated issuer URL cannot be changed to impersonate the setup of another customer.

If your application provides legacy support for the use of static IAM credentials for cross-account access, the application's user interface and customer documentation must make it clear that this method is deprecated. Existing customers should be encouraged to switch to cross-account role based-access, and collection of credentials should be disabled for new customers.