Part 4: Run Tasks, Module Registries, and Automated Cost Governance in Terraform Cloud

AuthorEmmanuel Secretaria

Published Jan 12, 2026

A detailed guide to extending Terraform Cloud with run-task integrations, private module registries, and automated cost governance so every plan is validated, every module is trusted, and every dollar is visible.

Part 3 established promotion, drift detection, and policy-as-code. The next evolution is about integration and scale: enriching every run with external signals, standardizing how modules are consumed, and governing cost automatically. This part shows how to build a full-stack Terraform Cloud platform that combines:

Run Tasks (external checks and approvals on plans)
Module Registries (versioned, trusted building blocks)
Automated Cost Governance (continuous cost visibility and enforcement)

1) Run Tasks: Extending Terraform Cloud with External Signals

Run Tasks let you attach external systems to the Terraform run lifecycle. They run after plan but before apply, which makes them ideal for checks that require full plan context.

1.1 What Run Tasks are best for

Use Run Tasks for checks that are:

Too complex for policy-as-code (e.g., enterprise CMDB validation)
Dependent on external systems (security scanners, ticketing systems, change-control)
Cross-domain (Kubernetes admission checks, network policy validation)

Examples:

Verify a change ticket exists in ServiceNow
Run static analysis on the plan with a security scanner
Validate that module versions are from an approved registry

1.2 Where Run Tasks fit in the lifecycle

Terraform Cloud sequence:

Plan created (Terraform evaluates desired state)
Run Tasks execute (external validation)
Policy checks (Sentinel/OPA)
Apply (if approved)

Run Tasks happen before policy checks, so you can block risky plans early.

1.3 Creating a Run Task integration

A run task is an HTTP integration. Terraform Cloud calls your endpoint with plan metadata, then waits for a response.

High-level flow:

Terraform Cloud posts plan info to your task endpoint.
Your service performs checks and returns PASS/FAIL/WAIT.
If WAIT, the run pauses until your service updates the status.

Minimal API contract (conceptual):

{
  "data": {
    "type": "task-results",
    "attributes": {
      "status": "passed",
      "message": "Change ticket verified"
    }
  }
}

1.4 Common Run Task patterns

Pattern A: Change management approval

Validate ticket ID format in plan variables
Check ticket state in ServiceNow/Jira
Fail if not approved

Pattern B: Security scanning

Parse
```
terraform plan -json
```
output
Detect insecure resources (public ACLs, open security groups)
Fail or warn if high severity

Pattern C: Ops guardrails

Enforce tagging requirements
Verify a module registry origin
Check ownership and cost center tags

1.5 Implementation tips

Keep tasks fast (timeouts block applies)
Return clear messages (humans will read failures)
Include links (to ticket, scan report, or documentation)
Use WAIT for asynchronous processes (manual approvals)

2) Module Registries: Standardizing and Scaling Infrastructure

A module registry is the source of truth for reusable infrastructure. It reduces duplication, enforces standards, and improves delivery speed.

Terraform Cloud provides a private registry with versioning, documentation, and controlled access.

2.1 Why a private module registry matters

A registry gives you:

Trusted modules (security reviewed, compliant)
Version control (pin to known-good versions)
Discovery (teams can find and reuse modules)
Standardization (one canonical VPC module, one IAM module)

2.2 Module structure and versioning

A clean module repository should include:

modules/
  vpc/
    main.tf
    variables.tf
    outputs.tf
    README.md

Best practices:

Tag releases using Semantic Versioning (
```
v1.2.0
```
)
Maintain a changelog and upgrade notes
Require CI checks for linting and validation

2.3 Consuming registry modules

Example usage:

module "vpc" {
  source  = "app.terraform.io/my-org/vpc/aws"
  version = "1.2.0"

  cidr_block = "10.10.0.0/16"
  env        = "prod"
}

Pinning versions gives you immutable infrastructure building blocks.

2.4 Access control and approvals

Terraform Cloud allows registry access controls:

Only approved teams can publish modules
Read access can be wide to encourage reuse
Deprecations can be enforced to prevent old modules

2.5 Module validation pipeline

A strong module pipeline includes:

```
terraform fmt
```
and
```
validate
```
Unit tests (e.g.,
```
terratest
```
or
```
kitchen-terraform
```
)
Security scans (tfsec/checkov)
Documentation generation (e.g.,
```
terraform-docs
```
)

This ensures modules are high quality before promotion.

3) Automated Cost Governance: Continuous Cost Control

Infrastructure cost should be treated like security: visible, enforced, and automated. Terraform Cloud can integrate with cost tools to prevent unexpected spend.

3.1 Cost estimation in Terraform Cloud

Terraform Cloud can provide cost estimates on plans when configured with your cloud provider billing details.

Benefits:

Compare before vs after cost
Detect expensive changes early
Provide visibility for approvals

3.2 Cost guardrails as policy

Combine cost estimation with policies:

Soft fail if cost increases exceed a threshold
Hard fail for prod environments
Require approval for changes > $X/month

Example (conceptual Sentinel):

import "cost-estimation/v1" as costs

main = rule {
  costs.delta_monthly_cost <= 500
}

3.3 Cost governance via Run Tasks

If you use external tools (FinOps platforms, custom billing analytics), run tasks can enforce more complex rules:

Cost center tagging validation
Budget validation against org limits
Approval routing for high-impact changes

3.4 Practical cost controls

Cost governance becomes effective when you:

Require tags (
```
cost_center
```
,
```
owner
```
,
```
env
```
)
Set budgets per workspace (dev vs prod)
Send alerts when estimates exceed thresholds
Document thresholds in policy

3.5 Example: Combine cost + policy + approvals

A realistic workflow:

Plan generates cost estimate
Run task validates budget in external FinOps tool
Sentinel policy blocks if > $500/month
Manual approval required if > $200/month

This gives automation and human oversight where it matters.

4) Building the Run Task Service (Reference Architecture)

A run task service can be lightweight and still powerful. A typical architecture:

Terraform Cloud
   │
   ├── Plan output → Run Task Webhook
   │
Run Task Service
   ├── Pulls plan JSON
   ├── Runs validation
   ├── Sends PASS/FAIL/WAIT
   └── Logs to monitoring

Key components:

Webhook endpoint (accepts run task payloads)
Plan parser (reads plan JSON for validation)
Integrations (ticketing, scanners, cost tools)
Status reporter (updates Terraform Cloud API)

Implementation notes:

Store credentials in a secrets manager
Use structured logs and alerts
Include audit IDs in responses for traceability

5) Operating Model: Putting It All Together

By layering these features, you get a true platform workflow:

Run Tasks add external validation
Module Registries standardize building blocks
Cost Governance prevents budget surprises

This produces a Terraform system that is:

✅ secure by default
✅ reusable and consistent
✅ budget-aware and transparent
✅ easy to audit

Final Thoughts

Part 4 turns Terraform Cloud into an integrated delivery platform, not just a state backend. With run tasks, module registries,and cost governance in place, you can scale Terraform across teams while maintaining control, security, and budget discipline.

We may conclude at Part 4, but will explore the following topics in future sections:

Self-service provisioning portals
Automated policy remediation
Multi-cloud drift and compliance reporting

Credits

Special thanks to Hari Sekhon https://github.com/HariSekhon for creating and maintaining the repository, and to all contributors for their valuable contributions.