AWS Product Listings: Ask Who Operates Each Layer

An AWS label tells you less than an operating-responsibility map. To evaluate a product, ask which service is involved, which organization operates the application, and who owns configuration, data recovery and access decisions. “Runs on AWS” is not a complete answer to any of those questions.

The October 3, 2026 AWS catalogue lists declared associations for Graded Prompts and CloudPloy. These declarations do not identify every AWS service or establish an independently audited deployment.

Start with the product's relationship to your account

A hosted marketplace and a deployment tool can have very different relationships with a customer's infrastructure. A user of a marketplace may never connect an AWS account. A deployment workflow might request access to resources that the customer owns.

Graded Prompts describes a curated prompt marketplace. CloudPloy describes deployment from an AI tool. These descriptions suggest different questions; they do not prove a particular credential flow or hosting arrangement.

Before comparing reliability or security claims, establish whether you are buying a hosted application, connecting your own cloud account, or receiving software to operate yourself.

Divide responsibilities by layer

AWS's shared responsibility model distinguishes its responsibilities for cloud infrastructure from customer responsibilities that depend on the chosen service. Application code, data and configuration cannot simply be assumed to become the provider's responsibility.

Turn that distinction into a worksheet for the product under review. Include identity, application deployment, database configuration, backups, logs and incident communication. For each row, name the party that acts and the evidence supporting the assignment.

If two parties both appear responsible, clarify the handoff. If neither does, you have found a question to resolve before adoption.

Ask about recovery as a workflow

“Backups enabled” is an incomplete answer. Ask what is backed up, how a recovery request is initiated and what the recovered system can actually do. A restored database without the corresponding file objects or required configuration may not restore the user workflow.

Request evidence appropriate to the purchase: public documentation, a contractual description or a demonstration in an authorized environment. Do not infer a recovery objective from the cloud provider's reputation.

Keep claims about observed tests separate from stated policies. Both can be useful, but they answer different questions.

Inspect account boundaries

For a service connected to your AWS account, identify which resources it can create, change or delete. Ask how access is revoked and what continues running after disconnection.

For a fully hosted service, focus on account separation, export options and the support path for mistaken access. You may not need to inspect infrastructure credentials at all.

This distinction prevents a long infrastructure checklist from obscuring the actual buyer risk. The relevant evidence follows the relationship, not the technology logo.

Record the unresolved facts

A short decision record should state the product workflow, known services, operating owners, available recovery evidence and unresolved dependencies. Date it so later changes can be compared.

Avoid translating an AWS association into claims about a region, certification, uptime or data residency. Those require their own evidence.

The AWS deployment credential guide covers connected-account permissions in more detail. For a broader founder decision about choosing manageable infrastructure, the solo SaaS stack guide provides the surrounding context.