How AWS’ new SaaS policy reshapes the marketplace for seller ISVs

In a groundbreaking move, AWS is shaking up its Marketplace policies. Starting May 1, 2025, SaaS products hosted on any infrastructure — even Google Cloud or Azure — can be listed on AWS Marketplace. But here’s the catch: only solutions fully deployed on AWS infrastructure will count toward customer spend commits. This policy shift opens new doors for independent software vendors (ISVs) while tightening the rules for those seeking to capitalize on AWS-related discounts and private pricing.

Let’s break this down and explore what it means for SaaS sellers navigating the evolving AWS ecosystem.

Key changes in the AWS marketplace policy

Previously, SaaS listings needed partial AWS hosting to qualify for spend commitments. The updated policy now simplifies and complicates things at the same time. Only products running entirely on AWS infrastructure, verified as "Deployed on AWS," will unlock spend commitments, custom pricing, and buyer discounts. This distinction is crucial for customers looking to maximize their AWS commitments, and even more so for sellers who want to remain an attractive, viable option for enterprise buyers relying on those commitments to build their tech stack.

This expectation for tighter alignment with AWS infrastructure has some big implications, so let’s dive into the details.

“We’re tightening up the Marketplace policy to say: in order to qualify for the discount, you must run 100% on AWS.”

Matt Yanchyshyn

VP of AWS Marketplace and Partner Services  |  AWS

What it takes to get the "Deployed on AWS" badge

Earning the "Deployed on AWS" validation is the key to unlocking customer spend commitments. To achieve this, SaaS providers must meet strict requirements:

• Full AWS hosting: The seller’s entire SaaS app — both the application and control planes — must run on AWS. Hybrid solutions or components hosted elsewhere are no longer eligible. This means that the application can be hosted in the seller's or buyer's AWS account, but it cannot include components running outside of AWS.
  
• Data replication and migration restrictions: If your product handles data replication or workload migration, it must target AWS exclusively. Any non-AWS replication must be spun off and listed as a separate product which will not qualify for this badge, and hence be ineligible for commit drawdown.
  
• Control plane management: The control plane must reside within AWS-managed infrastructure, even if application resources live in a customer’s AWS account. This helps AWS classify the product as SaaS rather than a managed service.
  
• Compliance with hosting patterns: Your application must fit one of AWS’s defined hosting patterns, ensuring tight integration with AWS services. This includes ensuring that all necessary services, such as content delivery networks and identity providers, are integrated within the AWS framework.
  
• Documentation and review: You must submit detailed architecture diagrams and deployment documentation through the AWS Marketplace Management Portal (AMMP). AWS will review and approve the submission before granting validation.

Submitting the architecture diagram is the most critical, time-sensitive step to earn validation and ensure customers can continue using their commitments to purchase your product without disruption.

How to submit your architecture design

Submitting your architecture design for AWS validation is a structured process. Follow these steps carefully for a smooth review:

1. Prepare your architecture diagrams: Create clear, detailed diagrams outlining your application's infrastructure. Use AWS’s guidelines to group components into two main categories:
   
   • Application plane: All components related to the product’s core functionality.
   • Control plane: Management and operational components, even if deployed in the buyer's AWS account.
2. Logical component placement: Label components accurately and show where they reside:
   
   • In the seller’s AWS account
   • In the buyer’s AWS account
   • Any external components (though these may disqualify the product)
3. Data flow and hosting pattern alignment: Map out data flows, including any replication or migration paths, to confirm compliance with AWS hosting patterns.
4. Diagram format and submission: AWS accepts PNG or JPG formats. Upload your diagrams through the AWS Marketplace Management Portal.‍
5. Allow Time for AWS Review: Submit early to accommodate AWS’s review process. Expect feedback, and be ready to revise diagrams if needed.

Some key resources to review -

• SaaS Architecture Fundamentals – Check if your architecture meets AWS criteria.
• Control Plane vs. Application Plane – Understand how AWS classifies these components.‍
• Architecture Guidelines & Diagram Specs – Ensure your submission meets AWS requirements.

Steps to prepare for the policy change

This policy may feel like a big change – and let's be honest, it is. However, by focusing on these preparatory items, you’ll be able to stay on track and achieve compliance on time. Here's what you should do:

1. Audit your current infrastructure: Map your current architecture. Are any components hosted outside AWS? If so, assess the cost, complexity, and timeline of migrating to AWS.
   
2. Choose a compliant hosting pattern: Select an AWS-approved hosting pattern that aligns with your architecture and product needs.
   
3. Diagram and document: Create detailed diagrams showing how components interact within AWS. Break elements into application and control planes, clearly labeling components and connections.
   
4. Submit for review early: We can’t emphasize this enough – don’t wait until the deadline. Submit your documentation early to allow AWS time for feedback and potential revisions.
   
5. Monitor AWS Communications: Stay informed about any further updates or clarifications regarding this policy change by regularly checking AWS announcements and communications.
6. Engage AWS Support: Collaborate with your AWS Account Manager or Partner Development Manager. Their insights can help you avoid pitfalls and accelerate the approval process.
7. Talk to us: If you’re a Clazar user, don’t hesitate to contact your CSM for queries or guidance on submitting your architecture diagrams.
   

Why the "Deployed on AWS" badge matters

Although these changes require effort, earning the "Deployed on AWS" badge comes with benefits that AWS wants their marketplace sellers to enjoy:

• Customer spend commitments: This, of course, is the most vital of all reasons to get validated. AWS customers can apply your product purchases toward their spend commitments, making your solution more attractive to enterprises heavily invested in AWS. This is also most likely to be a key decision criterion between renewal and churn.
  
• Enhanced marketplace visibility: The badge acts as a quality signal, increasing your product’s credibility and visibility in the AWS Marketplace. You’ll have the advantage of letting buyers know that your product is integrable and easily deployable.
  
• Access to AWS resources: AWS may provide additional promotional opportunities, technical resources, and partner support to validated solutions.
  

The bottom line

AWS’s new SaaS policy reflects a clear push toward tighter AWS infrastructure integration. While this raises the bar for ISVs, it also strengthens the value proposition for customers looking to consolidate their cloud spend.

For SaaS providers, the choice is clear: adapt to the new policy or risk losing marketplace traction. By aligning with AWS requirements and earning the "Deployed on AWS" validation, you not only future-proof your product but also position yourself as a trusted, high-value partner in the evolving cloud ecosystem.

Start planning today, and don’t let the May 2025 deadline catch you off guard!