--- title: "Upgrading to AWS Marketplace Concurrent Agreements" url: https://www.suger.io/resources/blog/aws-marketplace-concurrent-agreements-opt-in-or-relist/ canonical: https://www.suger.io/resources/blog/aws-marketplace-concurrent-agreements-opt-in-or-relist/ type: Blog description: "Opt an older AWS Marketplace SaaS listing into Concurrent Agreements or relist it: what AWS asks, then the EventBridge, LicenseArn and metering changes." --- # Upgrading to AWS Marketplace Concurrent Agreements > Canonical HTML version: https://www.suger.io/resources/blog/aws-marketplace-concurrent-agreements-opt-in-or-relist/ 1. [Home](/) 2. / 3. [Resources](/resources/) 4. / 5. [Blog](/resources/blog/) 6. / 7. AWS Marketplace Concurrent Agreements: Opt In or Relist? # AWS Marketplace Concurrent Agreements: Opt In or Relist? SaaS listings created before June 1, 2026 don't get Concurrent Agreements until you opt in or relist. Either way, the integration has to change first. [![Stacy Wu](/authors/stacy-wu.jpg)](/resources/blog/author/stacy-wu/) [Stacy Wu](/resources/blog/author/stacy-wu/) Sep 24, 2026 ![AWS Marketplace Concurrent Agreements: Opt In or Relist?](/images/blog/aws-marketplace-concurrent-agreements-opt-in-or-relist/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-marketplace-concurrent-agreements-opt-in-or-relist%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Marketplaces. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-marketplace-concurrent-agreements-opt-in-or-relist%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Marketplaces. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-marketplace-concurrent-agreements-opt-in-or-relist%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Marketplaces. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Faws-marketplace-concurrent-agreements-opt-in-or-relist%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20AWS%2C%20Marketplaces. "Summarize with Perplexity") Table of Contents - [Which AWS listings have to opt in to Concurrent Agreements?](#which-aws-listings-have-to-opt-in-to-concurrent-agreements) - [Should you opt in or create a new listing?](#should-you-opt-in-or-create-a-new-listing) - [What has to change in the integration first?](#what-has-to-change-in-the-integration-first) - [How do you switch metering without billing twice?](#how-do-you-switch-metering-without-billing-twice) - [What changes if Suger runs your AWS integration?](#what-changes-if-suger-runs-your-aws-integration) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _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](/resources/blog/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](/resources/blog/retire-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](https://doc.suger.io/aws-marketplace/integration/#enable-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](/platform/billing-metering/) reports each agreement’s usage against its own `LicenseArn`, so a second agreement bills as a second agreement. ## Sources Primary sources for the platform rules cited above. Last verified September 24, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure. - [AWS Marketplace Blog: Complete guide to upgrading your SaaS product to AWS Marketplace Concurrent Agreements](https://aws.amazon.com/blogs/awsmarketplace/complete-guide-to-upgrading-your-saas-product-to-aws-marketplace-concurrent-agreements/) — Published June 8, 2026 and updated June 12 (opt-in path), July 24 (LicenseArn backfill) and September 11 (final usage window): default versus opt-in by listing date, the opt-in template quoted, the new-listing alternative, SNS lacking LicenseArn, the four roadmap steps, the three tenant strategies, future-dated licenses, and the both-methods billing warning - [AWS What's New: AWS Marketplace now supports multiple purchases of SaaS & Professional Services products from the same account](https://aws.amazon.com/about-aws/whats-new/2026/02/concurrent-agreements-february/) — Posted February 26, 2026: Professional Services listings on by default that day, support required for new SaaS products from June 1, 2026, and opt-in for sellers who have completed the integration work - [AWS Marketplace Metering Service: BatchMeterUsage](https://docs.aws.amazon.com/marketplace/latest/APIReference/API_marketplace-metering_BatchMeterUsage.html) — ProductCode left off LicenseArn requests, duplicate billing when both are sent for a customer in the same hour, stop ProductCode before starting LicenseArn, existing integrations keep working, and InvalidLicenseException - [AWS Marketplace Metering Service: ResolveCustomer](https://docs.aws.amazon.com/marketplace/latest/APIReference/API_marketplace-metering_ResolveCustomer.html) — Returns LicenseArn and CustomerAWSAccountId to be stored, and leaves CustomerIdentifier unpopulated for new SaaS integrations - [AWS Marketplace Entitlement Service: GetEntitlements](https://docs.aws.amazon.com/marketplace/latest/APIReference/API_marketplace-entitlements_GetEntitlements.html) — The LICENSE\_ARN filter, LicenseArn on every returned entitlement, and the CUSTOMER\_AWS\_ACCOUNT\_ID filter - [AWS Marketplace Seller Guide: Managing SaaS subscription events with Amazon EventBridge](https://docs.aws.amazon.com/marketplace/latest/userguide/saas-eventbridge-integration.html) — The aws.agreement-marketplace event source, the SaaS event list, and the one-hour final usage window after License Deprovisioned - [AWS Marketplace Seller Guide: Amazon SNS notifications for SaaS products](https://docs.aws.amazon.com/marketplace/latest/userguide/saas-notification.html) — SNS is being replaced by EventBridge, existing SNS integrations continue to function, and the message formats identify a customer and a product - [Suger docs: Integration (AWS Marketplace)](https://doc.suger.io/aws-marketplace/integration/) — Suger behaviour: the EventBridge check, the opt-in request fields including why not a new listing, the test buyer allow-list and validation offers, the Container warning, and registering a customer-owned EventBridge rule - [Suger docs: Usage Metering](https://doc.suger.io/get-started/metering/) — Suger behaviour: one entitlement per concurrent agreement tied to its LicenseArn, and the Orb, Metronome and Chargebee usage-sync caveats ## Keep reading - [AWSAWS Marketplace Private Offer Errors: Why a Buyer Can't AcceptSep 19, 2026](/resources/blog/buyer-cannot-accept-aws-private-offer/) - [AWSWhat the Deployed on AWS Badge Proves, and What It Doesn'tSep 19, 2026](/resources/blog/deployed-on-aws-badge/) - [AWSAWS Marketplace Storefront vs Buy with AWSAug 24, 2026](/resources/blog/aws-marketplace-storefront-vs-buy-with-aws/) - [AWSSelling Data Products on Cloud MarketplacesAug 20, 2026](/resources/blog/selling-data-products-on-a-marketplace/) [Browse every post on the Suger Blog](/resources/blog/) ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.