What the FTR Is
The AWS Foundational Technical Review — FTR — is a self-service validation process that confirms your software meets a defined subset of AWS Well-Architected best practices. It covers three domains: security, reliability, and operational excellence. It is valid for three years from approval, costs nothing to complete, and is available to any partner on the Software Partner Path.
On the surface it looks like a technical checkbox. In practice it is much more consequential. The FTR is a prerequisite for SaaS Co-sell Benefit enrollment, gates access to several funding programs, and earns you a "Qualified Software" badge: a visible signal to AWS field teams and customers that your software meets AWS standards. Without it, you are invisible in the AWS Partner Solutions Finder, ineligible for co-sell priority programs, and locked out of funding pathways that your competitors may already be using.
The FTR is not a technical hurdle. It is a business unlock. Every material benefit of the AWS ISV ecosystem: co-sell, funding, Marketplace credibility, flows more easily once you have it.
Who Needs an FTR
The FTR is specifically for ISVs: independent software vendors whose products run on or integrate with AWS. If you build software and AWS is part of your delivery or infrastructure story, the FTR is for you. It is not designed for channel partners or MSPs, who have different validation paths.
The FTR is relevant if any of the following apply:
- You want to enroll in the AWS SaaS Co-sell Benefit, which requires FTR completion
- You want your software listed in the AWS Partner Solutions Finder with a Qualified Software badge
- You are pursuing AWS Competency designations, which often require FTR as a baseline
- You want access to co-sell priority with AWS field teams: FTR signals program maturity
- You are applying for funding programs including MAP or MDF: FTR completion strengthens eligibility
- You are listing on AWS Marketplace and want to signal credibility to buyers
If you are an ISV that has been operating in the AWS ecosystem for more than 12 months and has not completed an FTR, you are almost certainly leaving program benefits on the table. The review exists specifically to create a credible, verifiable baseline that unlocks the ecosystem's most valuable resources.
What the FTR Evaluates
The FTR is structured around the AWS Well-Architected Framework but applies a focused subset of its principles: the ones most directly relevant to software products. You are not being evaluated against every pillar of the full Well-Architected Framework. The FTR is specifically scoped to security, reliability, and operational excellence as they relate to your software's architecture and delivery model.
| Domain | What AWS Evaluates | Common Gaps |
|---|---|---|
| Security | Identity and access management, data protection, encryption at rest and in transit, network controls, incident response readiness | Overly permissive IAM roles, missing encryption, lack of documented incident response procedures |
| Reliability | Failure recovery, backup and restore procedures, scaling architecture, multi-AZ or multi-region considerations | Single points of failure, no documented RTO/RPO, manual recovery processes with no runbook |
| Operational Excellence | Monitoring and alerting, deployment automation, runbooks, periodic architecture review process | No automated alerting, manual deployments with no CI/CD, no documented review cadence |
The FTR uses a checklist-based self-assessment. You work through the FTR validation checklist, document how your software addresses each item, and submit the evidence through Partner Central. AWS reviews the submission and either approves it or provides specific remediation instructions.
There are two versions of the FTR checklist: one for partner-hosted SaaS solutions and one for customer-deployed software. Make sure you are working from the right one for your delivery model. Using the wrong checklist is the most avoidable reason submissions get sent back for remediation.
FTR Waivers: When You Can Skip the Review
AWS offers a waiver path for partners who have already completed equivalent third-party validation. If either of the following apply, you can request a waiver instead of completing the full FTR checklist:
- SOC 2 Type II audit: a completed and current SOC 2 Type II report is accepted as evidence of equivalent security and operational controls
- AWS Well-Architected Review (WAFR): a completed WAFR conducted by either an AWS employee or a confirmed Well-Architected Partner Program (WAPP) partner
If you are pursuing a SOC 2 audit for other compliance reasons anyway, completing it opens the FTR waiver path simultaneously. It is worth coordinating the timing if both are on your roadmap. That said, most ISVs do not have either of these in place and go through the standard FTR process, which is entirely achievable with the right preparation.
What You Unlock
The FTR is worth completing not because AWS requires it, but because of what it opens up. Here is what an approved FTR gives you access to:
The FTR Process, Step by Step
AWS outlines a five-step process for completing the FTR. Here is what each step involves in practice, not just what the official documentation says.
Enroll in the Software Partner Path
If you have not already, register with the AWS Partner Network and enroll in the Software Partner Path through Partner Central. This is the partner path specifically designed for ISVs and is the track under which the FTR lives.
Work Through the Validation Checklist
Download the appropriate FTR checklist for your delivery model: partner-hosted (SaaS) or customer-deployed. Work through each item methodically. For each control, document how your software addresses it and collect supporting evidence: configuration screenshots, policy documents, runbooks, architecture diagrams. Do not rush this step. Incomplete or thin evidence is the primary reason submissions get rejected.
Remediate Any Gaps Before You Submit
The checklist will surface gaps. Some are quick to fix: enabling encryption, tightening IAM policies, setting up CloudWatch alerts. Others require more work: building out a documented incident response process, establishing a backup and restore procedure, creating architectural review documentation. Fix the gaps before you submit, not after. Submitting a checklist with known open items and hoping AWS does not notice is not a strategy that works.
Share 10 Opportunities via ACE
Before requesting the FTR, you need to accept the ACE Terms and Conditions in Partner Central and share at least 10 sales opportunities through the ACE Pipeline Manager. This step exists because AWS wants to see that you are committed to co-selling, not just collecting a badge. Submit real, qualified opportunities with accurate customer and revenue detail.
Submit Through Partner Central and Wait for Review
In Partner Central, navigate to Build, then Solutions, select or create the solution you are submitting, and request validation. Attach your completed FTR checklist and supporting evidence. AWS will review the submission and either approve it or return specific remediation instructions. Response times vary: plan for 2 to 4 weeks. If you get remediation feedback, address it specifically and resubmit promptly.
Why FTR Submissions Get Rejected
Most FTR rejections are avoidable. The submission is sent back with remediation instructions, not permanently denied, but the back-and-forth adds weeks and slows down your access to the benefits on the other side. Here is what causes it.
Using the Wrong Checklist
There is a different checklist for SaaS/partner-hosted solutions versus customer-deployed software. Partners who submit using the wrong one get sent back immediately. Confirm your delivery model and match the checklist before you start.
Thin or Missing Evidence
Checking a box without attaching supporting evidence does not pass. AWS reviewers need to see proof, not assertions. Configuration screenshots, policy documents, architecture diagrams, runbook excerpts: document everything as you go, not after the fact.
IAM and Security Gaps
The security domain is where most ISVs have the most remediation work. Overly permissive IAM roles, missing encryption for data at rest, no documented key rotation policy: these come up consistently. Run an IAM audit before you start the checklist so you know what you are working with.
No Documented Operational Processes
The operational excellence domain requires more than functioning systems: it requires documented processes. A monitoring setup with no documented alert runbook, a deployment pipeline with no rollback procedure, an architecture with no periodic review cadence: these are all gaps that will surface. The fix is documentation, not new infrastructure.
ACE Opportunities Not in Place
Trying to submit an FTR without the 10 ACE opportunities shared first stops the process cold. Make sure your ACE pipeline is active and the Terms and Conditions are accepted before you request the review.
The partners who pass FTR on the first submission almost always did a dry run: they went through the checklist internally, identified every gap, fixed them, collected the evidence, and then submitted. The partners who get sent back for remediation almost always tried to shortcut the preparation phase. The review itself is not hard. The preparation discipline is what separates first-pass approvals from multi-round remediation cycles.
How FTR Connects to Tier Advancement and Co-Sell
The FTR does not directly affect your APN tier: it is a program-level validation, not a tier requirement. But its downstream effects on co-sell and funding access make it a meaningful accelerator for partners working toward Advanced tier.
Here is the chain: FTR leads to SaaS Co-sell Benefit eligibility, which leads to an active co-sell program, which leads to a stronger ACE pipeline, which leads to a more favorable tier assessment, which leads to faster Advanced tier advancement. Each step enables the next. Partners who complete FTR early in their AWS journey compress this timeline significantly compared to those who defer it.
For ISVs specifically, the FTR is also the clearest signal to AWS field teams that you are serious about the partnership. A PDM who sees an ISV with a Qualified Software badge, active ACE pipeline, and SaaS Co-sell Benefit enrollment treats that partner differently than one who has none of these. The FTR is the anchor of that credibility stack.
The Bottom Line
The FTR is not optional for ISVs who are serious about building a co-sell motion with AWS. It is the foundation that everything else: the SaaS Co-sell Benefit, Competencies, funding priority, co-sell credibility, is built on. The process is self-service, costs nothing, and is achievable by any ISV with a reasonably well-architected product and the discipline to prepare properly.
The only reason to delay it is not knowing it exists or underestimating what it unlocks. Now you know.
We help ISVs prepare for and complete the FTR as part of our consulting services: working through the checklist, identifying and remediating gaps before submission, managing the ACE requirement, and connecting FTR completion to your broader co-sell and funding strategy. If you want to understand where you stand and what it would take to get approved, reach out.