github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/docs/language/resources/syntax.html.md (about)

     1  ---
     2  layout: "language"
     3  page_title: "Resources - Configuration Language"
     4  sidebar_current: "docs-config-resources"
     5  description: "Resources correspond to infrastructure objects like virtual networks or compute instances. Learn about resource types, syntax, behavior, and arguments."
     6  ---
     7  
     8  # Resource Blocks
     9  
    10  > **Hands-on:** Try the [Terraform: Get Started](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) collection on HashiCorp Learn.
    11  
    12  _Resources_ are the most important element in the Terraform language.
    13  Each resource block describes one or more infrastructure objects, such
    14  as virtual networks, compute instances, or higher-level components such
    15  as DNS records.
    16  
    17  ## Resource Syntax
    18  
    19  Resource declarations can include a number of advanced features, but only
    20  a small subset are required for initial use. More advanced syntax features,
    21  such as single resource declarations that produce multiple similar remote
    22  objects, are described later in this page.
    23  
    24  ```hcl
    25  resource "aws_instance" "web" {
    26    ami           = "ami-a1b2c3d4"
    27    instance_type = "t2.micro"
    28  }
    29  ```
    30  
    31  A `resource` block declares a resource of a given type ("aws_instance")
    32  with a given local name ("web"). The name is used to refer to this resource
    33  from elsewhere in the same Terraform module, but has no significance outside
    34  that module's scope.
    35  
    36  The resource type and name together serve as an identifier for a given
    37  resource and so must be unique within a module.
    38  
    39  Within the block body (between `{` and `}`) are the configuration arguments
    40  for the resource itself. Most arguments in this section depend on the
    41  resource type, and indeed in this example both `ami` and `instance_type` are
    42  arguments defined specifically for [the `aws_instance` resource type](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance).
    43  
    44  -> **Note:** Resource names must start with a letter or underscore, and may
    45  contain only letters, digits, underscores, and dashes.
    46  
    47  ## Resource Types
    48  
    49  Each resource is associated with a single _resource type_, which determines
    50  the kind of infrastructure object it manages and what arguments and other
    51  attributes the resource supports.
    52  
    53  ### Providers
    54  
    55  Each resource type is implemented by a [provider](/docs/language/providers/requirements.html),
    56  which is a plugin for Terraform that offers a collection of resource types. A
    57  provider usually provides resources to manage a single cloud or on-premises
    58  infrastructure platform. Providers are distributed separately from Terraform
    59  itself, but Terraform can automatically install most providers when initializing
    60  a working directory.
    61  
    62  In order to manage resources, a Terraform module must specify which providers it
    63  requires. Additionally, most providers need some configuration in order to
    64  access their remote APIs, and the root module must provide that configuration.
    65  
    66  For more information, see:
    67  
    68  - [Provider Requirements](/docs/language/providers/requirements.html), for declaring which
    69    providers a module uses.
    70  - [Provider Configuration](/docs/language/providers/configuration.html), for configuring provider settings.
    71  
    72  Terraform usually automatically determines which provider to use based on a
    73  resource type's name. (By convention, resource type names start with their
    74  provider's preferred local name.) When using multiple configurations of a
    75  provider (or non-preferred local provider names), you must use the `provider`
    76  meta-argument to manually choose an alternate provider configuration. See
    77  [the `provider` meta-argument](/docs/language/meta-arguments/resource-provider.html) for more details.
    78  
    79  ### Resource Arguments
    80  
    81  Most of the arguments within the body of a `resource` block are specific to the
    82  selected resource type. The resource type's documentation lists which arguments
    83  are available and how their values should be formatted.
    84  
    85  The values for resource arguments can make full use of
    86  [expressions](/docs/language/expressions/index.html) and other dynamic Terraform
    87  language features.
    88  
    89  There are also some _meta-arguments_ that are defined by Terraform itself
    90  and apply across all resource types. (See [Meta-Arguments](#meta-arguments) below.)
    91  
    92  ### Documentation for Resource Types
    93  
    94  Every Terraform provider has its own documentation, describing its resource
    95  types and their arguments.
    96  
    97  Most publicly available providers are distributed on the
    98  [Terraform Registry](https://registry.terraform.io/browse/providers), which also
    99  hosts their documentation. When viewing a provider's page on the Terraform
   100  Registry, you can click the "Documentation" link in the header to browse its
   101  documentation. Provider documentation on the registry is versioned, and you can
   102  use the dropdown version menu in the header to switch which version's
   103  documentation you are viewing.
   104  
   105  To browse the publicly available providers and their documentation, see
   106  [the providers section of the Terraform Registry](https://registry.terraform.io/browse/providers).
   107  
   108  -> **Note:** Provider documentation used to be hosted directly on terraform.io,
   109  as part of Terraform's core documentation. Although some provider documentation
   110  might still be hosted here, the Terraform Registry is now the main home for all
   111  public provider docs.
   112  
   113  ## Resource Behavior
   114  
   115  For more information about how Terraform manages resources when applying a
   116  configuration, see
   117  [Resource Behavior](/docs/language/resources/behavior.html).
   118  
   119  ## Meta-Arguments
   120  
   121  The Terraform language defines several meta-arguments, which can be used with
   122  any resource type to change the behavior of resources.
   123  
   124  The following meta-arguments are documented on separate pages:
   125  
   126  - [`depends_on`, for specifying hidden dependencies](/docs/language/meta-arguments/depends_on.html)
   127  - [`count`, for creating multiple resource instances according to a count](/docs/language/meta-arguments/count.html)
   128  - [`for_each`, to create multiple instances according to a map, or set of strings](/docs/language/meta-arguments/for_each.html)
   129  - [`provider`, for selecting a non-default provider configuration](/docs/language/meta-arguments/resource-provider.html)
   130  - [`lifecycle`, for lifecycle customizations](/docs/language/meta-arguments/lifecycle.html)
   131  - [`provisioner` and `connection`, for taking extra actions after resource creation](/docs/language/resources/provisioners/index.html)
   132  
   133  ## Operation Timeouts
   134  
   135  Some resource types provide a special `timeouts` nested block argument that
   136  allows you to customize how long certain operations are allowed to take
   137  before being considered to have failed.
   138  For example, [`aws_db_instance`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance)
   139  allows configurable timeouts for `create`, `update` and `delete` operations.
   140  
   141  Timeouts are handled entirely by the resource type implementation in the
   142  provider, but resource types offering these features follow the convention
   143  of defining a child block called `timeouts` that has a nested argument
   144  named after each operation that has a configurable timeout value.
   145  Each of these arguments takes a string representation of a duration, such
   146  as `"60m"` for 60 minutes, `"10s"` for ten seconds, or `"2h"` for two hours.
   147  
   148  ```hcl
   149  resource "aws_db_instance" "example" {
   150    # ...
   151  
   152    timeouts {
   153      create = "60m"
   154      delete = "2h"
   155    }
   156  }
   157  ```
   158  
   159  The set of configurable operations is chosen by each resource type. Most
   160  resource types do not support the `timeouts` block at all. Consult the
   161  documentation for each resource type to see which operations it offers
   162  for configuration, if any.