Improvements to importing resources in Terraform 1.5

The widely adopted and popular IaaC tool Terraform has recently got some new and exciting features in version 1.5 regarding importing resources.

The term „importing a resource” in „Terraform-terminology” means bringing an already existing resource (for example a Virtual Machine or a Disk at a public cloud provider), that was created outside of our Terraform codebase, under the management of Terraform.
With doing so, you can incorporate already existing resources into your Terraform codebase and enjoy all the benefits of the Infrastructure-as-a-Code approach for their future management.

Previously, when you wanted to import a resource, your only option was to use the „terraform import” CLI commands. It did get the job done, however in more complex scenarios (or running as part of automations), it could easily become hard to execute for example for a large number of resources. Also, it was easy to make mistakes with it too, as it was a one-time operation, and it was lacking the same, well-known lifecycle (validate-plan-apply).

With Terraform’s 1.5 version, a new way of importing became possible: importing as part of our regular Terraform codebase.

This means, that importing a resource is as simple as declaring any other resource in Terraform: you just have to create one more „import” blocks in your Terraform code and you are ready to go.

In this import block, you simply need to provide the same informations, as it was needed for the „old way” of importing: the ID of the cloud resource to be imported and the HCL address for the new resource in the “to” property.

Example:

	
	import {
	  # ID of the cloud resource
	  # Check provider documentation for importable resources and format
	  id = "i-abcd1234"
	  # Resource address
	  to = aws_instance.example
	}
	

Once done, you can go through the usual lifecycle of performing operations with Terraform (validate-plan-apply), these import block(s) support all of those.

So essentially, you can now enjoy all of these benefits for imports as well:

• The code itself for the import operation can be reviewed
• The import is plannable too, which eliminates the risk of unwanted state modifications and gives another opportunity for a review by a second pair of eyes
• Import operations can be executed in bulk now

Better yet, until you perform any modifications on these imported resources (like renaming them, or moving them around) these import blocks can safely stay in your codebase, as Terraform is smart enough to notice they have already been imported.

But this still only covers the import operation for these resource, the matching Terraform code for these resources would still need to be created manually. Until you read the next paragraph…

Look no further regarding that Terraform code creation for imported resources, as Terraform 1.5 also introduces automatic code generation for imported resources. With this feature, you can drastically reduce the time spent on writing code, that matches the imported resources.

The heart of the code generation is also creating an import block first, as described earlier.

Once at least one import block is added to your Terraform codebase, when you execute a plan with the freshly introduced -generate-config-out parameter, magic happens, as Terraform will automatically create the matching Terraform code for the resource you want to import in a separate .tf file you specify (example: terraform plan -generate-config-out=generated_resources.tf).