On August 1, a programmatic IAM access key was compromised through a third-party supply-chain incident. The key belonged to one of our accounts, but no human identity or MFA-protected session was involved. We detected the compromise and contacted cloud support within four hours, well inside the advertised 48-hour cancellation window. The case then remained unassigned for 14 days and is still unresolved after 20 days.
The current bill is $477,505.20, including a $4,800 contract-creation charge and $472,705.20 in usage fees for 47,270,520 units at $0.01 each in us-east-1. The usage count has stopped increasing, but the charges remain.
The confusing part is that the Marketplace console still says "Set up product." No License ID was issued, CloudTrail shows no Marketplace activity in our account after the initial compromise window, and nobody from our company ever registered for or logged into the seller's service.
My understanding is that consumption for a SaaS contract-with-consumption product is submitted by the seller through Marketplace metering APIs, using the entitlement's customer identifier. If that is correct, the buyer's AWS account may not be involved in the actual usage submission. Revoking the compromised key, deleting the attacker's IAM user, and applying service-control policies would not necessarily prevent seller-side metering.
I'm trying to clarify several points: Is usage metering entirely seller-side, and can charges be attributed without the buyer completing registration? Does the continued "Set up product" status reliably indicate that the ResolveCustomer or fulfillment process never completed, or could the console simply be stale? Is there an API, billing record, or other way for the buyer to verify whether and when registration occurred? Does the 48-hour public-contract cancellation process still apply when support delays handling the case, or is the deadline strictly based on elapsed time? Finally, can Marketplace usage charges—not just the contract fee—be reversed after a credential compromise? We are a small company and cannot absorb hundreds of thousands of dollars in consumption that we did not generate on a product we never activated.
4 Answers
A persistent “Set up product” message is useful evidence, but I would not treat it as definitive proof that no fulfillment or registration event occurred. Console status can lag behind backend records. Ask support for the agreement’s fulfillment state, customer identifier, ResolveCustomer history, seller-submitted usage records, and the timestamps associated with each event.
Treat this as both a billing dispute and a possible Marketplace abuse or seller-metering problem. Escalate through the payer account, your AWS account team or technical contact if you have one, and the seller’s billing or Marketplace operations team. Provide the compromise timeline, the time support was contacted, CloudTrail evidence, screenshots showing the uncompleted setup state, and a request to place the disputed charges on hold while the usage records are audited. Whether the 48-hour remedy survives support delay is something AWS must decide under the contract, but the timing evidence should be documented clearly.
The seller is normally notified when a subscription is created, even if the customer never follows the setup link. If the subscription can be canceled from the Marketplace agreement page, canceling it may stop future billing, although that does not automatically resolve already-submitted usage. Since there was no obvious cancellation control in this case, AWS should verify whether the agreement is active, pending fulfillment, or stuck in an inconsistent state.
For SaaS Marketplace products, the seller can generally submit usage from its own infrastructure for billing to the customer’s AWS account. That means activity does not necessarily appear as Marketplace API calls or CloudTrail events in the buyer account. The key question is whether the seller’s metering records were valid and tied to the correct entitlement, so both AWS and the seller need to investigate the customer identifier, timestamps, and submitted quantities.
The product’s business model matters here. Some Marketplace products meter entirely through the seller, while others use different fulfillment or billing arrangements, so the exact listing configuration should be confirmed.
The fact that the console still shows setup is exactly why the agreement status and metering history need to be checked together rather than relying on the front-end label alone.