From the outside the three cloud marketplaces look like the same product with different logos: list your software, customers buy with their cloud account, you get paid. Teams plan accordingly — one integration, replicated twice.
It does not work out that way. The commercial concept is shared; almost none of the implementation is. Here is where the three diverge, in the order you will hit them.
Seller registration
Each cloud runs its own seller program with its own legal entity verification, tax documentation and payout setup. There is no reciprocity — being an established AWS Marketplace seller earns you nothing on the other two.
Plan for this to be the slowest step, and for the delay to come from your own finance and legal teams rather than the cloud’s review. Tax forms and banking details for three separate programs, each wanting slightly different things.
A wrinkle on the Microsoft side: its marketplace is currently two storefronts. Azure Marketplace covers infrastructure and developer-oriented software, AppSource covers business applications. Which one your product belongs in depends on who buys it, and the answer affects how it gets found.
Fulfillment: three different handshakes
This is the first real engineering divergence. All three need to tell your system that someone bought something, and all three do it differently:
- AWS redirects the buyer to a registration URL you host, carrying a token. You resolve that token to get the customer and entitlement details, then provision.
- Microsoft sends the buyer to a landing page you host with a token you resolve, and then requires an explicit activation call back to Microsoft. The activation step is separate from resolution, and forgetting it leaves subscriptions stuck in a pending state.
- Google Cloud has you approve the customer account first and then approve the order — two acknowledgements rather than a token exchange.
You cannot write this once. The shape of the flow is different, not just the endpoint.
Google carries an additional consideration that is strategic rather than technical. Google’s documentation describes Cloud Marketplace SaaS products as running on Google Cloud, and its guidance for new solutions refers to running primarily on Google Cloud. If your product runs entirely on another cloud, clarify that with your Google partner contact before you build, because it affects eligibility rather than mechanics.
Metering
All three support usage-based charging, and all three have their own API, their own units and their own reporting windows. The traps are the same everywhere even though the interfaces differ:
- Reporting deadlines — late usage may not bill at all
- Idempotency — retries that double-count are a revenue defect in both directions
- Time zones and period boundaries — a usage record attributed to the wrong period lands in the wrong invoice
If you charge by usage on more than one cloud, you now have three independent paths where revenue can silently go missing, and three sets of reports to reconcile against your own ledger.
Pricing models and currency
AWS offers subscription, contract, and contract with consumption. The others have their own equivalents, with their own constraints on what can be changed after a customer is live.
Currency is a concrete difference worth knowing early. On AWS, public listings are USD only, with private offers supporting a wider set. If your European pipeline expects euro pricing on a public listing, that is a private-offer motion on AWS whether or not you intended it.
Fees
The structures are not comparable line for line, so comparing a single headline percentage is misleading. On AWS, public offer fees depend on deployment method — 3% for SaaS, 20% for server products — while private offers are tiered by contract value from 3% down to 1.5%, with all renewals at 1.5%. Channel adds 0.5%. We went through the full AWS rate card separately.
Worth noting that regional uplifts have started appearing: AWS added an additional 1% for buyers in South Korea from April 1, 2025, additive with the standard fee. Expect the geography of a deal to matter more over time, not less.
Microsoft has moved its own levers, notably halving the agency fee on renewals sold as private offers from October 1, 2024.
The practical takeaway: model fees per deal shape, not per marketplace. A renewal, a channel deal and a public self-serve purchase have materially different economics on the same platform.
The channel model, where they diverge most
If resellers matter to you, this is the biggest structural difference between the three, because it changes who holds the customer contract and who pays you.
On AWS, you issue a resale authorization and the channel partner creates a channel partner private offer. The partner owns the financial and contractual relationship with the customer.
With Microsoft multiparty private offers, Microsoft collects from the customer and pays the channel partner directly, and the partner then pays you outside the marketplace.
Those produce different artifacts for your finance team: a marketplace disbursement in one case, a partner receivable in the other. We go through this in detail in CPPO explained.
All three are moving targets
Treating these as stable platforms is the last mistake. Each has been changing quickly, and the direction is the same across all of them: agents and AI solutions as a first-class category.
Google announced an AI agent ecosystem program and a marketplace category for partner-built agents in November 2024, and expanded on it at Cloud Next this month. Microsoft and AWS are both signalling in the same direction.
What that means practically for a SaaS seller today is less about agents and more about discovery: the clouds are investing in how customers find solutions, which makes listing content a live concern rather than something you write once at launch.
What this means if you want all three
Three seller registrations, three fulfillment integrations, three metering implementations, three sets of reports to reconcile, three channel models, and three listing content sets to keep current as each platform changes.
That is the work CloudX exists to absorb. Our marketplace platform puts listings, offers, hosted registration, metering and revenue behind one interface, with agreements and disbursements across clouds in a single record. Launch covers going live on a new marketplace, and managed operations covers keeping all of them running once you are.
If you are deciding which cloud to start with, the clouds overview sets out what each one involves.
In short
The commercial logic transfers across all three. The implementation does not. Budget for three integrations and one reconciliation problem, and decide your channel model per cloud rather than assuming it carries over.