AWS Marketplace now supports Concurrent Agreements for SaaS and professional services products, enabling multiple active purchases for the same product within a single Amazon Web Services (AWS) account. Starting June 1, 2026, AWS Marketplace requires all new software-as-a-service (SaaS) products to support updated integration requirements .

This guide walks you through the technical migration steps to implement Concurrent Agreements. It covers the transition from Amazon Simple Notification Service (Amazon SNS) to Amazon EventBridge, API updates, and best practices for managing multiple licenses within your SaaS integration.

Here’s what applies to you:

  • New listings created after June 1, 2026 – Concurrent Agreements is enabled by default for your product.
  • Existing listings created before June 1, 2026 – Concurrent Agreements is opt-in for your existing products. The guide below under Opt-In Steps walks you through the integration steps.

You may opt in to Concurrent Agreements on an existing listing or build on a newly enabled one. In either case, your integration must be updated to handle multiple active agreements per customer. The API changes, event schema updates, and license management logic described in this guide apply in both cases.

Instead of opting in, another migration approach is to create a new Concurrent Agreements enabled listing, restrict the legacy one, and facilitate customer migration as contracts renew. This can be a good option if you prefer to keep your legacy listing untouched. It lets you migrate customers gradually rather than updating your existing integration in place.

The business case for using Concurrent Agreements

Previously, the one-agreement-per-account limitation forced sellers to use workarounds such as agreement-based offers, duplicate product listings, or cancel-and-reissue processes.

With Concurrent Agreements, buyers can accept multiple offers for the same product within a single AWS account, each with independent terms and pricing.

You can now support:

  • Flexible procurement – Multiple separate agreements for the same SaaS product on one AWS account, removing the one-contract-per-product restriction
  • Independent terms – Multi-team procurement where different business units purchase independently with their own negotiated contracts
  • Seamless expansion – New projects and capacity additions without disrupting existing agreements or requiring finance and procurement approval chains

What’s changing: LicenseArn and the new architecture

AWS Marketplace is introducing LicenseArn , a new parameter across key APIs. Previously, you identified subscriptions using product ID and customer identifier. With multiple active agreements per product, you need a unique identifier for each agreement.

LicenseArn uniquely identifies each software license that customers receive when purchasing your product through AWS Marketplace.

Why LicenseArn matters:

  • Differentiates between multiple active licenses for identical products
  • Tracks usage against specific rate cards
  • Provides accurate attribution to the correct agreement

Key differences between agreement ID and LicenseArn:

  • Agreement ID represents the commercial or legal arrangement between parties
  • LicenseArn represents the actual authorization or right to use the software

Note: For future-dated agreements, the LicenseArn is generated on the agreement start date, which might occur months after the agreement ID is created.

When you upgrade your SaaS product to support Concurrent Agreements, you’ll experience these changes:

  • New LicenseArn parameter – Unique identifier for each license granted with every new agreement
  • EventBridge migration – Transition from Amazon SNS to Amazon EventBridge for subscription notifications (SNS doesn’t support LicenseArn)
  • API updates – Three core APIs now support LicenseArn
  • CustomerIdentifier deprecation – Starting June 1, 2026, new SaaS products should use CustomerAWSAccountId instead of CustomerIdentifier

Supported product types

  • Professional services are automatically enabled for all listings, with no action required on your part.
  • New listings created after June 1, 2026, have Concurrent Agreements enabled by default.

Existing SaaS listings created before June 1, 2026, will not have Concurrent Agreements enabled automatically. Sellers who intend to use Concurrent Agreements for those products can opt in using AWS Marketplace Management Portal.

Opt-In Steps:

  1. Log in to the AWS Marketplace Management Portal.
  2. Go to the Settings tab.
  3. Open the Products section.
  4. Select your SaaS product from the list.
  5. Enable Concurrent Agreements: Toggle or select the option to enable Concurrent Agreements for the product.

For new listings

If you’re creating a new SaaS listing after June 1, 2026, Concurrent Agreements is enabled by default. Build your integration from scratch using the following approach:

  • Use Amazon EventBridge (not Amazon SNS) for subscription notifications.
  • Use LicenseArn and CustomerAWSAccountId as your primary identifiers from the start.
  • Design your data schema with LicenseArn as the primary key.
  • Choose your tenant provisioning strategy before launch.

Integration roadmap for an existing listing

If you have an existing listing, you can opt in to Concurrent Agreements by completing the following high-level steps:

  1. Migrate from Amazon SNS to Amazon EventBridge
  2. Update API integration to support LicenseArn
  3. Update database schema
  4. Design your registration experience

The next sections explain these steps.

Migrate from Amazon SNS to Amazon EventBridge

Amazon SNS notifications for AWS Marketplace SaaS products are being replaced with Amazon EventBridge notifications, so you need to transition your subscription notifications from Amazon SNS to Amazon EventBridge. SNS doesn’t send the LicenseArn parameter, making it difficult to distinguish between concurrent subscriptions. EventBridge, on the other hand, includes LicenseArn and improved event handling capabilities. For more information, refer to Amazon SNS notifications for SaaS products.

Before you transition your notifications from Amazon SNS to Amazon EventBridge, you need to complete the following prerequisites:

  1. Create EventBridge rules for relevant event types in the US East (N. Virginia) – us-east-1 region
  2. Set up your targets, such as Amazon Simple Queue Service (Amazon SQS) queues or AWS Lambda
  3. Update your event handlers to process the new event patterns.

To transition your subscription notifications from Amazon SNS to Amazon EventBridge, follow the steps in Managing SaaS subscription events with Amazon EventBridge in the AWS Marketplace Seller Guide.

When you configure EventBridge, your rules should handle the following event types that AWS Marketplace sends for SaaS products:

  • Purchase agreement created – This event is sent to the manufacturer or proposer when a new agreement is established.
  • Purchase agreement ended – This event is sent to the manufacturer or proposer when an agreement expires. It provides a 1-hour window for final usage submissions.
  • License updated – This event is sent to the manufacturer when entitlements are modified.
  • License deprovisioned – This event is sent to the manufacturer when entitlements are fully revoked.

Update API integration to support LicenseArn

Three core APIs now support LicenseArn: ResolveCustomer, GetEntitlements, and BatchMeterUsage.

1. ResolveCustomer API now returns LicenseArn in addition to the buyer AWS account ID and product code. To capture and persist LicenseArn for use in subsequent API requests, you need to update your integration.

The response includes the following fields:

{
  "CustomerIdentifier": "string",
  "ProductCode": "string",
  "CustomerAWSAccountId": "string",
  "LicenseArn": "string"
}

2. GetEntitlements API now accepts LICENSE_ARN as a filter option and includes LicenseArn in all responses. You need to use the LicenseArn filter to retrieve entitlements for specific agreements and map entitlements to internal license keys using the returned LicenseArn.

Use the LICENSE_ARN filter in your request:

"LICENSE_ARN": ["string"]

Each entitlement object that the API returns includes:

"LicenseArn": "string"

3. BatchMeterUsageAPI now requires LicenseArn in usage records for opted-in products. You need to include LicenseArn in all usage records and track and report usage separately for each license.

Add LicenseArn to each UsageRecord:

"LicenseArn": "string"

Note: For opted-in products, LicenseArn is required, and ProductCode is not supported.

Update database schema

Redesign your data schema to make LicenseArn the primary identifier. This approach simplifies provisioning and billing by attributing usage to a specific purchase license rather than to the customer who might hold multiple licenses. To update your schema, replace any existing primary keys based on CustomerIdentifier or ProductCode with LicenseArn, and update your database tables and application logic to query and store records by LicenseArn.

Design your registration experience

In deciding how your application handles Concurrent Agreements, you need to consider the following design questions:

  • Will customers manually associate licenses with their application user accounts, or will licenses be applied automatically?
  • Will customers be able to switch between licenses during active use of your application?
  • How will your metering services select the correct LicenseArn (rate card) when reporting usage?

There are three tenant provisioning strategies you can consider :

  1. Separate tenants – you create individual tenants for each license or purchase. This works well for organizations requiring departmental separation
  2. Unified tenant – you map multiple licenses to a single tenant, which works well for organizations with consolidated billing
  3. Buyer’s choice – To provide maximum flexibility to your buyers, you can allow them to select their preferred approach.

Migration for usage metering

Starting June 1, 2026, new SaaS products must use CustomerAWSAccountId (instead of CustomerIdentifier) and LicenseArn(instead of ProductCode).

Usage metering changes

For consumption-based products, including LicenseArn in BatchMeterUsage requests helps correctly attribute usage when customers have multiple active subscriptions.

For usage-based billing products, AWS Marketplace provides approximately a 1-hour window for submitting final usage records after agreement termination:

  • Window start – The Purchase Agreement Ended event is sent at agreement expiration.
  • Window close – The License Deprovisioned event is sent when entitlements are fully revoked (usage reporting will no longer be accepted).

The Purchase Agreement Ended events don’t include the LicenseArn. Because BatchMeterUsage requires LicenseArn, maintain an accurate mapping between LicenseArn and active agreement IDs throughout the subscription lifecycle. Capture this mapping from License Updated events, which include both identifiers.

Important billing consideration

During migration, both LicenseArn-based and legacy ProductCode-based BatchMeterUsage requests will function at the same time. The one-time-per-hour rate limit applies independently to each method, which means you could accidentally report usage twice per hour. Pay careful attention when enabling LicenseArn-based integration in production environments.

Required updates for AWS SDKs

To fully support Concurrent Agreements, ensure your integration uses the latest AWS Marketplace SDKs that support LicenseArn

SDK support for LicenseArn

The LicenseArn parameter is already supported in current public AWS SDKs. You can use the latest versions of AWS SDK for JavaScript v3 (@aws-sdk/client-marketplace-meteringand @aws-sdk/client-marketplace-entitlement-service) and AWS SDK for Python (Boto3) for AWS Marketplace Metering and Entitlement services.

These SDKs already include LicenseArn support in the ResolveCustomer, GetEntitlements, and BatchMeterUsage APIs.

SDK update requirements

The following steps describe the actions you perform to use the LicenseArn parameter:

  1. Update to the latest SDK versions to access LicenseArn parameter support.
  2. Update your code to handle the new LicenseArn field in API responses.
  3. Update request structures to include LicenseArn where required.

Backfilling LicenseArn for existing customers

Before you can route usage and entitlement calls by LicenseArn, map your existing customers to their corresponding LicenseArn values. AWS Marketplace provides two mechanisms depending on whether your product uses contract-based or usage-only pricing:

  1. For contract-based pricing (contract-only or contracts with consumption), use the GetEntitlements API to backfill CustomerAWSAccountId and LicenseArn by calling the CUSTOMER_AWS_ACCOUNT_IDfilter
  2. For usage-only pricing, AWS Marketplace will provide the mapping through Amazon Simple Storage Service (Amazon S3) buckets containing CSV files with CustomerIdentifier, CustomerAWSAccountId, AgreementId, and LicenseArn.

Conclusion

For new sellers, these requirements are built in from the start. For existing sellers, migration requires updating APIs and SDKs, redesigning data schemas, and updating customer experiences. Completing this migration positions your product to take advantage of enhanced licensing capabilities while maintaining service continuity.

All SaaS products created after June 1, 2026, will have concurrent agreements enabled. If you’re planning to enable concurrent agreements for your product before this date or have concerns about the change, refer to the Managing Concurrent Agreements enrollment workshop.

Resources

About Authors

Tanvi Upadhyay

Tanvi is a Technical Account Manager at Amazon Web Services (AWS), where she partners with enterprise customers in the automotive and manufacturing industries to optimize their AWS deployments and achieve their business goals. Prior to her current role, she was an AWS Cloud Support Engineer on the Linux team, helping customers troubleshoot and resolve complex technical challenges.

Philipp Sacha

Philipp is a Partner Solutions Architect at Amazon Web Services (AWS). In this role, he supports partners in developing products on top of AWS and bringing those products to AWS Marketplace. Philipp has a background in IT infrastructure and joined AWS in 2015. Prior to joining AWS, he held several roles as project manager, head of IP infrastructure, and lead architect mainly in the IT infrastructure area.

About Author

Leave a Reply

Leave a Reply

Your email address will not be published. Required fields are marked *