<p><a href="https://docs.cloudposse.com/terraform-modules/overview/" rel="nofollow noreferrer">Terraform modules</a> are a way to encapsulate reusable business logic in order to be <a href="https://docs.cloudposse.com/glossary/dry/" rel="nofollow noreferrer">DRY</a>. For example, you might use a module to define a <a href="https://github.com/cloudposse/terraform-aws-jenkins" rel="nofollow noreferrer">jenkins</a> setup, then invoke that module every time you want a jenkins server. In other words, you can instantiate modules as many times as you need them to achieve the same outcome. </p>

<p>On the other hand, Terraform workspaces are a way to isolate terraform state between environments. For example, you don't want to mingle state between a production and staging environments. </p>

<p>In practice, we <em>highly</em> recommend writing modules for <em>everything</em>. This is why we have over <a href="https://github.com/cloudposse?q=terraform-" rel="nofollow noreferrer">100+ modules</a>.  Writing modules is like writing "functions" in other languages. Generally, it's considered a bad practice to stick all logic in a single function or scope; modules help us avoid that. </p>

<p>Workspaces are nice in principle, but in practice we recommend to share <em>nothing</em> between production and staging environments, including terraform state. Workspaces violate this principle. Thus we architect things so that production state remains in the production account and staging state in the staging account. We accomplish this with our <a href="https://github.com/cloudposse/terraform-aws-tfstate-backend" rel="nofollow noreferrer"><code>terraform-aws-tfstate-backend</code></a> module.</p>

<p>———</p>

<p>For the record, “we” refers to <a href="https://cloudposse.com" rel="nofollow noreferrer">Cloud Posse</a>, a DevOps professional services company. I am the founder. The views expressed are our own and may not represent the views of the community at large. :)</p>

CC BY-SA 4.0
2018-07-27T06:47:12.910Z
As you're using we along the answer, you may wish to drop a line about who is 'we' and you relation to it.
Tensibai
CC BY-SA 4.0
2018-07-27T03:37:11.107Z
2018-07-27T20:48:13.023Z
2018-07-27T20:48:13.023Z
Erik Osterman
<p>I think a key difference between Terraform Modules and Workspaces is that modules can be inherited and used by other modules and configurations. Terraform Workspaces are intended to be a collection of configurations that represent a single environment, whereas Modules are components that can be utilized by one or more modules/configurations. I think you could use Modules in a similar way to how you are using Workspaces, but you would be contradicting the intent of the Modules. </p>

<p>For example, say that you want to create a base configuration file for all your company's EC2 instances that allows traffic over SSH. You would create a module that spins up a VM, modifies your firewall to allow SSH, and any other configuration settings that you would want all of your instances to have. You would then have every VM Terraform config inherit this file. This would minimize the amount of code that you would have to write and allow for any changes that you would want across all of your TF configs to be made in one central module. </p>

CC BY-SA 3.0
2018-01-25T20:01:21.923Z
Thanks for the answer. what does "but you would be contradicting the intent of them." mean? I am configuring different environments like dev, test, prod. in general, is workspace the right way or module the right way?
user389955
CC BY-SA 3.0
2018-01-25T20:12:48.057Z
@user389955 corrected for a little more clarity. If you used modules in the way you are using right now, you would not be using them as they were intended. Modules are not intended to be single environment configurations, but are meant to be shareable components utilized by other TF configurations. IMHO, it would be like using a build system to deploy to your artifacts. You certainly CAN do it, but it's not the intent of the system. I think you are currently using Workspaces as they were intended.
Preston Martin
CC BY-SA 3.0
2018-01-26T01:01:47.530Z
@ PrestonM: my understanding is that you think my current way (using workspace to configure dev, test, prod env) is better than using module. is it correct? thanks.
user389955
CC BY-SA 3.0
2018-01-26T14:53:08.080Z
@user389955 Yes, I believe you are using them correctly. I have added an example into my original answer of a use case for a module.
Preston Martin
CC BY-SA 3.0
2018-01-25T19:07:09.367Z
2018-01-26T15:23:49.823Z
2018-01-26T15:23:49.823Z
Preston Martin
<p>I currently use Terraform workspaces to configure different environments like dev, test, prod, and my code works fine. And I believe I can use workspaces to configure different regions as well. </p>

<p>However, I think Terraform modules can do the same thing, right?</p>

<p>If that's so, when should I use workspaces and when should I use modules? Or they are doing a similar thing in different ways?</p>

<terraform><terraform-module><terraform-workspace>
What is the difference between modules and workspaces in Terraform
user389955
# What is the difference between modules and workspaces in Terraform

(Asked by: username_0 on 2018-01-25)

I currently use Terraform workspaces to configure different environments like dev, test, prod, and my code works fine. And I believe I can use workspaces to configure different regions as well.

However, I think Terraform modules can do the same thing, right?

If that's so, when should I use workspaces and when should I use modules? Or they are doing a similar thing in different ways?

**Tags:** terraform, terraform-module, terraform-workspace


---

## 2 answers

### Answer by username_3 on 2018-01-25. Score: 4 | Accepted answer

I think a key difference between Terraform Modules and Workspaces is that modules can be inherited and used by other modules and configurations. Terraform Workspaces are intended to be a collection of configurations that represent a single environment, whereas Modules are components that can be utilized by one or more modules/configurations. I think you could use Modules in a similar way to how you are using Workspaces, but you would be contradicting the intent of the Modules.

For example, say that you want to create a base configuration file for all your company's EC2 instances that allows traffic over SSH. You would create a module that spins up a VM, modifies your firewall to allow SSH, and any other configuration settings that you would want all of your instances to have. You would then have every VM Terraform config inherit this file. This would minimize the amount of code that you would have to write and allow for any changes that you would want across all of your TF configs to be made in one central module.

> **Comments:**
> **username_0**: Thanks for the answer. what does "but you would be contradicting the intent of them." mean? I am configuring different environments like dev, test, prod. in general, is workspace the right way or module the right way?  
> **username_3**: @username_0 corrected for a little more clarity. If you used modules in the way you are using right now, you would not be using them as they were intended. Modules are not intended to be single environment configurations, but are meant to be shareable components utilized by other TF configurations. IMHO, it would be like using a build system to deploy to your artifacts. You certainly CAN do it, but it's not the intent of the system. I think you are currently using Workspaces as they were intended.  
> **username_0**: @ PrestonM: my understanding is that you think my current way (using workspace to configure dev, test, prod env) is better than using module. is it correct? thanks.  
> **username_3**: @username_0 Yes, I believe you are using them correctly. I have added an example into my original answer of a use case for a module.  

---

### Answer by username_1 on 2018-07-27. Score: 4

[Terraform modules](https://docs.cloudposse.com/terraform-modules/overview/) are a way to encapsulate reusable business logic in order to be [DRY](https://docs.cloudposse.com/glossary/dry/). For example, you might use a module to define a [jenkins](https://github.com/cloudposse/terraform-aws-jenkins) setup, then invoke that module every time you want a jenkins server. In other words, you can instantiate modules as many times as you need them to achieve the same outcome.

On the other hand, Terraform workspaces are a way to isolate terraform state between environments. For example, you don't want to mingle state between a production and staging environments.

In practice, we *highly* recommend writing modules for *everything*. This is why we have over [100+ modules](https://github.com/cloudposse?q=terraform-). Writing modules is like writing "functions" in other languages. Generally, it's considered a bad practice to stick all logic in a single function or scope; modules help us avoid that.

Workspaces are nice in principle, but in practice we recommend to share *nothing* between production and staging environments, including terraform state. Workspaces violate this principle. Thus we architect things so that production state remains in the production account and staging state in the staging account. We accomplish this with our [`terraform-aws-tfstate-backend`](https://github.com/cloudposse/terraform-aws-tfstate-backend) module.

———

For the record, “we” refers to [Cloud Posse](https://cloudposse.com), a DevOps professional services company. I am the founder. The views expressed are our own and may not represent the views of the community at large. :)

> **Comments:**
> **username_2**: As you're using we along the answer, you may wish to drop a line about who is 'we' and you relation to it.  

---

