What Is AWS Partner Revenue Measurement?

AWS Partner Revenue Measurement is a set of capabilities that let a partner measure the AWS service consumption their solutions drive, across both partner-managed and customer-managed accounts. You instrument your solution — with a resource tag, a user agent string, or an AWS Marketplace listing — and AWS reports back, monthly, how much AWS revenue your product was responsible for.

That is the mechanical answer, and it is the least interesting thing about it. The interesting thing is what PRM replaces. For as long as cloud partner programs have existed, a partner’s contribution has been something they asserted and someone at the provider adjudicated. You registered an opportunity, you described your involvement, a partner manager agreed or did not. Recognition followed a claim about a deal.

PRM replaces the claim with a meter reading. And AWS is not being subtle about the direction. Partner Revenue Measurement is already how it measures partnership success across partner programmes and benefits, and from 1 January 2027 it becomes the foundation for how AWS measures, validates and recognises partner impact across eligible programmes — with programmes moving off statistical models and customer tagging onto a single framework.

The short version of what follows: influence you cannot express as structured, machine-readable evidence is on its way to not being paid for.

First, the name

PRM here means Partner Revenue Measurement. It is not Partner Relationship Management, the channel-software category that has owned that acronym for fifteen years and which has nothing to do with any of this.

This is not pedantry. It is the single biggest reason PRM is badly covered: search the acronym and you get a decade and a half of unrelated channel marketing, so the material that should explain AWS’s product is buried under material about somebody else’s. Answer engines make the same mistake — one of the three we tested flatly denied the AWS product exists.

What PRM actually changes

AWS’s framing of the problem is unusually candid. Partners have relied on estimated metrics — annual recurring revenue, total contract value — which are useful for pipeline management and do not reflect the AWS consumption a partner’s solution actually drives. There has been no systematic way to track attributed revenue at scale. The result AWS describes is that recognition and incentives end up tied to deal closure rather than to customer adoption and service consumption.

Sit with that for a moment, because it is a significant admission. The entire apparatus of partner recognition has been measuring the wrong event. Closing is a moment; consumption is a behaviour. A partner who closes a large deal that the customer never really adopts has, under the old measurement, outperformed a partner who quietly drove years of growing usage.

PRM inverts that. And the inversion has a second-order effect that matters more than the metric itself: it changes who has to be convinced. Under the claim model you persuade a person — a partner development manager with a book of partners, limited hours, and a memory of your last few submissions. Under the measurement model, there is no one to persuade. There is a pipeline that reads tags. It is more objective, and it is also completely indifferent to the quality of your relationship and to any contribution you failed to instrument.

The three ways to implement it

All three key off the same identifier: your AWS Marketplace product code. AWS presents them as complementary, and they are — you can run more than one.

AWS Marketplace Metering. If you list an AMI or a machine-learning product on AWS Marketplace, consumption of EC2 and SageMaker AI in customer-managed environments is measured automatically when customers buy and use it. No implementation effort at all. Zero work, narrow coverage.

Resource Tagging. Tag the resource with key aws-apn-id and value pc: followed by your product code. Attribution continues until the tag is removed or the resource is terminated. Simple, inspectable, and — as we will get to — contested.

User Agent String. Integrate APN_1.1/pc_<product-code>$ into your application, or set an environment variable and change no code at all. AWS reads it from the API calls your solution makes, and requires at least monthly evidence of continued interaction for attribution to persist.

The comparison everyone publishes ranks these by engineering lift, which is the least useful axis available. The real question is who controls the account. If the workload runs somewhere you control, tag it and put the tag in your infrastructure-as-code. If it runs in the customer’s account, under their tag policies, tagging is a negotiation — and, as we will see, one AWS has explicitly decided you can lose. The decision rule is short and it is not about effort.

What you need before you start

AWS publishes four prerequisites. Link an AWS account to your Partner Central account; have a product listing on AWS Marketplace; have a product that uses one or more supported AWS services; and enable Cost Explorer.

The linked account is the load-bearing one. AWS states that it determines PRM compliance for APN funding benefits eligibility, becomes the primary account for all APN activity, and is billed the APN membership fee — a decision with consequences well beyond attribution. If you hold several AWS Marketplace seller accounts, connecting them to that primary account uses subsidiary account connections, which requires the new Partner Central experience.

Cost Explorer is the one that gets skipped. It has nothing to do with tagging, it lives in a different console, and nothing in the PRM setup flow reminds you. Like every other failure mode here, it produces silence rather than an error.

Two clarifications worth having, because both remove an objection people raise:

The listing is an identifier, not a sales route. Its job is to give you a product code for the tag value or user agent string to carry. Which is why a free listing satisfies it.

Services partners are not excluded. Without a listing there is no product code, and without a product code there is no PRM. But AWS Marketplace supports Professional Services listings, and a free one supplies the code — so a consultancy with nothing to license still has a route in.

Revenue Attribution IDs: the part nobody is writing about

Here is the mechanism that changes how PRM should be understood, and which is almost entirely absent from the public conversation — it is not in AWS’s public onboarding guide, not in any partner-tooling vendor’s content, and not in the trade coverage.

Product-level PRM answers one question: how much AWS consumption does this product drive? That is useful for a business review and useless for an incentive claim, because incentives are paid against deals, not products.

A Revenue Attribution ID closes that gap. It is an identifier created in Partner Central that associates AWS Marketplace offers and ACE opportunities with a Marketplace product listing, so AWS can determine the revenue generated by those specific offers and opportunities. A listing carries one.

You can use it two ways. As a deal-level overlay on an existing product-level implementation: create the ID, associate the relevant offers and opportunities, and supply monthly cost-allocation percentages. Or as a standalone identifier, used directly in place of a product code in a tag value or user agent string.

The mechanics are worth knowing precisely, because they are more flexible than partners assume:

No rework. If your tags or user agent strings already carry a product code, nothing changes. You create the ID, associate it to the product in the wizard, and add allocation percentages. AWS built it explicitly as a mapping layer to avoid re-tagging.

Splitting.Where two or more offers or opportunities are active in the same billing month, revenue splits by the percentages you supply — 60/40 in June means 60/40 of June’s attribution. Where different deals are associated in different months, each month’s revenue follows that month’s association.

Renewals. Keep the same ID. Stop allocating to the expired deal, start allocating to the new one. No resources are touched. AWS names this as the recommended pattern.

Multi-tenant SaaS.This is the answer to the question every SaaS partner asks about shared infrastructure. One Revenue Attribution ID per product, associate each customer’s Marketplace offer or ACE opportunity, and provide monthly percentages reflecting each customer’s share of your consumption. Marketplace offers and ACE opportunities can be mixed on one ID and are treated identically.

And the reason it exists: to map revenue to the deals where you are seeking incentives, and to enable automated payment approvals when a deal reaches a revenue milestone, replacing reporting and reconciliation that today rests on manual inputs.

Read that last sentence commercially rather than technically. An incentive that pays out when a pipeline observes a milestone is an incentive with no submission, no reviewer, and no discretion. The administrative burden goes away. So does the room to explain yourself.

Where the two systems meet — and why that matters

The Revenue Attribution ID is also the answer to the question partners ask most about PRM: does this replace ACE?

It does not. The two measure different things and will increasingly be joined at the deal. ACE remains the record of the relationship — who found the opportunity, who was involved, what was agreed. PRM becomes the record of the consequence. The Revenue Attribution ID is the join key, and it points in a direction worth noticing: AWS is building towards deals whose claimed value and whose measured value sit in the same row.

Which makes reconciliation an operating discipline rather than a reporting task. Compare your ACE opportunities against your attributed revenue every month. Where a clean ACE win attributes nothing, either instrumentation is missing or the deal did not produce the consumption it promised — and you want to know which, before someone at AWS asks. Where consumption attributes with no ACE opportunity behind it, you are driving revenue you are getting no relationship credit for, which is a different and more fixable problem. The gap between the two numbers is the earliest leak detector available, and almost nobody is running it.

When the number arrives

Attributed revenue is processed monthly and, per AWS’s documentation, becomes available 17 days after the month endsfor the previous month. Instrument on 15 August and August’s partial consumption surfaces in mid-September. The 45-day figure circulating in partner summaries is wrong by a full planning cycle.

Do not wait blind in the meantime. The Attributed Revenue dashboard carries an Onboarding Status table showing which capability is enabled per product and whether it is actively measuring — a configuration view rather than a revenue view, and therefore a different question from the one the monthly cycle answers. The widely repeated advice that nothing can be checked until revenue appears conflates the two.

Note also that what you see is aggregated at product and AWS service level. PRM is not a customer-level reporting tool and is not designed to become one.

One tag per resource, and it is contested

A resource can carry one aws-apn-idtag with one product code. If another partner’s tag is already there, yours does not go alongside it.

AWS’s guidance for that case is to use the User Agent String method instead, which has no such limit — and, if you must tag, to coordinate with the other partner and the customer to determine tag ownership before making changes. Note also that anyone with access to the account can remove a tag, customers and partners alike.

Turn that into practice and it stops being an implementation detail. “Who else operates on this account’s infrastructure, and whose tag is on it?” is now a question with money attached, and it is answerable before the engagement starts rather than during implementation. It belongs in written qualification, next to the stakeholder who responded and the event that makes now the moment.

It also means attribution can disappear without notice. A customer tidying tags, another partner taking over the estate, or your own pipeline redeploying without the tag block all end attribution silently. That is the strongest argument for treating this as a monthly operational check rather than a configuration you set once.

What to do about it

Clear minimum compliance, and check the spend condition. Listing, linked account, one solution instrumented — in an account with real spend behind it. If you have several Marketplace seller accounts, connecting them requires the new Partner Central experience and subsidiary account connections, which is a slower job than it sounds.

Then expand, because compliance is not the goal.One instrumented solution keeps you eligible and tells you almost nothing. AWS’s own guidance after the deadline is to expand across your most-used products and service engagements — and partners who do that during 2026 are the ones positioned for the 2027 mechanics.

Do not rip out MAP tagging.AWS is explicit that partners should keep adhering to the tagging requirements in their current agreements, and that PRM can be implemented for use cases outside them. MAP’s construct shifts onto PRM Resource Tagging in 2027 — which means MAP partners are closer to this than they think, but not that they should pre-empt it.

Set up Revenue Attribution IDs before you need them. If any part of your business runs on deal-level incentives, or you are multi-tenant SaaS, this is the layer that makes attribution claimable. It requires no re-tagging, so the cost of doing it early is a wizard and a monthly percentage.

Start the monthly reconciliation now. ACE opportunities against attributed revenue, every month, looking for the gap in both directions. Doing this in 2026 costs an hour and produces a year of calibration before the numbers start deciding payouts.

Watch H2 2026 and re:Invent. AWS says programme-specific detail arrives through the second half of the year and at re:Invent. The 2027 rules are directional today and become arithmetic then.

The shift underneath all of this

It is tempting to read PRM as a compliance chore with a tagging exercise attached, hand it to whoever owns infrastructure, and move on. That reading survives about a quarter.

What AWS has actually changed is what counts as evidence of partnership. Contribution used to be asserted and adjudicated by someone who knew you. It is becoming something you either instrumented or did not — and the strength of your relationship, the quality of your architecture and the depth of your customer knowledge do not enter into it at the moment of measurement.

The instinctive response is cynical: game the tags. It is also wrong, because the meter is downstream of everything real. Attribution only exists where consumption exists, and consumption only exists where somebody found an account, understood a workload, and got something deployed that people actually use.

PRM does not change how partner businesses win. It changes what happens to the wins that leave no trace — and every one of those is now a contribution you made and will not be paid for.