AWS Marketplace Metering Agent Skill: What It Builds

The AWS Marketplace metering agent skill is AWS-authored guidance that an AI coding agent loads through the AWS MCP Server to build, deploy and test a usage-based (pay-as-you-go) SaaS metering integration in your own seller account. It generates the pipeline that reports usage to AWS. Your application still produces the usage, and what reaches production is still yours to review.

---

Acme sells a usage-priced API on AWS Marketplace, and its listing sits at Limited visibility while the integration is built. Its engineering lead can now ask a coding assistant to set up AWS Marketplace metering for the product, naming a dimension, a Region and a stage, and watch an agent read the listing, deploy two CloudFormation stacks into Acme’s seller account and dry-run the result. AWS describes the old route to the same integration as “documentation, workshops, and trial-and-error API calls.”

AWS announced the skill as generally available on September 30, 2026, and published its architecture on October 13, 2026, including what it leaves to the seller. This guide reads both for an engineering lead deciding what to build: what the skill builds, what AWS says stays yours, and three questions that decide between building with it and a managed metering system across marketplaces.

It assumes a usage-priced product. Choosing between contract and usage pricing comes first, and AWS Marketplace contract pricing vs usage pricing covers that choice.

What does the AWS Marketplace metering agent skill build?

The AWS Marketplace metering agent skill builds a serverless metering integration for a SaaS subscriptions (pay-as-you-go) product: two AWS SAM templates, deployed into your seller account as CloudFormation stacks, and the code they run. First, the agent reads your listing through the AWS Marketplace Catalog API, confirms it’s usage-based, reports which dimensions are externally metered and resolves the product code. AWS’s announcement lists mismatched dimension names among the “common mistakes” that “create billing gaps discovered days later,” and says the skill “cross-validates dimensions against the seller’s actual product configuration.”

After you confirm, it deploys under an IAM role with a limited permission boundary:

Stack	Part	What it does
Events	An EventBridge rule for aws.agreement-marketplace events, an SQS queue with a dead-letter queue, and a Lambda function	Writes one record per agreement to a DynamoDB subscribers table, including the licenseArn metering needs
Events	A scheduled deprovisioning sweep	Marks a license inactive only after its final metering window has closed
Metering	A registration endpoint on API Gateway, protected by AWS WAF, and a Lambda function	Exchanges the buyer’s registration token for customer identifiers through ResolveCustomer, and stores any registration fields you collect in a separate customer profile table
Metering	A scheduled discovery function and an SQS queue	Finds usage rows awaiting metering and queues one message per license per hour
Metering	An aggregation function and an aggregated usage table	Sums rows by license, buyer account, dimension and hour, with conditional writes to avoid duplicates
Metering	A submission function	Sends batches through BatchMeterUsage and records the result on each record

Testing comes in two steps. A dry run “validates the flow but doesn’t call the BatchMeterUsage API operation,” and for the live test, your own AWS Marketplace account or any other AWS account subscribes as a test buyer once you’ve added it to the allowlist. AWS adds that the skill “helps existing sellers inspect, debug, and analyze their metering records,” so it isn’t only for a first build.

The design is careful about failure. A failed agreement event is routed to a dead-letter queue, aggregation writes conditionally to avoid duplicates, a license stays active until its final metering window has closed, and each agreement keeps its own licenseArn, which AWS requires of new products: “Starting June 1, 2026, new SaaS products must use CustomerAWSAccountId (instead of CustomerIdentifier), LicenseArn (instead of ProductCode).”

The submission rules are AWS’s, unchanged. BatchMeterUsage takes up to 25 records per call, in a request under 1 MB, for one product, and “Usage records aren’t accepted 24 hours or more after an event.” Records for the previous billing month are accepted until 06:00 UTC on the first day of the next month. The limits and errors behind rejected usage records covers what the submitter works within.

What does AWS say stays yours?

Getting usage into the pipeline, reviewing and shipping what it generates, and anything outside a pay-as-you-go SaaS product on AWS. AWS puts the first one plainly: “The skill provisions the metering backend, but getting usage into it is the part you build.”

	The skill builds or runs	Still yours
Usage data	The tables, and the hourly pipeline that aggregates and submits usage	Writing usage rows into the usage table “from whatever accounts your workload runs in,” keyed by license ARN with timestamps, in the row format the skill documents
Buyer registration	A registration backend that can capture extra buyer fields on request	A branded registration page or custom domain, which “you must build and maintain,” and updating the product’s fulfillment URL
Testing	A dry run, then guidance for a live test	Allowlisting a test buyer account and subscribing it while the product is at Limited visibility
Production code	Integration code and SAM templates generated from your configuration	Reviewing the code “against your own security and compliance requirements before deploying it to production”
Published products	Direct deployment while the listing is at Limited visibility	For a published product, shipping the code it hands you “through your own deployment pipeline”
Pricing model	SaaS subscriptions, with at least one usage dimension	SaaS contracts, contracts with metered usage, and AMI and container products
Marketplaces	AWS Marketplace’s ResolveCustomer, BatchMeterUsage and agreement events	Usage you sell through any other marketplace
Resources	Two CloudFormation stacks in your seller account	Running them, and deleting the DynamoDB tables separately, because they’re retained when you delete the stacks

Your application still writes the usage

The pipeline meters only the rows that reach its usage table, and the code that writes them isn’t part of it: “The metering agent skill doesn’t deploy that part.” Deciding which events count, which tenant they belong to and which license that tenant bought through is product work, and it stays in your product.

Two of AWS’s rules don’t move to the skill either. “You’re responsible for ensuring that your product’s metering records are successfully transmitted and received,” and once you report a buyer’s usage of a dimension, “you cannot amend the record.” The submitter records each result; acting on a rejected one is yours, and why a usage report fails after the buyer accepted covers the results that point at the customer rather than the record.

A published product goes through your own pipeline

Limited visibility is the skill’s deployment boundary: “Limited is the only visibility the skill deploys directly. For a published product, it hands you the code to review and ship through your own deployment pipeline.” Publishing has its own gate, too. During publishing, “the AWS Marketplace Operations team will test that the SaaS application sends the metering record successfully before allowing the product to be published.” For a product that’s already selling, the skill’s output enters your change control like any other code.

One pricing model, one marketplace

The prerequisites call for a listing “that uses the SaaS subscriptions pricing model and at least one usage dimension,” and the skill’s published source on GitHub states the rest: “SaaS Contract, Contract with Consumption Pricing (CCP), and AMI/Container are out of scope.” AWS’s pricing page names that middle model SaaS contracts with pay-as-you-go, where buyers “are also billed an additional metered rate for usage on top of the contract price.” Everything the skill generates calls AWS Marketplace’s APIs, so usage sold through Microsoft, Google Cloud or Oracle needs an integration of its own.

How does reporting usage through Fours compare?

In Fours, your application sends usage to one Metering API instead of a table you run, and Fours validates it, aggregates it every hour and reports it to the marketplace behind the entitlement, in the format of that entitlement’s pricing model. Fours sells the managed option, so this comparison uses only what AWS documents for the skill and what Fours documents for its own product. Either way your product produces the usage; what changes is what receives it, and who runs everything after that.

	Build with the skill	Report through Fours
Where usage goes	Rows in a DynamoDB table in your seller account	A request to the Fours Metering API for an entitlement, or a CSV upload
Marketplaces	AWS Marketplace	Entitlements on AWS, Microsoft, Google Cloud and Oracle
AWS pricing models	SaaS subscriptions	Subscription and Contract entitlements
Concurrent Agreements	A licenseArn stored for each agreement	A separate entitlement for each agreement, with its LicenseArn added to every report
Checks before submission	Dimensions cross-validated against your product, and built-in guardrails	Every request checked on arrival, with HTTP 400 for a dimension the entitlement doesn’t carry or a negative quantity
Duplicates	Conditional writes to the aggregated table	An API request id already received for that entitlement in the last 15 days is rejected; a CSV upload isn’t de-duplicated
When a marketplace rejects usage	The result recorded on each record	A red Report Failed status, with plain-language guidance for errors Fours recognizes
Who runs it	You: the stacks, the code and its review	Fours runs the hourly reporting
AMI and container products	Out of scope	Not supported; Fours rejects that usage with HTTP 400

The two differ most on contracts. For an AWS contract with usage metering, Fours has an optional setting, Commit with additional usage metering: it accumulates every usage record, compares the total with the commit and reports only the usage that exceeds it. Fours’ AWS pricing guide describes the same shape as “commitment plus overages,” with the prepaid commitment consumed first and only the true overage reported to AWS.

Should you build with the skill or use a managed metering system?

Build with the skill when your metering is AWS-only, pay-as-you-go only and owned by a team that will run it as billing infrastructure; when any of those isn’t true, what’s left over is what a managed metering system covers. Three questions decide it:

1. Is every product you meter a pay-as-you-go SaaS listing on AWS? A SaaS contract with metered usage, or an AMI or container product, sits outside the skill’s scope.
2. Will you meter usage for the same product on Microsoft, Google Cloud or Oracle? The skill reports to AWS Marketplace only, so each other marketplace is another integration, with its own APIs and rules.
3. Will a team own the pipeline as production billing infrastructure? That means reviewing what the skill generates, shipping changes for a published product through your own pipeline, running the stacks, and carrying AWS’s responsibility for every record arriving.

If the answers are yes, no and yes, build with the skill: AWS wrote it around its own metering rules, and you keep code you control. Any other answer leaves a piece for something else to handle, whether that’s another pricing model, another marketplace or the operating work.

What do you need before you run the skill?

A seller account with registration complete, a SaaS subscriptions listing held at Limited visibility, AWS’s build tools, and the AWS MCP Server in your coding assistant. AWS’s prerequisites:

1. An AWS Marketplace seller account with registration complete, including tax and banking details. AWS recommends a dedicated seller account that you “maintain separately from your operational workloads.”
2. A SaaS listing on the SaaS subscriptions pricing model with at least one usage dimension, kept at Limited visibility, and its product entity ID from the AWS Marketplace Management Portal.
3. The AWS SAM CLI and AWS CLI version 2, plus a local Python 3 runtime or Docker for sam build, with credentials for your seller account.
4. The AWS MCP Server, a managed server that gives agents access to AWS through MCP, configured in your coding assistant. AWS says the skill works in any assistant that supports MCP, “including Amazon Q Developer, Kiro, and other MCP-compatible clients, with no plugin installation required.”

Add one item of your own: decide which service writes the usage rows, and from which accounts, before the stacks exist.

Frequently asked questions

What is the AWS Marketplace metering agent skill?

It’s AWS-authored guidance that an AI coding agent loads through the AWS MCP Server to build, deploy and test a usage-based (pay-as-you-go) SaaS metering integration in your seller account. AWS announced it as generally available on September 30, 2026.

Does the metering agent skill write the usage data?

No. AWS says your own application writes the usage rows into the skill’s DynamoDB usage table, keyed by license ARN with timestamps. The skill deploys the pipeline that aggregates those rows by the hour and submits them through BatchMeterUsage.

Can the skill deploy to a published AWS Marketplace product?

Not directly. AWS says “Limited is the only visibility the skill deploys directly.” For a published product, the skill hands you the code to review and ship through your own deployment pipeline.

Does the skill support SaaS contracts?

No. It needs a listing on the SaaS subscriptions pricing model, and the skill’s published source puts SaaS contracts, contracts with consumption pricing, and AMI and container products out of scope.

Which AI coding assistants can use the skill?

Any assistant that supports MCP, through the AWS MCP Server, including Amazon Q Developer and Kiro. AWS says no plugin installation is required, and the skill’s source is also published on GitHub.

How is reporting usage through Fours different?

Your application sends usage to the Fours Metering API instead of a table you run. Fours validates it, aggregates it hourly and reports it to AWS, Microsoft, Google Cloud or Oracle, and an optional setting reports only the usage above a contract’s commit.

Takeaways

• The skill builds a complete AWS metering pipeline: agreement events, buyer registration, hourly aggregation, submission through BatchMeterUsage, a deprovisioning sweep and a dry run.
• Your application still writes the usage rows, and AWS still holds you responsible for every record arriving.
• It deploys directly only at Limited visibility. For a published product, its code goes through your own review and deployment pipeline.
• It covers SaaS subscriptions on AWS. Contracts with metered usage, AMI and container products, and other marketplaces need something else.
• Build with it when metering is AWS-only, pay-as-you-go only and owned by a team; otherwise, a managed system covers what it leaves out.

Fours takes usage through one Metering API and reports it to AWS, Microsoft, Google Cloud and Oracle, with a separate entitlement for each AWS concurrent agreement and an optional setting that reports only the usage above a contract’s commit. See how Fours’ billing and metering runs that reporting for you.