When users launch an AWS CloudFormation template, they get charged for AWS usage even if the stack fails and the instance runs for a very brief time. For this reason, you need to test your Quick Start thoroughly before we publish it. Testing becomes even more important for complex stacks and expensive stacks (such as those that use X1 instance type).


Make sure to include the following in your testing:

  • Hitting AWS limits (for example, VPCs, Amazon EBS, Elastic IP addresses, etc.).
  • Stacks launched within the user’s VPC that don’t use our NAT gateway/instance or Internet gateway. This becomes an issue when an operating system doesn’t recognize the instances and repository registrations fail, which causes downstream failures.
  • Stack deletion. Make sure that deleting a CREATE_COMPLETE stack succeeds in a single try and doesn’t display a DELETE_FAILED status message.
  • Validate your templates. Launch your templates in the AWS CloudFormation console to check parameters and test the user experience. This review will make it easier to detect issues with parameter names, labels, defaults, and descriptions. For example:
    • If parameters appear in an “Other parameters” group in the console, they’re orphaned in the template. You’ll need to add these parameters to the appropriate group in the Metadata section of your template.
    • If you’ve defined default values that don’t comply with parameter constraints (AllowedValues or AllowedPatterns), the console will display an error message. You’ll need to fix the default value or revise the constraint.
    • The visual test pass will also help you identify cosmetic issues and inconsistencies such as typos in parameter labels and descriptions, or truncated descriptions.


Debugging the Quick Start templates is never easy, because deployment can fail midway through stack creation. Here are some helpful approaches:

  • Disable the Rollback on failure option before stack creation so that you have a partially working stack in case of a failure and can find details about the failure in the logs.
    Note that the user will still incur charges for whatever has been deployed up to the point of failure.
  • Use a debug/verbose flag as input to generate additional logging.
  • It’s always best to explicitly signal in order to properly control the flow of the deployment. You can do this by calling cfn-signal with the wait condition handle or resource.

For more information about troubleshooting your Quick Start templates, see the AWS CloudFormation documentation.