GRNMRK GROUP

AWS Technical Validation

AWS Foundational Technical Review
Checklist

Prerequisites, evidence documentation, and submission steps — everything you need to pass FTR on the first try and unlock Marketplace and SaaS Co-sell Benefit.

Program: Foundational Technical Review (FTR)

Unlocks: Marketplace Listings · SaaS Co-sell Benefit

First-pass rate: 100% for Grnmrk-managed submissions

FTR is the technical gate for AWS Marketplace transactable listings and SaaS Co-sell Benefit enrollment. Most partners know they need it. Far fewer know what AWS is actually looking for — which is why the first-submission pass rate across the ecosystem is well below 50%.

This checklist covers prerequisites, security, reliability, operational excellence, and evidence packaging. The most common failure mode is submitting prematurely with incomplete evidence. Work through this before you touch Partner Central.

What's Inside

Prerequisites — ACE opportunity, PSA engagement, account setup
Security pillar — the most common FTR failure area
Reliability and operational excellence evidence requirements
Evidence package preparation and submission checklist
Top failure reasons — what to check twice before submitting

Get the full checklist

Access the FTR Checklist

Enter your details and the full interactive checklist unlocks immediately.

✓

You're in.

Unlocking the checklist now.

Checklist Progress

0 / 27

01

Prerequisites

Before You Start

Active APN partner account in Partner Central Required
FTR is submitted through Partner Central. Confirm your account is active and you have the right user permissions.
At least one ACE opportunity exists and is submitted for your product Required
AWS requires an active ACE opportunity before FTR can be approved. Create and submit it before applying.
Your product is deployed on AWS or meaningfully uses AWS services
FTR validates how your product uses AWS. Products with no meaningful AWS integration will not pass.
Production workloads are NOT running from the AWS root account Required
Operating production workloads from root is a known FTR failure point. Use IAM roles with least-privilege instead.
AWS Partner Solutions Architect (PSA) engaged for pre-review
A PSA review before submission significantly improves first-pass rates. Request one through Partner Central if you don't have a direct relationship.

02

Security Pillar

Most Common Failure Area

IAM policies follow least-privilege — no wildcard (*) permissions in production Required
Any iam:*, s3:*, or *:* in production IAM policies will fail. Audit every role before submitting.
MFA enforced for all human IAM users with console access Required
Screenshot from IAM console showing MFA status for all human users. Service accounts using roles are exempt.
No long-term IAM access keys in use for EC2/Lambda workloads Required
Use IAM instance profiles and execution roles. Hardcoded or stored access keys are one of the top FTR failure reasons.
CloudTrail enabled in all regions used by your product Required
Provide a screenshot from the CloudTrail console showing an all-regions trail with S3 logging enabled.
Customer data encrypted at rest across all data stores
S3 SSE, RDS encryption, EBS encrypted volumes. Document each data store and its encryption configuration.
Data encrypted in transit — TLS 1.2 or higher on all endpoints Required
TLS 1.0 and 1.1 should be disabled. Provide certificate details or load balancer listener configuration as evidence.
VPC with public/private subnet separation deployed
Sensitive data stores (RDS, ElastiCache) should be in private subnets with no direct internet access.
Security groups restrict to required ports only — no 0.0.0.0/0 on SSH/RDP
Use SSM Session Manager instead of open SSH. Document security group rules for your core workloads.

03

Reliability Pillar

Architecture Evidence

Multi-AZ deployment configured for production workloads
At minimum, your database tier should span multiple Availability Zones. Document your AZ configuration.
Auto-scaling configured for compute resources
EC2 Auto Scaling Groups, ECS service auto-scaling, or Lambda's inherent scaling. Provide evidence of scaling policy configuration.
Backup and recovery process documented and tested Required
RDS automated backups, S3 versioning, or equivalent. Document your RTO/RPO targets and how your backup approach supports them.
Operational runbook exists for common failure scenarios
A basic runbook covering the top 3–5 incident scenarios is sufficient. AWS reviewers look for evidence your team can respond to failures.

04

Operational Excellence

Monitoring & Observability

CloudWatch monitoring enabled with dashboards for key metrics
Screenshot of your CloudWatch dashboard showing CPU, memory, error rates, and latency for core services.
CloudWatch Alarms configured for critical thresholds
Alarms covering high CPU, elevated error rates, low disk space, and unhealthy hosts. Provide evidence of alarm configuration.
Application logs centralized in CloudWatch Logs or equivalent
Logs must be retained, searchable, and accessible. Ephemeral logs on EC2 that disappear on termination will flag during review.
Infrastructure changes managed through IaC
CloudFormation, Terraform, or CDK. Not strictly required, but unmanaged manual changes are viewed as a reliability risk.

05

Evidence Package & Submission

Before You Hit Submit

Current architecture diagram prepared — labeled, showing all AWS services and data flows
This is the most important single evidence document. Label every service, show data flows, network boundaries, and AZ placement.
All evidence screenshots labeled by checklist section
Name files clearly: "02-CloudTrail-AllRegions.png" not "screenshot-042.png". Unlabeled screenshots slow the review significantly.
Every required checklist item has at least one piece of supporting evidence Required
The most common denial reason. AWS reviewers require proof — not assertions. A checked box without evidence fails review.
Second-set-of-eyes review completed on the full submission
Have someone unfamiliar with the submission review it. What's obvious to you is often unclear to the AWS reviewer.
Submission made through Partner Central FTR portal — not via email Required
Navigate to Partner Central > Solutions > FTR. Do not email submissions to AWS contacts.
PDM or PSA notified that submission is in
A heads-up to your AWS contact helps prevent the submission sitting in a queue. Most FTR reviews complete in 2–4 weeks.

Top FTR Failure Reasons — What to Check Twice

Wildcard IAM permissions

Any iam:*, s3:*, or *:* in production policies will fail. Audit every role before submitting.

Hardcoded access keys

Long-term access keys embedded in code or stored on EC2 instances. Use IAM instance profiles instead.

No ACE opportunity on file

Required before FTR can be approved. Create and submit at least one ACE opportunity first.

Evidence without context

Screenshots that don't clearly prove what they're meant to show. Label everything and crop to the relevant section.

Want to pass FTR on the first submission?

Grnmrk Group manages FTR preparation and submission for AWS partners. We've maintained a 100% first-submission pass rate across all client engagements. Let's talk about yours.

Book a Free Strategy Call Send an Email