How to Co-Sell With AWS: ACE, ISV Accelerate and the Path to Partner-Led Growth

AWS has the most developed co-sell infrastructure of the three hyperscalers: a formal program (ISV Accelerate), a dedicated pipeline-sharing system (ACE inside Partner Central) and an AE incentive structure that rewards co-sold business. Understanding how those pieces connect – and where they break down in practice – is the foundation of a working AWS co-sell motion. This post covers the mechanics from program entry through to active field engagement.

TL;DR

  • AWS co-sell runs through Partner Central and the APN Customer Engagements (ACE) pipeline-sharing system, with the formal ISV Accelerate (ISVA) program as the co-sell-eligible status that unlocks AE incentives and the SaaS Co-Sell Benefit for SaaS-archetype partners.
  • The AWS field organisation has multiple distinct roles – AE, Solutions Architect, CSM, specialist SAs, PDM, ISV PDM, regional and industry leads. Which roles you over-index on depends on tenancy archetype: customer-deployed products lean on AE and specialist SA engagement; ISV-hosted SaaS leans more on the ISV PDM. See ISV-Hosted vs Customer-Deployed.
  • The SaaS Co-Sell Benefit is the definitive example of the marketplace-bridges-the-two-worlds dynamic. AWS sellers get quota retirement credit when partner SaaS closes through marketplace private offers, which substantially changes their behaviour toward eligible ISVs.
  • The 2026 Specialisation renewal change is significant: renewals now require launched ACE opportunities tied to the Specialisation Solutions over a rolling 12 months. Execution-led, not activity-led.
  • The most common AWS co-sell failure mode is high-volume low-quality ACE submission. Acceptance rates collapse, PDMs disengage and the program fails to produce its intended outcomes. Submission selectivity is the single highest-leverage operational discipline.

What AWS Co-Sell Is

AWS co-sell is the partner-led and AWS-led motion of jointly pursuing customer business with the AWS field organisation, supported by formal programs (ISV Accelerate, Specialisations), a pipeline-sharing system (ACE in Partner Central) and marketplace-routed transaction structures. The motion sits inside the broader cloud co-sell model covered in Hyperscaler Co-Sell; this post covers the AWS-specific mechanics.

The AWS Field Organisation

The AWS customer-facing field is more layered than first-time alliance leads typically expect. The roles you’ll engage with:

Account Executive (AE). The primary owner of the customer relationship. Quota retires against customer cloud consumption growth and (increasingly) customer-side marketplace transactions. Has discretion to bring in partner technology where it accelerates customer outcomes. For customer-deployed ISVs, this is the most significant relationship – see ISV-Hosted vs Customer-Deployed.

Solutions Architect (SA). AWS’s customer-facing technical role. Leads architecture conversations, supports proof-of-concept work and acts as technical sponsor for the customer’s cloud adoption. Generalist SAs cover account portfolios; specialist SAs cover workload domains (data analytics, AI / ML, security, modernisation, agentic AI etc.).

Customer Success Manager (CSM). Focused on existing-customer adoption, expansion and consumption growth. Important counterpart for ISVs whose products drive consumption uplift on already-deployed accounts.

Partner Development Manager (PDM). The partner-side relationship owner within AWS. Manages the formal partner-program relationship, advocates for the ISV inside AWS, gates access to MDF funding and brokers introductions to the customer-facing field. For ISV-hosted SaaS ISVs, the PDM is the natural primary champion; for customer-deployed ISVs, the PDM is necessary but rarely sufficient.

ISV PDM. A specialisation of the PDM role for ISV partners specifically. Often dedicated to software-path partners with active marketplace presence. Same structural role as a general PDM but with deeper context on ISV-specific mechanics (marketplace, ISVA, SaaS Co-Sell Benefit).

Partner Sales Manager (PSM). A distinct AWS field role focused on partner-attached and partner-originated revenue in named accounts, verticals or territories. Where the PDM manages the partner relationship, the PSM operates on the customer-account and deal side – owning partner-sales pipeline, partner-attached revenue forecasting and co-sell engagement against a quota. PSMs are measured primarily on partner-contribution revenue and partner-sourced deal outcomes rather than on partner-program participation metrics. For ISVs, the PSM is typically a more commercially motivated co-sell counterpart than the PDM on specific named accounts: the PSM has direct incentive to see partner-attached deals close and will advocate within AWS for partner involvement in active pursuits. Microsoft had a roughly equivalent role (the Enterprise Channel Manager or ECM) but eliminated it in early 2023. Google Cloud does not have a direct equivalent at the time of writing.

Regional and industry leads. Theatre-level (AMER, EMEA, APJ) and segment leadership, plus dedicated industry-vertical leads (financial services, healthcare, public sector, retail). Engage through senior alliance leadership rather than individual AE relationships.

Specialist sellers. Sales-side workload specialists, distinct from specialist SAs. Cover the same workload domains and partner closely with the SAs but carry sales quotas rather than technical mandates.

The structural rule from Hyperscaler Co-Sell applies here with particular force: the layer you over-index on depends on tenancy archetype. Customer-deployed products should concentrate on AE, specialist SA and specialist seller engagement; ISV-hosted SaaS products can lean more heavily on the ISV PDM as the primary champion. The definitive reference is ISV-Hosted vs Customer-Deployed.

Partner Central and the ACE Program

Partner Central is AWS’s partner-facing portal – the system of record for AWS Partner Network membership, Partner Paths, Specialisations and the ACE opportunity-sharing system. All formal co-sell mechanics flow through Partner Central.

APN Customer Engagements (ACE) is the pipeline-sharing system inside Partner Central. It operates in two directions.

Outbound (partner → AWS). The partner shares an opportunity with AWS, providing customer details, deal value, expected close date, AWS services involved and the rationale for AWS involvement. AWS reviews and either accepts the opportunity (formally engaging on the deal), declines or returns for more information. Accepted opportunities show up in the AWS field’s pipeline views and become part of AE quota retirement when they close.

Inbound (AWS → partner). AWS shares an originated lead with the partner. The partner accepts (committing to work the opportunity), declines or escalates for clarification. Inbound opportunities are typically higher-quality than outbound submissions because the AWS field has already qualified the customer need. They are also rarer – the volume is far below most partners’ partner-led outbound volume.

The single most significant operational discipline for ACE is submission quality. ACE submissions that arrive with incomplete information, mis-named customer accounts, weak rationale or weak AWS-involvement justification get declined. Repeated declines damage the PDM relationship and reduce acceptance rates on subsequent submissions. Hygiene practices matter: clean customer account naming, complete service-mapping, named AWS-side contacts where available and explicit consumption-uplift rationale for customer-deployed products.

One submission type worth understanding separately: For Visibility Only (FVO). An FVO submission shares an opportunity with AWS for awareness purposes but does not request active AWS engagement on the deal. FVO submissions are excluded from the opportunity counts that determine ISVA eligibility and Specialisation renewal – they do not count toward either the 5 launched or the 15 qualified thresholds. Partners sometimes use FVO to build a shared pipeline view with their PDM without triggering the acceptance workflow; it is a legitimate tool but carries no co-sell credit.

The fastest way to signal low-quality submissions to any PDM or AWS reviewer is a pipeline where every opportunity carries the same deal value. Placeholder amounts – whether $50k, $100k or any other round number applied uniformly across a batch of submissions – are immediately visible and tell the reviewer that the ISV is treating ACE as a deal-registration system rather than a genuine co-sell pipeline. Deal size is often genuinely unknown early in a pursuit, which is a legitimate reason to use a placeholder; it is not a reason to use the same placeholder for every deal. The discipline is to enter the best available estimate at submission and update the value as the deal develops – ideally at each stage progression.

AWS Partner Central Agents (launched March 2026). AWS has introduced an agentic AI layer directly into Partner Central, powered by Amazon Bedrock AgentCore. This is distinct from AWS’s broader agentic AI product category for ISVs – it is agentic tooling built specifically to help partners manage their co-sell operations, not tooling to help customers deploy agents. The agents automate several operational pain points that the series has documented as significant friction points:

  • Opportunity field population from meeting notes. Partners can upload meeting transcripts, notes or emails and the agent pre-populates the relevant ACE opportunity fields, reducing the manual overhead that drives template-submission behaviour and low-quality ACE entries.
  • Pipeline intelligence. Conversational queries against live pipeline data – identify deals approaching deadlines, summarise stage distribution, flag opportunities needing attention – without switching between systems.
  • Funding eligibility identification. Rather than manually cross-referencing opportunity characteristics against funding programme eligibility documentation, the agent surfaces which opportunities in the pipeline qualify for MDF or other benefits and pre-populates fund requests.
  • Tailored sales plays. On-demand sales plays and next-step recommendations specific to an individual opportunity rather than generic programme guidance.

The agents are also accessible via MCP server, meaning partners can access Partner Central intelligence directly from their CRM without context-switching to the Partner Central portal. Third-party Cloud GTM Platform vendors (including Labra and WorkSpan) have already announced integrations that bring the agent capability into their own platforms.

The tooling addresses submission and hygiene mechanics; it does not replace the relationship and judgement work that remains the actual constraint on co-sell outcomes. Partner Central Agents are available to partners who have migrated to the new Partner Central experience in the AWS Console. Partners still on the old portal will need to migrate before accessing these capabilities.

The competitive position. AWS is currently the only hyperscaler to have launched a dedicated agentic layer for partner co-sell operations management. Microsoft has introduced generative AI features in Partner Center – including AI-assisted opportunity note generation and confidence scoring for outbound submissions – but these are incremental AI features rather than a full agentic workflow layer. Google Cloud’s major 2026 agentic partner announcements ($750M partner fund at Cloud Next 2026, partner-built agents in Gemini Enterprise) are focused on helping partners build and sell agentic AI products to customers, not on agentic tooling for partners to manage their co-sell operations. This distinction is worth tracking: if Microsoft or Google launch equivalent co-sell operations agents, the operational landscape for all three will shift.

AWS ISV Accelerate (ISVA)

AWS ISV Accelerate is the formal co-sell program for software partners. Membership unlocks the meaningful co-sell incentives – AE incentive multipliers on marketplace private offers, MDF access for newly enrolled partners post-January 2026 and the SaaS Co-Sell Benefit for SaaS-archetype products.

Eligibility for ISVA membership requires (as of mid-2026):

  • Software Path validation at Validated or Differentiated tier (or higher).
  • Marketplace listing: one or more software products listed at general availability on AWS Marketplace.
  • ACE-eligible status with active opportunity-sharing.
  • Amazon Payee Central account set up.
  • Trailing 12-month opportunity volume: at least 5 launched opportunities (via ACE or AWS Marketplace Private Offers, excluding For Visibility Only submissions) and at least 15 qualified opportunities in ACE (excluding For Visibility Only submissions) in the past 12 months.
  • Co-Selling with AWS learning module completed by at least 1 individual in the organisation.
  • Minimum AWS account revenue of approximately $2k at enrolment (i.e. the partner has had genuine consumption-driving activity on AWS).

The specific thresholds above are drawn from current AWS programme documentation; they move year-on-year. Check current AWS terms before relying on any specific number for partnership planning. The eligibility surface is unambiguous in shape: ISVA membership is gated by both validation status and demonstrated co-sell activity. A partner that holds the right tier on paper but hasn’t been operating ACE meaningfully won’t qualify.

Benefits, beyond the SaaS Co-Sell Benefit covered separately below, include co-sell-specific account team support inside AWS, partner-marketing programs (joint go-to-market plays, named events) and access to additional incentive mechanisms tied to marketplace transactions. For ISVs at scale, ISVA membership pays back significantly; for smaller partners, the eligibility threshold is high enough that it’s often a 12–18 month investment to reach.

SaaS Co-Sell Benefit (Formerly SaaS Revenue Recognition)

The SaaS Co-Sell Benefit is the single most significant AWS co-sell mechanic and the definitive documented example of the marketplace-bridges-the-two-worlds dynamic explored in ISV-Hosted vs Customer-Deployed.

The mechanic: when an AWS seller co-sells a partner SaaS solution through a marketplace private offer, the AWS seller receives quota retirement credit on the transaction. The seller’s quota is tied by design to customer cloud consumption growth, so without the SaaS Co-Sell Benefit, SaaS deals (which drive consumption in the partner’s cloud account, not the customer’s) wouldn’t move the AE’s number. With it, they do.

The benefit was formerly called SaaS Revenue Recognition and was scoped to a narrower subset of ISVA partners until re:Invent 2024. As of 2025–2026, the program is open to all ISVA partners with eligible SaaS or PaaS solutions transacted through marketplace private offers.

The behavioural change on the AWS field is material. AEs who would previously have been indifferent to partner SaaS pursuits (because the consumption wasn’t on their customer’s account) now have direct quota incentive to support them. This is the structural reason marketplace-routed transactions are commercially preferred for SaaS-archetype AWS partners: the AE motivation is aligned with the partner’s outcome.

Two practical implications. First, ISV-hosted SaaS partners on AWS should optimise heavily for marketplace-routed private offers; the SaaS Co-Sell Benefit only fires on marketplace transactions. Direct-invoiced SaaS deals don’t generate the AE quota credit and don’t trigger the same field engagement. Second, customer-deployed partners don’t benefit from this mechanic – the consumption already accrues to the customer’s account, so the AE was already motivated. The mechanic is genuinely SaaS-specific.

Marketplace Private Offer Promotion Program (MPOPP)

MPOPP is AWS’s incentive programme tied to partner-led marketplace transactions, sitting alongside the SaaS Co-Sell Benefit but operating on a different mechanic. Where the SaaS Co-Sell Benefit gives the AWS seller quota retirement credit, MPOPP offers AWS Promotional Credits to customers as an incentive for purchasing from participating ISVs through Marketplace Private Offers. Credits are issued to the customer’s AWS account based on the Total Contract Value and applicable programme rates following transaction verification. Partners submit self-service funding requests through the AWS Partner Funding Portal; funding is targeted for next-business-day delivery following Private Offer acceptance. MPOPP includes benefits for both new AWS Marketplace sellers and established sellers driving Marketplace renewals.

MPOPP eligibility and specific incentive terms shift roughly annually, sometimes more often. Any deal modelling that depends on MPOPP should check current AWS terms rather than rely on documented detail – the specific percentages change. Partners report that the post-2024 direction has been toward simpler, higher-volume incentive structures aimed at accelerating marketplace adoption among mid-sized ISVs. Detail on the operational mechanics of marketplace private offers is in Private Offers.

AWS ISV Workload Migration Program (WMP)

The ISV Workload Migration Program sits alongside ISVA and provides funding for customers migrating off third-party technology onto an ISV’s AWS-native solution. The ISV is the program execution lead; the customer is the financial recipient.

As of late 2025, WMP enables AWS Promotional Credits to be disbursed directly to end customers through AWS Marketplace, simplifying the operational mechanics versus earlier years when credits flowed to the ISV’s account for onward distribution. The program is most useful for ISVs whose value proposition includes migrating customers off on-premises or competing-cloud technology onto AWS-native infrastructure – a meaningful subset of database, data-platform, security and observability ISVs.

WMP is distinct from the broader AWS Migration Acceleration Program (MAP), which targets customer infrastructure migrations more broadly. WMP is ISV-specific and ties to the ISV’s product as the migration target. Detail on the broader funding landscape is in Cloud Provider Funding.

AWS Specialisations and ACE Renewal Mechanics

The 2026 Specialisation renewal change is the most significant AWS partner-program update in recent years. Specialisation renewals now require launched ACE opportunities tied to the Specialisation Solutions over a rolling 12-month period. The bar shifted from activity-led (you submitted ACE opportunities) to execution-led (the opportunities closed and produced AWS-relevant outcomes).

The practical implication: a Specialisation the partner earned through significant engineering and commercial investment can lapse if the co-sell motion underneath it isn’t running. A partner that earned the Data Analytics Specialisation in 2023 and let ACE activity drift in 2025 can find the renewal denied in 2026 despite the underlying technical capability being intact.

The fix is operational. ACE activity has to be paired with Specialisation investment, not run as a parallel function. The alliance team has to track which ACE opportunities map to which Specialisation Solutions and ensure trailing-12-month coverage stays above the threshold for each Specialisation the partner wants to retain. Specialisation renewals are now a continuous operational discipline, not an annual exercise.

Detail on the Specialisation landscape across hyperscalers is in Cloud Partner Programs and Specialisations.

Practical Co-Sell Workflow

The two directions of co-sell produce different starting points and different step sequences. They share a common closing motion once a joint pursuit is underway.

A note on classification. The hyperscaler’s inbound/outbound distinction and the ISV’s alliance-sourced/direct-sourced distinction are measuring different things and should not be conflated. Outbound (ISV submits to ACE) vs inbound (AWS shares to ISV) describes who entered the opportunity into the portal. Alliance-sourced vs direct-sourced describes who originated the relationship or pursuit that led to the opportunity. A common real-world pattern: the ISV alliance team sets a meeting with a hyperscaler AE, the conversation identifies a target customer, and the AE asks the ISV to “put something in the portal” – the result is an outbound ACE submission, but the opportunity was originated by the alliance team’s field engagement rather than by the ISV’s direct sales motion. From AWS’s perspective it is outbound; from the ISV’s internal attribution system it is alliance-sourced. The two classifications are orthogonal and a deal can legitimately sit in any combination. ISV reporting that treats “outbound ACE submission” as synonymous with “not alliance-sourced” will systematically undercount the alliance team’s contribution. This is a specific and common variant of the attribution problem covered in Cloud Alliance Team and Co-Sell Operations.

ISV-Led Outbound

The ISV identifies an opportunity and brings it to AWS.

  1. Opportunity identification. The ISV’s sales team identifies a customer need that involves AWS consumption. The alliance team reviews whether AWS engagement would genuinely change the outcome – accelerating the deal, unlocking a customer introduction, providing technical validation or enabling marketplace routing. Opportunities where AWS engagement adds nothing are run as direct deals and not submitted to ACE.
  2. ACE submission. The ISV submits the opportunity through Partner Central with the full information set: customer details, deal value, AWS services involved, named AWS-side contacts where available, expected close date and marketplace-routing intent. Submission quality determines acceptance; rushed or incomplete submissions get declined.
  3. AWS acceptance. The AWS PDM or designated reviewer accepts the submission (formally engaging), declines with feedback or returns for more information. Acceptance puts the opportunity in the AWS field’s pipeline views. Declines should be diagnosed before the next submission – repeated declines on similar opportunities signal a systematic quality or fit problem.
  4. Joint pursuit. The ISV and AWS work the deal together. The hyperscaler AE provides customer-facing support, technical validation and potentially MDF-funded activity. The ISV provides product expertise, proof-of-concept support and customer relationship continuity.
  5. Marketplace transaction. For marketplace-routed deals, the ISV creates a private offer in AWS Marketplace; the customer accepts; the transaction draws against the customer’s EDP commit. For direct-invoiced deals, traditional procurement applies – and the SaaS Co-Sell Benefit does not fire.
  6. Close and attribution. Deal closes. Closed-won status updated in ACE; opportunity closed in the ISV’s CRM. The closed deal flows into AWS’s reporting (contributing to AE quota retirement and the ISV’s ISVA / Specialisation renewal counters) and into the ISV’s reporting (alliance comp, marketplace transaction reporting, pipeline-source analysis). Closed-loop attribution discipline keeps the two systems in sync.

AWS-Led Inbound

AWS identifies an opportunity and brings it to the ISV. The inbound flow is structurally simpler: AWS has already qualified the customer need before making the introduction, so steps 1 and 2 of the outbound flow largely collapse.

  1. AWS origination and introduction. A hyperscaler AE, CSM or specialist seller identifies a customer need that includes the ISV’s product and shares the opportunity through ACE or makes a direct introduction. The qualification step is substantially done by AWS at this point – the customer problem is real, the fit has been assessed and the AWS field is prepared to advocate for the ISV.
  2. ISV acceptance and response. The ISV accepts the opportunity in ACE and responds promptly. Inbound opportunities are rarer and higher-quality than outbound; slow or unprepared responses damage the relationship with the AWS team that made the introduction. The triage model from Hyperscaler Co-Sell applies: CS or account-AE-originated inbound warrants immediate senior response; PDM-originated inbound warrants standard qualification.
  3. Joint pursuit, marketplace transaction, close and attribution. Same as steps 4–6 of the outbound flow above.

Tooling

AWS co-sell tooling sits in three layers:

AWS-native tooling. Partner Central is the system of record. The Partner Central APIs allow CRM-side automation against the partner-portal data. Slack Connect channels with AWS PDMs and account teams are increasingly common, particularly for active joint pursuits. Partner Connections is AWS’s more recent partner-engagement layer for structured field activities.

ISV-side CRM. Salesforce or HubSpot, holding the source-of-truth account and opportunity data. The Partner Central APIs allow bidirectional sync between ACE and CRM, though the implementation is non-trivial and ages out as AWS evolves the APIs.

Third-party Cloud GTM Platforms. Clazar, Labra, Suger and Tackle (acquired by AppDirect, December 2025) automate the bidirectional sync between Partner Central and the ISV’s CRM, plus the operational mechanics of marketplace listings, private offers and metering. Cited as a category, no endorsement of any specific provider. Detail on build-vs-buy trade-offs in Co-Sell Operations.

Common Pitfalls

A handful of patterns that recur in AWS co-sell motions of all sizes:

  • Sharing every opportunity. The team submits every CRM opportunity to ACE, drowning the AWS PDM in noise. Acceptance rates collapse; the PDM stops returning calls; genuine co-sell pursuits get lost. The fix is selectivity – submit opportunities where AWS engagement actually changes the outcome.
  • ACE submission quality issues. Incomplete customer details, mis-named accounts, weak rationale, missing AWS-side contacts. Each problem reduces acceptance probability; in combination they signal an unserious ISV. A specific and immediately visible quality signal: a pipeline where every opportunity carries the same deal value. Uniform placeholder amounts tell any PDM or AWS reviewer that the ISV is treating ACE as a deal-registration system. Build submission-quality discipline into the alliance team’s operating rhythm.
  • Mismatched account naming. AWS-side customer account names sometimes diverge from the ISV’s CRM customer names (subsidiaries, holding companies, regional variations). ACE submissions that don’t match the AWS-side naming convention get declined or routed to the wrong AWS-side team. Account-mapping discipline matters.
  • No AWS-side champion. Submissions arriving without prior PDM relationship or AWS-side advocacy get processed as transactional submissions rather than as joint pursuits. PDM rhythm is the prerequisite, not the optional extra.
  • Not linking ACE opportunities to marketplace private offers. Particularly for ISV-hosted SaaS partners. ACE submissions that don’t end in marketplace transactions don’t fire the SaaS Co-Sell Benefit, which means the AWS AE doesn’t get quota credit, which means AE engagement on the next pursuit will be lower. Route co-sold deals through marketplace deliberately.
  • Taking a co-sold deal direct to avoid the marketplace fee. The ISV AE has a deal that has been progressed with AWS field involvement – the hyperscaler AE has attended calls, provided technical support or made customer introductions. At the point of close, the ISV AE routes the transaction direct rather than through marketplace to avoid the 3% fee and protect their commission base. The mechanism is almost always the same: the ISV AE leverages their customer relationship to have the customer request a direct transaction, so the bypass appears to originate with the customer rather than the ISV. The immediate financial saving is real; the damage is larger and less visible. The hyperscaler AE who invested time in a deal that then bypassed marketplace did not get quota retirement credit, did not get the consumption attribution and will remember. The PDM who advocated for the ISV internally has been made to look foolish. Neither will prioritise the ISV on the next pursuit. This pattern is the same silent marketplace bypass dynamic covered in Cloud Alliances and Cloud Alliance Team, but with a specific personal dimension: it is not an anonymous programme metric that degrades, it is a named individual’s trust that is broken. The fix is comp design – gross-revenue-quota rather than net-revenue-quota on marketplace-routed deals – combined with an explicit routing policy and AE education before the first co-sold deal is in the pipeline.
  • Tenancy-archetype mismatch. Running a SaaS-style AWS co-sell motion (PDM-led, marketplace-as-origination) for a customer-deployed product, or vice versa. The most significant pitfall and the easiest to miss. The definitive reference is ISV-Hosted vs Customer-Deployed.

What This Looks Like in Practice

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

A security ISV with $35M ARR and customer-deployed software (agents inside customer VPCs) ran AWS co-sell for two years with limited results: ACE submissions in the right range (~15 per quarter), reasonable acceptance rates (~55%), but very little progression to closed-won. The pipeline looked busy and the comp models paid out a little, but the function wasn’t producing the trajectory the CRO expected.

The diagnostic showed the problem: every ACE submission was originated by the partner, every customer engagement was AWS-side-supported but partner-driven and the customer-side AEs the company actually needed to engage had never been deliberately cultivated. The motion was textbook for an ISV-hosted SaaS product. The product was customer-deployed.

Year three rebuilt the motion in three parallel tracks. Track one re-cast two CAMs as field alliance managers (per ISV-Hosted vs Customer-Deployed) with new comp structures tied to AE-originated pipeline. Track two built named-customer consumption-uplift evidence – three case studies showing measurable AWS consumption growth tied to the ISV’s product, over a six-month period. Track three preserved the partner-program work (Specialisation renewals, ACE hygiene, MDF) at lower headcount but with continued execution.

The trailing 12-month results at month 18 of the rebuild: ACE-attributable closed-won doubled, AE-originated pipeline shifted from near-zero to ~30% of total AWS co-sold pipeline and the SaaS Co-Sell Benefit – previously largely inactive for the partner – fired meaningfully on the small set of bundled offerings that included a SaaS-mode variant. The total trajectory took 18 months from the diagnostic to mature operating state; the alliance function’s headcount stayed roughly constant through the transition – a composite outcome, not a planning assumption.

Where to Go Next

Within this pillar:

  • Microsoft Co-Sell – the equivalent operating manual for Microsoft Azure.
  • Google Co-Sell – the equivalent for Google Cloud, including the Q1 2026 Partner Network reset.
  • Co-Sell Operations – the tooling and attribution infrastructure that supports AWS co-sell at scale.

Adjacent:

The full series glossary is at Glossary.

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

External References

Vendor Primary Sources

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.

Last reviewed: 2026-07-01. Vendor-specific clusters in this series are reviewed twice yearly after AWS re:Invent (late November / early December) plus mid-cycle for major program 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/.