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