Moving cloud resources with Terraform:

Introduction: Cloud resources often outgrow the initial definition with which they are created. When changes are applied to a resource, they are often updated in place or they might be destroyed and recreated. When Terraform keeps track of the resource, the changes are seamless to the end user and each instance will be associated with a configured resource at a specific resource address. When an existing infrastructure object must be associated with a different configured resource, Terraform can be informed about the history with a declaration block indicating the from and the to configured resources. Terraform reacts to this information during the planning step and in between init and apply steps in the three step deployment process.

Common operations like renaming or moving a resource into and out of a module can be performed with Terraform state mv command that changes which resource address in the configuration is associated with a particular real world object. In this case, you are required to come up with a new configuration that will instantiate the desired resource and then provide the id to the move command.

Changing a resource’s resource-group or location requires you to come up with a new configuration and something that Terraform cannot do automatically yet. This limitation is not imposed by Terraform but by the public cloud providers who want an entirely new instance to be created. When cloud provider say the support such operation, as for example, Azure can change the resource group membership of a virtual machine, it requires a new one to be created.

One reconciliation to performing such a move and keeping track of it in Infrastructure as code involves the following three steps. First, use the cloud provider’s resource to move the resource to the target region/resource group. Second, modify the Terraform configuration to use the new attribute value. Then, run Terraform refresh against the workspace or configuration to force Terraform to update the state file with the new attribute value. Then the next plan step would find a match between the new location or group and what’s defined in the configuration and would result in not requiring any changes.

Moving resources in production that requires recreation often involves moving production data. This implies there will be a down time but this way is usually the simplest way to move a resource to a target location or group. Some tools like aztfmove can help move resources based on Terraform state to different resource groups and subscriptions in Azure.  One limitation of this tool is that it cannot alter just the region.

Azure Resource Mover can help with moving resources from one region to another and it performs this successfully via UI, CLI and scripting for compute resources such as virtual machines, network resources, and relational databases. It gives ample time to test and validate the migration. It allows automation of rollback until the final commit. Source files can be deleted after the move. But this does not support advanced host and runtimes such as Kubernetes. In fact, the Azure public cloud offers no support for moving Kubernetes instances between regions, resource groups and subscriptions.

Consequently, the only available choice is for end-user to take this on themselves and recreate a new instance in the destination and then inform Terraform about the change.