Cloud Marketplace Listings: How to Get Listed on AWS, Azure and Google Cloud

A marketplace listing is the entry point for every marketplace transaction – and getting one wrong has downstream consequences for co-sell eligibility, pricing flexibility and operational maintenance burden. The choice of listing type, the technical validation required, the ongoing maintenance obligations and the co-sell status implications all vary by hyperscaler and by tenancy archetype. This post covers how to approach listing decisions across AWS, Microsoft and Google Cloud.

TL;DR

A marketplace listing is the catalogue entry that maps to a specific product variant. Each hyperscaler supports several listing types with material differences in technical validation, pricing-model support and operational mechanics.
Listing type is mostly determined by tenancy archetype: SaaS listings for ISV-hosted SaaS products, AMI / VM or container listings for customer-deployed products, sometimes both for hybrid products. The definitive reference is ISV-Hosted vs Customer-Deployed.
Marketplace onboarding requires technical validation on all three platforms, but the mechanics differ. AWS FTR validates eligible software or solutions for partner benefits and Qualified Software status; Microsoft Marketplace requires certification including technical validation before publication; Google Cloud Marketplace uses product-type review steps before a listing goes live.
Listings are not “set and forget.” They expire, drift and become non-compliant when the underlying product changes. Maintenance is a continuous operational discipline, not an annual exercise.
The most common listing failure modes recur across platforms. Avoiding them is mostly a matter of operational discipline: choose the right listing type for the tenancy archetype, complete the required product-type review before launch, maintain listing metadata and earn co-sell eligibility where applicable.

Listing Types Across the Three Hyperscalers

Not all listing types are created equal. The choice between SaaS, AMI / VM and container listings has direct consequences for co-sell eligibility, pricing-model support and ongoing maintenance overhead – and it is mostly determined by tenancy archetype. The comparison:

Listing type	AWS	Microsoft	Google Cloud	Best for
SaaS	✓	✓	✓	ISV-hosted SaaS products
AMI / VM	AMI	VM	VM	Customer-deployed VM-based products
Container	✓	✓	✓ (incl. Kubernetes Apps)	Containerised customer-deployed products
Free Trial	✓	✓ (selected offer types)	Selected VM and Kubernetes pricing models	Trial-to-paid conversion motions
BYOL	✓	✓	✓	Existing-customer migration to marketplace billing
Private Listing	✓	✓	✓	Restricted-distribution products and private-offer vehicles
Professional Services	✓	Professional Service	Professional Services	Implementation / managed-services packaged with ISV products
Platform-specific types	–	Managed Service, Power BI App, IoT Edge Modules (certification policies)	Kubernetes Apps, VM, container image, dataset and AI agent products	Specialised use cases per platform

The core three types (SaaS, AMI / VM, Container) cover almost all ISV product motions. The peripheral types (BYOL, Private Listing, Free Trial) are useful overlays on the core types rather than standalone listings in most cases. The platform-specific types serve narrow use cases and tend to be irrelevant to most ISVs.

The naming-convention reminder: “Microsoft Marketplace” is the unified name post-September 2025 (replacing the former Azure Marketplace and AppSource). VM and Container listings are the historical Azure Marketplace types; Power BI App was originally an AppSource type; everything sits under the unified Microsoft Marketplace surface today. IoT Edge Modules are referenced in Microsoft Marketplace certification policies.

Choosing the Right Listing Type for Your Product

The listing-type decision is mostly determined by product tenancy. Three rules of thumb that resolve the question for most ISVs:

Rule 1: Tenancy archetype decides the primary listing type. ISV-hosted SaaS products use SaaS listings. Customer-deployed products use AMI / VM or container listings. Hybrid products with separate SaaS-mode and self-deployed-mode variants may need separate listings for each variant. The definitive reference for tenancy-archetype implications is ISV-Hosted vs Customer-Deployed.

Rule 2: Container over AMI / VM where the customer’s infrastructure is containerised. Customer-deployed products historically used AMI on AWS and VM on Azure / Google Cloud. As customer infrastructure has shifted toward containerised deployment (Kubernetes, ECS, AKS, GKE), the container listing type has become in practice preferable in most new deployments. The legacy AMI / VM listings still exist for customers running on older infrastructure but most new listings should be container-first.

Rule 3: Understand BYOL’s scope before using it. BYOL is commonly used when customers already buy licences directly from the publisher or where software licensing remains outside the marketplace transaction – for example, in on-premises-to-cloud migration scenarios. For new customer acquisition where commit-drawdown and co-sell credit are the goals, BYOL bypasses the pricing and transaction mechanics that make marketplace useful. Verify each platform’s current BYOL rules before positioning it as a default route.

A third scenario exists in practice that the best-practice framing doesn’t fully account for: BYOL as a retrofit when an ISV AE and/or customer have committed to a direct deal, bypassing marketplace. In this situation BYOL is not a listing-type choice but a damage-limitation mechanism – the alliance team recovering partial marketplace credit and co-sell attribution from a deal that was never going to be a clean marketplace transaction. Not ideal, but better than no marketplace participation at all. The Marketplace Deal Routing and Comp Design section below addresses the structural reason this happens.

A handful of edge cases:

Hybrid products with separate listings. A product with a SaaS-mode variant and a customer-deployed variant typically needs both a SaaS listing and an AMI / VM or container listing. Customer-facing positioning should make clear which is which; otherwise marketplace customers buy the wrong variant.
Free Trial overlays on SaaS listings. Useful where the product has a measurable trial-to-paid conversion pattern. Less useful for enterprise products with consultative sales motions.
Private offers for restricted-distribution products. Common for products with vertical-specific compliance requirements, regional-restriction needs or customer-specific pricing structures. Each platform’s private-offer mechanism supports different product types; use the platform-specific terminology (AWS Private Offers, Microsoft Private Offers or private plans, Google Cloud Marketplace Private Offers) when referencing the mechanism. The relevant mechanics are covered in Private Offers.

AWS Marketplace Listing Process

The AWS Marketplace listing process follows a defined sequence:

Partner Path enrolment. The ISV joins the AWS Partner Network under the Software Path (or relevant alternative). Detailed Partner Network mechanics are in Cloud Partner Programs and Specialisations.
Marketplace seller registration. The ISV registers as an AWS Marketplace seller and provides the required tax and banking information for paid or BYOL products. Sellers manage Marketplace products in AWS Marketplace Management Portal; Partner Central is used for partner solution and FTR workflows.
Product creation. The ISV creates the product listing in AWS Marketplace Management Portal, including title, description, pricing model, supported regions and the technical artefact (AMI ID for AMI listings, container image for container listings, SaaS endpoint for SaaS listings).
Product-type integration and review. The ISV completes the integration and testing steps for the relevant product type. AWS Marketplace Seller Operations reviews the product before public visibility is enabled.
Publish. After the product-type review, the listing publishes to AWS Marketplace and becomes transactable.

FTR is AWS’s self-service validation of eligible software or solutions against selected AWS Well-Architected best practices for security, reliability and operational excellence. An approved FTR earns a Qualified Software badge and supports AWS Partner benefits. Applying for FTR is done through Partner Central; AWS documentation states that partners can receive approval in as little as 30 minutes when the submission meets requirements, though in practice preparation time varies considerably by product maturity.

Partners report that first-attempt submissions often require remediation before approval, and that the process is more demanding for products with architectural debt or incomplete operational controls. The feedback from AWS is actionable; treat remediation as an expected part of the workflow rather than a delay.

FTR remediation typically relates to AWS Well-Architected risk areas, particularly security, reliability and operational excellence. Use the current FTR Guide and validation checklist in Partner Central to identify the specific controls required for your solution.

Partners report that preparation for a first FTR pass can take several weeks of engineering and SE time depending on how well the product already aligns with AWS Well-Architected best practices.

FTR is valid for three years from the date of approval. Partners must submit renewal requests before the due date to maintain Validated stage. A lapsed FTR can affect FTR-linked AWS Partner benefits such as Qualified Software status and related co-sell visibility; marketplace transactability should be checked against the applicable product-type requirements.

Microsoft Marketplace Listing Process

The Microsoft Marketplace listing process runs through Partner Center:

Microsoft Marketplace enrolment. Publishers create and manage offers in Partner Center after enrolling in Microsoft Marketplace and setting up the required seller, payout and tax profiles. Certification may include checks against relevant Microsoft AI Cloud Partner Program eligibility criteria.
Offer creation. The ISV creates an offer in Partner Center, choosing the relevant offer type – Software as a Service, Azure Virtual Machine, Azure Application, Azure Container, Professional Service, Managed Service, Power BI App, Microsoft 365, and others – plus publishing details, pricing model and target audience.
Certification. Microsoft runs certification checks on the offer, including automated validation, content validation, technical validation and policy checks.
Preview and publish. Once certification is complete, Microsoft creates a preview. The publisher reviews the preview, selects Go Live and Microsoft completes final validation before the offer becomes live in Microsoft Marketplace.

The Azure Well-Architected Framework is organised around five pillars: Reliability, Security, Cost Optimisation, Operational Excellence and Performance Efficiency. The terminology is worth being precise about: the Azure Well-Architected Framework is the body of architectural guidance; the Azure Well-Architected Review is the structured assessment that scores a specific workload against it.

For Azure IP Co-Sell Eligible status – the prerequisite for MACC drawdown and the meaningful enterprise co-sell mechanics covered in Microsoft Co-Sell – the current requirements include co-sell-ready status, the required revenue threshold (verify in Partner Center for current terms), Microsoft technical validation for an Azure-based solution, reference architecture documentation where required and marketplace transactability for new offers.

Partners report that preparing for a first Microsoft technical validation typically takes several weeks of engineering and SE time per workload, though this varies by product maturity. It is understood that Microsoft’s validation process is more workshop-driven than AWS’s FTR, which tends to concentrate engineering effort into a shorter calendar window. Practitioners familiar with the programme note that common remediation areas include reliability, operational excellence and cost-optimisation gaps. Re-validation is typically triggered by material product changes rather than a fixed calendar cycle.

Google Cloud Marketplace Listing Process

The Google Cloud Marketplace listing process runs through Google Cloud’s Producer Portal:

Google Cloud Partner Network enrolment. The organisation must join Partner Network, access Partner Network Hub and complete the process of becoming authorised as a Build partner before onboarding products to Google Cloud Marketplace.
Product creation. The ISV creates the product listing in Producer Portal, including title, description, pricing model, supported regions and the technical artefact.
Product-type review. Google Cloud Marketplace uses product-type review steps that vary by listing type – for SaaS, these include product details, pricing and technical integration reviews; for Kubernetes products, container-image review and Build partner approval; for VM products, component reviews and vulnerability scanning. Architecture diagrams or business inputs may be requested during vendor onboarding to verify that the organisation and product meet listing requirements.
Publish. Once the applicable product reviews are complete and vendor or Build partner requirements are satisfied, the partner publishes the product through Producer Portal.

Google Cloud Marketplace product reviews vary by product type and can include product details, pricing, technical integration, container-image tests, deployment package review and vulnerability scanning. Architecture diagrams or business inputs may be requested to verify listing requirements. Partners report that the review process can be demanding, particularly for Kubernetes and VM products; it is understood that the Google Cloud team takes an active role in validating integration quality. Practitioners familiar with the programme note that feedback is technical and actionable where remediation is required.

When Google Cloud Marketplace product information changes after submission, the partner may need to acknowledge the change and resubmit the affected product-type review for approval.

Pricing Models Supported

All three platforms support a range of pricing models, with some differences in support depth:

Flat-rate subscription. Monthly or annual flat-fee pricing. Supported by all three platforms across SaaS and (for some configurations) VM-based listings. The simplest pricing model and the most common starting point for ISVs new to marketplace.

Usage-based / metered. Per-unit pricing where the ISV reports consumption to the marketplace metering API on a defined rhythm. Supported by all three platforms for SaaS listings. More demanding in practice than flat-rate because the metering integration has to be built and maintained; commercially more flexible because it aligns customer cost with customer value.

Tiered. Pricing that varies by usage tier (different rates for different volume bands) or feature tier (different prices for different product editions). Supported across all three platforms with platform-specific configuration patterns.

Contract / commit. Customer commits to a fixed annual or multi-year amount at a discounted rate. The mechanism most enterprise customers prefer because it aligns with their procurement cycle and integrates cleanly with committed-cloud-spend drawdown (EDP / MACC / CUD).

BYOL. Customer brings an existing licence; marketplace doesn’t bill licence fees but the customer’s underlying cloud consumption still runs through marketplace billing. The narrow use case covered in the listing-type decision section above.

The pricing-model choice interacts with the technical-validation choice. A product offering usage-based pricing has to provide metering integration; a product offering tiered pricing has to provide tier-distinct deployment artefacts. The configuration work compounds with the technical-review work and adds material engineering time beyond the validation itself.

Multi-Currency, Multi-Region and Tax

Each marketplace handles some elements of multi-currency and tax for the seller, with material variations in what’s covered:

Settlement currency. Each marketplace pays the seller in defined settlement currencies, typically USD by default with regional alternatives available. The seller’s billing currency to the end customer may differ from the settlement currency, which produces FX exposure that the seller’s finance team has to manage.

Exchange rate sources and timing. All three platforms price in USD as the base currency and convert for local billing, but the rate source and timing differ in ways that matter operationally.

AWS uses Bloomberg market rates. For upfront and scheduled invoices the rate is the Bloomberg rate at invoice creation; for pay-as-you-go consolidated invoices it is the rate on the last day of the month. The rate used is shown on each invoice. Sellers are fully insulated from FX risk: regardless of the currency the customer pays in, the seller receives the full original USD amount.

Microsoft uses the WM/Refinitiv (WMR) London spot closing rate at 4pm, taken three business days before the end of the previous month, sourced monthly. The commercially significant implication: local currency list prices entered in USD are converted at the WMR rate at the time the plan is saved in Partner Center and locked at that rate until the publisher actively updates them. A publisher’s GBP or EUR list price can silently diverge from the intended USD equivalent as exchange rates move, with no automatic correction. Multi-year or long-standing marketplace plans are particularly exposed. A periodic list-price review should be part of the standard marketplace maintenance rhythm.

Google uses rates published by leading financial institutions, set at the beginning of each month, without specifying a named provider. Unlike AWS, Google’s FX conversion applies to seller payouts as well as customer billing – a seller receiving disbursements in a non-USD currency is also subject to the month’s rate.

Customer billing currency. Marketplaces bill customers in the customer’s local currency (or the currency of the customer’s existing cloud invoice). The breadth of supported customer currencies varies by platform; all three cover the major economies plus a long tail of regional currencies.

Tax handling. Each marketplace handles a portion of customer-side tax obligations – typically VAT in EU jurisdictions, GST in some Asia-Pacific jurisdictions, US sales tax in some states. The coverage varies significantly by jurisdiction; the seller’s finance team needs to map which jurisdictions are marketplace-handled and which require seller-side tax registration and filing.

Where it gets messy: UK VAT (post-Brexit complications), EU VAT (different rules for B2B vs B2C, MOSS / OSS models), India GST (distinctive in practice registration requirements), multi-currency settlement when the customer’s local currency differs from the seller’s settlement currency.

A pragmatic operational discipline: maintain a per-marketplace tax-coverage matrix that maps each jurisdiction to “marketplace handles” / “seller handles” / “shared”. Update the matrix when marketplace policies change (which happens annually) or when entering new jurisdictions. The detailed tax mechanics are out of scope for this post; see Cloud Marketplace Operations for the broader finance-and-tax treatment.

Listing Optimisation for Discovery

A live listing is necessary but not sufficient. Listing-level discoverability matters for customers who search the marketplace rather than arriving through co-sell, and the optimisation discipline has measurable impact on transaction volume.

Title. Clear, customer-language naming. Avoid product-internal acronyms. Include the workload or use-case category where it doesn’t compromise readability.

Summary. Two-to-three-sentence value proposition. The first sentence is what shows in search-result cards across all three marketplaces; the second and third support deeper consideration. Customer-language outcomes, not engineering-language features.

Keywords and categorisation. Each marketplace has a categorisation taxonomy. Correct categorisation affects discoverability through both browse and search. Re-categorise when the marketplace taxonomy changes (which happens periodically).

Badges. Preferred Solutions (Microsoft), AWS Specialisations surfaced on listings, Google Cloud partner-tier indicators. Earned, not configurable; but the badges significantly affect discoverability for the subset of customers who use them as quality filters.

Listing optimisation tooling. Microsoft has introduced App Advisor as a self-service guidance experience for building, publishing and growing Microsoft Marketplace offers. It includes AI-powered listing optimisation, a listing quality score and recommendations across value proposition, content clarity and visual assets. Partners report that the suggestions are typically directionally useful. At the time of this post’s last review, AWS and Google Cloud had not introduced comparable tooling. Where the tooling exists, use it.

The single most common listing-optimisation failure is treating the listing as a one-time creation rather than as a continuously maintained asset. Suger’s practitioner guides catalogue the “9 common listing mistakes” – the patterns include stale metadata, mismatched categorisation, single-language listings in multi-language markets and inadequate visual assets. Worth reading alongside this post.

Maintenance Burden

Listings drift. Three failure modes:

Expiry. Some marketplace and partner-programme elements have explicit time limits. AWS FTR is currently valid for three years from approval; pricing promotions and product-type documentation should be checked against each platform’s current Marketplace requirements for their applicable validity periods. Lapsed or outdated programme validations can affect partner benefits, listing eligibility or publication workflows depending on the platform and product type. Expired promotions should be removed or updated so customers see accurate transaction options.

Drift from the product. Listings document the product as it was at listing creation. Product features added in the trailing 12 months don’t appear in the marketplace catalogue; deprecated features that customers stopped using still appear; pricing changes implemented by the ISV’s sales team don’t appear in marketplace pricing options. The result is a discovery surface that increasingly misrepresents the product.

Non-compliance from program changes. Marketplace policies change. Listings that complied when published can fall out of compliance when the marketplace updates a rule (e.g., new requirements for accessibility metadata, security disclosure formats, regional restrictions). The marketplace may flag non-compliance and de-list the offer if not remediated.

The organisational reason listings go stale deserves naming directly. Listing maintenance typically sits across multiple functions: Sales Ops and Finance own the commercial mechanics; Engineering owns the technical artefacts; Marketing owns the content. The Alliance team, despite being closest to co-sell activity, often has minimal operational involvement in the listing itself. Changes that make listings out of date – product positioning pivots, GTM redirections, feature deprecations, decisions to stop targeting a specific vertical – happen in product and marketing conversations that none of the listing’s nominal owners are necessarily in. There is no natural mechanism for a decision made in a product strategy meeting to propagate to a marketplace listing unless someone explicitly owns that propagation. Without a named owner who sits across product, marketing and the listing surface, drift is the default outcome.

The operational discipline: event-triggered review whenever the product, pricing or a marketplace policy changes, with a quarterly listing-review rhythm as the backstop for catching what slips through. Review the metadata against current product capabilities, the pricing against current ISV pricing structures, the technical validation status against current marketplace requirements, the compliance status against current marketplace policies. Most updates are minor; the cumulative effect of not doing them is listing decay.

Marketplace Deal Routing and Comp Design

When marketplace routing is bypassed in favour of a direct transaction, BYOL typically becomes the alliance team’s damage-limitation tool: marketplace participation is retrofitted after the commercial decision has been made, recovering partial co-sell credit and commit-drawdown attribution but bypassing the pricing and transaction mechanics that make marketplace genuinely useful. The pattern is common enough to deserve naming – and the fix is not primarily an alliance-team process problem.

An ISV AE whose commission is calculated on revenue net of marketplace fees has a structural incentive to route deals direct; alliance-team involvement at any stage of the sales cycle doesn’t change that incentive. Compounding this, the ISV AE typically has the customer relationship leverage to make bypass happen explicitly: telling the economic buyer or procurement contact that they can save 3% by purchasing direct rather than through marketplace is sufficient for the customer to request it, at which point the bypass presents as customer-initiated and becomes practically unavoidable. The alliance team then has no leverage to insist on marketplace routing without overriding what appears to be a customer preference – a position that is both uncomfortable and rarely tenable in a live sales cycle.

The floor is comp neutrality: the ISV AE’s net commission should be the same whether the deal routes through marketplace or direct, with the marketplace fee absorbed elsewhere in the P&L rather than deducted from commission. This removes the disincentive but does not create a positive incentive.

The stronger approach is to acknowledge in the comp plan itself that marketplace volume is strategically valuable – in terms of hyperscaler tier progression, rebate structures, co-sell mechanics and committed-spend drawdown – and to price that into individual incentives. The practical mechanism is a modest reduction applied to non-marketplace transactions rather than a bonus for marketplace ones: this frames marketplace as the expected channel and direct as the exception that carries a cost. Applied consistently across all GTM comp, not just ISV AEs. The comp complexity is manageable at this level of simplicity; the harder internal conversation is typically getting Finance and Sales leadership to agree that the marketplace fee is a cost of sale rather than a deduction from commission.

Common Pitfalls

Patterns that recur in marketplace listing motions:

Wrong listing type for the tenancy archetype. Using an AMI listing for a SaaS product, or a SaaS listing for a customer-deployed product. Often visible only when customer purchasing patterns reveal the mismatch. The definitive reference for tenancy-archetype mapping is ISV-Hosted vs Customer-Deployed.
Underestimating the marketplace and partner-programme review process. Marketplace and partner-programme reviews across all three platforms can require remediation. Treat review feedback as an expected part of the publishing workflow and plan engineering capacity to address issues and resubmit where required. The pitfall is treating remediation as a delay rather than a planned phase.
Missing IP co-sell eligibility because the listing isn’t transactable. Particularly on Microsoft: Co-Sell Ready is the lower bar; Azure IP Co-Sell Eligible requires a transactable marketplace offer with the right technical-validation status. ISVs that stop at Co-Sell Ready and assume IP Co-Sell follows automatically are systematically under-serving enterprise pipeline.
Never updating the listing. Listings drift. Quarterly review rhythm is the operational minimum.
Treating the listing as a marketing asset rather than a transaction enabler. Listings serve discovery, but their primary commercial purpose is enabling transactions. ISVs that optimise listing copy without optimising transactability are putting effort in the wrong place.
Skipping container listings for newer deployments. Customer infrastructure has shifted toward containerised deployment; ISVs still building AMI / VM listings for new products are sometimes choosing the legacy option without realising it.
Listing pricing structures that don’t match ISV sales reality. If the ISV’s direct sales team sells custom pricing tiers and contract durations but the marketplace listing only supports flat-rate monthly subscription, the marketplace closing mechanic breaks. Listing pricing must align with sales pricing.
Marketplace bypass through direct-deal routing. When an ISV AE routes a deal direct rather than through marketplace, BYOL becomes the alliance team’s damage-limitation tool – marketplace participation retrofitted after the commercial decision has been made. The structural fix is comp design, not pipeline visibility; see the section above.

What This Looks Like in Practice

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

A security ISV with $25M ARR launched its first marketplace listing on AWS in 2024. The listing was a SaaS listing for the product’s cloud-hosted variant, with flat-rate monthly subscription pricing.

Months 1–3: First listing. Partner Network enrolment, marketplace seller account creation, SaaS listing in flight. First FTR attempt failed at month two on three security-control deficiencies. Remediation completed; second FTR attempt cleared in month three. Listing live and transactable.

Months 4–6: First transactions and pricing-model adjustment. First public-listing transactions in month four. Customer feedback revealed that enterprise prospects wanted tiered pricing and contract / commit options. Listing pricing structure rebuilt to support tiered subscription plus contract pricing; first private-offer transaction in month five drawing against AWS EDP commit.

Months 7–12: Microsoft and Google additions. Microsoft Marketplace listing built under the post-September-2025 unified Microsoft Marketplace, with Azure IP Co-Sell Eligible status earned in month ten. Google Cloud Marketplace listing built under the current Partner Network structure, with product-type reviews completed and the listing published in month eleven. By month twelve: three live transactable listings on three platforms, each tested with at least one closed marketplace transaction.

The diagnostic insight from the build: the FTR cycle and the listing-creation cycle ran in parallel, not in sequence. Engineering capacity needed for FTR remediation was simultaneously needed for the listing artefact preparation. The ISV underestimated this dual demand on its engineering team and the timeline slipped by roughly four weeks against the original plan. The lesson: budget engineering time for listing creation and technical validation as separate concurrent workloads, not as sequential phases.

Where to Go Next

Within this pillar:

Private Offers – the transaction mechanics that close marketplace pipeline.
Cloud Marketplace Operations – the back-office stack that supports listings at scale: metering, billing reconciliation, finance and CRM sync.
Cloud Marketplace – the broader pillar this post sits under.

Adjacent:

ISV-Hosted vs Customer-Deployed – the tenancy-archetype dynamic that drives listing-type choice.
Cloud Partner Programs and Specialisations – the program structures gating marketplace eligibility.

The full series glossary is at Glossary.

External References

Vendor Primary Sources

AWS Marketplace seller documentation – the AWS-side listing-creation process.
Microsoft Learn – Commercial Marketplace – the Microsoft-side listing-creation process including the post-September-2025 unified Microsoft Marketplace.
Google Cloud Marketplace producer documentation – the Google-side listing-creation process via Producer Portal.

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. Practitioner introduction to marketplace mechanics. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.
Suger – practitioner guides on marketplace listing creation, optimisation and the “9 common listing mistakes” pattern. Suger is a Cloud GTM tooling vendor; the guides are informative but published from a commercially interested vantage.

Sources

The following primary sources were used to verify specific factual claims in this post. Claims relating to fee rates, eligibility thresholds, programme names and specific numeric values are hyperlinked inline to the relevant source.

AWS

AWS Foundational Technical Review – FTR mechanics, validity period and Qualified Software status (Verified June 2026)
AWS APN Blog – Updates to the AWS Foundational Technical Review – three-year renewal period and automated review mechanics (Verified June 2026)
AWS Marketplace seller guide – seller registration and AWS Marketplace Management Portal (Verified June 2026)
AWS Marketplace – SaaS product creation – SaaS product creation and launch process (Verified June 2026)

Microsoft

Microsoft Learn – Co-sell requirements – Azure IP co-sell eligible status requirements (Verified June 2026)
Microsoft Learn – Review and publish an offer – Marketplace certification and publish workflow (Verified June 2026)
Microsoft Learn – Publisher guide by offer type – current Microsoft offer types (Verified June 2026)
Microsoft Learn – Azure Well-Architected Framework – five-pillar structure and review tools (Verified June 2026)
Microsoft Community Hub – App Advisor – App Advisor features and listing optimisation (Verified June 2026)
Microsoft Community Hub – Microsoft Marketplace unification – 25 September 2025 unification of Azure Marketplace and AppSource (Verified June 2026)

Google Cloud

Google Cloud Marketplace – Offer products overview – Google onboarding and product-type review process (Verified June 2026)
Google Cloud Marketplace – Integrated SaaS submission – SaaS product review and resubmission mechanics (Verified June 2026)
Google Cloud Marketplace – Kubernetes product submission – Kubernetes container-image review and Build partner approval (Verified June 2026)
Google Cloud Marketplace – VM product submission – VM component review and vulnerability scanning (Verified June 2026)

Last reviewed: 2026-07-01. Vendor-specific clusters in this series are reviewed twice yearly after the major hyperscaler conferences plus mid-cycle for major program or marketplace changes. Major changes between reviews are flagged in the Updates section below.

Updates

(No updates yet. This section will record dated corrections, program changes between reviews and community-contributed clarifications as they arrive.)

© 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. Full disclosure and terms: flashdba.com/about/legal/.