Resources in Detail

Terraform resources#

Resources in Terraform represent things in the real world. For example, a resource could be an AWS Load Balancer, an alarm in PagerDuty, a policy in Vault, etc. The resource is the bedrock of Terraform. They allow you to define how you want to create something in the real world. Remember, you can create resources representing things from multiple vendors (for example, multiple clouds) in a single project.

Your project resource#

Let’s take a look in a bit more detail at the resource we defined in the previous chapter:

The resource type aws_s3_bucket starts with the name of the provider followed by an underscore (aws_). This allows you to tell just from the first word of the resource which vendor or component this resource will be created in.

Resource examples#

Let’s take a look at a few other examples:

The department resource above will create a folder in Google Cloud (GCP). You can see that it starts with google_ which is the name of the Google Cloud (GCP) provider. Every resource for this provider will start with google_.

Postgres provider resource example#

The my_role resource above will create a login on a Postgres database, with login name my_role and password password123. The resource name starts with postgresql_ as every resource for the Postgres provider will.

If we look back at our S3 bucket resource, the last word on the line in quotes was "first_bucket". This is the identifier for that S3 bucket within your Terraform project. The identifier is what we use inside our project to refer to an instance of a resource. If you created multiple instances of the same resource (for example, you could create many S3 buckets), the identifier would provide you a way to reference each one.

Resource properties#

The key name value pairs that make up the body of the resource are the properties for the resource. Some properties on the resource are mandatory and some are optional. For an AWS S3 bucket, the only mandatory property is the name of the bucket. We could have set more properties on the bucket, though. For example:

In the above example, we are setting the acl to private which essentially says that this bucket will only allow private access. We are also setting two properties for versioning, one to say we are enabling versioning and another to say that you do not require MFA to delete an item on this bucket. You will notice that the properties for versioning are nested in another object. This is a design choice by the resource creator that groups all of the versioning properties together. You may also notice that the two properties in the versioning section are booleans (true/false). These do not require quotes around them like strings do, as we have done for the other two properties.

You can get a full list of all of the properties that are supported for an S3 bucket on the Terraform provider documentation page. The documentation is quite easy to find on Google.

Another resource type#

Let’s take a look at another resource type to examine the other data types that resources can take in their properties:

In the above resource, we have the two other types of data resources that can take numbers and lists. The port properties (from_port and to_port) are numbers and are set by providing a value without quotes. cidr_blocks is a list type, which takes a list of CIDR blocks to which it will restrict this security group. You can see that a list is given in the same way a JSON array of strings is created, in that you surround it in square braces.