github.com/rstandt/terraform@v0.12.32-0.20230710220336-b1063613405c/website/docs/providers/terraform/d/remote_state.html.md (about)

     1  ---
     2  layout: "terraform"
     3  page_title: "Terraform: terraform_remote_state"
     4  sidebar_current: "docs-terraform-datasource-remote-state"
     5  description: |-
     6    Accesses state meta data from a remote backend.
     7  ---
     8  
     9  # remote_state
    10  
    11  [backends]: /docs/backends/index.html
    12  
    13  Retrieves state data from a [Terraform backend][backends]. This allows you to
    14  use the root-level outputs of one or more Terraform configurations as input data
    15  for another configuration.
    16  
    17  Although this data source uses Terraform's [backends][], it doesn't have the
    18  same limitations as the main backend configuration. You can use any number of
    19  `remote_state` data sources with differently configured backends, and you can
    20  use interpolations when configuring them.
    21  
    22  ## Example Usage
    23  
    24  ```hcl
    25  data "terraform_remote_state" "vpc" {
    26    backend = "remote"
    27  
    28    config = {
    29      organization = "hashicorp"
    30      workspaces = {
    31        name = "vpc-prod"
    32      }
    33    }
    34  }
    35  
    36  # Terraform >= 0.12
    37  resource "aws_instance" "foo" {
    38    # ...
    39    subnet_id = data.terraform_remote_state.vpc.outputs.subnet_id
    40  }
    41  
    42  # Terraform <= 0.11
    43  resource "aws_instance" "foo" {
    44    # ...
    45    subnet_id = "${data.terraform_remote_state.vpc.subnet_id}"
    46  }
    47  ```
    48  
    49  ## Argument Reference
    50  
    51  The following arguments are supported:
    52  
    53  * `backend` - (Required) The remote backend to use.
    54  * `workspace` - (Optional) The Terraform workspace to use, if the backend
    55    supports workspaces.
    56  * `config` - (Optional; object) The configuration of the remote backend.
    57    Although this argument is listed as optional, most backends require
    58    some configuration.
    59  
    60      The `config` object can use any arguments that would be valid in the
    61      equivalent `terraform { backend "<TYPE>" { ... } }` block. See
    62      [the documentation of your chosen backend](/docs/backends/types/index.html)
    63      for details.
    64  
    65      -> **Note:** If the backend configuration requires a nested block, specify
    66      it here as a normal attribute with an object value. (For example,
    67      `workspaces = { ... }` instead of `workspaces { ... }`.)
    68  * `defaults` - (Optional; object) Default values for outputs, in case the state
    69    file is empty or lacks a required output.
    70  
    71  ## Attributes Reference
    72  
    73  In addition to the above, the following attributes are exported:
    74  
    75  * (v0.12+) `outputs` - An object containing every root-level
    76    [output](/docs/configuration/outputs.html) in the remote state.
    77  * (<= v0.11) `<OUTPUT NAME>` - Each root-level [output](/docs/configuration/outputs.html)
    78    in the remote state appears as a top level attribute on the data source.
    79  
    80  ## Root Outputs Only
    81  
    82  Only the root-level outputs from the remote state are accessible. Outputs from
    83  modules within the state cannot be accessed. If you want a module output or a
    84  resource attribute to be accessible via a remote state, you must thread the
    85  output through to a root output.
    86  
    87  For example:
    88  
    89  ```hcl
    90  module "app" {
    91    source = "..."
    92  }
    93  
    94  output "app_value" {
    95    value = "${module.app.value}"
    96  }
    97  ```
    98  
    99  In this example, the output `value` from the "app" module is available as
   100  `app_value`. If this root level output hadn't been created, then a remote state
   101  resource wouldn't be able to access the `value` output on the module.