This repository demonstrates the scaling patterns mentioned in Armand's presentation about scaling Terraform workflows from individual use to hundreds or thousands of users.
Instead of one monolithic Terraform configuration, we break infrastructure into smaller, manageable workspaces:
01-core-network/ # Foundation network (VPC, subnets, security groups)
02-shared-services/ # Shared infrastructure (databases, logging, monitoring)
03-module-registry/ # Reusable modules for common patterns
04-app-teams/ # Application-specific infrastructure
05-policy-as-code/ # Automated governance and compliance
Benefits:
- Smaller blast radius for changes
- Team-based ownership and access control
- Faster plan/apply cycles
- Parallel development
Producers (DevOps/Platform teams) create standardized modules:
java-app/- Complete Java application deployment- Future modules:
nodejs-app/,python-app/,database/,redis-cluster/
Consumers (Application teams) use simple inputs:
module "my_app" {
source = "../../03-module-registry/java-app"
# Simple inputs - no infrastructure expertise needed
app_name = "customer-service"
environment = "dev"
jar_file = "customer-service-1.2.3.jar"
instance_count = 3
}
# Get back what they need
output "app_url" {
value = module.my_app.application_url
}What's Hidden from Consumers:
- Auto Scaling Groups, Load Balancers, Security Groups
- CloudWatch setup, IAM roles, VPC configuration
- Health checks, auto scaling policies
- Best practices implementation
Instead of manual review processes, policies are automated:
# sentinel.hcl
policy "no-public-s3-buckets" {
enforcement_level = "hard-mandatory" # Cannot be overridden
}
policy "enforce-resource-tagging" {
enforcement_level = "soft-mandatory" # Can be overridden with permissions
}Enforcement Levels:
- hard-mandatory: Critical security (no public S3 buckets)
- soft-mandatory: Best practices with exceptions (tagging, instance types)
- advisory: Recommendations only (cost optimization)
Same code, different configurations:
environments/
├── dev/terraform.tfvars # Small instances, relaxed policies
├── staging/terraform.tfvars # Medium instances, moderate policies
└── prod/terraform.tfvars # Large instances, strict policies
Workspaces share data via:
- Remote state:
data.terraform_remote_state.network - SSM Parameters: Central parameter store for service discovery
- Tags: Resource metadata for discovery
graph TB
A[Core Network<br/>VPC, Subnets, Security Groups] --> B[Shared Services<br/>RDS, Redis, Logging, Monitoring]
B --> C[App Team 1<br/>Customer Service]
B --> D[App Team 2<br/>Payment Service]
B --> E[App Team 3<br/>Notification Service]
F[Module Registry<br/>Java App, Node App, Database] --> C
F --> D
F --> E
G[Policy as Code<br/>Sentinel Policies] --> A
G --> B
G --> C
G --> D
G --> E
scaling-terraform-example/
├── 01-core-network/ # Foundation infrastructure
│ ├── main.tf # VPC, subnets, security groups
│ ├── variables.tf # Network configuration
│ ├── outputs.tf # Shared network data
│ └── terraform.tfvars.example # Environment-specific values
│
├── 02-shared-services/ # Platform services
│ ├── main.tf # RDS, Redis, logging, monitoring
│ ├── variables.tf # Service configuration
│ └── outputs.tf # Service endpoints
│
├── 03-module-registry/ # Reusable modules
│ └── java-app/ # Standardized Java app deployment
│ ├── main.tf # ALB, ASG, security groups, etc.
│ ├── variables.tf # Simple consumer interface
│ ├── outputs.tf # DNS name, monitoring URLs
│ ├── user_data.sh # Instance configuration
│ └── README.md # Usage documentation
│
├── 04-app-teams/ # Application workspaces
│ └── customer-service/ # Example application
│ ├── main.tf # Uses java-app module
│ ├── variables.tf # App-specific configuration
│ └── terraform.tfvars.example # Environment values
│
└── 05-policy-as-code/ # Automated governance
├── no-public-s3-buckets.sentinel # Security policy
├── enforce-resource-tagging.sentinel # Compliance policy
├── restrict-ec2-instance-types.sentinel # Cost control policy
└── sentinel.hcl # Policy configuration
# Deploy core network
cd 01-core-network/
cp terraform.tfvars.example terraform.tfvars
# Edit terraform.tfvars with your values
terraform init
terraform plan
terraform apply
# Deploy shared services
cd ../02-shared-services/
# Configure variables
terraform init
terraform plan
terraform apply# Application team deploys their service
cd 04-app-teams/customer-service/
cp terraform.tfvars.example terraform.tfvars
# Edit with app-specific values
terraform init
terraform plan
terraform apply
# Get application URL
terraform output app_url- Standardization: Common patterns implemented once
- Security: Best practices baked into modules
- Governance: Automated policy enforcement
- Efficiency: Reusable components across teams
- Simplicity: Focus on application, not infrastructure
- Self-Service: Deploy without waiting for approvals
- Speed: Minutes instead of days/weeks
- Reliability: Battle-tested patterns
- Scalability: Hundreds of teams can operate independently
- Compliance: Automated policy enforcement
- Cost Control: Standardized, right-sized resources
- Risk Reduction: Smaller blast radius, tested patterns
- Private subnets for applications
- Security groups with least privilege
- No public S3 buckets (enforced by policy)
- Encryption at rest and in transit
- IAM roles instead of access keys
- Resource tagging enforced for cost allocation
- Instance types restricted by environment
- Public access automatically blocked
- Compliance checked before deployment
- Network team: Can modify core network only
- Platform team: Manages shared services and modules
- App teams: Can only deploy applications using approved modules
- Security team: Defines and manages policies
| Environment | Instance Types | Policies | Access |
|---|---|---|---|
| Dev | t3.micro, t3.small | Relaxed | All developers |
| Staging | t3.small → m5.large | Moderate | Team leads |
| Production | m5.large+ | Strict | Ops team only |
# Traditional workflow
terraform plan # One person reviews
terraform apply # One person approves# Modern workflow
git push # Triggers automated pipeline
# → Policy checks (automated)
# → Security scan (automated)
# → Plan review (automated)
# → Apply (automated if approved)Test your Sentinel policies:
# Test no public S3 buckets policy
sentinel test no-public-s3-buckets.sentinel
# Test resource tagging policy
sentinel test enforce-resource-tagging.sentinel
# Test instance type restrictions
sentinel test restrict-ec2-instance-types.sentinel- Terraform Module Registry
- Terraform Cloud Workspaces
- Sentinel Policy Language
- Terraform Best Practices
- Decompose large configurations into smaller workspaces
- Standardize common patterns into reusable modules
- Automate governance with policy as code
- Enable self-service for application teams
- Maintain security and compliance at scale
This approach transforms Terraform from a tool for infrastructure experts into a platform that enables any team to safely deploy infrastructure following organizational best practices.