Container Listing Checklist
A step-by-step readiness checklist for publishing a container product on AWS Marketplace — with a clear split of what Automatum does for you versus what stays your engineering and business responsibility.
Not a container product?
- Shipping an Amazon Machine Image buyers run on EC2? → AMI (Server) Listing Checklist
- Selling cloud-hosted SaaS billed through AWS? → Listings Management
- Not yet an approved AWS seller? → Before You Begin
High-level brief
A container product ships one or more container images (optionally a Helm chart) that buyers run on Amazon ECS, EKS, or Fargate. It's a "bring your own artifact" model: AWS Marketplace lists, meters, and bills the product, but you build, push, and (for paid pricing) instrument the images.
Three parties do the work. Read this table first — it frames every checklist item below:
| Marker | Who | What it means |
|---|---|---|
| 🟢 | Automatum builds/automates | We configure and submit it for you through the platform and API |
| 🟡 | Automatum advises — you own it | Lives in your application code or is your business decision; we guide, you execute |
| 🔵 | AWS handles | Automatic on the AWS side once your product is set up correctly |
The honest boundary
Automatum can create your listing, configure delivery options, pricing and dimensions, help you author the Helm chart / CloudFormation template, and submit and track everything with AWS. Automatum cannot build or harden your container images, and cannot write the entitlement/metering (RegisterUsage / MeterUsage) calls into your software — that code has to live inside the container you ship. We can only advise on those and on pricing strategy.
Delivery options at a glance
| Delivery option | How buyers deploy | Automatum can create the listing? | AWS reference |
|---|---|---|---|
| Container image | Pull image(s) → run on ECS / EKS / Fargate | 🟢 Yes | Container products |
| Helm chart | helm install on EKS / self-managed k8s | 🟢 Yes — we can help author the chart | Container requirements |
| EKS console add-on | Deploy from the EKS console add-on catalog | 🟢 Yes | Add a container version |
The checklist
Work top-to-bottom. The 🟡 items are the ones that take real engineering time on your side; budget for them early.
1. Prepare & push images — 🟡 your engineering
- [ ] Build Linux-based image(s); EKS console add-ons must support both AMD64 and ARM64
- [ ] 🟢 Automatum/AWS provision AWS Marketplace-owned Amazon ECR repositories — all images (including open-source bases like
nginx) must be pushed there; external registries (Docker Hub, ECR Public, Quay) are not allowed - [ ] Push with the standard ECR flow (
GetAuthorizationToken→docker push/helm push); the tag identifies the version (up to 70 repos/product) - [ ] 🔵 AWS security-scans each image version layer-by-layer (typically completes within an hour)
→ AWS: Container product getting started · Add a version
2. Choose delivery option(s) — 🟢 Automatum / 🟡 your template
- [ ] Pick up to 4 delivery options per version (max 50 images each): Container image, Helm chart, or EKS console add-on
- [ ] Target environments: ECS, EKS, Fargate (all); Helm also runs on EKS Anywhere / self-managed / on-prem k8s
- [ ] Helm charts must reference images only through
values.yamlvariables ({{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}), passhelm lint+helm template(Helm 3.19+), and collect no secrets in config - [ ] Paid Helm/CFN products need the service-account override
DefaultValue "${AWSMP_SERVICE_ACCOUNT}"(EKS Anywhere adds${AWSMP_LICENSE_SECRET}) - [ ] 🟢 Automatum can help you author and lint the Helm chart / CloudFormation template to these rules — see Deployment templates below
Helm-on-EKS Quick Launch is discontinued
AWS discontinued Quick Launch for Helm chart deployments on Amazon EKS on March 1, 2026. Existing deployments keep running; buyers now deploy via standard Helm commands or container images on ECS. Plan delivery instructions accordingly. → Container products
3. Decide pricing — 🟡 your decision, Automatum configures
- [ ] Pick a model: Free, BYOL, per-task/per-pod hourly, fixed monthly, custom metered (up to 24 dimensions), or contract (± consumption) — container pricing
- [ ] 🟡 Pricing strategy (which model, what numbers) is your business call — Automatum advises but cannot decide it for you
- [ ] 🟢 Once decided, Automatum configures the model and dimensions on the listing
4. Integrate metering / entitlement — 🟡 your application code
- [ ] 🟡 Hourly / monthly: call
RegisterUsageonce at container launch (within 6 hours) — it does both entitlement check and metering; on any non-throttling error at startup your code must terminate the container - [ ] 🟡 Custom/usage-based: call
MeterUsageonce per hour per dimension from your software - [ ] 🟡 Contract: use AWS License Manager for entitlement
- [ ] Integrate the SDK directly into your own container — AWS ships no drop-in metering sidecar; any sidecar is a pattern you build
- [ ] Credentials: EKS requires IRSA (not Pod Identity or node roles); ECS requires task IAM roles; attach
AWSMarketplaceMeteringRegisterUsage
→ AWS: Billing/metering integration · RegisterUsage · MeterUsage
5. Create, test & submit — 🟢 Automatum / 🔵 AWS
- [ ] 🟢 Automatum creates the listing, delivery options, pricing, and usage instructions and submits the change request, then tracks status with AWS
- [ ] 🟡 Launch at least one task/pod in
us-east-1so AWS Seller Operations can verify metering logs (testing on EKS alone covers both ECS and EKS) - [ ] 🔵 AWS review to Public typically takes 2–4 calendar weeks; test in the Limited state (and create private offers) first
Deployment templates (Helm / CloudFormation)
A Helm chart or CloudFormation delivery needs a template that deploys your product self-service in the buyer's account. This is the classic place ISVs get stuck, and where 🟢 Automatum can help most directly by drafting and reviewing the template with you.
AWS's hard requirements for Helm charts (we validate against these):
- Container image references defined exclusively in
values.yamlthrough variables — never hardcoded elsewhere (this lets AWS regionalize image references) - Explicit image tags required; no conditional logic that bypasses the
values.yamlreferences - Must pass
helm lintandhelm templateon Helm 3.19+ - Config schema must not collect secrets — reference Kubernetes Secret names instead
- Usage instructions must not tell buyers to edit any file other than
values.yamlor use--set - Paid products: include the service-account override
DefaultValue "${AWSMP_SERVICE_ACCOUNT}"; EKS Anywhere products add a license-secret overrideDefaultValue "${AWSMP_LICENSE_SECRET}" - EKS console add-ons additionally require an
aws_mp_configuration_schema.json, a templatized namespace (notdefault/kube-system/kube-public), and IRSA, not Pod Identity, for PAYG
What "Automatum helps" means here
We don't magically generate a correct chart from nothing — your architecture is yours. We draft the skeleton, move image references into values.yaml, wire the required override parameters, and lint it against the rules above so it clears AWS review on the first pass. The infrastructure decisions stay yours.
→ AWS: Container product requirements
Who does what — responsibility matrix
The single most important table on this page. Use it to plan staffing.
Getting listed
| Task | Automatum | You (your app / business) | AWS |
|---|---|---|---|
| Build & harden container image(s) | — | 🟡 Owns | — |
| Pass image security scan | advises | 🟡 Remediates | 🔵 Scans |
| Push images to Marketplace ECR | 🟢 Provisions repos | 🟡 Pushes | — |
| Author Helm chart / CloudFormation template | 🟢 Helps author + lints | 🟡 Owns architecture | 🔵 Reviews |
| Decide pricing model & numbers | advises | 🟡 Decides | — |
| Configure listing, delivery options, pricing, dimensions | 🟢 Builds | reviews | — |
Entitlement/metering (RegisterUsage / MeterUsage / License Manager) code | advises | 🟡 Implements in container | 🔵 Meters & bills |
| Write usage instructions | 🟢 Drafts | reviews | — |
| Submit change request & track status | 🟢 Automates | — | 🔵 Reviews & publishes |
Ongoing maintenance
| Task | Automatum | You (your app / business) | AWS |
|---|---|---|---|
| Ship a new image / chart version | 🟢 Submits version | 🟡 Builds, pushes & scans | 🔵 Auto-publishes (no re-review) |
| Edit listing metadata | 🟢 Edits & submits | reviews | 🔵 Auto-publishes |
| Change pricing | 🟢 Submits change | 🟡 Decides | 🔵 90-day buyer notice; effective 1st of month |
| Create / manage private offers | 🟢 Automates | 🟡 Sets terms | 🔵 Delivers to buyer |
| Renewals & metering monitoring | 🟢 Alerts & reports | 🟡 Acts on alerts | 🔵 Bills |
Effort & time estimates
Two different things people conflate: your internal effort (engineering days you must staff) and AWS's clock (calendar time you wait). Plan for both.
Your internal effort (customer-side)
Rough engineering effort to complete each task, assuming a competent team new to Marketplace. The 🟡 rows are yours; 🟢 rows shrink dramatically with Automatum.
| Task | Type | Typical effort |
|---|---|---|
| Build & harden container image(s) | 🟡 | 1–3 days |
| Remediate image-scan findings | 🟡 | 0.5–2 days |
| Push images to Marketplace ECR | 🟡 | 0.5–1 day |
| Author Helm chart / CloudFormation template (DIY) | 🟡 | 2–5 days |
| ↳ …with Automatum's help | 🟢 | ~0.5–1 day |
Metering/entitlement SDK (RegisterUsage / MeterUsage) | 🟡 | 3–8 days (only if paid metered) |
| License Manager integration | 🟡 | 2–5 days (only if contract) |
| Configure listing, delivery options, pricing | 🟢 | ~0.5 day (Automatum-assisted) |
| Write usage instructions | 🟡 | ~0.5 day |
Where the time really goes
The long poles are image/chart preparation and metering integration — both 🟡 items inside your codebase. Automatum removes the listing-and-submission overhead, but it can't remove engineering that lives in your product. A BYOL or free container is dramatically faster to launch than a usage-metered one.
AWS's clock (you wait)
| Milestone | AWS timeline |
|---|---|
| Container image scan | ~1 hour |
| Initial product publication (manual review) | 2–4 calendar weeks |
| Recommended lead time before a launch/event | 45 days |
| Pricing-change buyer-notification window | 90 days, effective the 1st of the following month |
| Subsequent version / metadata updates | Self-service, published without re-review |
→ AWS: Product submission & review
The listing process
The first publish is reviewed and slow; every update afterward is self-service and fast. That asymmetry is the single most useful thing to internalize.
Approved AWS sellerTax + banking verified
🟡 Build image + push to Marketplace ECR
🔵 AWS image scan
🟢 Automatum: configure listingDelivery options & pricing
🟡 Your app: RegisterUsage / MeterUsageOnly if paid
🟢 Automatum: submit change request to AWS
🔵 AWS review2–4 weeks
Limited stateTest in us-east-1 + create private offers
Public listing 🎉
Ongoing maintenance
Live container listing
New image / chart version🟢 submit / 🔵 auto-publish
Metadata edit🟢 auto-publish
Pricing change🔵 90-day notice
Private offers🟢 automated
Renewals + metering🟢 alerts / 🟡 you act
Automatum keeps the maintenance loop turning: version submissions and metadata edits go out self-service (no AWS re-review), pricing changes respect AWS's 90-day notice window, and renewals and metering are monitored with alerts so nothing lapses silently.
Common pitfalls
- Pushing images to an external registry. All images — including open-source bases — must live in the AWS Marketplace-owned ECR repos.
- Using the wrong metering call. Containers use
RegisterUsage(hourly/monthly) orMeterUsage(custom); AMIs useMeterUsage. Wiring the wrong one fails review. - Expecting a metering sidecar from AWS. There isn't one — the SDK goes inside your own container.
- Hardcoding image references outside
values.yaml. Helm charts that don't centralize image refs are rejected. - Using Pod Identity or node roles on EKS. Metering requires IRSA.
- Relying on Helm-on-EKS Quick Launch. It was discontinued March 1, 2026 — document standard Helm/ECS deployment instead.
- Not budgeting AWS's clock. Even a perfect submission waits 2–4 weeks. Start 45 days before any launch.
Your complete checklist
Everything above condensed into one tick-through list for your container launch. Expand it, copy it into your own tracker, and work top-to-bottom.
📋 Full container listing checklist — click to expand
Before you start — prerequisites
- [ ] Approved AWS Marketplace seller account with tax + banking/disbursement verified (Before You Begin)
- [ ] Automatum connected to your AWS seller account
1. Prepare & push images — 🟡 you
- [ ] Linux-based image(s) built · EKS add-ons support AMD64 + ARM64
- [ ] All images pushed to Marketplace-owned ECR (no Docker Hub / ECR Public / Quay)
- [ ] Versions tagged · image security scan passes
2. Delivery option(s) — 🟢 Automatum helps
- [ ] Up to 4 options chosen (Container image / Helm chart / EKS console add-on)
- [ ] Target environments confirmed (ECS / EKS / Fargate / EKS Anywhere / self-managed)
- [ ] Helm: image refs only via
values.yaml· passeshelm lint+helm template(3.19+) · no secrets - [ ] Paid:
${AWSMP_SERVICE_ACCOUNT}override (+${AWSMP_LICENSE_SECRET}for EKS Anywhere)
3. Pricing — 🟡 you decide / 🟢 Automatum configures
- [ ] Model chosen (Free / BYOL / per-task-or-pod hourly / monthly / custom metered / contract)
- [ ] Model + up to 24 dimensions configured on the listing
4. Metering / entitlement — 🟡 your code
- [ ] Hourly / monthly →
RegisterUsageat launch (terminate container on non-throttling error) - [ ] Custom / usage-based →
MeterUsagehourly per dimension - [ ] Contract → AWS License Manager
- [ ] SDK integrated inside your own container (no AWS-provided sidecar)
- [ ] EKS uses IRSA · ECS uses task role ·
AWSMarketplaceMeteringRegisterUsageattached
5. Test, submit & go live — 🟢 Automatum / 🔵 AWS
- [ ] Listing, delivery options, pricing, usage instructions submitted
- [ ] Test task/pod launched in
us-east-1for Seller Operations verification - [ ] AWS review passed (2–4 weeks)
- [ ] Tested in the Limited state; private offers created
- [ ] Product Public 🎉
Ongoing maintenance
- [ ] New image/chart versions submitted as needed (self-service, no re-review)
- [ ] Pricing changes respect the 90-day buyer-notice window
- [ ] Renewals + metering monitored via Automatum alerts
What's next
- AMI (Server) Listing Checklist — the parallel guide for server products
- AWS Marketplace overview — features, IAM setup, metering constraints
- Listings Management — the platform workflow for creating and editing listings
- Metering Guide — reporting usage through Automatum
- Private Offers — custom deals you can create even in the Limited state
- AWS Marketplace listing checklist (AWS) — AWS's own canonical checklist
Need Help?
Planning a container launch? Contact hello@automatum.io or use the in-app chat — we can review your delivery options, draft your Helm chart or CloudFormation template, and map out the metering integration your team owns.