AWS recently announced a new AWS Cloud Development Kit (CDK) feature that allows cloud engineers to refactor their infrastructure as code, preserving resources while renaming constructs and reorganizing applications.
With the new refactor feature, the company addresses a significant pain point: previously, any change to a resource’s logical ID caused by renaming or moving a construct would force AWS CloudFormation to delete and then recreate the resource. This destructive process often led to data loss and downtime for stateful resources, such as databases, causing many developers to avoid refactoring altogether.
However, with the new CDK refactor command, cloud engineers can now detect, review, confirm, and safely apply refactored changes to their resources without requiring resource replacement. The authors of an AWS DevOps and Developer productivity blog write:
This feature leverages the recently-launched AWS CloudFormation refactor feature, but the CDK automatically computes the mappings that CloudFormation needs to redefine the refactored resources, providing a layer of abstraction that allows developers to focus on code rather than resource configuration.
The refactor feature is currently still in a pre-release state and requires the –unstable=refactor flag. Developers who want to try it out must also re-bootstrap their CDK environment to get the necessary permissions.
(Source: AWS DevOps & Developer Productivity blog post)
The company states that the CDK Refactor allows developers to apply object-oriented principles to their infrastructure, simplifying code, improving maintainability, and ultimately making their applications more robust and well-architected without the fear of destructive deployments.
Yet, Ran Isenberg, a principal software architect at CyberArk, cautioned on the feature in a LinkedIn post:
Bottom line – an important feature, BUT: That said, I wouldn’t recommend using it too often — it’s best reserved for cases where you really don’t have a better solution.
While the AWS CDK refactor provides a means for refactoring, other Infrastructure as Code (IaC) tools handle similar tasks differently. For instance, Pulumi relies on the concept of aliases, which are explicit properties cloud engineers can add to a resource definition to tell Pulumi to update an existing resource’s identity rather than replacing it.
Another IaC offering, Terraform, has a more manual, declarative method using the moved block, which cloud engineers add to their HCL configuration to explicitly map an old resource address to a new one, ensuring the state file is updated without destroying the underlying resource. And finally, Bicep, as a stateless tool that compiles to ARM templates, doesn’t have a dedicated refactor command. Instead, refactoring is handled through its native deployment model, which relies on Azure Resource Manager to manage the resource’s lifecycle without requiring a local state file.
Lastly, more details on the refactor feature are available on the documentation pages.
