The AWS Foundational Technical Review (FTR) is a validation process that separates AWS partners who follow Well-Architected best practices from those who don’t. For Independent Software Vendors (ISVs) and SaaS providers building on AWS, passing the FTR unlocks partner benefits, co-selling opportunities, and the coveted “Qualified Software” badge.

This guide covers what the FTR evaluates, what you need to pass it, and the specific blockers that trip up even experienced engineering teams.

What Is an AWS Foundational Technical Review?

The AWS Foundational Technical Review is a structured evaluation of your software’s architecture, operational practices, and AWS resource configurations against a subset of the AWS Well-Architected Framework. AWS designed it specifically for partners in the Software Partner Path who want to demonstrate that their solutions meet production-grade standards for security, reliability, and operational excellence.

Unlike a full Well-Architected Review (WAFR) — which examines all six pillars in depth — the FTR focuses on a defined checklist of mandatory requirements. AWS publishes a validation checklist that partners must complete and submit alongside their solution documentation.

The process works like this:

 

  1. Register with the AWS Partner Network (APN) and enroll in the Software Partner Path.
  2. Perform a self-assessment using the FTR validation checklist. This covers your architecture, security controls, data handling, and operational processes across all accounts and AWS Regions where you process customer data.
  3. Accept ACE Terms and Conditions and prepare your Partner Central profile, solution listing, and supporting documentation for submission.
  4. Submit your solution for review via Partner Central. Attach the completed FTR checklist and supporting documentation.
  5. AWS reviews your submission. A Partner Solutions Architect (PSA) evaluates your documentation and may request additional evidence or remediation.
  6. Receive approval or remediation guidance. If gaps exist, AWS provides specific instructions for what needs to change before resubmission.

 

One important detail: if your organization has already completed a SOC2 Type II audit or a Well-Architected Review (WAFR) with an AWS employee or a confirmed Well-Architected Partner Program (WAPP) partner, you can receive a waiver for the FTR. This alternative path uses a separate validation checklist with modified requirements.

It’s also worth noting that an FTR is not required to list a solution in AWS Marketplace. However, passing it is required to access the full suite of partner benefits.

Benefits of AWS Foundational Technical Review

Passing the FTR opens doors that remain closed to unvalidated partners. Here’s what approval gets you:
BenefitWhat It Means
“Qualified software” badgeSignals to customers that your solution meets AWS standards. Visible on your partner profile and listing.
AWS Partner fundingAccess to Marketing Development Funds (MDF) and Proof of Concept (POC) funding programs.
AWS Competency Program eligibilityRequired step toward AWS Competency designations, such as Security, Migration, and DevOps.
ISV Accelerate ProgramEnables co-selling with AWS field sales teams who can bring your solution into active customer conversations.
Partner Solution Finder listingYour solution appears in AWS’s customer-facing partner directory, driving inbound leads.
Improved AWS relationshipYour PSA relationship deepens after FTR, often leading to referrals and joint customer engagements.

Beyond the direct benefits, the FTR process itself forces architectural rigor. Teams that go through it consistently report finding security gaps and operational blind spots they hadn’t addressed — issues that would have eventually surfaced as production incidents.

As one practitioner noted after completing their FTR: “It’s not a quick checklist — it’s a pretty detailed technical deep dive with AWS solution architects reviewing your infrastructure, architecture, and deployment practices.” The process, while demanding, produces tangible improvements to your AWS deployment.

AWS FTR Requirements and Checklist

The FTR requirements map to a subset of the Well-Architected Framework’s six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. The FTR validation checklist is the definitive source, but here’s a breakdown of the key requirement categories:

Security Requirements

Security receives the heaviest scrutiny in the FTR. Mandatory items include:

 

  • IAM best practices: No root account usage for daily operations. Individual IAM users or roles for all access. Least-privilege policies enforced.
  • Multi-Factor Authentication (MFA): Required for all privileged accounts, including the root account.
  • Data encryption: Server-side encryption enabled for all data at rest (S3, RDS, DynamoDB, EBS). TLS 1.2 or higher for all data in transit.
  • Network security: VPC configurations with private subnets for sensitive workloads. Security groups following least-access principles. No overly permissive rules (0.0.0.0/0 on non-public ports).
  • Logging and audit trail: AWS CloudTrail enabled across all regions. Logs stored in a dedicated, access-controlled S3 bucket.

Reliability Requirements

  • Automated backups: Configured using AWS Backup or native service features (RDS snapshots, DynamoDB point-in-time recovery). Defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
  • Multi-AZ deployment: Critical workloads deployed across multiple Availability Zones.
  • Failure handling: Documented incident response procedures and runbooks for common failure scenarios.

Operational Excellence Requirements

  • Infrastructure as Code (IaC): Deployments managed through CloudFormation, Terraform, or equivalent. Manual console changes are not acceptable for production environments.
  • CI/CD pipelines: Documented and automated deployment processes.
  • Monitoring and alerting: Active monitoring using CloudWatch or equivalent. Alerts configured for key operational metrics.
  • Documentation: Up-to-date architecture diagrams, operational runbooks, and change management procedures.

Performance and Cost Requirements

  • Right-sizing: Evidence that compute resources match workload requirements.
  • Scaling strategy: Auto-scaling configured for variable workloads, or documented justification for fixed capacity.
  • Cost monitoring: AWS Budgets or equivalent cost alerting configured.

Customer-Deployed Components

If your software includes components deployed within customer AWS accounts, additional requirements apply. You must document the permissions required, demonstrate least-privilege access, and provide clear deployment and teardown instructions.

How to Prepare for Your AWS FTR

The 70%+ initial failure rate means preparation is non-negotiable. Based on patterns from teams that pass on first attempt, here’s a practical preparation framework:

Phase 1: Gap Assessment (Weeks 1–2)

Run the FTR validation checklist against your current environment. For each item, document one of three statuses:

 

  • Compliant: Evidence exists and is readily demonstrable.
  • Partially compliant: The capability exists but documentation or configuration is incomplete.
  • Non-compliant: The requirement isn’t met and remediation is needed.

Use AWS Config rules and AWS Security Hub to automate parts of this assessment. Both services can flag non-compliant resources against predefined rule sets that overlap heavily with FTR requirements.

Phase 2: Remediation (Weeks 2–4)

Prioritize remediation by category:

  1. Security items first. These are the most common failure reasons and the hardest to waive.
  2. Documentation gaps second. Architecture diagrams, runbooks, and deployment docs are frequently incomplete but fast to fix.
  3. Operational tooling third. Adding monitoring, alerting, or backup configurations.

Phase 3: Evidence Collection (Week 4)

The FTR submission isn’t just a checked box — you need evidence. Prepare:

  • Screenshots or exports from AWS Config showing compliance status
  • Architecture diagrams (at minimum: network topology, data flow, deployment pipeline)
  • Links to operational runbooks and incident response procedures
  • Encryption configuration evidence (KMS keys, TLS certificates, bucket policies)

Phase 4: Submission and Review

Submit through Partner Central with your completed checklist and all supporting materials. Expect 2–4 weeks for review. If remediation items are returned, address them specifically — the PSA is evaluating whether you fixed exactly what they flagged, not re-reviewing everything.

Decision Framework: FTR vs. SOC2 Waiver vs. WAFR Waiver

ScenarioBest PathWhy
You already have SOC 2 Type IISOC 2 waiver pathSkip the standard FTR and use the alternative checklist. Fastest route.
You recently completed a WAFR with a WAPP partnerWAFR waiver pathLeverage existing review documentation.
You have neither auditStandard FTRUse the full validation checklist. Budget 4–6 weeks.
You’re early-stage with limited infrastructure maturityFix gaps first, then FTRSubmitting too early leads to rejection and delays.

Common FTR Risks and Blockers

Understanding where teams fail helps you avoid the same mistakes. These are the most frequent blockers, drawn from practitioner reports and the Well-Architected Framework pillars:

1. IAM Misconfigurations

The single most common failure point. Teams that have grown quickly often accumulate overly permissive policies — wildcard permissions (`*`), unused roles that were never cleaned up, or shared credentials across environments.


Remediation: Run IAM Access Analyzer to identify unused permissions. Remove all wildcard policies in production accounts. Implement role-based access with time-limited session credentials where possible.

2. Encryption Gaps

Partial encryption is treated the same as no encryption. If S3 buckets serving non-public data lack server-side encryption, or if internal service-to-service communication uses HTTP instead of HTTPS, the FTR will flag it.

Remediation: Enable default encryption on all S3 buckets. Enforce HTTPS-only access via bucket policies. Audit RDS instances and EBS volumes for encryption status. Enable encryption for any that lack it (note: enabling encryption on existing unencrypted RDS instances requires creating an encrypted snapshot and restoring from it).

3. Missing Backup and Recovery Plans

AWS reviewers check for both the existence of backups and documented recovery procedures. Having RDS automated backups enabled but no documented RTO/RPO or tested restoration process is insufficient.


Remediation: Configure automated backups across all data stores. Document RTO and RPO for each tier of your application. Test recovery at least once — and document the test results.

4. Incomplete Documentation

Architecture diagrams that haven’t been updated since initial deployment, missing runbooks, or deployment processes that exist only as tribal knowledge. Reviewers need to understand your system from documentation alone.


Remediation: Create or update architecture diagrams showing current state. Write operational runbooks for the top 5 failure scenarios your team encounters. Document your CI/CD pipeline from commit to production.

5. Insufficient Monitoring and Alerting

Running without CloudWatch alarms, relying solely on customer-reported issues, or monitoring only uptime without performance metrics. The FTR expects proactive observability.


Remediation: Configure CloudWatch alarms for CPU, memory, error rates, and latency on all production services. Set up a centralized logging solution. Implement health checks and automated alerting for service degradation.

6. Cost Management Gaps

While cost optimization receives less weight than security in the FTR, the absence of any cost monitoring signals operational immaturity. Teams running entirely on-demand without budgets or anomaly detection raise flags.

Remediation: Configure AWS Budgets with alert thresholds. Enable Cost Anomaly Detection. Document your approach to resource right-sizing — even if the approach is “we review quarterly” rather than continuous automation.

This is an area where many organizations struggle operationally. As one Director-level engineering leader described the challenge: “We don’t have people with a lot of spare cycles… we need automation because it’s fully automated.” The tension between FTR requirements and team bandwidth is real — which is why many teams address cost optimization requirements as part of a broader cloud management strategy rather than treating them as isolated FTR line items.

7. Stakeholder Coordination Failures

FTR touches security, operations, architecture, and business teams. When a single engineer attempts the process without cross-functional buy-in, gaps appear in areas outside their domain expertise.

Remediation: Assign a dedicated FTR lead. Hold a kickoff meeting with security, operations, and product stakeholders. Create a shared tracker for remediation items with clear ownership and deadlines.

How nOps can help with your FTR

The FTR assessor checks specific cost optimization criteria. Here’s how nOps maps to what they actually ask for:

  • Multi-account visibility — the FTR requires you to demonstrate awareness of spend across your entire AWS footprint. nOps connects all linked accounts into a single view so you can show the assessor a complete picture.
  • Workload-level cost allocation — assessors look for tagging and allocation practices that tie spend to business units or services. nOps breaks costs down by account, team, workload, and K8s cluster/container.
  • Budget tracking and anomaly detection — the FTR expects ongoing cost governance, not a one-time cleanup. nOps provides automated budget alerts and anomaly reporting that prove you have continuous monitoring in place.
  • Commitment coverage and utilization — the review checks whether you’re using Savings Plans or RIs effectively. nOps Commitment Manager handles utilization tracking and optimization automatically, which matters especially for AI/ML workloads where static reservations don’t fit.

If cost optimization is the requirement holding up your FTR, get a free savings analysis to find out exactly where the gaps are.

FAQ

Plan for 4–6 weeks from self-assessment to submission, plus 2–4 weeks for AWS review. Teams with existing SOC2 or WAFR documentation can complete the alternative path in 2–3 weeks total.
No. An FTR is not required to list a solution in AWS Marketplace. However, it’s required for partner benefits including funding, the “Qualified Software” badge, AWS Competency eligibility, and ISV Accelerate co-selling.
AWS provides specific remediation guidance identifying exactly what needs to change. You can resubmit once remediations are complete. There’s no penalty for failing — only a delay while you address the gaps. Most teams that fail initially pass on their second submission after targeted fixes.
Yes. A SOC2 Type II audit (not Type I) provides an alternative pathway with a modified validation checklist. You still submit documentation, but the requirements are adjusted to account for controls already validated through your SOC2 process.
The FTR evaluates a defined checklist of mandatory requirements — it’s pass/fail against specific criteria. A Well-Architected Review is a broader, advisory assessment across all six framework pillars with prioritized improvement recommendations. A WAFR completed with a WAPP partner can serve as an FTR waiver.