What co-sell means inside the platform
Partner teams use the word co-sell loosely. Finance teams use it precisely, and the precise version is the one that determines whether a partnership produces revenue. Inside AWS, Microsoft, and Google, a co-sell is a transaction with a specific shape: your software is sold alongside cloud consumption, the platform's field seller gets credit for it, and the money moves through the platform's own billing system onto an account the customer already has. The badge, the solution brief, and the joint webinar are marketing wrapped around that transaction. A firm evaluating a public-sector partner program is really asking two questions in sequence. Can we clear the listing gate? And once we are listed, does anything happen?
AWS draws the distinction cleanly in its own tooling. In ACE, the AWS Partner Central customer engagement system, a partner shares an opportunity as either a referral or a co-sell. A referral hands the customer to AWS. A co-sell means the partner and AWS work the account together. Microsoft draws the same line differently, through co-sell statuses attached to the offer rather than the opportunity: an offer is in market, co-sell ready, or Azure IP co-sell eligible, and each status changes what Microsoft's sellers can do with it. Google works through Marketplace listing and partner standing. Three vocabularies, one underlying question — is there a live, sellable unit that a platform seller can attach to a deal.
That unit is almost always a private offer: negotiated pricing, published to a named customer, transacted through the marketplace, billed on the customer's existing cloud account. If your product cannot be transacted that way, the co-sell conversation has nowhere to land, and the field seller who liked your demo has no mechanism to help you.
The one number that predicts the relationship
Platform field sellers are compensated on cloud consumption. Your product is interesting to them roughly in proportion to how much of the platform's own meter it turns. A model-serving product that pulls a hundred thousand dollars a year of GPU, storage, and network behind each deployment is a different asset to that seller than a lightweight SaaS tool running on your own infrastructure and billed as a flat license.
This is not cynicism, it is the design of the system, and it explains most of the disappointment small firms report about partner programs. The partner badge is not the product. The transactable listing is the product, and the consumption your software pulls behind it is the price of the field seller's attention. Firms that walk into the first partner-manager call with that number ready — measured, not estimated — get a different meeting than firms that walk in with a capability deck.
What actually moves a hyperscaler co-sell toward a closed deal
Our ranking of the levers by how much each one moves a closed transaction, read off published program mechanics and how platform seller incentives are structured. Editorial weighting, illustrative, not a measured statistic.
Read the bars as a ranking, not as probabilities. Consumption sits at the top because it is what the platform's compensation system rewards. Transactability sits second because a deal a seller cannot book is a deal that does not exist. Badges and directory placement sit last because they change discovery, not close rate, and a firm that spends its first year chasing designations instead of its first transacted private offer usually has nothing to show for the year.
The listing gate, program by program
The three programs publish their requirements at different levels of detail, and the differences are worth knowing before you pick where to start. What follows is drawn from current vendor documentation rather than from partner-manager conversations, because the documented requirements are the ones that get enforced.
| Dimension | AWS | Microsoft | Google Cloud |
|---|---|---|---|
| How you enter | AWS Partner Paths: Software, Hardware, Services, Training, Distribution. Software vendors qualify through the Software Path. | Microsoft AI Cloud Partner Program. Co-sell status attaches to the offer: in market, co-sell ready, or Azure IP co-sell eligible. | Membership in good standing in Google's cloud partner network, plus a Marketplace vendor account and payment profile in good standing. |
| Technical gate | Foundational Technical Review. Free, self-service, checks security, reliability and operational excellence against Well-Architected practice; accepts a SOC 2 Type II report or a Well-Architected Framework Review. Valid two years. | Microsoft technical validation. The offer must be actively platformed on Azure at the time of the transaction, and a reference architecture diagram is required for SaaS offers. | Product must be production-ready rather than alpha or beta, free of known vulnerabilities, and primarily hosted on Google Cloud following one of nine approved architectural patterns. |
| Traction bar for the co-sell tier | ISV Accelerate: Validated or Differentiated status, five launched opportunities and fifteen qualified ACE opportunities in the trailing twelve months, and $2,000 of recognized AWS account revenue at enrollment. | Azure IP co-sell eligible: $100,000 of Azure Consumed Revenue or Marketplace Billed Sales at the organization level over the trailing twelve months. Azure credits do not count toward it. | Not published as a numeric threshold in the public seller documentation. Confirm with the partner team. |
| Opportunity system | ACE, which separates referrals from co-sells and tracks the launched-versus-qualified counts the ISV Accelerate bar is measured against. | Partner Center co-sell, covering co-sell with Microsoft sellers, partner-to-partner, private deal registration, and solution assessments. | Partner-managed. Confirm the current opportunity-registration path in writing. |
| What the top tier buys | Placement in AWS seller-facing libraries and partner recommendation engines, private-offer promotion incentives, and workload migration credits. | Marketplace sales count toward the customer's Azure consumption commitment, and the offer carries a Microsoft preferred solutions badge. | Marketplace transactability and listing placement. |
| Product feature parity | Not stated as a distinct listing condition. | Offer must be transactable on the marketplace for new offers seeking IP co-sell status. | Listed products must carry the same capabilities and features as versions sold outside the Marketplace. |
Two things stand out when the requirements are laid side by side. The first is that AWS gates on activity and Microsoft gates on revenue. AWS wants to see five launched and fifteen qualified opportunities in a year, which a firm can produce by working its own pipeline through the platform's system. Microsoft wants to see a hundred thousand dollars of consumed Azure revenue or marketplace billed sales, which a firm cannot produce by paperwork. Neither bar is an ambition bar. Both are proof-of-traction bars, designed to accelerate a motion that already exists rather than to create one.
The second is that Google publishes less. Its seller requirements are clear about product readiness, hosting architecture, and account standing, and quiet about thresholds and commercial treatment. That is not a reason to skip Google; it is a reason to get the commercial terms in writing rather than inferring them from what Microsoft publishes.
What the marketplace takes
Marketplace fees are published, they are not negotiable at small scale, and they vary enough by deployment model to change how you package a product. The AWS schedule has been in effect since January 2024 and is tiered by deal size. Microsoft charges a flat store service fee.
| Transaction shape | AWS Marketplace listing fee | Microsoft Marketplace |
|---|---|---|
| Public SaaS listing | 3% | 3% store service fee |
| Public server listing (AMI, container, machine learning) | 20% | 3% store service fee |
| Private offer, total contract value under $1M | 3% | 3% store service fee |
| Private offer, $1M to under $10M | 2% | 3% store service fee |
| Private offer, $10M or more, and all renewals | 1.5% | 3%, with a 50% discount available on private-offer customer renewals |
| Sold through a channel partner, and professional services | 0.5% uplift on the listing fee for channel partner private offers; 0.5% on professional-services private offers | Professional services transact through private offers only |
The seventeen-point gap between SaaS and server listings
On AWS, a public SaaS listing carries a 3% listing fee and a public server listing — machine image, container, or machine learning product — carries 20%. For a model-serving product that could ship either way, that gap is the largest commercial consequence of a packaging choice most engineering teams make on technical grounds alone. Private offers, which is how nearly all government business transacts, price at 3% or less regardless of deployment model, which is another reason the private-offer path matters more than the public storefront.
Consumption commitment is the real procurement lever
Here is the mechanic that makes a marketplace listing worth the fee, and it is the strongest argument a hyperscaler partnership hands a vendor in a government sale.
Large agencies frequently sign a committed-spend agreement with a cloud provider. Microsoft calls its version the Azure Consumption Commitment. When a customer buys an Azure benefit eligible partner offer through the marketplace, 100% of the pretax purchase amount counts toward fulfilling that commitment. The practical translation is direct: your software stops being a new budget line the customer has to find money for and becomes a use of money the customer has already promised to spend. That reframing wins deals that a feature comparison would not.
The conditions are narrow and worth reading carefully. Azure IP co-sell eligible status is a prerequisite for an offer's commitment eligibility, which means the $100,000 trailing-revenue bar sits upstream of the benefit. The purchase has to be made through the marketplace inside the Azure portal on a subscription tied to the customer's agreement; a credit-card purchase on the marketplace storefront does not count. Purchases made with Azure prepayment are excluded. And the benefit applies only to licenses used exclusively in Azure, so a hybrid or on-premises deployment of the same product is out of scope.
Microsoft documents this treatment in detail. Google's public seller documentation does not set out equivalent commitment-drawdown terms, and AWS publishes its fee schedule rather than a drawdown rule. If drawdown is part of the business case you are taking to a customer, confirm the treatment in writing with the platform's team for that specific agreement before you put it in a proposal. This is one of the places where partner-manager enthusiasm and contract language diverge.
Government changes the boundary, not the motion
The co-sell mechanics above are the same in a federal deal as in a commercial one. What changes is which cloud the deal runs in, and what that cloud's authorization does and does not do for you.
Start with the fact that trips up most first-time public-sector vendors: a hyperscaler's authorization does not cover your software. Running inside an authorized region gives you inherited infrastructure controls and a shorter control-implementation story. It does not give you an authorization. Your product still needs its own path, whether that is an agency authorization to operate, a FedRAMP package of its own, or coverage under a customer's existing boundary.
The published positions differ by platform and by region. AWS describes AWS GovCloud (US) at the level formerly known as the FedRAMP High baseline and its US East and US West commercial regions at the level formerly known as Moderate, both through the FedRAMP Program Management Office. Microsoft describes both Azure commercial and Azure Government as holding FedRAMP High provisional authorizations from the Joint Authorization Board, alongside several hundred agency authorizations, with the Azure Government scope covering the US Gov Arizona, US Gov Texas, and US Gov Virginia regions. Azure Government adds a control that matters for some workloads: potential access to systems processing customer data is limited to screened US persons.
For Defense work, the Cloud Computing SRG impact levels are the governing frame, and the mapping is narrower than most vendors expect. AWS states that GovCloud (US) carries provisional authorization at Impact Levels 2, 4, and 5, that its US East and US West regions carry Impact Level 2, and that the AWS Secret Region carries Impact Level 6. A product intended for IL5 workloads therefore has a region decision baked into its architecture, not bolted on later.
The FedRAMP vocabulary is mid-transition, and that is a real problem for proposals
This is genuinely in flux right now, and pretending otherwise on a capability page would be a disservice. FedRAMP 20x, announced publicly in March 2025 following OMB Memorandum M-24-15, is replacing the Low, Moderate, and High baseline vocabulary with certification classes. Class A covers mature services entering the federal marketplace, Class B maps to the former Low baseline, Class C to Moderate, and Class D to High. The Low pilot completed in September 2025 and the Moderate pilot completed in March 2026. Class D is later in the rollout sequence. As of August 2026 the FedRAMP marketplace lists 528 certified cloud services, of which 28 carry FedRAMP 20x certification.
The practical consequence for a vendor writing proposals: the two vocabularies are both live in the market at once. AWS's compliance page already describes GovCloud in class terms with the former baseline in parentheses. Microsoft's Azure compliance documentation still speaks in P-ATO and High baseline terms. Both are accurate descriptions of the same underlying authorizations. When you write an authorization inheritance section, name the platform's stated position and the date you read it, and say which vocabulary you are using. Evaluators read a lot of proposals that assert an authorization level with no source and no date, and precision here is cheap credibility.
Government buyers usually cannot buy from you directly
A commercial co-sell often ends with a customer clicking through a private offer on a corporate card or an enterprise agreement. A government co-sell rarely does. The buyer needs a contract vehicle, a purchase order, and frequently a reseller who already holds the paper.
Both major marketplaces accommodate this, and the mechanism has a name on the AWS side: the channel partner private offer. The vendor authorizes a reseller to create and manage private offers on its behalf, the reseller negotiates with the end customer, and the transaction still runs through the marketplace so it retains the commercial treatment a direct offer would have. The fee structure reflects it, with a 0.5% uplift on the listing fee for channel partner private offers, calculated on the discounted price the vendor extends to the channel partner rather than the end price.
If a public-sector reseller relationship is part of the plan, build it early. Reseller onboarding, authorization inside the marketplace, and the reseller's own contract-vehicle coverage each take weeks, and none of them compress well when a fiscal-year-end deal appears in August. The reseller decision is also a margin decision, since the reseller's markup and the marketplace uplift both come out of the same transaction.
Government-wide pricing agreements are now part of the picture
One more layer has become hard to ignore. GSA's OneGov strategy signs government-wide agreements directly with technology vendors, and the pace has been steady: a Broadcom agreement in January 2026, a Snowflake agreement in May 2026, and a CORAS agreement in July 2026, among others. GSA reported in April 2026 that OneGov had saved taxpayers $1.1 billion in its first year.
For a vendor evaluating a hyperscaler partnership, this matters in two directions. It is a second path to government-wide pricing that does not run through a cloud platform at all, and it is a reason your pricing has to be coherent across channels. A marketplace price, a schedule price, and a government-wide agreement price that disagree with each other is a problem a contracting officer will find.
What the ramp actually looks like
Durations below reflect what the published gates require and how long the sequencing takes when nothing goes wrong. The ordering is more stable than the timing.
A realistic first year in a hyperscaler partner program
Step three is where most programs stall, and the reason is structural rather than technical. Every traction bar in the table above is measured on transactions, and the first transaction has to come from your own pipeline. Nobody hands a new partner a deal. Firms that enter a partner program expecting lead flow get twelve months of portal access. Firms that enter with two deals they intend to route through the marketplace clear the bar and then start receiving the thing they wanted in the first place.
What to have ready before the first partner-manager call
- The consumption number. How much of the platform's own meter one deployment of your product turns in a year, measured on a real deployment rather than modeled.
- A listing plan. Which offer type, which pricing model, and whether professional services ride along as a separate private offer.
- The authorization boundary in one sentence. Which region, which data classification, which impact level, and what your product still needs on top of the platform's authorization.
- A reference architecture diagram. Microsoft requires one for SaaS offers seeking IP co-sell status, and the AWS technical review asks the same questions in a different form.
- Named customers you are bringing, not asking for. Two deals you intend to route through the marketplace beats any capability deck.
- A reseller path. Identify who will hold the paper for buyers who cannot transact directly, and start their marketplace authorization early.
- Payee or vendor account and tax profile. Administrative, unglamorous, and the single most common reason a first listing sits unpublished for a month.
- Sales contacts by geography. Microsoft requires a sales contact for each co-sell-eligible geography before an offer reaches co-sell-ready status.
When a hyperscaler program is the wrong motion
A services firm with no product to list. The marketplaces do transact professional services, but only through private offers, and a services engagement pulls far less consumption than a deployed product. For a pure services firm the value in a partner program is the specialization credential and the field introductions, not the transaction. That value is real, and it is a different value than co-sell. Judge the program against it accordingly.
Deal sizes below the effort floor. Listing, technical review, offer maintenance, and the reseller path all carry fixed cost. Below a certain average contract value the marketplace mechanics cost more attention than they return, and a direct sale on a schedule is cleaner.
Products that are not primarily platformed on the cloud in question. Microsoft requires an offer to be actively platformed on Azure at the time of the transaction for IP co-sell status. Google requires products to be primarily hosted on Google Cloud following one of its approved architectural patterns. A product that runs mostly in your own data center, or mostly on a competitor's cloud, will not clear the technical gate no matter how good the relationship is.
All three platforms entered at once. Each carries its own listing work, technical review, trailing-twelve-month clock, and reseller relationships. One program taken to a transacted private offer beats three half-built listings that never clear a traction bar.
Bottom line
A hyperscaler partner program is a distribution channel with published entry requirements, a published fee schedule, and a compensation system that rewards cloud consumption. Treat it as that and the decisions become tractable: measure what your product pulls on the platform's meter, get a transactable listing published, route deals you already have through it, clear the traction bar, and only then expect the field organization to bring you anything. In government, add one more layer — the authorization boundary decides which region you live in, the region decides which impact levels you can serve, and a reseller usually decides how the money actually moves. The programs are documented well enough that most of this can be checked before a single meeting. Check it first.
Frequently asked questions
A referral hands an opportunity to the cloud provider to pursue. A co-sell means the partner and the provider work the account together. AWS makes the distinction explicit when a partner shares an opportunity in ACE, and the counts of launched and qualified opportunities in that system are what the ISV Accelerate traction bar is measured against. Microsoft attaches the equivalent distinction to the offer rather than the opportunity, through its co-sell status levels.
For the tiers that matter, effectively yes. AWS ISV Accelerate requires at least one product listed as generally available in AWS Marketplace. Microsoft requires the offer to be published live for co-sell-ready status, and new offers must be transactable on the marketplace to reach Azure IP co-sell eligible status. The listing is the sellable unit the platform's field organization attaches to a deal.
No. Running inside an authorized region gives you inherited infrastructure controls and a shorter control-implementation story, not an authorization. Your product still needs its own path — an agency authorization to operate, its own FedRAMP package, or coverage under a customer's existing boundary. Note also that the FedRAMP vocabulary is mid-transition from Low, Moderate and High baselines to FedRAMP 20x certification classes, so state which vocabulary you are using and the date you verified the platform's position.
On AWS, public SaaS listings carry a 3% listing fee and public server listings — machine images, containers, and machine learning products — carry 20%. Private offers price by total contract value at 3% under $1M, 2% from $1M to under $10M, and 1.5% at $10M and above and on all renewals, with a 0.5% uplift when the deal runs through a channel partner. Microsoft charges a flat 3% store service fee, with a 50% discount available on private-offer customer renewals.
When a customer holds an Azure consumption commitment and buys an Azure benefit eligible partner offer through the marketplace, 100% of the pretax purchase amount counts toward that commitment. The purchase must be made through the marketplace inside the Azure portal on a subscription tied to the agreement, and the license must be used exclusively in Azure. Equivalent treatment on other platforms should be confirmed in writing for the specific agreement rather than assumed.
It can be, for different reasons. The marketplaces transact professional services only through private offers, and services engagements pull far less cloud consumption than deployed products, so the co-sell economics are weaker. The value for a services firm is the specialization credential and access to the platform's field organization. That is a real benefit and a different one, so evaluate the program against it rather than against transaction volume.