AWS CloudFormation is one of many Amazon Web Services (AWS) available to enable modern IT development in the cloud. AWS or third-party resources can be easily modeled and quickly and consistently provisioned and managed throughout the lifecycle with AWS CloudFormation, an Infrastructure-as-code (IaC) tool.
At Arvato Systems, we use AWS CloudFormation in most customer projects to provision all AWS resources. It enables us to achieve a repeatable, versionable state of the customer’s infrastructure.
For a serverless application, for example, DynamoDB database, API Gateway, Lambda functions, and the associated permissions are defined in a CloudFormation template and deployed into the target account. This is initially done in a test environment and, after successful testing, will be set up in a production environment using an identical template. Since the resource names or sizes may differ in the different environments, CloudFormation can adjust them accordingly in the different stages by parameterization. The CloudFormation template also describes the desired resources and their dependencies’ configuration together in a stack. Using a CloudFormation template, a complete stack can be created, updated, and deleted as a single entity as often as needed, rather than managing resources individually. This allows stacks to be managed and provisioned across multiple AWS accounts and regions.
Since AWS CloudFormation is a native AWS tool, it is readily available for us to use without the need for 3rd party tools. For this reason, we often use this service in our customer projects. While repeatability of the infrastructure setup is a key part of providing stability required for a robust production environment, AWS is constantly working on improving the service based on customer feedback.
CloudFormation's latest feature to shorten development cycle using stack failure options
Building resources in AWS CloudFormation could be time-consuming and error-prone. Depending on the type and number of resources, this can take several minutes or even hours. Even if the syntax of a template is tested before deployment, errors can still occur during the actual build. Previously, CloudFormation's behavior was to abort the build and roll back to the last working state. The new feature for deactivation of rollback now prevents this automatic rollback of successfully provisioned resources, allowing previously failed resources to be created or updated.
We have tested the new feature extensively in our development processes. The new feature enables a much more time-saving correction of errors. Especially for resources with a long build time like CloudFront or EC2 instances with startup scripts at the beginning of a larger template, errors can now be fixed much faster. The reduced turnaround time ensures increased efficiency. The developer does not always have to jump back and forth between different tasks to use his time effectively but can focus on the specific problem.
The new feature does not have to be controlled globally but can be turned on or off per stack. Additionally, one can activate a full rollback in case of an error anyway. We would still like to see the availability of the feature in CodePipeline, so that it can also be used in automation. We have provided this feedback to the CloudFormation team, and they are evaluating this feature request.
Overall, the new feature seems well thought out. The user interface is clean and intuitive. The time it saves is significant in some cases. We will definitely continue to use it to shorten debugging timelines.