AWS Marketplace Concurrent Agreements: Opt In or Relist?

AWS Marketplace Concurrent Agreements lets one AWS account hold several active agreements for the same product. SaaS listings created before June 1, 2026 don’t have it until the seller opts in or relists, and both paths start with the same integration work.

---

Your SaaS listing went up before June 1, 2026, and a customer wants a second agreement beside the one they hold: another business unit buying on its own terms, or an expansion that shouldn’t disturb the original contract. Whether a second agreement beats an amendment is the commercial question, answered in co-terming and expanding marketplace agreements. This post is the other half: opt in or relist, and what your integration has to change first.

AWS is clear that the choice doesn’t spare you the work: “In either case, your integration must be updated to handle multiple active agreements per customer.” It decides where that work lands.

Which AWS listings have to opt in to Concurrent Agreements?

SaaS listings created before June 1, 2026. AWS switched Concurrent Agreements on for every Professional Services listing when it announced the feature on February 26, 2026, and SaaS listings created after June 1, 2026 have it by default.

Concurrent Agreements is AWS Marketplace’s support for more than one active agreement for the same product in one AWS account, each with its own terms and pricing. LicenseArn is the identifier AWS gives each license a buyer receives, one per agreement. With two agreements in one account, the license identifies a subscription and the customer no longer can, which is what makes this an integration project.

Listing	Concurrent Agreements	What you do
SaaS, created after June 1, 2026	On by default	Build on LicenseArn and CustomerAWSAccountId from the start
SaaS, created before June 1, 2026	Off until you opt in	Update the integration, then opt in or relist
Professional Services	On since February 26, 2026	Nothing

AWS’s upgrade guide sets no deadline for older listings, and existing integrations keep working. What waiting costs is the second purchase: until the listing opts in, a buyer can hold only one active agreement for it per AWS account.

Should you opt in or create a new listing?

Opt in when the listing carries agreements you can’t wait out; relist when you would rather leave the old listing untouched and move customers as their contracts renew. AWS supports both, and its opt-in request asks you to explain why relisting won’t work.

The opt-in is a request through the AWS Marketplace Contact Us form, under Product Configuration / Integration and the Concurrent Agreements Support subcategory. AWS’s template asks for your seller account ID, product ID and number of active agreements, then leaves a line to finish: “I am unable to create a new listing because: [Explain the specific circumstances that prevent you from creating a new listing and migrating customers]”. The alternative, in AWS’s words: “create a new Concurrent Agreements enabled listing, restrict the legacy one, and facilitate customer migration as contracts renew.”

	Opt in the existing listing	Create a new listing
Existing agreements	Stay on the same product	Stay on the old listing until each one renews onto the new one
Integration effort	Update the live integration in place and backfill LicenseArn for current customers	Build the new integration on LicenseArn from the start, and run the old one until its last customer moves
What AWS asks you to justify	Why you can’t create a new listing and migrate customers	Nothing: new SaaS listings have Concurrent Agreements by default
The old listing	Unchanged, with Concurrent Agreements added	Restricted, then eventually retired
Fits best when	Long or numerous agreements would hold customers on the old listing too long	You want the old listing untouched and can wait for renewals

Relisting also leaves the old listing to retire, and retiring a marketplace listing has its own rules for what existing buyers keep. Either way, the integration work comes first: AWS’s announcement opens the opt-in to sellers “who have completed the integration work.”

What has to change in the integration first?

Four things, in the order AWS’s guide gives them: subscription events move to EventBridge, three APIs carry LicenseArn, your records re-key on the license, and licenses get mapped to tenants. Metering is part of the second step and gets its own section, because it hides a billing trap.

1. Move subscription events from SNS to EventBridge. In AWS’s words, “SNS doesn’t send the LicenseArn parameter, making it difficult to distinguish between concurrent subscriptions.” Create the rules in us-east-1 for the event source aws.agreement-marketplace, and handle at least Purchase Agreement Created, Purchase Agreement Ended, License Updated and License Deprovisioned.
2. Carry LicenseArn through three APIs.
   • ResolveCustomer returns LicenseArn and CustomerAWSAccountId at registration, and AWS says to store both. New SaaS integrations get no CustomerIdentifier back, so nothing new should key on it.
   • GetEntitlements filters by LICENSE_ARN and returns LicenseArn on every entitlement, so you provision against one agreement rather than the whole account.
   • BatchMeterUsage takes LicenseArn and CustomerAWSAccountId on each record: “For opted-in products, LicenseArn is required, and ProductCode is not supported.”
   • Current AWS SDKs already support the field in all three.
3. Re-key your records on LicenseArn. AWS’s instruction is to “replace any existing primary keys based on CustomerIdentifier or ProductCode with LicenseArn.” Backfill current customers from the Agreements data feed or the License IDs in the Agreements and Renewals dashboard; for contract pricing, GetEntitlements filtered by CUSTOMER_AWS_ACCOUNT_ID returns them directly. A future-dated agreement gets its license on the start date, which “might occur months after the agreement ID is created,” so hold it on the agreement ID until then.
4. Decide how licenses map to tenants. AWS describes three models: a tenant per license, one tenant holding several, or the buyer’s choice. Decide with it how your metering will “select the correct LicenseArn (rate card) when reporting usage” for a tenant holding more than one, because the meter depends on the answer.

How do you switch metering without billing twice?

Stop sending ProductCode-based records before you send the first LicenseArn-based one, and never send both for the same customer in the same hour. AWS’s BatchMeterUsage reference is blunt about the alternative: it “will result in duplicate billing.”

Both methods work during the migration. AWS’s guide: “The one-time-per-hour rate limit applies independently to each method, which means you could accidentally report usage twice per hour.” So the usual way to prove a new meter, running old and new side by side, is the one thing not to do here.

Cut over in one direction:

1. Pick the hour. Usage before it is reported by product code; usage from it onward, by license.
2. Send the last ProductCode-based records, then switch that reporter off. AWS’s instruction: “stop sending ProductCode before you start sending LicenseArn.”
3. Start the LicenseArn-based reporter with ProductCode left off the request; the license “identifies both the product and the specific agreement.”
4. Watch for InvalidLicenseException. BatchMeterUsage fails the call with this HTTP 400 error when a LicenseArn is wrong, doesn’t match the customer, or the usage falls outside the license’s activation period.

One more deadline belongs in the new meter. For usage-priced products, AWS’s September 11, 2026 update to the guide spells it out: after a License Deprovisioned event you have one hour to report the customer’s remaining usage, and then BatchMeterUsage rejects it.

What changes if Suger runs your AWS integration?

Less, but not nothing. Suger creates a separate entitlement for each concurrent agreement, tied to its LicenseArn, and adds that LicenseArn when it reports usage to AWS, so usage you already send to Suger’s Metering API by entitlement ID needs no change. Three steps in Suger’s opt-in runbook for Concurrent Agreements stay with you:

• Keep EventBridge active on the AWS integration (its details show agreementEventBridgeEnrolled as true); it is how Suger receives each agreement’s LicenseArn. If Suger may not create IAM resources in your account, deploy the standalone EventBridge stack yourself, then register the rule in the Suger Console (Edit, then Register existing setup) so Suger tracks it rather than creating its own.
• Send the opt-in request, with one extra ask: that AWS allow-list Suger’s test buyer account.
• Run the validation round. In Suger’s documented steps, AWS reviews test transactions before it completes the migration: a small test private offer per pricing model you sell, accepted from that test account, plus a test usage record if you meter usage.

Where it stops:

• Orb and Metronome usage syncs don’t yet tell a buyer’s concurrent agreements apart, so their usage can land on the wrong agreement.
• Chargebee’s hourly sync won’t guess: if more than one of the buyer’s entitlements covers the start of a billing period it hasn’t seen before, it skips that period, so none of its Chargebee-priced usage reaches the marketplace.
• Container products are the exception. Suger’s documentation warns that opting one in breaks its usage metering: BatchMeterUsage rejects its records once they carry a LicenseArn, and usage must then be reported from inside the container, which Suger doesn’t do on your behalf.

For Orb, Metronome and Chargebee, Suger recommends reporting usage through its Metering API directly.

Frequently asked questions

Do existing AWS Marketplace SaaS listings get Concurrent Agreements automatically?

No. SaaS listings created before June 1, 2026 need an opt-in request to AWS. SaaS listings created after that date have Concurrent Agreements by default, and every Professional Services listing has had it since February 26, 2026.

Is there a deadline to opt in an older listing?

AWS’s upgrade guide doesn’t set one, and AWS says existing integrations keep working. The June 1, 2026 requirement applies to new SaaS products. Until a listing opts in, a buyer can hold only one active agreement for it per AWS account.

What does AWS ask for in an opt-in request?

Your seller account ID, product ID and number of active agreements, plus the circumstances that prevent you from creating a new listing and migrating customers. The request goes through the AWS Marketplace Contact Us form, under Concurrent Agreements Support.

What happens if ProductCode and LicenseArn records are sent in the same hour?

The customer is billed twice. AWS’s BatchMeterUsage reference says sending both for the same customer within the same hour results in duplicate billing. Stop sending ProductCode-based records before you start sending LicenseArn-based ones.

Do sellers who meter through Suger need to change anything?

Not in how they report usage, if they use Suger’s Metering API by entitlement ID: Suger creates one entitlement per concurrent agreement, tied to its LicenseArn. They still keep EventBridge active, send the opt-in request and run the validation offers. Orb, Metronome, Chargebee and container products carry caveats.

Takeaways

• SaaS listings created before June 1, 2026 opt in by request, and AWS’s template asks why you can’t relist instead.
• Opting in and relisting need the same integration work: EventBridge events, LicenseArn in three APIs, records keyed on the license.
• Switch metering in one direction: last ProductCode record, then first LicenseArn record, never both for a customer in the same hour.
• Through Suger, entitlement-ID metering needs no change; Orb, Metronome, Chargebee and container products are the exceptions.

The part of this migration that goes wrong quietly is usage landing on the wrong agreement. Suger’s billing and metering automation reports each agreement’s usage against its own LicenseArn, so a second agreement bills as a second agreement.