Back to DevOps & CI/CD
terraform-module-library
TerraformIaCAWSAzureGCPCloud InfrastructureDevOpsModularity
Install this skill
npx skills add wshobson/agentsWorks across Claude Code, Cursor, Codex, Copilot & Antigravity
The terraform-module-library provides a structured repository of pre-configured, modular Terraform components for provisioning cloud infrastructure. It standardizes common deployment patterns across AWS, Azure, and GCP, ensuring that infrastructure remains consistent and repeatable. By following a uniform directory layout, the library simplifies the creation of VPCs, database clusters, and Kubernetes environments. Each module includes standard files such as inputs, outputs, provider version constraints, and integrated Terratest suites for verification. The repository acts as a blueprint for organizations moving away from monolithic Terraform files toward reusable, versioned component blocks. Developers can integrate these modules directly into their projects, reducing configuration errors and promoting stable environment provisioning through well-documented, testable infrastructure code patterns that support multi-cloud deployment strategies.
When to Use This Skill
- β’Establishing a standardized internal library of approved infrastructure components
- β’Transitioning from flat Terraform scripts to modular, component-based architectures
- β’Ensuring consistent cloud environment configuration across different teams
- β’Implementing automated integration tests for infrastructure changes
How to Invoke This Skill
Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:
- βInitialize a new AWS VPC using the library pattern
- βCreate a modular Terraform structure for GCP
- βAdd a new Terratest file for my module
- βStandardize my RDS module configuration
- βGenerate a new module following the repository standard
Pro Tips
- π‘Always include `examples/complete` directories within your modules to demonstrate full, working deployments, making it easier for consumers to adopt and understand.
- π‘Integrate `Terratest` for comprehensive module testing, ensuring your infrastructure components are reliable and resilient before deployment.
- π‘Utilize `terraform-docs` to automatically generate and maintain README files for your modules, keeping documentation synchronized with your code changes.
What this skill does
- β’Standardized directory structure for multi-provider Terraform modules
- β’Pre-written code blocks for common resources like VPCs, EKS, AKS, and GKE
- β’Automated unit testing capabilities using Terratest
- β’Built-in input validation for CIDR blocks and configuration variables
- β’Consistent tagging and resource output mechanisms
When not to use it
- βSmall projects requiring only a single, simple Terraform file
- βScenarios where specific cloud provider features prevent modularization
- βPrototypes that need to be deployed instantly without long-term maintenance
Example workflow
- Clone the Terraform module repository
- Select the required provider directory, such as aws/vpc
- Copy the template structure into your infrastructure project
- Customize the variables.tf and main.tf to your specific network requirements
- Run terraform plan to verify the resources
- Execute the associated Terratest suite to confirm deployment integrity
Prerequisites
- βTerraform installed locally
- βGo and Terratest installed for validation
- βConfigured cloud provider credentials
- βBasic knowledge of HCL
Pitfalls & limitations
- !Adding too many input variables, which complicates module usage
- !Failing to pin provider versions, leading to breaking changes during updates
- !Creating overly rigid modules that lack necessary flexibility for edge cases
FAQ
Why include a Terratest file for every module?
Testing ensures that your infrastructure code actually creates the intended resources without hidden configuration errors.
Should I store all modules in one repository?
Centralizing modules makes it easier to version, share, and maintain consistent infrastructure standards across your organization.
How does this handle resource tags?
The modules use a standard tagging variable, allowing you to pass dynamic maps to ensure all resources comply with organizational naming policies.
How it compares
Unlike manual scripting which is prone to copy-paste errors, this approach provides version-controlled, validated templates that enforce project-wide consistency.
π Full skill instructions β original source: wshobson/agents
# Terraform Module Library
Production-ready Terraform module patterns for AWS, Azure, and GCP infrastructure.
## Purpose
Create reusable, well-tested Terraform modules for common cloud infrastructure patterns across multiple cloud providers.
## When to Use
- Build reusable infrastructure components
- Standardize cloud resource provisioning
- Implement infrastructure as code best practices
- Create multi-cloud compatible modules
- Establish organizational Terraform standards
## Module Structure
## Standard Module Pattern
## AWS VPC Module Example
**main.tf:**
**variables.tf:**
**outputs.tf:**
## Best Practices
1. **Use semantic versioning** for modules
2. **Document all variables** with descriptions
3. **Provide examples** in examples/ directory
4. **Use validation blocks** for input validation
5. **Output important attributes** for module composition
6. **Pin provider versions** in versions.tf
7. **Use locals** for computed values
8. **Implement conditional resources** with count/for_each
9. **Test modules** with Terratest
10. **Tag all resources** consistently
## Module Composition
## Reference Files
-
-
-
-
-
## Testing
## Related Skills
-
-
Production-ready Terraform module patterns for AWS, Azure, and GCP infrastructure.
## Purpose
Create reusable, well-tested Terraform modules for common cloud infrastructure patterns across multiple cloud providers.
## When to Use
- Build reusable infrastructure components
- Standardize cloud resource provisioning
- Implement infrastructure as code best practices
- Create multi-cloud compatible modules
- Establish organizational Terraform standards
## Module Structure
terraform-modules/
βββ aws/
β βββ vpc/
β βββ eks/
β βββ rds/
β βββ s3/
βββ azure/
β βββ vnet/
β βββ aks/
β βββ storage/
βββ gcp/
βββ vpc/
βββ gke/
βββ cloud-sql/## Standard Module Pattern
module-name/
βββ main.tf # Main resources
βββ variables.tf # Input variables
βββ outputs.tf # Output values
βββ versions.tf # Provider versions
βββ README.md # Documentation
βββ examples/ # Usage examples
β βββ complete/
β βββ main.tf
β βββ variables.tf
βββ tests/ # Terratest files
βββ module_test.go## AWS VPC Module Example
**main.tf:**
resource "aws_vpc" "main" {
cidr_block = var.cidr_block
enable_dns_hostnames = var.enable_dns_hostnames
enable_dns_support = var.enable_dns_support
tags = merge(
{
Name = var.name
},
var.tags
)
}
resource "aws_subnet" "private" {
count = length(var.private_subnet_cidrs)
vpc_id = aws_vpc.main.id
cidr_block = var.private_subnet_cidrs[count.index]
availability_zone = var.availability_zones[count.index]
tags = merge(
{
Name = "${var.name}-private-${count.index + 1}"
Tier = "private"
},
var.tags
)
}
resource "aws_internet_gateway" "main" {
count = var.create_internet_gateway ? 1 : 0
vpc_id = aws_vpc.main.id
tags = merge(
{
Name = "${var.name}-igw"
},
var.tags
)
}**variables.tf:**
variable "name" {
description = "Name of the VPC"
type = string
}
variable "cidr_block" {
description = "CIDR block for VPC"
type = string
validation {
condition = can(regex("^([0-9]{1,3}\\.){3}[0-9]{1,3}/[0-9]{1,2}$", var.cidr_block))
error_message = "CIDR block must be valid IPv4 CIDR notation."
}
}
variable "availability_zones" {
description = "List of availability zones"
type = list(string)
}
variable "private_subnet_cidrs" {
description = "CIDR blocks for private subnets"
type = list(string)
default = []
}
variable "enable_dns_hostnames" {
description = "Enable DNS hostnames in VPC"
type = bool
default = true
}
variable "tags" {
description = "Additional tags"
type = map(string)
default = {}
}**outputs.tf:**
output "vpc_id" {
description = "ID of the VPC"
value = aws_vpc.main.id
}
output "private_subnet_ids" {
description = "IDs of private subnets"
value = aws_subnet.private[*].id
}
output "vpc_cidr_block" {
description = "CIDR block of VPC"
value = aws_vpc.main.cidr_block
}## Best Practices
1. **Use semantic versioning** for modules
2. **Document all variables** with descriptions
3. **Provide examples** in examples/ directory
4. **Use validation blocks** for input validation
5. **Output important attributes** for module composition
6. **Pin provider versions** in versions.tf
7. **Use locals** for computed values
8. **Implement conditional resources** with count/for_each
9. **Test modules** with Terratest
10. **Tag all resources** consistently
## Module Composition
module "vpc" {
source = "../../modules/aws/vpc"
name = "production"
cidr_block = "10.0.0.0/16"
availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]
private_subnet_cidrs = [
"10.0.1.0/24",
"10.0.2.0/24",
"10.0.3.0/24"
]
tags = {
Environment = "production"
ManagedBy = "terraform"
}
}
module "rds" {
source = "../../modules/aws/rds"
identifier = "production-db"
engine = "postgres"
engine_version = "15.3"
instance_class = "db.t3.large"
vpc_id = module.vpc.vpc_id
subnet_ids = module.vpc.private_subnet_ids
tags = {
Environment = "production"
}
}## Reference Files
-
assets/vpc-module/ - Complete VPC module example-
assets/rds-module/ - RDS module example-
references/aws-modules.md - AWS module patterns-
references/azure-modules.md - Azure module patterns-
references/gcp-modules.md - GCP module patterns## Testing
// tests/vpc_test.go
package test
import (
"testing"
"github.com/gruntwork-io/terratest/modules/terraform"
"github.com/stretchr/testify/assert"
)
func TestVPCModule(t *testing.T) {
terraformOptions := &terraform.Options{
TerraformDir: "../examples/complete",
}
defer terraform.Destroy(t, terraformOptions)
terraform.InitAndApply(t, terraformOptions)
vpcID := terraform.Output(t, terraformOptions, "vpc_id")
assert.NotEmpty(t, vpcID)
}## Related Skills
-
multi-cloud-architecture - For architectural decisions-
cost-optimization - For cost-effective designsBy W. Shobson
How to Use This Skill Unit
Option A: Project-Specific (Recommended)
- Click "Download" above
- In your project, create the directory:
.agent/skills/terraform-module-library/ - Save the file as
SKILL.md - The agent will automatically discover the skill based on its description.
Option B: Global Installation (All Agents)
Save the file to these locations to make it available across all projects:
- Claude Code:
~/.claude/skills/wshobson/agents/terraform-module-library/SKILL.md - Cursor:
~/.cursor/skills/wshobson/agents/terraform-module-library/SKILL.md - Antigravity:
~/.gemini/antigravity/skills/wshobson/agents/terraform-module-library/SKILL.md
π Install with CLI:npx skills add wshobson/agents
Recommended Rules
View more rules βInfrastructure as Code (Terraform, Pulumi)
IaCTerraformPulumi
You are an expert in Infrastructure as Code (IaC) using Terraform and Pulumi. Key Principles: - Infrastructure as versioned code - Idempotency (repea...
AWS Cloud Architecture Expert
AWSCloudArchitecture
You are an expert in AWS Cloud Architecture and services. Key Principles: - Follow AWS Well-Architected Framework - Design for high availability and ...
Azure Cloud Services Expert
AzureCloudMicrosoft
You are an expert in Microsoft Azure cloud services and architecture. Key Principles: - Follow Cloud Adoption Framework - Design for reliability and ...
Recommended Workflows
View more workflows βCheck SSL Certificates
SecurityDevOpsSSL
--- description: Verify SSL certificate validity and expiration --- 1. **Check Expiry**: - Use openssl to check a domain. Replace `google.com` wit...
Implement Feature Flags
Feature FlagsDeploymentA/B Testing
--- description: Safely release features with toggles for gradual rollouts --- 1. **Simple Approach: Environment Variables**: - Use env vars for b...
Implement Blue-Green Deployment
DeploymentDevOpsZero-Downtime
--- description: Zero-downtime deploys --- 1. **Setup Two Environments**: - Blue: Current (v1.0) - Green: New (v1.1) 2. **Route Traffic Gradua...
