Terraform Modules: Reuse AWS Infrastructure Code
Learn how Terraform modules make AWS infrastructure reusable, organized, and easier to maintain across development and production environments.
Series: My 90-Day AWS & DevOps Learning Journey (27 articles)
- …
- 25Terraform Modules: Reuse AWS Infrastructure Code This article
Terraform Modules: Reuse AWS Infrastructure Code
Imagine creating three environments for the same application: development, testing, and production.
Each environment needs an S3 bucket, security groups, networking, and other AWS resources.
Would you write the same Terraform configuration three times?
That might work for a small experiment, but maintaining duplicated code becomes difficult as infrastructure grows.
This is where Terraform modules become useful.
As I continue learning Infrastructure as Code, I'm exploring how DevOps engineers keep their infrastructure configurations reusable and organized.
What Is a Terraform Module?
A Terraform module is a collection of Terraform configuration files managed together for a specific purpose.
Every Terraform configuration starts as a root module: the collection of files in the working directory where Terraform commands are run.
We can also create child modules to group reusable infrastructure components.
For example, we could create a module for:
- An S3 bucket
- A VPC and its subnets
- An EC2 application server
- A reusable security-group configuration
- A complete application environment
Instead of repeatedly writing the same resource definitions, we can call a module with different input values.
Why Are Modules Useful?
Imagine you need to create similar S3 buckets for different environments.
Without a module, you might duplicate resource configuration and update the names and settings in multiple places.
With a module, you can define the reusable logic once and supply different inputs.
This helps with:
- Reusing infrastructure code
- Keeping configurations organized
- Reducing duplication
- Applying consistent standards
- Making changes easier to maintain
Modules don't automatically make infrastructure secure or eliminate every configuration error, but they can make good practices easier to reuse.
A Simple Terraform Module Example
Let's create a small module that defines an S3 bucket.
Our folder structure could look like this:
1
2
3
4
5
6
7
8
terraform-project/
├── main.tf
├── variables.tf
└── modules/
└── s3-bucket/
├── main.tf
├── variables.tf
└── outputs.tfStep 1: Define the module resource
Inside
modules/s3-bucket/main.tf:1
2
3
resource "aws_s3_bucket" "this" {
bucket = var.bucket_name
}This defines the bucket using an input variable.
Step 2: Create the input variable
Inside
modules/s3-bucket/variables.tf:1
2
3
4
variable "bucket_name" {
description = "Name of the S3 bucket"
type = string
}Now the module can accept a bucket name rather than hardcoding one.
Step 3: Call the module
Inside the root
main.tf:1
2
3
4
module "app_bucket" {
source = "./modules/s3-bucket"
bucket_name = "replace-with-a-unique-bucket-name"
}Replace the example name with a valid, globally unique S3 bucket name before applying the configuration.
The
source argument points Terraform to the local module directory.When Terraform processes this configuration, it uses the module to define the S3 bucket resource.
For real applications, the module should also account for required security settings, encryption, public-access blocking, and other appropriate controls.
How Do Modules Help With Multiple Environments?
Suppose your application needs separate development and testing buckets.
You can call the same module twice:
1
2
3
4
5
6
7
8
9
module "dev_bucket" {
source = "./modules/s3-bucket"
bucket_name = "replace-with-unique-dev-name"
}
module "test_bucket" {
source = "./modules/s3-bucket"
bucket_name = "replace-with-unique-test-name"
}The example illustrates reuse, but it requires two distinct, globally unique bucket names.
The important idea is that the resource logic lives in one place, while each module call supplies its own configuration.
For larger projects, teams may organize environments using separate root configurations, workspaces, or other environment-management approaches depending on their needs.
Where Do Modules Fit Into DevOps?
Modules become especially useful when infrastructure is managed through Git and CI/CD.
A simplified workflow looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
Terraform Modules
↓
Git Repository
↓
Code Review
↓
Terraform Plan
↓
Review Proposed Changes
↓
Terraform Apply
↓
AWS InfrastructureA team can update a reusable module, review the change, and test its effect before applying infrastructure modifications.
When using shared modules, teams should also manage versions carefully and test changes before rolling them out to important environments.
My Learning Journey
My recent learning has progressed from Terraform basics to state management, and now reusable modules.
I'm beginning to see that writing Terraform code is only one part of Infrastructure as Code.
Good infrastructure code should also be organized, reusable, secure, and maintainable.
The goal is not just to create AWS resources once. It's to create infrastructure that can be managed consistently as a project grows.
💬 Let's Discuss
If you were building your first Terraform project, which component would you turn into a reusable module first: a VPC, an EC2 instance, an S3 bucket, or a complete application environment? Why?
If you've already used modules, what helped you decide when to create a module instead of keeping the configuration in one file?
I'd love to hear practical experiences from people working with Terraform and AWS.
Series: My 90-Day AWS & DevOps Learning Journey (27 articles)
- …
- 25Terraform Modules: Reuse AWS Infrastructure Code This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article