Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Author title

Using generic CI/CD tools for your IaC automation? 🤖⚙️

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Transform your IaC management to scale
securely, efficiently, and productively
into the future.

Blog

What Are Terraform Modules and How to Use Them: Tutorial

Terraform Functions, Expressions, Loops (Examples)

Managing Terraform State - Best Practices & Examples

Terraform For Loop - Expression Overview with Examples

What is Terraform? What is it Used For, How it Works

44 Ansible Best Practices to Follow [Tips & Tricks]

How to Stop and Remove Docker Containers

How to Create a CI/CD Pipeline with Docker [Tutorial]

CI/CD Pipeline : Everything You Need To Know

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

Terraform with Azure DevOps CI/CD Pipelines - Tutorial

Terragrunt Tutorial - Getting Started & Examples

Pulumi Pricing – Editions Overview 2024

73 Most Useful DevOps Tools to Use in 2024

Top 10 Terraform Enterprise Alternatives for 2024

Terraform Cloud/Enterprise Pricing - Tiers Overview 2024

16 Most Useful Infrastructure as Code (IaC) Tools for 2024

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

ebook-global-banner

ebook global banner

Product overview

How it works

Integrations

Product

Solutions

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

Infrastructure at Scale

Use cases

Financial

Technology

Industries

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

blog-2

partners

Partners

partners-2

events

Events

events-2

Insights and quick guides to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Ebooks & Cheatsheets

users

Users

users-2

Case studies

33-what-makes-spacelift-secure

What Makes Spacelift Secure

About Us

Contact Us

About

cheatsheets-2

Test

See more

Test webinar name

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Terraform

Stanislaw Szymanski

Flavius Dinu

Terraform makes it easier to grow your infrastructure and keep its configuration clean. But, as the infrastructure grows, a single directory becomes hard to manage.
That’s where Terraform modules come in. 
In this post, you will learn what Terraform modules are, how to use them, and what problems they solve.
<ol>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#what-is-a-terraform-module">What is a Terraform module?</a></li>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#types-of-terraform-modules">Types of Terraform modules</a></li>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#when-should-you-use-terraform-modules">When should you use Terraform modules?</a></li>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#how-to-use-terraform-modules">How to use Terraform modules</a></li>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#what-problems-do-terraform-modules-solve">What problems do Terraform modules solve?</a></li>
<li><a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work#terraform-modules-best-practices">Terraform modules best practices</a></li>
</ol>

A Terraform module is a collection of standard configuration files in a dedicated directory. Terraform modules encapsulate groups of resources dedicated to one task, reducing the amount of code you have to develop for similar infrastructure components.
Some say that Terraform modules are a way of extending your present Terraform configuration with existing parts of reusable code reducing the amount of code you have to develop for similar infrastructure components. Others say that the Terraform module definition is a single or many .tf files stacked together in their own directory. Both are correct.
Module blocks can also be used to force compliance on other resources—to deploy databases with encrypted disks, for example. By hard-coding the encryption configuration and not exposing it through <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">variables</a>, you’re making sure that every time the module is used, the disks are going to be encrypted. 
A typical module can look like this:

As you can see, practically any Terraform configuration is already a module in itself. If you run Terraform in this directory, those configuration files would be considered a root module. It means that this configuration is the base of your operation, a core that you can expand further.
If you need more help learning about Terraform, check out our <a href="https://spacelift.io/blog/terraform-tutorial" target="_blank" rel="noopener">Get Started with Terraform tutorial</a>.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.
<h3>What is the difference between resources and modules in Terraform?</h3>
A resource in Terraform describes a piece of infrastructure that is going to be created (e.g., a VPC, a subnet, an ec2 instance, etc), whereas a module is a collection of resources that are used together to achieve a reusable use case.

Modules are used to create reusable components inside your infrastructure. There are primarily two types of modules depending on how they are written (root and child modules), and depending if they are published or not, we identify two different types as well (local and published).
<h3>Root module</h3>
The root module consists of all the resources defined in the .tf files in a Terraform configuration, meaning that all Terraform configurations have their own root module. 
Even if you are simply creating a main.tf that has just a locals block inside of it with a local variable, that is still considered a root module. 
This can be confusing, but keep in mind that every Terraform configuration can become a reusable module for other configurations. Every module can call other modules, and all of the modules called inside another module are considered child modules.
<h3>Child module</h3>
Calling a child module means to include all the resources defined in that module in the current configuration. This is done by using a module block inside your Terraform configuration:

You can call the same module as many times as you want and configure it to your liking.
<h3>Local module</h3>
A local module is a module that wasn’t published in any registry and when it is sourced, it is using the path to that particular module.
<h3>Published module</h3>
A published module refers to a module that has been pushed to a Terraform Registry, or even simply on a VCS and has a tag associated with it. When a published module is sourced, the URL of that module is used either from the registry or from the VCS itself.

The short answer to this question is always, but depending on your organization and where you are in the infrastructure as code journey, this may vary.
The best way to think about writing Terraform code is to keep reusability in mind. HCL, being a declarative language, can be very wordy, so repeating the same configuration over and over again will be cumbersome. So usually, if you can, start by defining modules from the beginning and then try to use them as much as possible for maximum reusability. 
If you are just starting with Terraform or IaC in general, you can omit using modules until you get a grasp of how Terraform works.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

OK, now that you know what a Terraform module is, let’s take a look at a step-by-step process of creating them. So, let’s get started!
<h3>1. Create the module block</h3>
To use a Terraform module, you have to first declare that you wish to use it in your current configuration. To do this, use the module block and provide the appropriate variable values:

As you’re adding the variables, there are a few arguments that you should keep an eye on: their source, version, and four meta-arguments.
<h4>Sources</h4>
Terraforms modules can be stored either locally or remotely. The `source` argument will change depending on their location. For example, if the module you wish to call is stored in a directory named “terraform-test-module” located in the same place as your root module directory, your root configuration would look like this:

But, if you want to keep the module in a VCS (let’s assume git and GitHub), the source will need to point to the correct repository containing the appropriate version of the module that you’re calling:

Terraform modules can also be stored in so-called registries. <a href="https://spacelift.io/blog/terraform-registry" target="_blank" rel="noopener">Registries</a> are places where you can find modules published by fellow Terraform users, or where you store the ones you have created—either privately, for your company/yourself, or publicly, for everyone to enjoy. A Terraform module called from a registry might look like this:

Please note that the URL scheme depends on the registry provider. For example, imagine that you wish to include a VPC module stored in the <a href="https://spacelift.io/blog/spacelift-module-registry" target="_blank" rel="noopener">Spacelift registry</a> in your configuration:

As you’ve probably noticed, those two examples are a bit different from one another. A big advantage of the Spacelift’s registry is that it provides an example for each module. This means that you can check whether the source argument in your configuration is correct. Additionally, you can grab the entire example and use it as a template, filling in the blanks, and starting your work right away!
<h4>Versions</h4>
Versioning enables you to control what module changes should be introduced into your infrastructure. Why is it useful? It helps prevent the damage of your infrastructure caused by unpredictable updates or faulty code. You probably know from experience that any update of software, packages, or applications on a production server can go wrong. This can also happen to Terraform modules, if they’re not kept under control.
The syntax for version constraints is simple. Simply put, a version is a string containing one or more conditions. 
The first part is an operator:
<ul>
<li style="font-weight: 400;" aria-level="1">“=” (or no operator) means “Only one version—this specific version.”</li>
<li style="font-weight: 400;" aria-level="1">“!=” translates to “Other versions are fine, except this one here”</li>
<li style="font-weight: 400;" aria-level="1">“&gt;, &gt;=, &lt;, &lt;=” are used for comparisons. For example, “Use any version newer than 1.0.0, but older than 1.1.0”</li>
<li style="font-weight: 400;" aria-level="1">“~&gt;” is quite interesting. This operator allows only the rightmost part of the version number to increment. In other words, “~&gt;2.6.0” would mean that you wish to use the newest patch version of the module (2.6.&lt;anything&gt;), but not the newer minor or major versions (2.7.0 or above).</li>
</ul>
The second part of the syntax is the version number. Although it isn’t absolutely required (except when using registries), it’s best to stick to the <a href="https://semver.org/" target="_blank" rel="nofollow noopener">Semantic Versioning convention</a>—it’s easy to understand and very transparent. One look at the version, and you know where you are.
As you might have already noticed, there is an exception to the “keep things versioned” rule—in two of the examples above, the version argument is defined. In one, it&#8217;s not. The reason for this is that Terraform considers modules loaded from the same source repository as being of the equal version to the caller. Local modules, by the way, need no version constraints whatsoever.
<h4>Meta-Arguments</h4>
Meta-arguments are special arguments that change the behavior of Terraform when parsing the declared module. Currently, there are four of them in active use:
<ul>
<li style="font-weight: 400;" aria-level="1">“Count” and “for_each” are used to create multiple instances of the same module or resource. More on this: <a href="https://spacelift.io/blog/terraform-count-for-each" target="_blank" rel="noopener">Terraform Count vs. For_Each Meta-Argument: When to Use Them</a> 
</li>
<li style="font-weight: 400;" aria-level="1">“providers”— this meta-argument allows you to directly declare which provider the module should use for its operation. This comes in handy if you have two cloud service accounts and you want to create resources bound to the secondary. In order to achieve that, you need to properly design your Terraform module so that it takes the provider as an argument and passes it along, like this:</li>
</ul>

<ul>
<li>“<a href="https://spacelift.io/blog/terraform-depends-on" target="_blank" rel="noopener">depends_on</a>”—usually, Terraform handles implicit dependencies quite well, but sometimes they aren’t enough. If you need to declare that something should be created before something else, use this meta-argument to define an explicit boundary between resources or modules.</li>
</ul>

<h3>2. Declare module outputs</h3>
Sometimes you might need to use the values that are available in the already created resources. A Terraform module completely encapsulates those resources, and here’s how they can be accessed. 
First, declare in your Terraform module that the selected value should be available as an output:

Then, call this value like this:

The module outputs are not passed on from the resources by default—so if you don’t declare an output, it won’t exist.
<h3>3. Taint Terraform modules</h3>
Sometimes you might need to recreate some or even all component parts of the Terraform module. As there is no way of flagging an entire module that needs to be recreated, you will need to manually taint every resource that was created by the module. While it may seem like a downside, it is actually a feature that offers additional protection against human error. What’s more, you will rarely need to taint an entire Terraform module.
To taint the resources that were created by the example module presented above, try this: 
terraform taint module.example.aws_example_resource.example_something
<h3>4. Test modules</h3>
Whether a blessing or a curse, Terraform’s code is still code, and should be properly tested. It is absolutely crucial. But when done manually, it can be quite a chore. Luckily, Spacelift, alongside other upgrades and extensions, provides automated module testing and you will absolutely love it. 
Terraform modules managed by the Spacelift registry get tested every time you push a new commit. They are applied, deleted, and you get all of the details on the run. If something fails along the way, the entire test fails, too. If everything goes smoothly, the test is successful. The entire process is automatic, but if you feel like playing around with it, you can even write your own tests, such as this one:

Customizable automated testing—what’s not to love here?

Alright, now that you know how to use Terraform modules and what to keep an eye on when doing it, let’s see what problems Terraform modules solve.
<h3>1. Code Repetition</h3>
As your <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">Terraform infrastructure grows in scale</a>, the code will need to do so as well. Copy-pasting an entire stack of code whenever you need more than a single instance of something isn’t scalable or efficient. It’s a waste of many things, time in particular.
<h3>2. Lack of Code Clarity</h3>
Copy-pasting isn’t clean either. Good code is readable, and great code documents itself. A modular approach addresses all those pesky details. A configuration of connecting modules dedicated to particular tasks is much easier to read and understand. 
<h3>3. Lack of Compliance</h3>
When you create a Terraform module in compliance with appropriate standards and best practices, whenever you reuse it, it follows the same right pattern. No matter if it’s encryption, redundancy, or lifecycle policies—practices configured inside the module will be enforced, so that you won’t have to do it again personally.
<h3>4. Human Error</h3>
When you copy-paste or create a group of resources from scratch, it’s easy to make a mistake, like rewriting or renaming something. To make sure that doesn’t happen, create a single Terraform module, test it, then use it in multiple places to check whether all of the elements are correct. It’s easier to check and test what you type into a single block than scroll, jumping from one place to another, and so on. 
As you can see, there are a lot of advantages to using Terraform modules, so long as they aren’t overused. Find the right balance and keep it.

There are a couple of things you should consider when using Terraform modules:
<ol>
<li>Each Terraform module should live in its own repository, and versioning should be leveraged.</li>
<li>Minimal structure: main.tf, variables.tf, outputs.tf.</li>
<li>Each Terraform module should have examples inside of them.</li>
<li>Use input and output variables (outputs can be accessed with <code>module.module_name.output_name</code>).</li>
<li>Used for multiple resources, a single resource module is usually a bad practice.</li>
<li>Use defaults or optionals depending on the data type of your variables.</li>
<li>Use <a href="https://spacelift.io/blog/terraform-dynamic-blocks" target="_blank" rel="noopener">dynamic blocks</a>.</li>
<li>Use ternary operators and take advantage of Terraform built-in functions.</li>
<li>Test your modules.</li>
</ol>

The logic of Terraform modules may seem a bit complicated at first, but in the end, is a simple and efficient way of building your infrastructure quickly and reliably. If you want to step up your efforts, check out <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> and the additional features it offers, which extend and perfect the modular approach.
Spacelift provides everything you need to make your module easily maintainable and usable. There is CI/CD for multiple specified versions of Terraform, which is capable of testing your module on each commit. You get an autogenerated page describing your Module and its intricacies, so your users can explore them and gather required information at a glimpse. It&#8217;s also deeply integrated with all the features <a href="https://docs.spacelift.io/concepts/stack/" target="_blank" rel="noopener">Stacks</a> use which you know and love, like <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">Environments</a>, <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a>, <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a>, and <a href="https://docs.spacelift.io/concepts/stack/stack-settings#worker-pool" target="_blank" rel="noopener">Worker Pools</a>. <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">Create a trial account and check it out for free</a>.
Cross-organization private module sharing and the above-mentioned module testing automation will help you get the most out of your configuration and make its development a lot smoother.
If you need more help with Terraform, I encourage you to check the following blog posts: <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a>, and <a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">12 Terraform Best Practices.</a>
Enjoy writing your code and growing your infrastructure, and have a productive day!

Spacelift helps manage Terraform state, build more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

Grab our ultimate cheat sheet PDF to master building reusable Terraform modules!

frame-8479

Frame 8479

How to Use Terraform Variables: Examples & Best Practices

How Spacelift Can Improve Your Infrastructure Orchestration

Terraform Taint, Untaint, Replace - How to Use It (Examples)

Deep dive into Terraform modules - what is it, how to create it, when and how to use it with examples. Terraform module vs resource explained.

14-terraform-modules

terraform modules

What Are Terraform Modules and How to Use Them - Tutorial

Sumeet Ninawe

Variables are fundamental constructs in every programming language because they are inherently useful in building dynamic programs. We use variables to store temporary values so that they can assist programming logic in simple as well as complex programs.
In this post, we discuss the types of Terraform variables and how they are used in Terraform. We will also present examples and 10 best practices to use Terraform variables. 
Terraform uses HCL (Hashicorp Configuration Language) to encode infrastructure. It is declarative in nature, meaning several blocks of code are declared to create a desired set of infrastructure. Before we dive into various types of variables, it is helpful to think of the complete Terraform configuration as a single function. As far as variables are concerned, we use them with function in the form of arguments, return values, and local variables. These are analogous to input variables, output variables, and local variables in Terraform.
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#what-are-terraform-variables" rel="">What are Terraform variables?</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#terraform-variables-types" rel="">Terraform variable types</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#local-variables">Local variables</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#terraform-input-variables">Input variables</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#variable-substitution-using-cli-and-tfvars">Variable substitution using CLI and .tfvars</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#environment-variables">Environment variables</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#variable-precedence">Variable precedence</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#variable-validation">Variable validation</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#sensitive-variables">Sensitive variables</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#output-variables">Output variables</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#using-variables-in-foreach-loop">Using variables in for_each loop</a></li>
<li><a href="https://spacelift.io/blog/how-to-use-terraform-variables#terraform-variables-best-practices">Terraform variables best practices</a></li>
</ol>
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

Terraform variables are placeholders for values that you can use to make your configurations more dynamic and reusable. They let you define values that can be reused throughout your Terraform configuration, similar to variables in any programming language. 
Terraform variables are used to accommodate different configurations without altering your code. You can easily change only the values of these variables to achieve different use cases. They make your configuration more dynamic and flexible, and they enhance the parametrization of your code. 
The importance of Terraform variables
Terraform variables are essential for building scalable, maintainable, and adaptable infrastructure configurations, ultimately contributing to efficient infrastructure management and deployment practices.

Terraform has several types of variables, each designed to handle different kinds of data. Below is the full list of Terraform variable types:
<ul>
<li style="font-weight: 400;" aria-level="1">String — This fundamental type stores text values. Use strings for data that doesn&#8217;t require mathematical operations, such as usernames or tags.</li>
<li style="font-weight: 400;" aria-level="1">Number — This type is used for numeric values that you might need to perform calculations on or use in numeric settings, such as scaling parameters, setting timeouts, and defining a number of instances to deploy.</li>
<li style="font-weight: 400;" aria-level="1">Bool — Short for Boolean, this type is strictly for true or false values. They are essential for logic and conditional statements in configurations, such as enabling or disabling resource provisioning.</li>
<li style="font-weight: 400;" aria-level="1">List — A list is a sequence of values of the same type. This type is ideal for scenarios where you need to manage a collection of similar items, like multiple configuration tags.</li>
<li style="font-weight: 400;" aria-level="1">Map — Maps are collections of key-value pairs, each unique key mapping to a specific value. This type is useful, for example, when associating server names with their roles or configurations.</li>
<li style="font-weight: 400;" aria-level="1">Tuple — This type is similar to lists but can contain a fixed number of elements, each potentially of a different type. Tuples are suitable when you need to group a specific set of values with varied types together, like a coordinate of mixed data types.</li>
<li style="font-weight: 400;" aria-level="1">Object — Objects are used to define a structure with named attributes, each with its own type. They are very flexible, allowing the definition of complex relationships, like a configuration block that includes various attributes of different types.</li>
<li style="font-weight: 400;" aria-level="1">Set — Sets are collections of unique values of the same type. They are useful when you need to ensure no duplicates, such as a list of unique user identifiers or configurations that must remain distinct.</li>
</ul>
We’ll discuss these in more detail with examples later in the article.

Local variables are declared using the <code>locals</code> block. It is a group of key-value pairs that can be used in the configuration. The values can be hard-coded or be a reference to another variable or resource.
Local variables are accessible within the module/configuration where they are declared. Let us take an example of creating a configuration for an EC2 instance using local variables. Add this to a file named <code>main.tf</code>.

In this example, we have declared all the local variables in the locals block. The variables represent the AMI ID (<code>ami</code>), Instance type (<code>type</code>), Subnet Id (<code>subnet</code>), Network Interface (<code>nic</code>) and Tags (<code>tags</code>) to be assigned for the given EC2 instance.
In the <code>aws_instance</code> resource block, we used these variables to provide the appropriate values required for the given attribute. Notice how the local variables are being referenced using a <code>local</code> keyword (without ‘s’).
The usage of local variables is similar to data sources. However, they have a completely different purpose. Data sources fetch valid values from the cloud provider based on the query filters we provide. Whereas we can set our desired values in local variables — they are not dependent on the cloud providers.
It is indeed possible to assign a value from a data source to a local variable. Similar to how we have done it to create the <code>nic</code> local variable, it refers to the <code>id</code> argument in the <code>aws_network_interface</code> resource block.
As a best practice, try to keep the number of local variables to a minimum. Using many local variables can make the code hard to read.
If you want to know more about locals, see: <a href="https://spacelift.io/blog/terraform-locals">Terraform Locals: What Are They, How to Use Them, Examples</a>

Terraform input variables are used to pass certain values from outside of the configuration or module. They are used to assign dynamic values to resource attributes. The difference between local and input variables is that input variables allow you to pass values before the code execution.
Further, the main function of the input variables is to act as inputs to modules. <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> are self-contained pieces of code that perform certain predefined deployment tasks. Input variables declared within modules are used to accept values from the root directory.
Additionally, it is also possible to set certain attributes while declaring input variables, as below:
<ul>
<li style="font-weight: 400;" aria-level="1"><code>type</code> — to identify the type of the variable being declared.</li>
<li style="font-weight: 400;" aria-level="1"><code>default</code> — default value in case the value is not provided explicitly.</li>
<li style="font-weight: 400;" aria-level="1"><code>description</code> — a description of the variable. This description is also used to generate documentation for the module.</li>
<li style="font-weight: 400;" aria-level="1"><code>validation</code> — to define validation rules.</li>
<li style="font-weight: 400;" aria-level="1"><code>sensitive</code> — a boolean value. If true, Terraform masks the variable’s value anywhere it displays the variable.</li>
</ul>
<h3>Terraform input variable types</h3>
Input variables support multiple data types.
They are broadly categorized as simple and complex. <code>String</code>, <code>number</code>, <code>bool</code> are simple data types, whereas <code>list</code>, <code>map</code>, <code>tuple</code>, <code>object</code>, and <code>set</code> are complex data types.
The following snippets provide examples for each of the types we listed.
<h4>String type</h4>
The string type input variables are used to accept values in the form of UNICODE characters. The value is usually wrapped by double quotes, as shown below.

The string type input variables also support a heredoc style format where the value being accepted is a longer string separated by new line characters. The start and end of the value is indicated by “EOF” (End Of File) characters. An example of the same is shown below.

<h4>Number type</h4>
The number type input variable enables us to define and accept numerical values as inputs for their infrastructure deployments. For example, these numeric values can help define the desired number of instances to be created in an auto-scaling group. The code below defines a number type input variable in any given Terraform config.

<h4>Boolean type</h4>
The boolean type input variable is used to define and accept true/false values as inputs for infrastructure deployments to incorporate logic and conditional statements into the Terraform configurations. Boolean input variables are particularly useful for enabling or disabling certain features or behaviors in infrastructure deployments. 
An example of a boolean variable is below.

<h4>Terraform list variable</h4>
Terraform list variables allow us to define and accept a collection of values as inputs for infrastructure deployments. A list is an ordered sequence of elements, and it can contain any data type, such as strings, numbers, or even other complex data structures. However, a single list cannot have multiple data types.
List type input variables are particularly useful in scenarios where we need to provide multiple values of the same type, such as a list of IP addresses, a set of ports, or a collection of resource names. 
The example below is for an input variable of a type list that contains strings.

<h4>Map type</h4>
The map type input variable enables us to define and accept a collection of key-value pairs as inputs for our infrastructure deployments. A map is a complex data structure that associates values with unique keys, similar to a dictionary or an object in other programming languages. For example, a map can be used to specify resource tags, environment-specific settings, or configuration parameters for different modules.
 The example below shows how a map of string type values is defined in Terraform.

Learn <a href="https://spacelift.io/blog/terraform-map-variable" target="_blank" rel="noopener">how to use the Terraform map variable</a>.

<h4>Object type</h4>
An object represents a complex data structure that consists of multiple key-value pairs, where each key is associated with a specific data type for its corresponding value. The object type input variable allows us to define and accept a structured set of properties or attributes as inputs for our infrastructure deployments. For example, an object is used to define a set of parameters for a server configuration. 
The variable below demonstrates how an object type input variable is defined with multi-typed properties.

<h4>Tuple type</h4>
A tuple is a fixed-length collection that can contain values of different data types. The key differences between tuples and lists are:
<ol>
<li style="font-weight: 400;" aria-level="1">Tuples have a fixed length, as against lists.</li>
<li style="font-weight: 400;" aria-level="1">With tuples, it is possible to include values with different primitive types. Meanwhile, lists dictate the type of elements included in them.</li>
<li style="font-weight: 400;" aria-level="1">Values included in tuples are ordered. Due to their dynamic sizes, it is possible to resize and reorder the values in lists.</li>
</ol>
An example of a tuple type input variable:

<h4>Set type</h4>
A set is an unordered collection of distinct values, meaning each element appears only once within the set. As against lists, sets enforce uniqueness &#8211; each element can appear only once within the set. Sets support various inbuilt operations such as union, intersection, and difference, which are used to combine or compare sets. 
An example of a set type input variable is below.

<h4>Map of objects</h4>
One of the widely used complex input variable types is map(object). It is a data type that represents a map where each key is associated with an object value.
It allows us to create a collection of key-value pairs, where the values are objects with defined attributes and their respective values. When using map(object), we define the structure of the object values by specifying the attributes and their corresponding types within the object type definition. Each object within the map can have its own set of attributes, providing flexibility to represent diverse sets of data. 
An example of the same is given below, where the map of objects represents attribute values used for the creation of multiple subnets.

<h4>List of objects</h4>
This type of variable is similar to the Map of objects, except that the objects are not referred to by any “key”. The example used for the Map of objects can also be represented in the form of a list of objects, as shown below. 
The list(object) is an ordered list of objects where each object is referred to using the index. On the other hand, map(object) is an unordered set, and each object is referred to using the key value.

<h3>Terraform input variables example</h3>
Let us work through the same example as before. Only this time, we use variables instead of local variables. Create a new file to declare input variables as <code>variables.tf</code> and add the below content to it.

Here, we have declared 5 variables — <code>ami</code>, <code>nic</code>, <code>subnet</code> and <code>type</code> with the simple data type, and <code>tags</code> with a complex data type object — a collection of key-value pairs with string values. Notice how we have made use of attributes like <code>description</code> and <code>default</code>.
The <code>ami</code> variable also has validation rules defined for them to check the validity of the value provided. We have also marked the <code>type</code> variable as <code>sensitive</code>.
Let us now modify <code>main.tf</code> to use the variables declared above.

Within the resource blocks, we have simply used these variables by using <code>var.&lt;variable name&gt;</code> format. When you proceed to plan and apply this configuration, the variable values will automatically be replaced by default values. The following is a sample plan output.

To check how validation works, modify the default value provided to the <code>ami</code> variable. Make sure to change the <code>ami-</code> part since validation rules are validating the same. Run the <code>plan</code> command, and see the output. You should see the error message thrown on the console as below.

Also, notice how the <code>type</code> value is represented in the plan output. Since we have marked it as <code>sensitive</code>, its value is not shown. Instead, it just displays <code>sensitive</code>.

In the previous example, we relied on the default values of the variables. However, variables are generally used to substitute values during runtime. The default values can be overridden in two ways:
<ul>
<li style="font-weight: 400;" aria-level="1">Passing the values in CLI as <code>-var</code> argument.</li>
<li style="font-weight: 400;" aria-level="1">Using .tfvars file to set variable values explicitly.</li>
</ul>
If we want to initialize the variables using the CLI argument, we can do so as below. Running this command results in Terraform using these values instead of the defaults.

While working with <code>plan</code> or <code>apply</code> commands, <code>-var</code> argument should be used for every variable to be overridden. Note how we have provided the value for complex data type with escaped characters.
Imagine a scenario where many variables are used in the configuration. Passing the values using CLI arguments can become a tedious task. This is where .tfvars files come into play.
Create a file with the <code>.tfvars</code> extension and add the below content to it. I have used the name <code>values.tfvars</code> as the file name. This way we can organize and manage variable values easily.

This time, we should ask <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> to use the <code>values.tfvars</code> file by providing its path to <code>-var-file</code> CLI argument. The final <code>plan</code> command should look as such:

The <code>-var-file</code> argument is great if you have multiple <code>.tfvars</code> files with variations in values. However, if you do not wish to provide the file path every time you run <code>plan</code> or <code>apply</code>, simply name the file as <code>&lt;filename&gt;.auto.tfvars</code>. This file is then automatically chosen to supply input variable values.

Additionally, input variable values can also be set using <a href="https://spacelift.io/blog/terraform-environment-variables" target="_blank" rel="noopener">Terraform environment variables</a>. To do so, simply set the environment variable in the format <code>TF_VAR_&lt;variable name&gt;</code>.
The variable name part of the format is the same as the variables declared in the <code>variables.tf</code> file. For example, to set the <code>ami</code> variable run the below command to set its corresponding value.

Apart from the above environment variable, it is important to note that Terraform also uses a few other environment variables like <code>TF_LOG</code>, <code>TF_CLI_ARGS</code>, <code>TF_DATA_DIR</code>, etc. These environment variables are used for various purposes like logging, setting default behavior with respect to workspaces, CLI arguments, etc.

As we have seen till now, there are three ways of providing input values to Terraform configuration using variables. Namely—default values, CLI arguments, and <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener">.tfvars file</a>. The precedence is given to values passed via CLI arguments. This is followed by values passed using the <code>.tfvars</code> file and lastly, the default values are considered. 
In the current example, now that we have the <code>values.tfvars</code> file saved, try to run a <code>plan</code> command by passing values via CLI <code>-var</code> arguments. Make sure to provide different values as that of .tfvars and defaults. Terraform ignores the values provided via .tfvars and defaults.
If the values are not provided in the .tfvars file, or as defaults, or as CLI arguments, it falls back on <code>TF_VAR_</code> environment variables.
Additionally, if we don’t provide the values in any of the forms discussed above, Terraform would ask for the same in interactive mode when <code>plan</code> or <code>apply</code> commands are run.
As a best practice, it is not recommended to store secret and sensitive information in variable files. These values should always be provided via the <code>TF_VAR_</code> environment variable.
This is where <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> shines. It makes use of these Terraform native environment variables to manage secrets as well as other attributes that make the most sense. Managing the environment in the Spacelift console is easy, thanks to a dedicated tab where values can be edited on the go.

In any programming language, you try to catch the errors as soon as possible, and even if Terraform uses a declarative language, this is the same.
Variable validations ensure that constraints are applied to your variables. Before this feature was even introduced, the only way you could do validations was by making use of a hacky method leveraging the file function. Let’s see that in action:

Basically, in the above example, I’m checking if the network mask is lower than 16 and greater than 30, and if it is, my “validation” will try to open a file that doesn’t exist and will actually print out the error message that I want. Otherwise, it won’t print anything:

Now, let’s change the cidr to receive an error:

It does the job, but as you can see, the error message can be misleading.
With variable validations, however, things are improved a lot. Variable validations are defined in the variable block, and they receive two parameters:
<ul>
<li style="font-weight: 400;" aria-level="1">condition – what you want to check inside your variable</li>
<li style="font-weight: 400;" aria-level="1">error_message – what error message you would like your users to get if the condition is not fulfilled</li>
</ul>
Let’s recreate the above example with a variable validation:

This will result in an error because the cidr_block is not between /16 and /30:

We could take this example even up a notch and verify if the string we are passing is in a cidr format:

This validation checks if our cidr has a “/” and if it has 3 “dots”.

Terraform has also the ability to mark variables as sensitive and will not display their value when you are running <code>terraform plan</code> and <code>apply</code>, but they will be readable from within the Terraform state.
Let’s take a look at an example of a sensitive variable:

Now, if we want terraform not to error out and at least show the output, we should add the sensitive = true to that output:

If you want to see the sensitive value in the output too, Terraform has a mechanism in place for that if you are leveraging the nonsensitive function:

For situations where you <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">deploy a large web application infrastructure using Terraform</a>, you often need certain endpoints, IP addresses, database user credentials, and so forth. This information is most useful for passing the values to modules along with other scenarios.
This information is also available in Terraform state files. But state files are large, and normally we would have to perform an intricate search for this kind of information.
Output variables in Terraform are used to display the required information in the console output after a successful application of configuration for the root module. To declare an output variable, write the following configuration block into the Terraform configuration files.

Continuing with the same example, we would like to display the instance ID of the EC2 instance that is created. So, declare an output variable named <code>instance_id</code> — this could be any name of our choosing.
Within this output block, we have used some attributes to associate this output variable’s value. We have used resource reference for <code>aws_instance.myvm</code> configuration and specified to use its <code>id</code> attribute.
Optionally, we can use the <code>description</code> and <code>sensitive</code> flags. We have discussed the purpose of these attributes in previous sections. When a <code>plan</code> command is run, the plan output acknowledges the output variable being declared as below.

Similarly, when we run the <code>apply</code> command, upon successful creation of EC2 instance, we would know the instance ID of the same. Once the deployment is successful, output variables can also be accessed using the <code>output</code> command:

Output:

Output variables are used by child modules to expose certain values to the root module. The root module does not have access to any other component being created by the child module. So, if some information needs to be made available to the root module, output variables should be declared for the corresponding attributes within the child module.

This section goes through an example where we want to create multiple subnets for a given <a href="https://spacelift.io/blog/terraform-aws-vpc" target="_blank" rel="noopener">VPC</a>. Without variables, we would write the configurations for the number of subnets specified. The other way is to use the <a href="https://spacelift.io/blog/terraform-for-loop" target="_blank" rel="noopener">Terraform </a><a href="https://spacelift.io/blog/terraform-for-loop" target="_blank" rel="noopener"><code>for</code></a><a href="https://spacelift.io/blog/terraform-for-loop" target="_blank" rel="noopener"> loop</a> and create separate subnets based on the index value of the iteration.
The for loop thus implemented is not very useful. Consider a case where subnets need to be in selected availability zones, and each of them has a different CIDR range specified. For situations like these, we can make use of complex variable type <code>map(object())</code> along with <code>for</code> loop to iterate over this variable.
Below is the input variable declaration we need to define attributes of multiple subnets. This block specifies the <code>type</code> of variable <code>my_subnets</code> to be <code>map(object())</code>. It means we want to define a variable that has a map of objects, with a couple of attributes in each object. We have used <code>cidr</code> and <code>az</code> attributes for each object with string type.

Let us move to the .tfvars file to initialize the value for this input variable. The <code>.tfvars</code> file should contain the following lines of code.

If you compare the input variable declaration and initialization, you will see we have aligned the attributes. Also, the initialized value consists of 6 objects mapped by a string key. Each object has a unique CIDR and Availability Zone (<code>az</code>) value.
Lastly, let’s define the configuration for the subnets themselves. Note: The following code assumes that we have defined <code>aws_vpc.my_vpc</code> elsewhere in the configuration.

20 Terraform Best Practices to Improve your TF workflow

5 Ways to Manage Terraform at Scale - Best Practices

Terraform variables types and how to use them. Learn how to use local, input, output, and environment variables. See how to mark Terraform variables as sensitive.

21-terraform-variables

Terraform variables

How to Manage Active Directory Objects with Azure AD Provider for Terraform

Azure Guides and Tutorials | Spacelift Blog

Azure

Adam Connelly

The <a href="https://registry.terraform.io/providers/hashicorp/azuread/latest/docs" target="_blank" rel="nofollow noopener">Azure AD provider for Terraform</a> can be used to manage your Azure Active Directory resources declaratively. This allows you to do things like:
<ul>
<li style="font-weight: 400;" aria-level="1">Automatically provision users and make sure they belong to the correct groups.</li>
<li style="font-weight: 400;" aria-level="1">Manage Azure compute permissions via Azure AD groups.</li>
</ul>
In this post, you will learn what the Azure AD Terraform provider is used for, how to authenticate and grant permissions, and see examples of what you can do with it. Let’s get started.

The Terraform Azure AD Provider is a Terraform provider that is used to interact with Azure Active Directory using the Microsoft Graph API. Azure Active Directory is Microsoft’s cloud-based identity and access management (IAM) service, which helps users sign in and access resources. By using the Terraform provider for Azure AD, you can easily manage your AD-related resources directly from Terraform without needing another tool for this purpose.

The following example shows how to use the Azure AD provider to create a <a href="https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/group" target="_blank" rel="nofollow noopener">group</a> in Azure AD:

The <code>terraform</code> section at the beginning is used to specify the version of the provider that we want to use, while the <code>azuread_group</code>  resource defines our group.

The Azure AD provider allows for multiple authentication methods, which are outlined in the <a href="https://registry.terraform.io/providers/hashicorp/azuread/latest/docs#authenticating-to-azure-active-directory" target="_blank" rel="nofollow noopener">provider&#8217;s documentation</a>. To allow you to get up and running quickly, the AD provider will attempt to get your credentials via the <a href="https://docs.microsoft.com/en-us/cli/azure/install-azure-cli" target="_blank" rel="nofollow noopener">Azure CLI</a>.
While this is fine for experimentation and local testing, for non-interactive scenarios like CI you will need to use a Service Principal or a Managed Service Identity.

In order to manage your Azure AD objects, the account used by <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> needs to have the correct permissions to perform its actions. You can manage these permissions via the Roles and administrators section of Azure AD:

Roles and administrators section of Azure AD

For example, to allow a Service Principal to manage groups, you would add it to the Groups administrator role:

Azure AD Groups administrator

The Terraform provider is well documented, and will typically contain a notice at the top of each resource explaining the permissions that are required for using it.

Learn how to manage Active Directory Objects with Azure AD Provider for Terraform. Check Terraform Azure AD provider usage examples.

What Are Terraform Modules and How to Use Them: Tutorial

Get the newsletter

Recent posts

How to Use Terraform Variables: Examples & Best Practices

Managing Active Directory with Azure AD Terraform Provider

Terraform Data Sources – How They Are Utilized

What is OPA? Open Policy Agent Examples & Tutorial

Provisioning AWS EKS Cluster with Terraform – Tutorial

Importing Existing Infrastructure Into Terraform – Step by Step

How to Rename an AWS S3 Bucket in Terraform – Step by Step

What is Terraform? What is it Used For, How it Works

Share your data and download the guide