How to List Your Product in AWS Marketplace

The following is a guest post from Suney Sharma, a Partner Solutions Architect at AWS. 

Are you planning to launch an AWS Marketplace offering for your product?

If you are an independent software vendor (ISV), the AWS Marketplace offers you an opportunity to capitalize on the widespread migration to cloud computing, simplify and shorten your sales cycle, and grow your business. Many APN Partners sell their solutions on AWS Marketplace, as it is a great channel with which to reach customers who are running their workloads on AWS. In this post, we walk through an overview of AWS Marketplace, followed by some key considerations and best practices as you get ready to list your product in AWS Marketplace. We focus on bundling your product as an AMI (Amazon Machine Image). We also offer tips for applications that have a complex multi-node architecture.

What is AWS Marketplace?

AWS Marketplace is an online store where customers can find, buy, and deploy software that runs on AWS. As with AWS services, customers pay only for what they use. AWS Marketplace helps enable you, as an ISV, to reduce the cost of customer acquisition and deliver your solution on a global scale. To date, AWS Marketplace has over 2,700 listed offerings from more than 925 software vendors. AWS customers use 205 million hours a month of Amazon Elastic Compute Cloud (Amazon EC2) resources for AWS Marketplace products. These numbers are a strong statement of the value of AWS Marketplace for both customers and partners.

AWS customers subscribe to products in AWS Marketplace based on their business needs. They can then launch the software in their AWS accounts. AWS meters and charges customers based on usage, and the usage charges are reflected in the monthly AWS bill. This method of software delivery enables customers to link software costs to actual usage instead of being bound by a fixed cost license.

AWS Marketplace also takes into account that different products might have different metrics for metering usage. For instance, some products may need to be billed by the number of provisioned users while others might be billed by amount of data transfer. To support additional billing options, AWS Marketplace now supports multiple dimensions for usage metering: Users, Hosts, Bandwidth, and Data.  For example, by using the AWS Marketplace Metering Service, a seller can charge a customer every hour based on the number of provisioned users or the amount of data transferred. Find out more about the AWS Marketplace Metering Service.

How Products are Listed in AWS Marketplace

Sellers can bundle their product in an AMI, which is listed in AWS Marketplace. Customers use these AMIs to launch Amazon EC2 instances in their AWS account. AWS charges customers based on their usage of the product. See the AWS Marketplace Seller Guide for more details.

Along with the AMI, the seller provides product metadata in a form called the Product Load Form. The form captures a lot of information about the product, including:

• Types of instances that the customer can select.
• Product charges applicable to each instance (in addition to Amazon EC2 charges).
• AWS regions in which the product will be available.
• Additional information such as product description, links to support information, and the seller’s end user license agreement (EULA).

The AWS Marketplace team uses this information to provide a product description on the AWS Marketplace website. Customers who wish to purchase the product do so by subscribing to the AMI and accepting the seller’s EULA.

The customer is then taken to the launch page within the AWS Marketplace website. The AMI is used to launch Amazon EC2 instances in the customer’s AWS account, and the necessary API calls from the software are provided on a minimal privilege basis. This means that the software will have limited privileges to the customer’s AWS account and to the resources provisioned within it.

Support for Clusters and AWS Resources

In the flow explained above, the customer runs the product on one or more Amazon EC2 instances. However, some products might have more complex needs; for example, they might need to:

• Run on a cluster of instances or meet HA requirements.
• Access AWS resources like Elastic Load Balancing or Auto Scaling groups.
• Need specific network and security configurations.

An example could be a product with a three-tier architecture (web, app, and database), which is deployed on different Amazon EC2 instances. Each tier may need to interact with different AWS services, which will need to be provisioned along with the instances. For example, Auto Scaling groups and Elastic Load Balancers may be required for the web and app layers, and the database layer may need access to an Amazon S3 bucket for backups.

For such products, AWS Marketplace provides support for clusters and AWS resources. When a customer subscribes to such a product in AWS Marketplace, all resources, including Amazon EC2 instances, required AWS services, and dependencies get installed and configured automatically.

Under the hood, this is a simple execution of an AWS CloudFormation template provided by the seller. When the customer chooses Subscribe on the AWS Marketplace page, the AWS CloudFormation console window is displayed and the seller-provided template is executed. It is important to remember that the template is executed in the customer’s AWS account and relies on AWS Identity and Access Management (IAM) roles and policies to provide access to AWS resources in the account. This is a powerful capability because customers can securely deploy sophisticated software in their accounts without having to understand the underlying setup complexity.

For these types of software, the seller provides the AWS Marketplace team with an AMI and the AWS CloudFormation templates required to set up and install the product. AWS CloudFormation manages the installation and setup.

Best Practices for Creating AMIs

AWS provides detailed documentation around creating generic AMIs in the Amazon EC2 user guides for Linux and Windows.

The best practices mentioned in these documents apply to AWS Marketplace AMIs. There are some additional considerations that we’d like to highlight.

Customer experience considerations:

• Your AMI dictates the customer experience; therefore, you should take appropriate care that it conforms to your customer experience requirements.
• Launching an AMI performs an unassisted installation of your software. Since a good customer experience is of paramount importance, we recommend that you have clear documentation around setup, usage, and best practices to assist the customer.

Security considerations:

• User accounts and passwords: For security of the customer, you should not hard-code passwords in cleartext in the AMI. As a best practice you can:
  • Generate a password at boot time or use passwords that are specific to the customer environment, such as instance IDs (see the Tips section).

OR

• Force the customer to change the password at first login.
• If any new vulnerability affecting your AMI is discovered, you will need to modify your AMI to ensure that the customer is not affected.
• In some cases you may have no control over the network and security group configurations for the Amazon EC2 instances the AMI is deployed on. In such cases it is a good idea to disable or uninstall unnecessary services and packages.

Development and Test considerations:

• Make sure you have a well-defined, repeatable strategy to build, update, and test your AMIs. (Note: No test or sandbox capabilities exist for AWS Marketplace.)
• Your AMI should provide the customer with an image that is secure and performant per requirements. This means that you may need to include these aspects in your testing.

For additional details, see the Security Guidance for AMI Developers.

Best Practices for Using AWS CloudFormation for AWS Marketplace

As mentioned earlier, in cases where a product needs to be deployed on multiple nodes and also interact with other AWS services like Elastic Load Balancing, Amazon S3, etc., the seller can provide AWS CloudFormation templates along with the AMI.

Some points to consider while planning this approach:

• Documentation: Clear documentation with snapshots of the setup screens will be of great value in unassisted installations. This could be in the form of setup guides, user guides, etc.

• Customer input: A multi-node deployment will need to capture some information from the customer such as security group configuration, network details, instance types, instance count, etc. The AWS CloudFormation templates provide parameters to capture customer input, and description fields that provide information about the required input. For example, you could use parameters to define the source IPs in a security group configuration and provide a description to assist the customer.

• Region of launch: Since the customer will have the choice of launching the application in different AWS Regions, you can use the Mappings section in the AWS CloudFormation template to point to the relevant AMI in the region.

• Outputs: The Outputs section of the template can be used to provide more information about the deployed stack. This can include things like IP addresses of the configured nodes.

• AWS Identity and Access Management Roles: In most cases, the Amazon EC2 instances may need to interact with other AWS services like Amazon S3, Amazon SNS, etc. Use of access/secret keys in the AMI is forbidden. As a security best practice, you should use AWS IAM roles. These roles should have the least privileges that are required for interacting with the service. The good news is that IAM roles can be created in the AWS CloudFormation template, in the Resources section. If you choose to create a role using this method, it will be a good idea to include details in the documentation.

• Successful completion: Your documentation should clearly articulate how the customer will know that the installation is complete. This could be something like a login page displayed on one of the IPs provided in the Outputs section. The documentation should also provide information on what the user should do if the installation fails. Remember that the customer is charged for the AWS resources even if your product is not correctly installed.

• If you create or edit security group rules, please ensure that SSH/RDP [port 22/443] is not open to 0.0.0.0/0 by default.

Additional Tips for Your AWS Marketplace Deployments

• For unique passwords to be generated at run time you can use the instance IDs of the created instances. The metadata service can be queried for instance IDs. Customers can then be required to change the password when they log in for the first time.

• AWS CloudFormation does not allow you to create a variable number of instances. If your product requires the customer to select the number of nodes, you could create an Auto Scaling group where the group size is captured as input in the Parameters section.

• If you need to create new security groups as a part of the deployment, request customer input for the CIDR block/IP address allowed to access the application and use the same for security group configuration.

• For complex configuration management tasks like editing files, configuring inter-node communication and complex deployment tasks, consider using AWS OpsWorks. AWS CloudFormation supports creation of AWS OpsWorks stacks, layers, and applications in the Resources section. The relevant recipes can be stored in a publicly readable Amazon S3 bucket.

Conclusion

In this post, we provided a high-level view of how to list products in AWS Marketplace. We also shared some important considerations when creating AMIs and AWS CloudFormation-based offerings. To conclude, remember that customer experience and security should be your top considerations when you evaluate different strategies to list your product in AWS Marketplace.