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! 

Top FAQ's

1. What does this mean for SaaS sellers?‍

Sellers can still list products hosted outside AWS, but:

• Those products will not draw down AWS customer commitments.
• Non-AWS-hosted SaaS offerings may become less attractive to enterprise buyers who depend on commitment utilization to meet contractual targets.
• To stay competitive, SaaS sellers will likely need to migrate infrastructure to AWS or launch AWS-native versions.

2. What is the “Deployed on AWS” badge and why does it matter?

This badge is AWS’s formal validation that your SaaS product is 100% hosted on AWS.
It matters because it unlocks:

• Spend commitment drawdown
• Eligibility for private offers and discounted pricing
• Higher marketplace visibility
• Stronger credibility with AWS enterprise buyers
• Access to partner programs and AWS co-sell motions

Without this badge, your product will not help customers consume their AWS commits—and that can impact renewals, deal velocity, and competitiveness.

3. What are the key risks if my product is not fully hosted on AWS?

You may face:

• Lost renewals if customers cannot use their commits
• Reduced competitiveness vs. AWS-native competitors
• Lower private offer activity
• Limited AWS co-sell alignment
• Drop in marketplace discoverability

In many cases, this policy will force buyers to switch vendors if commit drawdown is non-negotiable.

4. What resources should sellers review before submitting?

Recommended AWS guidelines:

• SaaS Architecture Fundamentals
• Control Plane vs. Application Plane Guidance
• AWS Hosting Pattern Specifications
• Architecture Diagram Requirements for Marketplace

5. What are the requirements to earn the “Deployed on AWS” validation?

To qualify, sellers must demonstrate:

✓ Full AWS Hosting

• Both the application plane and control plane must run entirely on AWS.
• No hybrid solutions (e.g., Azure ML + AWS backend) are allowed.
• Hosting may occur in the seller’s or buyer’s AWS account—but nowhere outside AWS.

✓ AWS-Exclusive Data Replication & Migration

• If your product migrates data or workloads, these must target AWS only.
• Any multi-cloud replication must be split into a separate, non-eligible product.

✓ Control Plane on AWS-Managed Infrastructure

• Even if customer-facing resources run in the buyer’s account, the management layer must be AWS-native.

✓ Approved AWS Hosting Pattern

Your architecture must map to one of AWS’s defined SaaS hosting patterns.

✓ Documentation & Architecture Review

You must submit:

• Architecture diagrams
• Data flows
• Deployment details
  via the AWS Marketplace Management Portal (AMMP) for review and approval.