If you’re planning to list your solution on AWS Marketplace or enroll in a Co-Sell program, there’s one acronym you’ll hear right away: FTR—Foundational Technical Review.It’s a required checkpoint for most AWS Partner Network (APN) programs. But what exactly is FTR? Why does AWS insist on it? And more importantly—how do you pass it without delays?In this beginner’s guide, we break down the FTR process step by step and explain how to make your product—and your documentation—ready for approval.
What Is the Foundational Technical Review (FTR)?
The Foundational Technical Review is AWS’s way of ensuring that your solution meets core best practices around:
- Security
- Reliability
- Operational Excellence
- Cost Optimization
It’s not a deep-dive code audit—but it is a content-driven review where your solution architecture and product maturity are evaluated based on documentation, diagrams, and declared practices.If you want to:
- List your SaaS product on AWS Marketplace
- Qualify for Co-Sell support
- Apply for AWS Competencies
- Appear in industry solution libraries
…you need to pass the FTR first.
Who Conducts the FTR?
It’s led by your AWS Partner Solutions Architect (PSA) or Partner Manager. You’ll submit your documentation ahead of time, and they’ll review it against AWS Well-Architected principles.In some cases, AWS may request follow-ups, edits, or improvements—especially in areas like security and deployment readiness.
What Do You Need for an FTR?
Here’s a typical checklist of FTR-ready content:
| Document | Purpose |
|---|---|
| Architecture Diagram | Shows how your solution runs on AWS (with services labeled) |
| Deployment Guide | Explains how users install or launch the solution |
| Security Overview | Covers identity, access, data protection, and compliance |
| Operational Practices | Describes monitoring, alerts, backups, etc. |
| Project Charter / Overview | Summarizes the business need and product capability |
| Support & Update Process | Details how you handle patches, support tickets, etc. |
You may also be asked for:
- Pricing models
- Backup & disaster recovery flow
- Onboarding experience for end users
Common FTR Mistakes (and How to Avoid Them)
- Incomplete architecture diagrams
→ Include actual AWS services, flow directions, and environments (staging/prod). - Generic security statements
→ Back them up with specifics: encryption standards, IAM roles, audit logs, etc. - No clear deployment model
→ Clearly mention if it’s SaaS, AMI, container, etc.—with steps. - Sales content instead of technical proof
→ FTR is not marketing. It’s validation. Keep it focused, not fluffy.
Pro Tip: Build for Reuse
The good news?
All FTR content can be reused in:
- AWS Marketplace listing
- Competency applications
- Co-Sell GTM documents
- Sales decks and solution briefs
So don’t treat it like a one-off. Build it to scale.
Conclusion
The FTR is not just a checkbox—it’s the foundation of your AWS growth.
It validates your product, unlocks new sales channels, and builds trust with AWS and enterprise customers.The fastest way to pass?
Get your documentation aligned with AWS expectations from the start.
