Skip to content

AMI (Server) Listing Checklist

A step-by-step readiness checklist for publishing an AMI (server) product on AWS Marketplace — with a clear split of what Automatum does for you versus what stays your engineering and business responsibility.

Not an AMI product?

High-level brief

An AMI product ships your software as an Amazon Machine Image that buyers launch on EC2. It's a "bring your own artifact" model: AWS Marketplace lists, meters, and bills the product, but you build, harden, and (for usage-based or contract pricing) instrument the AMI.

Three parties do the work. Read this table first — it frames every checklist item below:

MarkerWhoWhat it means
🟢Automatum builds/automatesWe configure and submit it for you through the platform and API
🟡Automatum advises — you own itLives in your application code or is your business decision; we guide, you execute
🔵AWS handlesAutomatic on the AWS side once your product is set up correctly

The honest boundary

Automatum can create your listing, configure pricing and dimensions, help you author the CloudFormation template, and submit and track everything with AWS. Automatum cannot build or harden your AMI, and cannot write the metering (MeterUsage) or licensing (License Manager) calls into your software — that code has to live inside the AMI you ship. We can only advise on those and on pricing strategy.

Delivery methods at a glance

Delivery methodHow buyers deployAutomatum can create the listing?AWS reference
Single AMILaunch AMI as an EC2 instance🟢 YesAMI products
AMI + CloudFormationCloudFormation stack (multi-instance / clustered)🟢 Yes — we can help author the templateCloudFormation templates

The checklist

Work top-to-bottom. The 🟡 items are the ones that take real engineering time on your side; budget for them early.

1. Build & harden the AMI — 🟡 your engineering

  • [ ] Build your source AMI in US East (N. Virginia) us-east-1 — required as the source Region
  • [ ] Use HVM virtualization, EBS-backed, x86-64 or 64-bit ARM, ≤ 5 TB, no encrypted snapshots
  • [ ] Ship a currently supported OS (no end-of-life software) and keep the AMI ≤ 2 years old
  • [ ] Enforce IMDSv2-only (--imds-support v2.0 at registration)
  • [ ] Remove all authorized_keys, hardcoded secrets, private keys, and default/blank passwords
  • [ ] Set sshd_config PasswordAuthentication no and disable password-based root login
  • [ ] Do not bake in AWS credentials — use an EC2 instance IAM role instead

→ AWS: Best practices for building your AMIs · AMI product policies

2. Grant AWS access & pass the security scan — 🟡 your engineering / 🔵 AWS scans

  • [ ] Create an IAM role trusting AWS Marketplace → "Marketplace – AMI Assets Ingestion" with the managed AWSMarketplaceAmiIngestion policy (this replaces the old account-sharing method)
  • [ ] Open the scanner's reachable ports (SSH/RDP) to the AWS scanning subnets so the automated scan can run
  • [ ] 🔵 AWS scans for critical/high CVEs and security best practices (self-service scan usually completes in < 1 hour) — remediate and re-run until it passes

→ AWS: Give AWS Marketplace access to your AMI

3. Choose a delivery method — 🟢 Automatum / 🟡 your template

  • [ ] Single AMI (buyer launches one instance), or AMI + CloudFormation for clustered / multi-instance deployments (max 3 templates per single-AMI product)
  • [ ] If CloudFormation: the AMI ID must be a template parameter (AWS::EC2::Image::Id), never hardcoded; no secrets in parameters (use NoEcho); no 0.0.0.0/0 on SSH/RDP; must deploy self-service in the buyer's account; one architecture diagram per template (1100×700 px)
  • [ ] 🟢 Automatum can help you author and review the CloudFormation template against these rules — see CloudFormation deployment templates below

→ AWS: AMI with CloudFormation template requirements

4. Decide pricing — 🟡 your decision, Automatum configures

  • [ ] Pick a model: Free, BYOL, Hourly (± Annual/Monthly), Contract, or Usage-based (custom metering)AMI pricing models
  • [ ] 🟡 Pricing strategy (which model, what numbers) is your business call — Automatum advises but cannot decide it for you
  • [ ] 🟢 Once decided, Automatum configures the pricing and up to 24 dimensions on the listing

5. Integrate metering / entitlement — 🟡 your application code

  • [ ] 🔵 Hourly / Annual / Monthly: metering is automatic — AWS bills off the product code baked into the AMI. No SDK work.
  • [ ] 🟡 Usage-based (custom): your software must call MeterUsage hourly from the EC2 instance, using the instance role's temporary credentials, to the in-Region endpoint. Handle retries/fail-open. (Note: RegisterUsage is container-only — AMIs use MeterUsage.)
  • [ ] 🟡 Contract pricing: integrate AWS License Manager to read entitlements and provision features — License Manager does no enforcement; that's your app's job

→ AWS: Custom metering (MeterUsage) · Metering API overview

6. Create & submit the listing — 🟢 Automatum

  • [ ] 🟢 Automatum creates the listing metadata, pricing, dimensions, and usage instructions, then submits the change request and tracks status with AWS
  • [ ] 🔵 AWS reviews and publishes the initial version in ~7–10 business days; test in the Limited state (and create private offers) before going Public

CloudFormation deployment templates

An AMI + CloudFormation product needs a template that deploys your software self-service in the buyer's account — typically for clustered or multi-instance architectures. 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 (we validate against these):

  • AMI ID referenced via a template parameter, resolved by AWS to the Region-specific AMI at deploy time — never hardcoded
  • No secrets in parameters; sensitive inputs use NoEcho; templates cannot create long-term access keys (use IAM roles)
  • No insecure defaults — no 0.0.0.0/0 ingress to SSH (22), RDP (3389), or database ports
  • Must launch successfully in every enabled Region and be Availability-Zone-agnostic
  • Nested-stack templates hosted in a publicly readable S3 bucket, referencing MPS3BucketName / MPS3BucketRegion / MPS3KeyPrefix
  • An architecture diagram per template (1100×700 px, current AWS icons); max 3 templates per single-AMI product

What "Automatum helps" means here

We don't magically generate a correct template from nothing — your architecture is yours. We draft the skeleton, wire the AMI-ID parameter and Region mappings, remove insecure defaults, and lint it against the rules above so it clears AWS review on the first pass. The infrastructure decisions stay yours.

→ AWS: CloudFormation template requirements


Who does what — responsibility matrix

The single most important table on this page. Use it to plan staffing.

Getting listed

TaskAutomatumYou (your app / business)AWS
Build & harden the AMI🟡 Owns
Pass CVE / security scanadvises🟡 Remediates🔵 Scans
Author CloudFormation template (multi-instance)🟢 Helps author + lints🟡 Owns architecture🔵 Reviews
Decide pricing model & numbersadvises🟡 Decides
Configure listing, pricing, dimensions🟢 Buildsreviews
Metering (MeterUsage) / entitlement (License Manager) codeadvises🟡 Implements in AMI🔵 Meters & bills
Write usage instructions🟢 Draftsreviews
Submit change request & track status🟢 Automates🔵 Reviews & publishes

Ongoing maintenance

TaskAutomatumYou (your app / business)AWS
Ship a new AMI version🟢 Submits version🟡 Builds & scans AMI🔵 Auto-publishes (no re-review)
Edit listing metadata🟢 Edits & submitsreviews🔵 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.

TaskTypeTypical effort
Build & harden AMI🟡2–5 days
Remediate security-scan findings🟡0.5–2 days
Author CloudFormation template (DIY)🟡2–5 days
↳ …with Automatum's help🟢~0.5–1 day
Metering SDK integration (MeterUsage)🟡3–8 days (only if usage-based)
License Manager integration🟡2–5 days (only if contract)
Configure listing metadata, pricing, dimensions🟢~0.5 day (Automatum-assisted)
Write usage instructions🟡~0.5 day

Where the time really goes

The long poles are AMI hardening 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 hourly AMI with no custom metering is dramatically faster to launch than a usage-based one.

AWS's clock (you wait)

MilestoneAWS timeline
AMI self-service security scan< 1 hour
Initial product publication (manual review)7–10 business days
Recommended lead time before a launch/event45 days
Pricing-change buyer-notification window90 days, effective the 1st of the following month
Subsequent version / metadata updatesSelf-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 & harden AMIus-east-1 · IMDSv2 · no secrets
🔵 AWS security scan
🟢 Automatum: configure listingPricing & dimensions
🟡 Your app: MeterUsage / License ManagerOnly if usage-based or contract
🟢 Automatum: submit change request to AWS
🔵 AWS review7–10 business days
Limited stateTest + create private offers
Public listing 🎉

Ongoing maintenance

Live AMI listing
New AMI 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

  • Building the AMI outside us-east-1. The source AMI must be there; AWS clones it to other Regions.
  • Using the wrong metering call. AMIs use MeterUsageRegisterUsage is container-only. Wiring the wrong one fails review.
  • Hardcoding the AMI ID or secrets in CloudFormation. Both are automatic rejections — use parameters and NoEcho.
  • Leaving metering integration to the end. It's the longest 🟡 pole; start it in parallel with AMI hardening.
  • Assuming Automatum can pass the scan for you. We advise; remediation happens in your AMI.
  • Not budgeting AWS's clock. Even a perfect submission waits 7–10 business days. Start 45 days before any launch.

Your complete checklist

Everything above condensed into one tick-through list for your AMI launch. Expand it, copy it into your own tracker, and work top-to-bottom.

📋 Full AMI 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. Build & harden the AMI — 🟡 you

  • [ ] Source AMI built in us-east-1
  • [ ] HVM · EBS-backed · x86-64 or ARM64 · ≤ 5 TB · no encrypted snapshots
  • [ ] Currently-supported OS · AMI ≤ 2 years old
  • [ ] IMDSv2-only enforced
  • [ ] No authorized_keys, secrets, or default/blank passwords · PasswordAuthentication no
  • [ ] No baked-in AWS credentials (use an instance IAM role)

2. Grant access & pass the scan — 🟡 you / 🔵 AWS

  • [ ] AWSMarketplaceAmiIngestion IAM role created
  • [ ] Scanner ports (SSH/RDP) reachable from AWS scanning subnets
  • [ ] CVE / best-practice scan passes (re-run until clean)

3. Delivery method — 🟢 Automatum helps

  • [ ] Single AMI, or AMI + CloudFormation (≤ 3 templates)
  • [ ] If CloudFormation: AMI ID as parameter · no secrets (NoEcho) · no 0.0.0.0/0 on SSH/RDP · self-service · arch diagram per template

4. Pricing — 🟡 you decide / 🟢 Automatum configures

  • [ ] Model chosen (Free / BYOL / Hourly ± Annual/Monthly / Contract / Usage-based)
  • [ ] Pricing + up to 24 dimensions configured on the listing

5. Metering / entitlement — 🟡 your code

  • [ ] Hourly / annual / monthly → nothing to build (AWS meters via product code)
  • [ ] Usage-based → MeterUsage integrated (hourly, in-Region, instance role)
  • [ ] Contract → AWS License Manager integrated

6. Submit & go live — 🟢 Automatum / 🔵 AWS

  • [ ] Listing, pricing, dimensions, usage instructions submitted
  • [ ] AWS review passed (~7–10 business days)
  • [ ] Tested in the Limited state; private offers created
  • [ ] Product Public 🎉

Ongoing maintenance

  • [ ] New AMI 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

Need Help?

Planning an AMI launch? Contact hello@automatum.io or use the in-app chat — we can review your delivery method, draft your CloudFormation template, and map out the metering integration your team owns.

Automatum GTM Platform