AMI-based product requirements

AMIs must not contain any known vulnerabilities, malware, or viruses as detected by the self-service AMI scanning tool or AWS Security.

AMIs must use currently supported operating systems and other software packages. Any version of an AMI with an End-of-Life (EoL) operating system or other software packages will be delisted from the AWS Marketplace. You can build a new AMI with updated packages and publish it as a new version to AWS Marketplace.

All instance authentication must use key pair access, not password-based authentication, even if the password is generated, reset, or defined by the user at launch. AMIs must not contain passwords, authentication keys, key pairs, security keys, or other credentials for any reason.

AMIs must not request or use access or secret keys from users to access AWS resources. If your AMI application requires access to the user, it must be achieved through an AWS Identity and Access Management (IAM) role instantiated through AWS CloudFormation, which creates the instance and associates the appropriate role. When single-AMI launch is enabled for products with an AWS CloudFormation delivery method, corresponding usage instructions must include clear guidance for creating minimally privileged IAM roles. For more information, see AMI-based delivery using AWS CloudFormation.

Linux-based AMIs must not allow SSH password authentication. Disable password authentication via your sshd_config file by setting PasswordAuthentication to NO.

AMIs must allow operating system (OS)-level administration capabilities to allow for compliance requirements, vulnerability updates, and log file access. Linux-based AMIs use SSH, and Windows-based AMIs use RDP.

AMIs must not contain authorized passwords or authorized keys.

AMIs must not use fixed passwords for administrative access. AMIs must use a randomized password instead. An alternative implementation is to retrieve the instance metadata and use the instance_id as the password. The administrator must be prompted for this randomized password before being permitted to set or change their own credentials. For information about retrieving instance metadata, see Instance Metadata and User Data in the Amazon EC2 User Guide for Linux Instances.

You must not have access to the customer's running instances. The customer has to explicitly enable any outside access, and any accessibility built into the AMI must be off by default.

AMIs must disable password-based remote logins.

AMIs must disable remote logins for root.

AMIs must allow users to gain administrator control to perform root function. For example, allow sudo access for Linux-based OS. For other systems, allow full privileged-level access.

AMIs must log the root activity for an audit trail.

AMIs must not contain authorized passwords for OS users.

AMIs must not contain authorized keys.

AMIs must not have blank or null root passwords.

For Windows Server 2016 and later, use EC2Launch.

For Windows Server 2012 R2 and earlier, use the most recent version of Ec2ConfigService and enable Ec2SetPassword, Ec2WindowsActivate, and Ec2HandleUserData.

Remove guest accounts and remote desktop users, none of which are allowed.

Software must not collect or export customer data without the customer's knowledge and express consent except as required by BYOL (Bring Your Own License). Applications that collect or export customer data must follow these guidelines:

Products must not restrict access to the product or product functionality by time, number of users, or other restrictions. Beta and prerelease products, or products whose sole purpose is to offer trial or evaluation functionality, are not supported. Developer, Community, and BYOL editions of commercial software are supported, provided an equivalent paid version is also available in AWS Marketplace.

All AMIs must be compatible with either the Launch from Website experience or AMI-based delivery through AWS CloudFormation. For Launch from Website, the AMI can't require customer or user data at instance creation to function correctly.

AMIs and their software must be deployable in a self-service manner and must not require additional payment methods or costs. Applications that require external dependencies on deployment must follow these guidelines:

AMIs that require an ongoing connection to external resources not under the direct control of the buyer—for example, external APIs or AWS services managed by the seller or a third party—must follow these guidelines:

Product software and metadata must not contain language that redirects users to other cloud platforms, additional products, or upsell services that aren't available in AWS Marketplace.

If your product is an add-on to another product or another ISV’s product, your product description must indicate that it extends the functionality of the other product and that without it, your product has very limited utility. For example, This product extends the functionality of <product name> and without it, this product has very limited utility. Please note that <product name> might require its own license for full functionality with this listing.

Source AMIs for AWS Marketplace must be provided in the US East (N. Virginia) Region.

AMIs must use HVM virtualization.

AMIs must use 64-bit or 64-bit ARM architecture.

AMIs must be AMIs backed by Amazon Elastic Block Store (Amazon EBS). We don't support AMIs backed by Amazon Simple Storage Service (Amazon S3).

AMIs must not use encrypted EBS snaphots.

AMIs must not use encrypted file systems.

AMIs must be built so that they can run in all AWS Regions and are Region-agnostic. AMIs built differently for different Regions aren't allowed.