Partner Revenue Measurement (PRM) is the mechanism AWS uses to credit partners for the AWS consumption their solutions and services drive. AWS announced it in January and it now feeds co-sell visibility, funding eligibility and your standing in ACE.
The concept takes a sentence. The implementation is where partners lose money, because it comes down to whether specific resources carry a specific tag with a specific value at the moment the spend occurs.
How PRM measures anything
AWS associates your contribution with existing AWS resource usage through what its documentation calls lightweight mechanisms: resource tags or user agent strings. There is no agent to install, no performance overhead, and no change to how the workload runs. That matters when you need a customer’s security team to approve it — you are asking to set tags, not to deploy software.
Two implementation routes, and one case where you do nothing:
- Resource tagging — you tag the AWS resources your solution causes to exist or to run.
- User agent string — your software identifies itself in API calls. AWS has been extending which services this covers, so a service that was not attributable at launch may be now.
- Nothing at all — if a customer buys your AMI or machine learning product through AWS Marketplace, attribution happens automatically. No implementation required. The tagging work exists for the consumption your solution drives around and after that purchase.
PRM also added support for the AWS Marketplace Metering Service for certain Marketplace products last month, which closes a gap for metered SaaS.
The tag key, precisely
This is the detail worth getting right the first time.
The key format AWS now directs partners to use is:
aws-apn-id-<partner-central-aws-account-id>For example, aws-apn-id-012345678901. AWS’s manual tagging guidance says to use this key “for all future attributions, including single-partner scenarios” — so there is no case where the older approach is the recommended one.
The older format you will still find in circulation is the key aws-apn-id carrying a value of pc:<marketplace-product-code>, where the product code comes from your AWS Marketplace listing. If your tagging was set up in the first weeks after launch, this is probably what you deployed. Check it against current guidance rather than assuming it still maps correctly.
One genuinely useful property: when more than one partner tags the same resource, each tagged partner receives attribution. Co-delivery with an SI or MSP is not zero-sum. You do not have to negotiate over who gets to tag.
Where the architecture decision comes in
PRM supports three architecture patterns, and which one you are in determines who has to cooperate:
- Partner account — all components run in your AWS account or VPC. You control the tagging end to end.
- Customer account — all components run in the customer’s account or VPC. Every tag depends on access you were granted.
- Hybrid — components spread across both.
Most real SaaS and managed-service deployments are hybrid, which is the hardest case: part of your footprint you control, part you have to keep tagged inside an environment that changes without telling you.
The prerequisite that blocks everything
Before tagging works, AWS asks you to create and link an AWS account representing your global business, then connect each individual AWS Marketplace account to it using Subsidiary Account Connections.
Those connections are only available after you have migrated to the new Partner Central experience. If you have not migrated, PRM tagging is not something you can finish this month — the account work has to come first, and the migration itself is irreversible with a permanent account choice that deserves deliberate thought.
With the migration cutoff reported for the end of June, the two pieces of work are effectively one project with a fixed order.
Four traps
Untagged spend is simply gone. This is the one that costs the most. Consumption that was not tagged while it happened does not get credited later, regardless of how well documented the engagement was. There is no backfill.
A one-time tagging pass measures one week. Customer environments add resources constantly. If your tagging ran as a script during onboarding and never again, your coverage has been decaying since. Tagging is a maintained state, not a task.
Not every service supports resource tagging. AWS publishes which services are supported for the tagging route. For anything outside that list, the user agent path is the option, and its coverage has been expanding.
Coverage without a number is a guess. “We’ve set up PRM” and “94% of eligible spend in this account is tagged” are different claims. Only one of them tells you what you are losing.
What good looks like
A working setup has four properties: the current tag key, deployed per target account, applied to new resources automatically as they appear, and a coverage percentage you can read per account.
That is the shape of CloudX’s PRM tagging — one CloudFormation stack per target account, automatic discovery and tagging of supported resources, continued tagging as resources are created, and per-account coverage reporting. It needs your AWS accounts connected in the new Partner Central, for the reason above.
If you are not sure which architecture pattern your product falls into, or what your real coverage is today, advisory is where to start. PRM attribution is also what makes co-sell measurable rather than anecdotal — the AWS account team can see what your solution drove.
The summary
PRM is not a dashboard you turn on. It is a tagging discipline with a specific key format, an account-structure prerequisite, and no retroactive credit. Get the key right, get the prerequisite done, and then make sure the tags keep applying to resources that did not exist when you set it up.