🏗️ Terraform Code: Who Should Write It? — Ending the Infra Team vs. Dev Team Debate

“Our team can just write it, can’t we?”

— This one sentence can cost an organization three months.

>

🎯 What this article covers

• The real reasons behind the Terraform code ownership debate
• Advantages and limitations when the infrastructure team is responsible
• Advantages and limitations when the development team (including DevOps) is responsible
• 3 practical models that work in the field
• Optimal structure proposals by organization size

---

📌 Introduction / Background

As cloud adoption accelerates, Terraform has, at some point, transformed from being the “exclusive property of the infrastructure team” to a “shared resource that everyone needs to touch.”

The problem starts here.

“I submitted a ticket to create an ECS cluster, and it took two weeks.”

“Terraform code written directly by the development team wiped out our production VPC.”

Both stories are real occurrences. The former is a case where the infrastructure team became a bottleneck, and the latter is a disaster that happened when anyone could touch it without clear ownership.

The issue of Terraform code ownership is not simply a matter of “who writes the code.” It’s a complex problem intertwined with three factors: organizational structure, accountability, and speed of change.

---

🔍 First, let’s distinguish the areas Terraform covers

Terraform code can be broadly divided into two layers.

Layer 1 — Platform Infrastructure (Foundation Layer)

• VPC, Subnets, Routing, TGW
• IAM Policies, Security Group base templates
• EKS/ECS Clusters themselves
• S3 Bucket Policies, KMS Keys
• DNS (Route 53 Hosted Zones)

This area has a low frequency of change, and incorrect modifications can lead to company-wide outages. Caution is required.

Layer 2 — Application Infrastructure (App Layer)

• ECS Services, Task Definitions
• Lambda Functions, API Gateway
• RDS Instances (app-specific)
• CloudFront Distribution settings
• Environment-specific variables, service-specific S3 buckets

This area has a high frequency of change and is directly linked to the deployment cycle. Speed is crucial.

Conflicts arise when teams try to manage these two layers in the same way.

---

⚙️ Model 1 — Centralized Ownership by the Infrastructure Team

This model involves the infrastructure team (or SRE team) owning and managing all Terraform code.

Advantages

• Easy standardization: Naming conventions, tagging policies, and module structures are consistent.
• Security control: All creations must go through a review process.
• Concentrated expertise: Proficiency in Terraform Provider version management, state file management, etc., accumulates.

Disadvantages

• Bottleneck: Development team requests pile up, causing the ticket queue to explode.
• Lack of context: The infrastructure team writes code without fully understanding the application’s requirements.
• Slow deployment speed: Conflicts with agile CI/CD pipelines.

Suitable Organizations

• Organizations with strong security and compliance requirements, such as finance, public sector, and healthcare.
• On-premise + cloud hybrid environments where infrastructure changes are infrequent.
• Early stages of cloud migration (when standardization is not yet established).

---

⚙️ Model 2 — Decentralized Ownership by the Development Team (“You Build It, You Run It”)

In this model, each development team (service team) directly defines the infrastructure needed for its service using Terraform. This model is adopted by large tech companies like Netflix and Spotify.

Advantages

• Deployment speed: PRs can be reflected immediately, no waiting for the infrastructure team.
• Context alignment: The team that best understands the application also decides its infrastructure.
• Clear accountability: “I am responsible for the infrastructure I build.”

Disadvantages

• Risk of fragmentation: Inconsistency arises as different teams create resources in different ways.
• Security incident risk: Developers lacking Terraform knowledge might create public S3 buckets.
• State file conflicts: State files can become corrupted when multiple teams touch overlapping resources.

Suitable Organizations

• Startups or tech companies with high DevOps maturity.
• Organizations with clearly separated teams by MSA (Microservices Architecture).
• Environments where developers are familiar with the cloud (AWS certification level or higher).

---

⚙️ Model 3 — Platform Team + Golden Path Model (Platform Engineering)

This is currently the most prominent model. The core concept is that the infrastructure team builds the “platform,” and the development team deploys “services” on it.

Key Idea: The infrastructure team creates and provides validated Terraform modules, and the development team consumes those modules.

# Verified module created by the infra team (example)
module "my_ecs_service" {
  source  = "git::https://github.com/company/terraform-modules//ecs-service?ref=v2.1.0"

  # Values to be filled by the development team
  service_name   = "payment-api"
  container_port = 8080
  desired_count  = 2
  cpu            = 512
  memory         = 1024

  # Security-related aspects are enforced within the module
  environment = "prod"
  vpc_id      = var.vpc_id
}

Development teams cannot change the source module and can only input allowed variables. Security group rules, IAM policies, and tagging standards are already baked into the module.

Advantages

• Achieves both speed and standardization simultaneously.
• Development teams don’t need to be Terraform experts.
• Infrastructure teams can focus solely on module quality.

Disadvantages

• High initial cost for module design.
• Developer dissatisfaction if modules are too restrictive.
• Module version management is required (tagging with ?ref=v2.1.0 format is essential).

Suitable Organizations

• Mid-sized to large enterprises, with 5 or more teams.
• Organizations operating a separate Platform Engineering or DevEx (Developer Experience) team.
• Organizations planning to build an Internal Developer Portal (IDP).

---

💡 Common Anti-Patterns in Reality

❌ Pattern 1 — “Let’s just all use it together”

Anyone can submit a PR to the main branch without clear ownership. There are no review standards, and state lock conflicts occur periodically. This pattern often becomes entrenched in small teams.

❌ Pattern 2 — The infrastructure team writes everything, but there are no reviews

Centralization exists, but there’s no code quality management. Terraform code that’s years old becomes “legacy IaC” that no one dares to touch.

❌ Pattern 3 — Development teams write code but don’t share it with the infrastructure team

Teams operate independently, claiming “we know our service infrastructure best,” only for security audits to uncover a large number of unauthorized resources.

---

✅ Summary / Conclusion

The answer to “Who should write Terraform code?” varies depending on the organization’s size and maturity.

Organizational Situation	Recommended Model
Early cloud adoption, teams of 5 or fewer	Centralized ownership by infra team
High DevOps maturity, MSA, small startups	Decentralized ownership by dev team
5+ teams, need for standardization	Platform team + Golden Path modules
Environments with strong compliance (finance/public sector)	Infra team ownership + mandatory review gates

The most important principle is this:

Platform infrastructure (VPC, IAM, clusters) by the infrastructure team, application layer (services, functions) by the development team

— However, modules and standards are provided by the infrastructure team.

Clear ownership also clarifies who responds in case of an outage. Code ownership is synonymous with operational responsibility.