How do you register as a publisher on each marketplace?
Each cloud runs its own publisher programme. On Azure, you create a Microsoft Marketplace account in Partner Center with a work account tied to your organisation, accept the Microsoft Publisher Agreement and, if you will sell paid plans, set up tax and payout profiles.
On AWS, you register as a seller from an AWS account in good standing and manage server products in AWS Partner Central, which now includes the former AWS Marketplace Management Portal. Paid and BYOL listings also need tax and bank account information and residency or incorporation in an eligible jurisdiction.
On Google Cloud, your organisation joins Google Cloud Partner Network, signs the Marketplace Vendor Agreement in Partner Network Hub, creates a Google Cloud project to host the product and completes a Project Info form, which gives access to Producer Portal.
How do you build and generalise the image as code?
Build every image from a version-controlled template rather than capturing a hand-configured VM. HashiCorp describes Packer as a tool for creating identical machine images for multiple platforms from a single source configuration, so one pinned definition can drive every build and every later security rebuild.
Generalisation removes machine-specific state. For Windows, run Sysprep with the /generalize switch; the VM shuts down and must not be restarted. For Linux on Azure, waagent -deprovision+user deletes provisioning data and the last provisioned user, though Microsoft warns this does not guarantee the image is free of sensitive data. On Google Cloud, clean the input disk, because an image taken straight from a VM carries user directories and SSH keys into customer VMs.
AWS needs an EBS-backed, HVM, 64-bit AMI in US East (N. Virginia) with unencrypted snapshots and IMDSv2 only. Azure expects a fixed-type 64-bit VHD whose virtual size is a multiple of 1 MB, with no swap partition on the OS disk. Google Cloud images start from a supported base public image and must carry the Marketplace licence.
What hardening and security scanning do the marketplaces expect?
Every marketplace scans what you submit, so treat its checks as a floor. AWS rejects AMIs with critical or high-severity unpatched vulnerabilities, malware, end-of-life software or a creation date over two years old. Google Cloud scans the image for vulnerabilities during review, and Microsoft validates that it is bootable, secure and compatible with Azure, with malware scanning part of certification.
For the baseline, apply the CIS Benchmark for your distribution during the build and run your own vulnerability scanner in the pipeline, so a marketplace scan is never where you first see a CVE.
- Remove default, blank and hard-coded passwords, private keys and credentials.
- Disable SSH password authentication and remove all authorised SSH keys.
- Clear shell history; Azure fails images with Bash history over 1 KB.
- Delete home directories and temporary build files.
- Use a minimally privileged IAM role instead of asking customers for AWS credentials.
How should you structure listing content, plans and pricing?
A listing needs a title, descriptions, screenshots, usage instructions and legal terms such as a EULA, and Microsoft checks the title and descriptions for accuracy and quality. AWS also asks for security group recommendations naming the minimum ports required. On Azure, pricing sits on plans, and every image in a plan must have the same number of data disks.
All three clouds support free listings, where customers pay only for infrastructure, and bring your own licence (BYOL), where licensing is handled outside the marketplace. For paid usage, Azure bills per hour with options such as a flat rate or per vCPU, AWS offers hourly, monthly, usage-based and contract pricing, and Google Cloud charges a single hourly rate or by vCPU, RAM or GPU.
How do certification and review work before going live?
Microsoft runs automated validation, then certification covering publisher eligibility, content and technical checks. A certified offer moves to Preview for your preview audience, and nothing goes live until you select Go live.
AWS handles each submission as a change request: a new product first reaches a Limited state for testing, and AWS Marketplace Seller Operations reviews it before it goes Public. Test 'Add version' runs the AMI scan without creating a version, a useful pre-flight check.
Google Cloud reviews product details, pricing and the deployment package separately, and checks that the image deploys and uninstalls cleanly.
| Stage | Azure (Microsoft Marketplace) | AWS Marketplace | Google Cloud Marketplace |
|---|---|---|---|
| Publisher portal | Partner Center | AWS Partner Central (formerly AWS Marketplace Management Portal) | Producer Portal |
| Image artefact | Generalised VHD or Azure Compute Gallery image version | EBS-backed HVM AMI in US East (N. Virginia) | Compute Engine image with the Marketplace licence attached |
| Security validation | Certification test cases and malware scanning | Scan for unpatched CVEs, malware and policy violations | Vulnerability scan plus deploy, uninstall and unit tests |
| Before going live | Preview, then the publisher selects Go live | Limited listing for testing, then an Update visibility request to go Public | Publish privately, then make public |
| Updating | Add an image version to the plan and republish | Add a version, restrict the old one, support it for 90 days | Monthly rebuild with a new, unique image name |
How do you maintain and re-publish new versions?
Google Cloud expects a rebuild and re-publish each month when it updates its base public images, with a new, unique image name each time. AWS keeps scanning live listings and can temporarily make non-compliant products unavailable to new subscribers.
On AWS you add a new version, which triggers a fresh scan, then restrict the old one. On Azure you add a new image version, remove the vulnerable one and republish; the last image in a plan cannot be removed. Automating this from upstream security releases keeps a catalogue current.
What is the end-to-end checklist for publishing a VM image?
Registration is a one-off per marketplace; repeat the other steps for each product, automating steps four to eight.
- 1Confirm redistribution rights, including resell rights for non-free Linux distributions.
- 2Register as a publisher or seller and complete tax, payout and verification steps.
- 3Choose a pricing model per cloud and submit it early if it needs separate review.
- 4Write a Packer template with pinned packages from each cloud's supported base image.
- 5Harden against the relevant CIS Benchmark and remove all credentials, keys and history.
- 6Generalise with Sysprep for Windows, or deprovision Linux images and confirm the provisioning agent, such as cloud-init, is configured.
- 7Scan for vulnerabilities, then run pre-checks such as AWS Test 'Add version'.
- 8Launch a test instance and verify the customer experience end to end.
- 9Complete listing content, plans, usage instructions and legal terms, then submit for review.
- 10Preview and approve the offer, then rebuild and re-publish on a regular cadence.
How can WIEWAVE help with marketplace publishing?
WIEWAVE is a cloud, DevOps and AI company serving clients worldwide and has published 3,500+ products across Azure Marketplace, AWS Marketplace and Google Cloud Marketplace combined.
If you have a product to bring to a cloud marketplace, or images that have fallen behind on patches, we can help you plan the image build, hardening, submission and ongoing maintenance.
Sources
- Microsoft Learn: How to review and publish an offer to Microsoft Marketplace
- Microsoft Learn: Virtual machine certification troubleshooting for Microsoft Marketplace
- AWS Marketplace Seller Guide: Creating AMI-based products
- AWS Marketplace Seller Guide: AMI-based product requirements
- Google Cloud Marketplace: Build your VM image
- Google Cloud Marketplace: Submit your VM product for review
