Exploring AWS CloudFormation Wait Conditions and Creation Policies
AWS CloudFormation has transformed the way infrastructure is provisioned and managed in the cloud. Among its features, Wait Conditions and Creation Policies stand out as powerful tools that contribute to the reliability and efficiency of deployments. In this blog post, we will take a deep dive into CloudFormation Wait Conditions and Creation Policies, exploring their significance, how to effectively use them, and when to employ these features for optimal results.
Understanding Wait Conditions:
Wait Conditions play a crucial role in managing the sequence of events during stack creation. They allow you to specify that the creation of a particular AWS resource should wait until a certain condition is met. This is especially valuable in scenarios where dependencies between resources need careful orchestration.
Consider the below scenario, where the AWS CloudFormation template uses Wait Condition during the creation of resources.
The scenario includes provisioning a database, which may be located either on-premises or in AWS, and creating an Amazon EC2 instance. The EC2 instance contains an application that requires the database instance to be setup, configured and running before the application is deployed on Amazon EC2 instance.
The process works as follows:
1. AWS CloudFormation executes the template which contains instructions to provision the database and Amazon EC2 instance.
2. The stack creation process is started.
3. The database creation starts.
4. The AWS CloudFormation template execution enters a pause state due the WaitCondition specified in template as below prior to creation of Amazon EC2 instance.
AppWaitConditionHandle:
Type: AWS::CloudFormation::WaitConditionHandle
AppWaitCondition:
Type: AWS::CloudFormation::WaitCondition
Properties:
Handle: !Ref AppWaitConditionHandle
Timeout: 36005. Post completion of database creation and configurations, the cfn-signal script is triggered.
6. This script sends a PUT request to AWS CloudFormation on a pre-signed URL as below:
curl -X PUT -H 'Content-Type:' –data-binary
'{"Status" : "SUCCESS",
"Reason" : "DB Configuration Complete",
"UniqueId" : "123456",
"Data" : "Database has completed configuration."}' '<presigned-url>'- <presigned-url> — The presigned URL created by the WaitConditionHandle resource. This can be obtained from the AWS CloudFormation console or can be published to Amazon SNS Topic via Amazon EventBridge so that the cfn-signal script can obtain the same.
- Status — SUCCESS value signals a successful completion of database configuration, FAILURE value signals a failure in database configuration and results in rollback of the stack.
- Reason — may provide details of the Status.
- UniqueId — identifier used by CloudFormation to uniquely identify a signal.
- Data - any additional information that needs to be sent with signal
7. Once AWS CloudFormation receives signal, if the Status is SUCCESS AWS CloudFormation resumes further stack creation.
If the Status is FAILURE or the WaitCondition is timed out before receiving the signal response, it will ROLLBACK the stack creation.
8. If the status is SUCCESS, the AWS CloudFormation starts Amazon EC2 instance creation and installs the application.
Understanding Creation Policies:
Creation Policies are another feature that enhances the control and reliability of AWS CloudFormation deployments. Unlike Wait Conditions, which focus on the timing of resource creation, Creation Policies define the success criteria for resource creation. This means you can dictate when a resource is considered successfully created, allowing AWS CloudFormation to proceed only when the resource is in the desired state.
Creation Policies are particularly useful in scenarios where resources take time to stabilize or become available. For example in below scenario, AWS CloudFormation launches an Amazon EC2 instance and waits for the initialization scripts to complete and a custom status check to be completed. Once the status check is completed, signals AWS CloudFormation to resume the creation of stack.
When launching Amazon EC2 instances, you can use a Creation Policy as below to specify that the instance is considered successfully created only when it passes a status check after a specific period.
CreationPolicy:
ResourceSignal:
Count: '1' #Count of signals to be recieved
Timeout: PT15M #15 Minutes TimeoutAWS CloudFormation can be signaled post completion of status check using below command in Amazon EC2 UserData script.
yum update -y aws-cfn-bootstrap
/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName}
--resource <EC2InstanceName> --region ${AWS::Region}Wait Condition vs Creation Policy
Best Practices for Effective Usage:
- Employ Wait Conditions to carefully orchestrate the order in which resources are created, ensuring dependencies are resolved in a controlled manner.
- Leverage Creation Policies to manage resources that may take time to stabilize, such as Amazon EC2 instances, databases, or other services that require additional setup time.
- Explore the flexibility of Wait Conditions by using custom signals via Amazon SNS topics. This allows you to tailor the conditions based on your application’s specific requirements.
- Consider using Wait Conditions to manage resource creation in the event of failures. This can prevent further resource creation until the underlying issues are resolved.
- Adjust timeout values for Wait Conditions and Creation Policies to align with the nature of your resources and the expected timeframes for their creation.
Conclusion:
In conclusion, AWS CloudFormation Wait Conditions and Creation Policies provide a robust mechanism for controlling the timing and success criteria of resource creation. By understanding these features and incorporating them into AWS deployments, reliability, efficiency, and predictability of infrastructure can be enhanced. Whether you are orchestrating complex resource dependencies or managing resources that require additional time to stabilize, AWS CloudFormation Wait Conditions and Creation Policies offer the flexibility and control needed for successful deployments in the AWS cloud.
References and Further Reading: