Cloud Marketplace: The Complete Guide to Listing, Selling and Scaling on AWS, Azure and Google Cloud

Hyperscaler GTM Playbook Hub & overview ↗

Cloud Alliances P1 – Overview A1 – Partner Programs A2 – Alliance Team A3 – Funding A4 – Tenancy Model

Co-Sell P2 – Overview B1 – AWS Co-Sell B2 – Microsoft Co-Sell B3 – Google Co-Sell B4 – Co-Sell Operations

Cloud Marketplace ► P3 – Overview C1 – Marketplace Listings C2 – Private Offers C3 – Marketplace Operations

Enterprise procurement teams discovered cloud marketplaces before most ISV sales teams did. Customers with pre-committed cloud budgets were already routing large software purchases through marketplace to draw down their commits – while their ISV vendors were still treating marketplace as a listing exercise. The gap between those two realities is where deals are being lost today.

TL;DR

A cloud marketplace – AWS Marketplace, Microsoft Marketplace and Google Cloud Marketplace – is three things in one: a discovery surface, a procurement system and a billing / contracting infrastructure for third-party software sold to cloud customers.
The dominant procurement driver is committed-spend drawdown. Customers with EDPs (AWS), MACCs (Microsoft) or eligible Google Cloud Minimum Commitment obligations prefer to spend pre-committed cloud budget through marketplace rather than open new procurement budget. This is the same dynamic that drives co-sell, covered in Hyperscaler Co-Sell.
The seller case is meaningful: faster cycles, larger deal sizes, win-rate uplift on co-sold marketplace transactions, structural alignment with hyperscaler-side AE comp. The honest counter-case is that listings without co-sell are visibility, not pipeline – marketplace is not a discovery channel that produces leads.
All three platforms support similar listing types (SaaS, AMI/VM, container, professional services, free trial, BYOL, private listing) with meaningfully different fee structures, contract mechanics and commit-drawdown rules.
Marketplace operations – listing maintenance, private-offer creation, metering, disbursement reconciliation, finance / rev-rec, CRM sync – is the back-office discipline most ISVs underinvest in until it breaks. The detailed treatment is in Cloud Marketplace Operations.

What a Cloud Marketplace Actually Is

A cloud marketplace is three distinct things rolled into one operating surface:

A discovery surface. Marketplaces present ISV products to cloud customers as a catalogue, with search, categorisation, badges and recommendation tools. The discovery component is the part that most resembles a traditional consumer marketplace. It is also, for most ISVs, the least valuable component – marketplaces produce minimal pipeline from organic discovery alone. The “list and the leads will come” myth comes from over-weighting this discovery role.

A procurement system. Marketplaces handle the procurement workflow for third-party software purchases: contract acceptance, terms negotiation through private offers, customer billing through the cloud invoice, vendor onboarding through the customer’s existing cloud relationship. The procurement component is operationally light for the customer compared to opening new vendor procurement – sometimes by weeks of cycle time. This is the component customers actually care about.

A billing and contracting infrastructure. Marketplaces hold the contract between the ISV and the customer, route the transaction through the hyperscaler’s invoicing infrastructure, apply customer committed-spend drawdown where applicable (AWS EDP, Microsoft MACC and eligible Google Cloud Minimum Commitment obligations), handle currency and tax for the participating jurisdictions, disburse to the seller on a defined payout cycle. The billing infrastructure is what makes the procurement component possible – and what makes marketplace operationally heavy on the seller side.

This three-in-one structure explains why marketplace strategy is genuinely strategic rather than purely operational. ISVs that treat marketplace as just a procurement convenience underinvest in the discovery and contracting infrastructure – or, conversely, treat marketplace as a discovery channel and underinvest in the procurement and billing infrastructure. The right architecture invests in all three components, weighted by the ISV’s customer profile.

The platforms in scope are AWS Marketplace, Microsoft Marketplace (unified from the former Azure Marketplace and AppSource on 25 September 2025) and Google Cloud Marketplace. All three operate the same three components but with different surface details, fees, listing types and commit-drawdown mechanics.

The Procurement Reasons Customers Buy Through Marketplace

The customer’s reason for preferring marketplace procurement is operational, financial and political:

Consolidated billing. The marketplace transaction is billed through the platform’s billing system rather than as a separate vendor invoice from the ISV, although depending on the platform and purchase it may appear on a separate marketplace invoice from the hyperscaler. For customers managing dozens or hundreds of cloud-related vendor relationships, the consolidation is material – finance teams measure it in days of saved AP processing per quarter.

Existing contracting framework. The customer’s existing marketplace relationship with the hyperscaler provides the purchasing and billing framework, and the ISV’s terms are presented through the marketplace for the customer to accept. Where the customer accepts the ISV’s standard or previously agreed terms, cycle time saved on legal review is typically measured in weeks; in some industries (regulated, public sector), it’s measured in months. The marketplace does not replace the contract between ISV and customer, though – for enterprise deals, the licence or MSA is usually negotiated directly between them and carried into the private offer. The marketplace handles the commerce; the legal relationship sits alongside it.

Lighter vendor onboarding. Buying through a marketplace uses the customer’s existing purchasing and billing arrangements with the hyperscaler. The customer’s separate vendor-onboarding process – security questionnaires, financial-stability checks, insurance verification – can often be skipped or at least substantially abbreviated for marketplace purchases. Marketplace availability is not a substitute for the customer’s own vendor-risk assessment, though, and the customer’s purchasing controls still apply: AWS, for example, lets buyers require purchase orders and set custom purchasing guidance for Marketplace purchases.

Committed-spend drawdown. The single most important driver for enterprise customers. Customers with AWS EDPs, Microsoft MACCs or eligible Google Cloud Minimum Commitment obligations have pre-committed cloud spend and often prefer to draw it down rather than open new procurement budget. Eligible marketplace transactions can count against the commit; direct-invoiced transactions don’t.

Faster legal cycle. Even when the customer hasn’t pre-committed cloud spend, the legal cycle for a marketplace transaction is significantly faster than for a traditional vendor onboarding. The contract can be templated, and the customer’s legal team has often already reviewed the standard marketplace terms for the major hyperscaler relationships.

Sourcing simplification. Procurement teams managing thousands of vendor relationships actively prefer fewer vendor relationships. Routing ISV purchases through the marketplace can consolidate billing through the platform’s billing system, although marketplace charges may appear on a separate invoice. It does not remove the ISV from the relationship – the software contract remains between ISV and customer, with the marketplace handling procurement and billing steps alongside it.

The combined effect is large enough that some enterprise customers now have explicit procurement policies favouring marketplace transactions for cloud-adjacent software. These policies vary by jurisdiction and industry but the directional trend is unambiguous: marketplace is increasingly the preferred procurement path for the segment of customers most ISVs want to sell to.

The Seller Reasons to Be There

The seller’s case for being on marketplace is by design complementary to the customer’s:

Meet buyer demand. Customers increasingly start procurement with “is this on marketplace?” rather than “what’s your standard onboarding process?” ISVs not on marketplace are functionally invisible to the part of the customer base that has the largest budgets and the most committed spend.

Larger deal size. Marketplace transactions are often larger than direct-invoiced equivalents. Customers drawing down committed spend feel less procurement friction and are more willing to expand scope at signature. AWS cites a Forrester Total Economic Impact study of AWS Marketplace sellers (commissioned 2022; a composite of 12 seller interviews and a 60-seller survey) finding sellers realised 80% larger deal sizes and closed 27% more deals through AWS Marketplace than through other sales channels. Treat the Forrester numbers as AWS-specific and several years old rather than a current cross-platform benchmark.

Faster cycle. The procurement-friction reduction at the customer’s legal and finance desks means marketplace deals close faster than direct equivalents. The cycle compression is typically meaningful enough to be visible in quarterly forecasting.

Co-sell incentive alignment. Marketplace transactions trigger the hyperscaler-side incentives that make the AE field by design motivated to support the ISV. AWS’s SaaS Co-Sell Benefit is a perfect example: AE quota retirement on marketplace-routed partner SaaS. Microsoft has multiple incentive structures tied to marketplace-routed MACC drawdown. Google Cloud’s incentives flow through similar mechanics. The detail is in Hyperscaler Co-Sell and the per-cloud cluster posts.

Win-rate uplift on co-sold marketplace transactions. Co-sold deals that route through marketplace win at significantly higher rates than equivalent direct-only deals. The combination of hyperscaler-side AE engagement, procurement-friction reduction and committed-spend drawdown produces a compounding effect that mature ISVs measure and report.

Reference compounding. Partners report that marketplace transactions show up in hyperscaler-side reporting and contribute to partner-program metrics, including specialisation renewal and partner-tier progression. The same closed deal produces commercial value to the ISV, comp credit to the hyperscaler AE and program-metric value to the alliance function. Few revenue events are this leveraged.

Contractual commitment rigidity. A less-discussed benefit of transacting through marketplace. When a customer commits to a multi-year deal via a hyperscaler marketplace, the billing relationship runs through the hyperscaler’s systems and the invoice comes from the hyperscaler. A customer seeking to dispute or withdraw from that commitment is not dealing with the ISV’s collections process alone – the charges sit inside their billing relationship with the hyperscaler. Partners report that this creates a degree of protection against unilateral withdrawal that equivalent direct contracts do not provide. The reverse applies when the customer is running short on commit and seeking renegotiation: the hyperscaler’s billing infrastructure is equally present in that conversation, and not always on the ISV’s side.

The honest counter-case: marketplace fees vary by platform, offer type and deal attributes – a 3% figure is a useful shorthand only for some baseline transactions, and the actual fee on a given deal may be higher or lower depending on contract value, renewal status and program eligibility. For ISVs operating on thin margins, the fees can move the gross-margin calculations materially. The right analytical framing is to compare net-of-fee marketplace revenue against direct revenue net of the procurement-cycle-time cost – and the net comparison almost always favours marketplace for ISVs selling to enterprise customers with committed spend.

Three-platform Overview

The high-level orientation. Detail per platform sits in the cluster posts (Cloud Marketplace Listings, Private Offers, Cloud Marketplace Operations) and the per-cloud co-sell posts.

Dimension	AWS Marketplace	Microsoft Marketplace	Google Cloud Marketplace
Year established	2012	2014 (Azure Marketplace; consolidated with AppSource into Microsoft Marketplace on 25 September 2025)	2017
Baseline marketplace fee	Varies by offer type, contract value and renewal status – see AWS listing fees for current rates	Varies by offer category and transaction structure	Tiered revenue share, subject to eligibility: 3% standard, 3%/2%/1.5% by TCV tier on new-deal private offers, 1.5% on qualifying native renewals, channel shifts and migrations – see Google Cloud Marketplace revenue-share schedule
Customer incentives and fee structures	AWS listing fees vary by offer type and TCV; MPOPP provides AWS Promotional Credits to customers on qualifying transactions	Varies by transaction type; Microsoft standard fee is 3%, with 1.5% for qualifying renewal private offers	MCCP gives up to 3% in Google Cloud credits on eligible first-time solution purchases via private offer, subject to a $100k+ annualised-GTV minimum; seller-side revenue share is tiered by deal type and size, from 3% standard down to 1.5% for large new-deal private offers and qualifying renewals
Listing types	SaaS, AMI / VM, Container, Professional Services, Free Trial, BYOL, Private Listing	SaaS, VM, Container, Consulting Services, Managed Service, Power BI Apps, IoT Edge Modules	SaaS, VM, Container, Kubernetes Apps, Solutions, Consulting Services
Pre-committed spend mechanism	EDP	MACC	Eligible Google Cloud Minimum Commitment obligations; MCCP is a separate customer-credit program
Channel-partner private offer	CPPO	MPO	Channel-partner private offer
Technical validation	FTR	Well-Architected Review	Architecture Review
Term for customer’s cloud environment	Customer account	Customer tenant	Customer project (sometimes customer organisation)
2026 notable feature	Express Private Offer (announced around re:Invent 2025, launch post dated 30 November 2025); agentic AI categories	Post-unification Microsoft Marketplace stabilising through 2026; MPO now available across 36 customer billing-account markets following the addition of Australia, Japan and South Africa on 15 July 2026	Q1 2026 Partner Network reset; variable marketplace revenue share introduced for eligible partners and deals

The three platforms are recognisably similar at the architectural level: catalogue, transaction infrastructure, contract overlay, commit drawdown. They differ in surface detail enough that practitioner knowledge from one platform translates imperfectly to the others.

AWS Marketplace is the most mature of the three and has the deepest tooling ecosystem (third-party platforms have invested most heavily there). Microsoft Marketplace is the most strategically integrated with the customer’s broader enterprise relationship (the MACC drawdown mechanic in particular is highly leveraged). Google Cloud Marketplace is the leanest of the three but, per Google Co-Sell, the lighter tooling is partly compensated by the more accessible field organisation.

For ISVs starting marketplace strategy from a near-zero baseline, the right approach is single-cloud-first (whichever cloud the largest customer cohort sits on) with the second and third clouds added in sequence as the operational discipline scales. Trying to launch on all three simultaneously typically produces sub-scale presence on all three.

Listing Types Explained

A listing is a marketplace catalogue entry that maps to a specific product or product variant. Each platform supports several listing types, with material differences in operational mechanics, technical-validation requirements and customer-purchase patterns. Detail is in Cloud Marketplace Listings; the orientation:

SaaS. ISV-hosted multi-tenant software, customer subscribes through marketplace and consumes over a network endpoint. The listing pattern that aligns with ISV-hosted SaaS tenancy archetype. Technical-validation overhead is lighter than VM-based listings; where pricing is usage-based, the operational complexity is in the metering integration (the ISV reports usage to the marketplace for billing).

AMI / VM. Customer-deployed machine-image listings. The customer launches the AMI (AWS) or VM (Azure, Google Cloud) in their own cloud account; consumption accrues to the customer’s bill plus the ISV’s licence fee. The pattern that aligns with customer-deployed tenancy archetype. Technical-validation overhead is higher – the AMI / VM has to pass the hyperscaler’s standards.

Container. Container-image listings (Docker / OCI format) deployable into customer Kubernetes clusters or container services. Newer than AMI / VM and growing fast as customer infrastructure shifts toward container-based deployment. Validation requirements are still maturing across the three platforms.

Professional Services / Consulting Services. Services rather than software listings – implementation, migration, managed services. Typical for SI / MSP partners rather than ISVs, but ISVs with strong services attach motions sometimes list services alongside their software.

Free Trial. A time-bounded or usage-bounded trial variant of a SaaS or AMI listing, with the customer automatically moved to paid status on conversion. Operationally simpler than running a separate trial system. Useful for products with measurable trial-to-paid conversion patterns.

BYOL. Bring Your Own Licence. The customer has an existing licence (purchased directly from the ISV, not through marketplace) and uses the BYOL listing to deploy the software while keeping the licence relationship outside marketplace. BYOL supports customers bringing licences bought outside marketplace, including for on-premises-to-cloud migrations; customers need to confirm that their existing licence permits the intended deployment. Because the licence fee is not billed through marketplace, that licence spend bypasses the pricing and transaction mechanics that make marketplace useful for commit drawdown.

Private Listing. A listing visible only to specific invited customers, used to expose custom pricing, custom terms or restricted-distribution products without making them publicly discoverable. Distinct from a private offer (a transaction structure) – private offers do not require a private listing, and availability depends on the platform and product type. See Private Offers.

Which listing type to use is largely determined by tenancy archetype and customer preference, though the mapping is a strong default rather than a fixed rule. ISV-hosted SaaS products typically use SaaS listings; customer-deployed products typically use AMI / VM or container listings; hybrid products may need separate listings for the SaaS-mode and self-deployed-mode variants. Edge cases exist on all three platforms – the detailed decision guide is in Cloud Marketplace Listings and references the broader tenancy-archetype discussion in ISV-Hosted vs Customer-Deployed.

The Four Marketplace Transaction Motions

Marketplace transactions fall into four broad motions, each with different mechanics, customer behaviour patterns and seller operational requirements:

Public-listing transaction. The customer discovers the product through marketplace search, accepts the public-listing terms and pricing as-displayed and transacts. The simplest transaction type and the rarest at meaningful deal sizes – enterprise customers almost always negotiate custom terms rather than accepting public pricing.

Click-to-subscribe. A variant of public-listing transaction for SaaS products with usage-based billing. The customer subscribes through marketplace, accepts the metered-billing terms and consumes the service. It is operationally light for both seller and buyer and is commonly used for self-service customer segments where deal size is too small to justify private-offer overhead.

Private offer. The most operationally important transaction type. The seller (or, in CPPO / MPO structures, the seller plus a channel partner) creates a customer-specific offer with negotiated pricing, custom terms, defined contract length and payment schedule. The customer accepts the private offer through marketplace; the transaction executes. Private offers are the route through which the majority of enterprise marketplace business closes. Detail in Private Offers.

Multiparty / CPPO offer. A private-offer variant involving the seller, a channel partner (SI, MSP or reseller) and the customer. The channel partner is part of the commercial structure – mark-up, services-included pricing, regional fulfilment – and the marketplace transaction handles the multiparty payout. AWS calls this CPPO; Microsoft calls it MPO; Google Cloud has a channel-partner private offer with similar mechanics. Detail in Private Offers.

The architectural pattern that recurs: as an ISV’s marketplace motion matures, the transaction mix shifts away from public-listing and click-to-subscribe toward private-offer and multiparty / CPPO. The shift reflects the maturity of the underlying co-sell motion – enterprise deals close through private offers because enterprise procurement requires custom terms.

Three operational implications of the transaction-motion mix:

First, private-offer cycle time matters. The difference between a 2-week and a 6-week private-offer cycle is the difference between closing a deal in the quarter it’s negotiated versus the next quarter.

Second, multiparty / CPPO structures require operational depth – the channel-partner relationship management, the multiparty contract structures and the payout reconciliation are non-trivial. Most ISVs add CPPO / MPO motions only after their direct private-offer motion is operational.

Third, click-to-subscribe motions are easy to under-invest in. They look like commodity self-service flows and get treated as low-priority, but for ISVs with self-service customer segments they’re often a meaningful share of new-customer acquisition.

The Marketplace Operations Stack

Marketplace operations is the back-office discipline that makes the marketplace motion work at scale. The major components:

Listing management. Creating and maintaining marketplace listings, including the listing metadata (titles, descriptions, categorisation, badges), pricing structures, supported regions and currencies and the metering integration for listings with usage-based pricing. Listings are not “set and forget” – they expire, age out as the product evolves and need regular refresh.

Private offer creation. Producing private offers for negotiated deals, including custom pricing, payment schedules, contract length, custom terms overlays and customer-specific configuration. At scale this is templated and automated; at small scale it’s done by hand and is operationally heavy.

Metering. For usage-based SaaS listings, reporting consumption to the marketplace metering API on a defined rhythm. Metering accuracy is critical in practice – missed metering events cost real money, double-reported events cost credibility with the marketplace ops team.

Billing reconciliation. Matching marketplace-side transaction records to ISV-side CRM and ERP records, identifying disagreements, resolving them before they propagate into customer-facing disputes.

Payout. Receiving disbursements from each marketplace on the platform’s defined rhythm (typically 45–60 days after customer billing close), reconciling to the ERP, recognising revenue per the appropriate accounting treatment.

Finance and revenue recognition. The principal-vs-agent question (covered in Cloud Marketplace Operations), treatment of marketplace fees, gross-vs-net presentation, handling of channel-partner-routed transactions through CPPO / MPO structures. Finance involvement is non-optional.

CRM sync. Routing marketplace transaction records into the ISV’s CRM for opportunity-closing, comp-credit calculation and alliance-attribution reporting. Closes the loop on co-sell attribution.

The marketplace operations stack typically becomes the rate-limiting factor on the marketplace motion as it scales. ISVs that under-invest in operations find their marketplace motion capped at the volume the existing ops team can hand-process; ISVs that over-invest in operations before transaction volume justifies it pay infrastructure costs that don’t yet produce revenue. The right calibration is highly stage-dependent; the detailed treatment is in Cloud Marketplace Operations.

Marketplace as Part of a Cloud GTM Strategy

Marketplace strategy is not a standalone discipline – it sits inside the broader cloud GTM strategy described in Cloud Alliances and operationalised through co-sell as covered in Hyperscaler Co-Sell. The maturity arc for marketplace specifically:

Stage 1: List. A live, transactable marketplace listing on the primary cloud. Not just enrolled – actually transactable, with at least one private-offer-eligible product variant. Meet the chosen platform’s own requirements for reaching a transactable listing. On AWS, FTR submission follows listing publication and completion of the other software-validation prerequisites; it supports the AWS partner benefits that come afterwards rather than gating the listing itself. Verify the relevant listing, technical-validation and co-sell requirements against Microsoft’s and Google’s own current documentation.

Stage 2: Transact public. First public-listing transactions closed through the marketplace. Often these are renewals of pre-existing direct customer relationships routed through marketplace at the customer’s request – expected and not a failure. The motion at this stage is mostly procurement-friction reduction for customers who would have bought anyway.

Stage 3: Transact private. First private-offer transactions closed through the marketplace. The shift from public to private signals that the alliance and co-sell motions have started producing pipeline that closes through marketplace. The private-offer share of transactions typically grows from near-zero to a clear majority over 12–24 months as the motion matures.

Stage 4: Transact through channel partners. First CPPO / MPO / channel-partner private-offer transactions, integrating channel partners into the marketplace motion. The stage that requires the most operational maturity – multiparty contracts, channel-partner relationship management, payout reconciliation.

Stage 5: Marketplace as primary procurement path. Marketplace transactions account for the majority of new enterprise business in the relevant customer segments. The motion at this stage is mature enough that the marketplace is not “a sales channel” but “the default procurement path the customer expects”.

The progression is not linear – some ISVs reach stage 4 before stage 3 if they have channel-led motions; some skip stage 4 entirely if their channel-attach is minimal. The directional progression holds for most.

The connection to tenancy archetype matters here. ISV-hosted SaaS partners typically reach stage 5 faster – their marketplace motion is more integrated with co-sell and the AE incentives align cleanly. Customer-deployed partners reach a different stage 5 – marketplace is the closing mechanic, not the origination channel, and the maturity arc emphasises stages 3 and 4 over stage 5. The definitive reference is ISV-Hosted vs Customer-Deployed.

Common Myths About Cloud Marketplace

A handful of recurring misconceptions worth addressing directly:

“We’ll launch a listing and the leads will come.” No. Marketplace listings are visibility, not pipeline. The discovery component of marketplace produces minimal organic lead flow for almost all ISV categories. A live listing without an active co-sell motion produces almost no incremental business beyond what the ISV would have closed anyway. The leads come from co-sell engagement (covered in Hyperscaler Co-Sell); marketplace is where co-sold leads close.

“Marketplace fees make it unprofitable.” Depends. Marketplace fees vary by platform, offer type and deal attributes – the oft-cited 3% is a useful rough guide for some baseline transactions but the actual figure on a given deal will differ. For some product categories with very thin margins, fees can move the gross-margin arithmetic. But the net comparison is fee-vs-direct-cycle-time-cost: marketplace deals close faster and at larger sizes than direct-invoiced equivalents. Net of accelerated cycle, larger deal size and the co-sell-incentive alignment, marketplace transactions are usually accretive to the ISV’s revenue mix. Run the analysis with real numbers; intuition tends to be wrong.

“We don’t need to worry about FTR / Well-Architected / Architecture Review.” AWS FTR should not be confused with the review needed to publish a Marketplace product: for the documented software-validation path, the listing and other prerequisites come first, and FTR approval unlocks additional AWS partner benefits rather than gating the listing itself. For Microsoft and Google, check the relevant listing, technical-validation and co-sell requirements separately – AWS’s submission order doesn’t establish when the other platforms’ own validations happen. What skipping any of the three validations actually costs is the meaningful co-sell mechanics layered on top: AWS’s Qualified Software badge and Competency / ISV Accelerate eligibility sit behind an approved FTR, and Microsoft’s Azure IP Co-Sell Eligible status – the one that matters for MACC drawdown – requires its own Azure-platformed technical validation. The validation work is the gating activity for the co-sell and partner-program layer, not for getting listed in the first place.

“Marketplace is just procurement convenience.” No – it’s procurement convenience plus committed-spend drawdown plus co-sell incentive alignment. The combination is by design different from a payment-rail simplification. Treating marketplace as just a payment rail underinvests in the strategic value.

“Public-listing transactions will scale to majority of business.” No – in almost all enterprise ISV motions, private-offer transactions are the majority of business at maturity. Public listings serve the self-service customer segment and act as discovery surface for enterprise prospects who eventually transact through private offer. Building marketplace strategy around public-listing scale is building for the wrong customer segment.

“All three marketplaces are roughly equivalent.” Architecturally similar, in practice distinct. The metering APIs differ. The disbursement schedules differ. The private-offer structures differ. The channel-partner integration mechanics differ. Practitioner knowledge from one cloud translates imperfectly to the others; assume material learning curve when adding a second or third cloud.

“Marketplace is for new business only.” No – existing customers are increasingly converting from direct invoicing to marketplace billing at renewal, particularly when the customer’s procurement team decides the marketplace motion produces better economics for them. This conversion produces no incremental revenue at the moment of conversion but reshapes the renewal-cycle dynamics in subsequent years.

Common Pitfalls

Beyond the structural myths, several practical pitfalls recur:

Underinvesting in marketplace operations. The back-office stack (Cloud GTM Platforms or equivalent native tooling) is critical in practice and consistently under-budgeted in year one of marketplace adoption. Build the operational infrastructure before the transaction volume needs it.
Missing technical-validation renewal cycles. FTR / Well-Architected Review / Architecture Review aren’t one-time events. They need re-passing as the product evolves. Lapsed validations put the dependent partner benefits and co-sell mechanics at risk – marketplace transactability itself should be checked against the applicable product-type requirements rather than assumed to follow automatically from validation status.
Not maintaining listings as the product evolves. Listings drift. Product features added in the trailing 12 months don’t appear in the marketplace catalogue. Pricing variants supported by the ISV don’t appear as marketplace pricing options. Marketing or product collateral linked from the marketplace page looks obviously out of date, or – unforgivably – resolves to broken links. The discovery surface becomes increasingly stale; customer trust in the listing as accurate erodes.
Publishing placeholder pricing on public listings. ISVs intending to transact exclusively via private offer often create a public listing as a discovery surface while setting nominal or nonsensical public pricing – a $0.001 per-hour AMI, a $1 monthly SaaS subscription, or conversely a $999,999 annual fee that functions as a “do not buy this” signal. The reasoning is that real transactions will never flow through the public listing, so the pricing doesn’t matter. The flaw in that reasoning: the public listing is visible to every prospective customer who searches the marketplace, including enterprise buyers at accounts the ISV’s sales team has never touched. A buyer who finds obviously placeholder pricing draws one of two conclusions – that the product is cheap and probably not enterprise-grade, or that the ISV doesn’t take its marketplace presence seriously. Either conclusion ends the evaluation before the ISV ever knows it began. Public listing pricing should reflect actual positioning even when all real transactions are expected to go through private offer.
Treating click-to-subscribe and private offers as the same motion. They are by design different. Self-service click-to-subscribe needs different pricing, different metering, different customer-success motion than negotiated private offers. Designing for one and applying to the other produces operational friction.
Skipping channel-partner marketplace integration. ISVs with established channel motions sometimes treat marketplace as direct-only, leaving the channel partners off-marketplace. The channel partner loses access to MACC-eligible transactions; the ISV loses the channel-amplification of marketplace co-sell. Wire CPPO / MPO mechanics in from the start if a channel motion exists.
Over-engineering metering before launching. Listings with usage-based pricing need metering, but the metering complexity should match the product’s actual usage-pricing dimensions. ISVs building elaborate metering infrastructure for products with simple subscription pricing waste engineering time; ISVs building simple metering for products with complex usage-pricing get caught out at scale.
Confusing marketplace-fee calculations with co-sell-economics calculations. Marketplace fees vary by platform and deal attributes; co-sell incentives can produce gross-revenue effects measured in tens of percent on individual deals. The two calculations are not additive in the simple way they look; mature ISVs model them together.

What This Looks Like in Practice

A composite example, drawn from patterns across multiple real situations.

A data-platform ISV with $40M ARR built its marketplace motion across the three major hyperscalers over two-and-a-half years. The starting state was an AWS Marketplace listing earned through ISV-Success-style onboarding, with a transactable SaaS variant and very little operational depth around it. The trigger to take marketplace seriously was a specific customer conversation: a Fortune-500 prospect in late-stage pursuit asked, in the final commercial review meeting, whether the deal could be routed through AWS Marketplace to draw down the customer’s EDP commit. The ISV’s deal-desk answer was “in principle yes, in practice we’ve never done a private offer of this size” – which the procurement lead heard as “no” and stalled the deal for six weeks while a parallel direct-invoice path was explored.

Months 1–6: AWS depth. Marketplace operations infrastructure built around the AWS listing, prompted directly by the stalled-deal incident. The first private-offer transactions closed (renewals routed through marketplace at customer request); first non-renewal private-offer transactions in month five. Marketplace operations manager hired in month four, after the alliance lead had spent three weeks doing reconciliation in spreadsheets and reached the same conclusion that the original Fortune-500 customer’s procurement team had reached: this was not a sustainable approach. By end of month six: $1.4M of marketplace transactions in the trailing six months, mostly AWS, mostly private-offer. The original Fortune-500 deal closed through marketplace in month four after a 9-week extension cycle that the customer accepted with visible irritation.

Months 7–12: Microsoft entry. Microsoft Marketplace listing built through ISV Success. Azure IP Co-Sell Eligible status earned in month ten – two months later than the alliance leader had planned because the Well-Architected Review identified an authentication-architecture issue that the engineering team initially disputed and then conceded after a two-week back-and-forth with the Microsoft reviewer. First MACC-drawdown transaction in month eleven (a $260k renewal that had previously been direct-invoiced; the customer’s procurement team directly preferred the MACC drawdown). CPPO mechanics added to AWS motion in parallel; first CPPO transaction with a regional SI partner in month twelve, after the SI’s account manager spent a month learning the AWS-side mechanics that the ISV’s alliance team had to walk them through.

Months 13–18: Google Cloud entry. Google Cloud Marketplace listing under the new Partner Network structure. Lower-friction onboarding produced a transactable listing in 12 weeks – the alliance team had expected closer to 20 weeks based on the AWS and Microsoft timelines, and the speed surprise meant that the marketplace ops team wasn’t ready to handle the third platform’s reconciliation workflow when the first Google transactions started arriving. Second-quarter month-end close ran three weeks late as a result. First Google Cloud Marketplace transaction in month sixteen.

Months 19–30: Maturity progression. All three clouds at stage 3–4 of the marketplace maturity arc. Transaction mix shifted decisively toward private-offer and CPPO / MPO (roughly 70% private-offer, 20% CPPO/MPO, 10% public-listing and click-to-subscribe by month 30). Marketplace operations stack rebuilt around a Cloud GTM Platform in month 22 after the manual processes hit operational ceiling; the rebuild was triggered by the marketplace ops manager submitting a resignation that the CRO talked her out of by approving the platform spend the same week. By month 30: $11M trailing-12-month marketplace transactions across all three clouds; marketplace as a percentage of new business at roughly 35%.

The diagnostic insight from the 30-month build: marketplace operations was consistently 6–9 months behind the demand curve. The team kept adding capacity reactively rather than building ahead of need. Each of the three operational crises – the original Fortune-500 stalled deal, the second-quarter close that ran three weeks late after Google launched and the resignation in month 22 – was the symptom of the same underlying pattern. The lesson for the next ISV in the same position: hire the marketplace ops capability earlier than feels justified by current volume, and budget the Cloud GTM Platform spend in year two rather than year three. The infrastructure cost is real but the alternative is leaving deals on the table for want of operational capacity, alongside the human cost of running operations in permanent firefighting mode.

Where to Go Next

The cluster posts under this pillar:

Cloud Marketplace Listings – the listing process, technical validations and listing-type decision guide across the three hyperscalers.
Private Offers – private offer mechanics, CPPO, MPO and the operational depth required to run marketplace closing at scale.
Cloud Marketplace Operations – the back-office stack: metering, billing reconciliation, finance, revenue recognition, CRM sync.

Adjacent pillars:

Cloud Alliances – the partnership function that operates the broader cloud GTM motion this marketplace strategy sits inside.
Hyperscaler Co-Sell – the co-sell motion that originates the pipeline that closes through marketplace.

The full series glossary is at Glossary.

External References

Vendor Primary Sources

AWS Marketplace – seller-facing documentation on AWS Marketplace.
Microsoft Learn – Commercial Marketplace – Microsoft Commercial Marketplace documentation.
Microsoft TechCommunity – Thriving in the reimagined Microsoft Marketplace – Microsoft’s announcement of the 25 September 2025 unification of Azure Marketplace and AppSource into a single Microsoft Marketplace.
Google Cloud Marketplace – Google Cloud Marketplace partner documentation.

Independent Analyst Research

Omdia – partner-channel and analyst research including marketplace transaction patterns and marketplace ecosystem economics. Note: Omdia acquired Canalys in 2023; research previously attributed to Canalys is now published under the Omdia brand.

Practitioner Models and Industry Commentary

These sources are influential within the cloud-GTM practitioner community but published from a commercial or advisory vantage point. Cited with attribution.

CONNACT – Cloud Marketplaces Explained and Unlocking the Full Potential of Cloud Marketplaces. Practitioner introductions to cloud marketplace mechanics from a partner-advisory practice. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.
AppDirect / Clazar / Invisory / Labra / Suger / WorkSpan – educational guides published by Cloud GTM Platform vendors. Useful for category orientation; treat as commercially interested practitioner content.
Tackle – State of Cloud GTM annual report, including marketplace transaction patterns and the SaaS-vs-deployable mix. Tackle is a Cloud GTM tooling vendor; the report is informative but published from a commercially interested vantage.

Sources

AWS – Listing fees for selling in AWS Marketplace – AWS documentation on marketplace listing fees by offer type, contract value and renewal status (Verified June 2026)
AWS Marketplace – Total Economic Impact of AWS Marketplace for ISV Sellers (Forrester) – AWS-commissioned Forrester study (2022; 12 seller interviews plus a 60-seller survey, aggregated into a composite profile) reporting 80% larger deal sizes and 27% more deals closed through AWS Marketplace than through other sales channels – the source for the deal-size figures cited above (Verified September 2026)
Google Cloud Marketplace – Commitment drawdown rates – confirmation that eligible Google Cloud Marketplace spend counts toward Minimum Commitment obligations (Verified September 2026)
Google Cloud – Marketplace revenue-share schedule – Google Cloud’s tiered revenue-share schedule (3% standard, 2% for $1M–$10M TCV private offers, 1.5% for $10M+ TCV or on qualifying native renewals, channel shifts and migrations) (Verified 7 September 2026)
Microsoft Learn – Multiparty private offers overview – confirmation of MPO availability across 36 customer billing-account markets, including Australia, Japan and South Africa from 15 July 2026, and of the narrower 35-market channel-partner tax-profile list (Verified July 2026)
Microsoft TechCommunity – Thriving in the reimagined Microsoft Marketplace – confirmation of the 25 September 2025 Azure Marketplace and AppSource unification into Microsoft Marketplace (Verified June 2026)

Last reviewed: 2026-09-28. Pillars in this series are reviewed twice yearly after the major hyperscaler conferences (late November / early December following AWS re:Invent and Microsoft Ignite; late April / early May following Google Cloud Next). Major program changes between reviews are flagged in the Updates section below.

Updates

Updated 28 September 2026: Replaced an unsupported “50%+ uplift on win rates and deal size” claim with a dated, AWS-specific figure: a Forrester Total Economic Impact study commissioned in 2022 found that sellers realised 80% larger deal sizes and closed 27% more deals through AWS Marketplace than through other channels. Corrected passages that treated AWS’s Foundational Technical Review and similar validations as gating basic listing transactability; AWS requires an existing Marketplace listing before it accepts an FTR request. Corrected the procurement section: a marketplace purchase sits alongside the ISV–customer contract rather than replacing it and doesn’t replace the customer’s own vendor-risk assessment. In the Three-platform Overview table, corrected Azure Marketplace’s launch year to 2014, gave Google’s actual tiered fee schedule and added MCCP’s $100,000 annualised-GTV minimum. Also made several smaller clarifications. Factual corrections were checked against the cited sources and independently reviewed.

Updated 24 July 2026: Microsoft Marketplace multiparty private offers expanded to Australia, Japan and South Africa on 15 July 2026, taking customer availability to 36 markets. The three-platform comparison table has been updated accordingly.

Updated 6 July 2026: Expanded the list of illustrative Cloud GTM Platform vendors cited for educational guides to include WorkSpan and Invisory, alongside the existing Suger, Clazar, Labra and AppDirect.

© Chris Buckel / flashdba. Part of the Hyperscaler GTM Playbook. If you quote or reproduce this content – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source. Legal information and terms: flashdba.com/about/legal/.