Cloud Marketplace Listings: How to Get Listed 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

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	✓	✓	✓	Customers bringing licences bought outside marketplace
Private Listing	✓	✓	Hidden from search; accessible by URL	Restricted distribution or reduced discoverability
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 usually 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 operationally 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 listings for restricted-distribution products. Common for products with vertical-specific compliance requirements, regional-restriction needs or customer-specific pricing structures. A private listing is 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. Private-offer 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 two years from 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. FTR itself sits downstream of listing, not ahead of it: for this software-validation path, the solution must already be linked to a single software-type AWS Marketplace product, with an approved AWS-hosted architecture documented by a diagram uploaded to the Marketplace portal and completed PRM onboarding, before an FTR request can be submitted.

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 program 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 Technology 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 program 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 where the purchase is eligible (EDP / MACC / Google Cloud Minimum Commitment obligations).

BYOL. Customer brings an existing licence; marketplace doesn’t bill licence fees. 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. 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 supports specified payout currencies, and the rules for determining the seller’s payout currency differ by platform. On AWS, eligible non-USD private offers are disbursed in the offer currency, and India-registered sellers are always disbursed in INR, whatever the pricing currency. On Microsoft, the currency selected in the seller’s payout profile determines the payout currency. Google’s payout conversion is covered below. The currency the customer is billed in is a separate matter from the currency the seller is paid in. Where the payout currency differs from the seller’s reporting currency, this can create an FX exposure for the seller’s finance team to manage – on agreed future amounts as well as cash already received.

Exchange rate sources and timing. USD is the starting point for pricing across the three platforms, with exceptions including AWS non-USD offers and Microsoft’s market-price overrides. Currency conversion rules differ by platform and by the stage of the transaction.

AWS uses Bloomberg daily exchange rates. Where a USD-priced purchase is invoiced in the buyer’s preferred currency, upfront and scheduled invoices use the rate for the invoice date and pay-as-you-go consolidated invoices use the rate on the last day of the month; the rate used is shown on each invoice. AWS pricing is not always in USD, however. AWS Marketplace’s commercial catalogue uses USD for public offers; its European Sovereign Cloud catalogue requires EUR for public offers. Eligible private offers can be created in EUR, GBP, AUD or JPY, with the seller disbursed in the offer currency, and INR private offers are limited to buyers and sellers in India. For non-USD private offers, AWS fixes the exchange rate at acceptance for the contract portion but refreshes it monthly for consumption and pay-as-you-go charges, with the agreed non-USD unit price held constant. A fixed amount in the offer currency can still change in value against the seller’s reporting currency.

Microsoft uses the WM/Refinitiv (WMR) 4pm London closing rate, sourced monthly. The commercially significant implication: public list prices entered in USD are converted into local-currency prices using the applicable monthly WMR rate when first saved in Partner Center. Those local prices remain fixed until the publisher initiates a price change. Accepted private offers retain their agreed market prices for their duration. 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. Payouts carry a second conversion: where the seller’s payout currency differs from the customer’s billing currency, Microsoft converts at the rate for the month of the billing transaction, so the amount received can differ from the price originally set.

Google uses rates published by leading financial institutions, set at the beginning of each month, without specifying a named provider. Google’s conversion applies to seller payouts as well as customer billing: a seller paid in a supported currency other than USD is also subject to the exchange rate active when the usage was measured.

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 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. Microsoft’s AI Cloud Partner Program certified software badge, AWS Specialisations surfaced on listings, Google Cloud partner-tier indicators. Earned, not configurable. Microsoft says the certified software badge helps distinguish high-quality offers in Microsoft Marketplace; the author has not found published Microsoft evidence quantifying its effect on discoverability. Microsoft’s older Preferred Solutions badge does not appear in its current customer-facing badge list.

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-program elements have explicit time limits. AWS FTR is currently valid for two 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 program 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-program review process. Marketplace and partner-program 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 synthesis of recurring patterns across multiple ISVs: a security ISV with $25M ARR launched its first marketplace listing on AWS. 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 built and published through the standard product-type review process – live and transactable by month two. With the listing live, its AWS-hosted architecture approved and PRM onboarding complete, the ISV submitted its first FTR that same month; it failed on three security-control deficiencies. Remediation completed; the second FTR attempt cleared in month three, earning Qualified Software status.

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 request had to wait until the listing and other prerequisites were complete, but the team had not reserved enough engineering capacity for the remediation that followed submission, so it competed with the team’s other commitments. The FTR approval milestone slipped by roughly four weeks against the original plan. The lesson: allow engineering capacity for technical-review preparation alongside listing work, and for any further remediation after submission. The FTR request itself must wait until the listing and other prerequisites are complete.

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, program names and specific numeric values are hyperlinked inline to the relevant source.

AWS

AWS Foundational Technical Review – FTR mechanics, two-year validity period and Qualified Software status (Verified September 2026)
AWS Partner Central Builder Guide – Requesting an FTR – accepted validation documents and the FTR prerequisite gate (linked software-type Marketplace product, approved architecture diagram, PRM enabled) (Verified September 2026)
AWS APN Blog – Updates to the AWS Foundational Technical Review – historical November 2024 announcement; AWS now directs readers to a later update. For current validity and submission requirements, see the FTR program page and Builder Guide (notice checked September 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)
AWS Marketplace buyer guide – paying for products – Bloomberg exchange rates, buyer billing preferences and India-only INR support (Verified September 2026)
AWS Marketplace buyer guide – paying for a private offer with foreign currencies – fixed contract FX, and variable FX for consumption and pay-as-you-go private offers (Verified September 2026)
AWS – Multi-currency support for usage-based private offers – October 2025 expansion of private-offer pricing to EUR, GBP, AUD and JPY with offer-currency disbursements; public offers in USD (Verified September 2026)
AWS Marketplace multi-currency pricing for private offers – supported currencies by pricing model and product type (Verified September 2026)
AWS Marketplace – Managing disbursements – supported payout currencies, banking requirements and offer-currency disbursements (Verified September 2026)
Listing and selling in AWS Marketplace for AWS European Sovereign Cloud – EUR requirement for public offers in the sovereign catalogue (Verified September 2026)
AWS Marketplace – Sellers in India FAQ – INR-only disbursements for India-registered sellers, regardless of pricing currency (Verified September 2026)

Microsoft

Microsoft Learn – Co-sell requirements – Azure IP co-sell eligible status requirements (Verified June 2026)
Microsoft Learn – Solution badges in Microsoft Marketplace – current customer-facing badge list, including the certified software badge (Verified September 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)
Microsoft Learn – Marketplace foreign exchange FAQ – WMR rates, price conversion when plans are saved and payout conversion (Verified September 2026)
Microsoft Learn – Payouts and tax profile FAQ – payout currency set by the payout profile (Verified September 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)
Google Cloud – Currencies available for Cloud Billing – monthly exchange-rate setting from rates published by leading financial institutions (Verified September 2026)
Google Cloud Marketplace – Receiving payments from Google – USD pricing and exchange-rate conversion of customer charges and seller payouts (Verified September 2026)

Last reviewed: 2026-09-28. 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

Updated 28 September 2026: Rewrote the multi-currency passage, including wording added on 6 July 2026. It no longer says that sellers on USD-priced AWS offers receive the full USD amount whatever currency the buyer pays in – India-registered sellers, for example, are paid in INR – and it now sets out which currencies AWS supports for public and private offers, how exchange rates are applied and how the customer’s billing currency differs from the seller’s payout currency. Corrected the Foundational Technical Review validity (two years, not three) and the composite example, which had FTR clearing before the listing went live; AWS accepts an FTR request only for an existing Marketplace product. Clarified that private offers don’t require a private listing and that a BYOL licence stays outside marketplace billing. The listing-optimisation section no longer asserts that badges affect discoverability and names Microsoft’s certified software badge in place of the Preferred Solutions badge. Also made several smaller clarifications. Factual corrections were checked against the cited sources and independently reviewed.

Updated 15 July 2026: Updated Google Cloud Marketplace enrolment step 1 – the general vendor authorisation terminology has moved from “Build partner” to “Technology Partner” on Google’s current documentation. The Kubernetes-specific submission step still refers to “Build partner” approval, since that Google documentation page has not yet migrated to the new terminology; this post reflects both accurately.

Updated 6 July 2026: Corrected the AWS FX-insulation claim – sellers are insulated from FX risk only for USD-priced offers; AWS private offers can now be created directly in EUR, GBP, AUD, JPY or INR, in which case the seller carries the currency exposure. Also trimmed an unsourced timing detail from the Microsoft WMR rate description and fixed a broken External References link.

© 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/.