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_COMPLETEstack succeeds in a single try and doesn’t display a
- Resource cleanup. Make sure that after successful stack deletion, no AWS resources are left behind that weren’t part of the stack. Examples might include resources created by a script that’s embedded into your AWS CloudFormation template. Users could be charged for these leftover resources.
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.