How to Use Terraform Import to Generate Configuration

In this article, we'll cover how the feature works and show a practical example.

How to import Terraform config with the generate configuration flag

Starting in Terraform v1.5, you can use the import block combined with the -generate-config-out flag to automatically bring existing cloud resources into Terraform management.

Rather than writing configuration files by hand for resources that already exist, Terraform inspects the real-world resource and produces HCL code that reflects its current state.

Note that this feature is still considered experimental, and its behavior or output format may change in future Terraform releases.

The process works in four steps:

1. Write an import block that tells Terraform which existing resource to target and what address it should have in state.
2. Run terraform plan -generate-config-out="generated_resources.tf", which causes Terraform to read the live resource and write a matching configuration file.
3. Review and refine that generated file, because Terraform's output is a starting point rather than a finished product.
4. Run terraform apply to import the resource into state and make it official. This is the step that actually modifies your state file, not the plan step above.

This approach replaces the older terraform import CLI command for most use cases. The key advantage is that it is declarative and repeatable, because the import block lives in your configuration files and can be reviewed in version control just like any other Terraform code.

Example: Importing an existing AWS S3 bucket that was created manually

Imagine your team created an S3 bucket through the AWS Console months ago to store application logs. The bucket is called acme-prod-logs-2024, and it has versioning enabled along with a lifecycle rule.

Nobody wrote Terraform configuration for it at the time, and now you want to bring it under infrastructure as code management so future changes go through your standard pull request workflow.

Start by creating a file called imports.tf in your Terraform project directory. Inside that file, define an import block that maps the real-world bucket to the Terraform resource address you want it to have.

import {
  to = aws_s3_bucket.prod_logs
  id = "acme-prod-logs-2024"
}

The to argument is the Terraform resource address that will appear in your state file. The id argument is the provider-specific identifier used to look up the resource. For S3 buckets this is simply the bucket name, but the format varies by resource type.

For example, an EC2 instance would use its instance ID like i-0abc123def456, and an IAM role would use the role name. Check the provider documentation for the correct format.

Make sure your provider block for AWS is already configured and that you have run terraform init. Then run the plan command with the configuration generation flag.

terraform plan -generate-config-out="generated_resources.tf"

Terraform reaches out to the AWS API, reads the current state of the bucket, and writes a resource block into generated_resources.tf. The output might look something like this:

resource "aws_s3_bucket" "prod_logs" {
  bucket              = "acme-prod-logs-2024"
  object_lock_enabled = false
  tags                = {}
  tags_all            = {}
}

Notice that Terraform generates every attribute it can read from the provider, including ones you may not care about.

This is where the review step becomes important. You should remove computed attributes like tags_all that Terraform manages automatically, and you may want to add explicit arguments for features like versioning if you manage those through separate resources such as aws_s3_bucket_versioning.

You may also see warnings or errors about conflicting attributes in the plan output. This is normal for a generated configuration and just means you need to resolve those conflicts before you can apply.

Once you are satisfied with the configuration, run terraform apply to complete the import. From that point forward, any changes to the bucket should be made through Terraform.

Key points

Generated configuration is a starting point, not a finished product. Terraform includes every attribute it can read from the provider, so you should strip out computed values and unnecessary defaults to keep your code clean.

The -generate-config-out flag requires a path to a new file. Terraform will return an error if the file already exists, which prevents it from overwriting configuration you have already reviewed.

Once you have successfully imported a resource and committed the configuration to version control, you can safely remove the import block. It is no longer needed for future plans or applies.

Terraform is really powerful, but managing imports, state, and configuration at scale requires more than the CLI alone. Spacelift takes Terraform management to the next level by giving you access to a powerful CI/CD workflow and features such as:

• Policy as code (based on Open Policy Agent) to enforce guardrails on every plan and apply
• Drift detection to catch resources that have changed outside of Terraform
• Multi-IaC workflows across Terraform, OpenTofu, CloudFormation, Pulumi, and Kubernetes
• Self-service infrastructure through Blueprints and Templates
• Full audit trails so you always know what changed, when, and who approved it

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Note: HashiCorp changed Terraform’s license for newer releases, while earlier versions remain under their previous open-source license. OpenTofu is an open-source fork based on Terraform 1.5.6 and is a viable alternative for teams that want a community-governed option.