The terraform import command imports existing resources into Terraform. Refer to Import for additional information.
Hands-on: Try the Import Terraform Configuration tutorial.
Usage: terraform import [options] ADDRESS ID
Import will find the existing resource from ID and import it into your Terraform state at the given ADDRESS.
ADDRESS must be a valid resource address. Because any resource address is valid, the import command can import resources into modules as well as directly into the root of your state.
ID is dependent on the resource type being imported. For example, for AWS EC2 instances it is the instance ID (i-abcd1234) but for AWS Route53 zones it is the zone ID (Z12ABC4UGMOZ2N). Please reference the provider documentation for details on the ID format. If you're unsure, feel free to just try an ID. If the ID is invalid, you'll just receive an error message.
Warning: Terraform expects that each remote object it is managing will be bound to only one resource address, which is normally guaranteed by Terraform itself having created all objects. If you import existing objects into Terraform, be careful to import each remote object to only one Terraform resource address. If you import the same object multiple times, Terraform may exhibit unwanted behavior. For more information on this assumption, see the State section.
Instead of manually importing resources, you can add the import block to your Terraform configurations so that Terraform imports resources when you run the terraform apply command. Using Terraform configurations lets you automate resource imports as part of your CI/CD pipelines. Refer to the import block reference documentation for additional information.
The command-line flags are all optional. The following flags are available:
-config=path - Path to directory of Terraform configuration files that configure the provider for import. This defaults to your working directory. If this directory contains no Terraform configuration files, the provider must be configured via manual input or environmental variables.
-input=true - Whether to ask for input for provider configuration.
-lock=false - Don't hold a state lock during the operation. This is dangerous if others might concurrently run commands against the same workspace.
-lock-timeout=0s - Duration to retry a state lock.
-no-color - If specified, output won't contain any color.
-parallelism=n - Limit the number of concurrent operations as Terraform walks the graph. Defaults to 10.
-provider=provider - Deprecated Override the provider configuration to use when importing the object. By default, Terraform uses the provider specified in the configuration for the target resource, and that is the best behavior in most cases.
-var 'foo=bar' - Set a variable in the Terraform configuration. This flag can be set multiple times. Variable values are interpreted as literal expressions in the Terraform language, so list and map values can be specified via this flag.
-var-file=foo - Set variables in the Terraform configuration from a variable file. If terraform.tfvars or any .auto.tfvars files are present in the current directory, they are automatically loaded. Terraform loads terraform.tfvars first and the .auto.tfvars files after in alphabetical order. Any files specified by -var-file override any values set automatically from files in the working directory. This flag can be used multiple times. This is only useful with the -config flag.
For configurations using the HCP Terraform CLI integration or the remote backend only, terraform import also accepts the option -ignore-remote-version.
For configurations using the local backend only, terraform import also accepts the legacy options -state, -state-out, and -backup.
Terraform will attempt to load configuration files that configure the provider being used for import. If no configuration files are present or no configuration for that specific provider is present, Terraform will prompt you for access credentials. You may also specify environmental variables to configure the provider.
The only limitation Terraform has when reading the configuration files is that the import provider configurations must not depend on non-variable inputs. For example, a provider configuration cannot depend on a data source.
As a working example, if you're importing AWS resources and you have a configuration file with the contents below, then Terraform will configure the AWS provider with this file.
variable "access_key" {}
variable "secret_key" {}
provider "aws" {
access_key = var.access_key
secret_key = var.secret_key
}
This example will import an AWS instance into the aws_instance resource named foo:
$ terraform import aws_instance.foo i-abcd1234
The example below will import an AWS instance into the aws_instance resource named bar into a module named foo:
$ terraform import module.foo.aws_instance.bar i-abcd1234
The example below will import an AWS instance into the first instance of the aws_instance resource named baz configured with count:
$ terraform import 'aws_instance.baz[0]' i-abcd1234
The example below will import an AWS instance into the "example" instance of the aws_instance resource named baz configured with for_each:
Linux, Mac OS, and UNIX:
$ terraform import 'aws_instance.baz["example"]' i-abcd1234
PowerShell:
$ terraform import 'aws_instance.baz[\"example\"]' i-abcd1234
Windows cmd.exe:
$ terraform import aws_instance.baz[\"example\"] i-abcd1234
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4