This guide provides information about building a Quick Start and working with the AWS Quick Start team to get it published. It also includes detailed guidelines for developing your Quick Start template and testing it, based on best practices developed by solutions architects on the AWS Quick Start team.

Before you begin work on the Quick Start, keep in mind that the turnaround time from finalizing the templates (all tests pass) to launch (publication on the AWS Quick Start site) is at least two weeks. We have a rolling launch schedule throughout the year, so we are generally able to publish a Quick Start two weeks after its completion. However, we publish two Quick Starts per week, and we’re not able to publish at all during the occasional AWS marketing blackout dates. If you would like your Quick Start to go live on a specific date, let us know as soon as possible so we can hold a launch date for you, and make sure that your templates are complete at least two weeks before the requested launch date.

How to contribute

If you’re interested in building a Quick Start, the Amazon Web Services (AWS) Quick Start team will work with you to get it published on the AWS website (https://aws.amazon.com/quickstart/). Follow these steps:

Take a look at current Quick Starts. Decide whether a Quick Start or an Amazon Machine Image (AMI) offering in the AWS Marketplace is a better option for deploying your technology on AWS.

Quick Start AWS Marketplace AMI
Gold-standard reference architectures for key workloads Single-vendor solutions
For test or production use AWS-scanned, approved, and hosted assets
Modular and customizable Low-friction, self-contained deployments
BYOL, or leverage AWS Marketplace and/or publicly available assets Billed to buyer's AWS account

Talk to your Partner Development Manager or Partner Solution Architect at AWS, or contact quickstart@amazon.com about your Quick Start proposal. A brief spec for your deployment and/or an architectural diagram will help us determine if and when your Quick Starts fits on the roadmap.

If your project is approved, we will schedule a kick-off meeting to discuss commitments and timeline for development, documentation, testing, and launch. Allow 45 days from acceptance to launch.

Your Quick Start must include, at the minimum:

  • A path to partner media or AMI used by the Quick Start
  • An AWS CloudFormation template that automates the deployment
  • Explanation of deployment architecture and steps
  • A license that allows us to distribute the template (Apache 2.0)
  • An SLA to maintain and support the Quick Start, or an expiration date for the Quick Start

For detailed guidelines on building and testing your template, see the subsequent sections of this guide.

AWS launch activities include:

The launch includes:

After launch:

  • Plan for proactive updates
  • Respond to user queries and fix bugs
  • Have a well-defined support path or contact person for issues
  • Obsess over your customers and iterate quickly on feedback

If you have any questions, contact us at quickstart@amazon.com.

Quick Start checklist

Here’s a quick list that you can use to check off your development tasks:

Complete the prerequisites listed in the Before you get started section.

Work with us to set up a Git repo for your Quick Start files.

Visualize your Quick Start architecture by creating an architecture diagram.

Build your Quick Start templates:

Test and debug your code.

Create a parameters file for automated testing.

Create a deployment guide with architecture and step-by-step instructions.

AWS CloudFormation checklist

Quick Starts are designed for both trial and production use, so your AWS CloudFormation templates should incorporate AWS best practices. If you’re unable to meet the following requirements, contact us to discuss your exception case.

Multi-AZ architecture (details)

Support for the majority of AWS Regions (details)

New VPC and existing VPC deployment options (details)

Product instances in private subnets (details)

NAT gateways for outbound Internet access from private subnets (details)

Marketplace AMIs whenever possible; no prebaked AMIs (details)

AMI mappings; no hardcoded AMIs (details)

User-friendly parameter labels and groups (details)

CIDR block lockdown for external admin access (details)

Security groups with principle of least privilege (details)

No software bits with deployment (details)

No hardcoded passwords (details)

No sensitive data in EC2 instance user data or other clear text (details)

No use of 0.0.0.0/0 for open remote management access (details)

No resources created automatically outside stack (details)