Selling SaaS through AWS Marketplace requires more than a product page. A seller must register an eligible entity, choose a supported product and pricing model, integrate subscription and entitlement workflows, pass product review, operate public and private offers, and reconcile marketplace events with its own product, CRM, finance, and support systems.
This implementation-oriented guide focuses on SaaS sellers. AWS also supports other product types, and current AWS documentation remains authoritative for eligibility, fees, regions, policies, and portal steps.
AWS Marketplace seller lifecycle
- Create and secure a dedicated seller AWS account.
- Register as a seller and complete applicable tax, banking, and identity requirements.
- Select the product type, delivery model, pricing, regions, and legal terms.
- Design subscription, entitlement, metering, fulfillment, and customer-onboarding flows.
- Create listing metadata and product configuration.
- Test technical and commercial lifecycle paths.
- Submit for review, resolve findings, and publish.
- Operate public offers, private offers, reporting, renewals, and support.
AWS recommends a dedicated seller account and requires seller registration before publication. Requirements differ by residence, product, paid or free status, and jurisdiction; verify them before investing in integration.
Step 1: define product architecture and responsibility
Document the application plane, control plane, buyer-facing components, seller account components, external dependencies, customer data path, identity, tenant isolation, logging, support, backup, and deletion. AWS’s SaaS guidelines cover setup, security, customer information, usage, and architecture expectations and are updated over time.
Decide whether the service qualifies for any “deployed on AWS” designation only after reviewing the current definition. Do not infer eligibility because a database or one service runs on AWS.
Step 2: choose the contract and pricing model
Map how customers buy today: fixed subscription, contract term, seats, usage, tiers, or a combination. Then confirm which AWS Marketplace SaaS pricing and contract model can represent it without confusing entitlement.
Write precise answers to these questions:
- What event creates a subscription or agreement?
- What entitlement does each dimension or contract grant?
- What is reported as metered usage, at what cadence, and with which idempotency rules?
- What happens on upgrade, renewal, expiration, cancellation, refund, or failed payment?
- How are an existing direct customer and a new marketplace customer distinguished?
Step 3: build a reliable fulfillment flow
A buyer who subscribes is directed through fulfillment and registration. The seller must resolve the marketplace token or event, identify the AWS customer, create or link the correct application tenant, and grant only the purchased entitlement.
Design the flow as a state machine rather than one request handler:
- Receive and validate the marketplace identity or subscription signal.
- Persist the marketplace customer and product relationship before side effects.
- Associate it with the correct application organization through authenticated onboarding.
- Apply entitlement idempotently.
- Record audit events and surface an actionable status to support.
- Retry transient failures without creating duplicate tenants or grants.
Do not trust browser parameters alone to grant access. Keep marketplace identifiers, application tenant IDs, agreement state, offer ID where relevant, entitlement state, and lifecycle timestamps in an auditable mapping.
Step 4: process lifecycle notifications
Subscription and entitlement changes must reach the product even when no user is signed in. Use the AWS-supported notification and API pattern for the selected SaaS model. Handle duplicate, delayed, and out-of-order events safely. Reconcile periodically rather than assuming every event was delivered and processed exactly once.
Create alerts for unmatched customers, failed entitlement changes, metering rejection, stale agreements, and product access that differs from the marketplace state.
Step 5: create a trustworthy listing
The listing should state the product’s outcome, supported use cases, architecture and deployment responsibility, data flow, prerequisites, pricing dimensions, onboarding sequence, support, refund or cancellation information, security resources, and documentation. Use accurate product screenshots and a diagram that distinguishes seller-managed and buyer-managed components.
Make claims reviewable. Avoid unsupported superlatives, ambiguous pricing, hidden prerequisites, logos without permission, or screenshots that do not represent the delivered service. Review every link and keep operational documentation accessible after publication.
Step 6: test the full lifecycle
| Test | Expected evidence |
|---|---|
| New subscription | Correct customer mapping, tenant, entitlement, and audit event |
| Repeated callback or event | No duplicate account, grant, or invoice behavior |
| Wrong or existing application account | Safe linking or explicit resolution path |
| Upgrade or entitlement change | Access changes once and reconciles |
| Cancellation or expiration | Defined access and data-retention behavior |
| Metered usage failure | Retry, alert, and finance-visible exception |
| Private offer | Correct buyer account, dates, pricing, terms, and activation |
Public and private offers
A public offer creates the base listing and terms. AWS describes private offers as negotiated pricing, EULA terms, or custom solutions extended to designated buyer accounts. Sellers need at least one active public listing to be eligible to issue private offers under the documented rules.
Build an internal offer checklist: legal buyer, AWS account ID, management versus linked account, country, product, pricing, duration, renewal type, expiration, EULA, sales documents, approval, offer URL, acceptance verification, and CRM agreement mapping. A correct commercial agreement addressed to the wrong AWS account cannot be accepted by the intended buyer.
Channel Partner Private Offers
AWS Marketplace Channel Partner Private Offers allow an authorized channel partner to resell an ISV product through a selling authorization and extend a private offer to a buyer. This adds wholesale terms, partner margin, authorization lifecycle, and seller-of-record considerations. Define who owns the customer, support, renewal, reporting, and any services before authorizing resale.
Operations after launch
- Reconcile marketplace reports, agreements, metering, application access, and CRM records.
- Monitor failed onboarding, lifecycle events, usage reports, and support paths.
- Review listing accuracy after product, region, architecture, pricing, and policy changes.
- Track offer-to-acceptance time, activation, usage, gross margin, renewal, and churn.
- Test cancellation, refund, renewal, and entitlement recovery procedures.
- Limit seller and private-offer permissions and retain useful audit logs.
Common launch failures
- Building the listing before confirming buyer demand and pricing.
- Coupling marketplace purchase to manual tenant provisioning.
- Failing to make callbacks and events idempotent.
- Ignoring existing-customer migration and renewal paths.
- Publishing vague pricing dimensions that sales cannot explain.
- Treating private offers as documents rather than account-specific executable transactions.
- Leaving finance and customer success without agreement or entitlement visibility.
Stay in the loop
Get the latest multicloud hosting updates delivered to your inbox.