Terraform at Team Scale: Governance, Cost & Multi-Cloud Patterns

The series closer. Assumes the full stack from Parts 1-8 — state, modules, structure, providers, drift handling, testing, and CI/CD — and adds the organizational and financial layer that sits above all of it once Terraform is running dozens of services across multiple accounts, teams, and (in this chapter) more than one cloud.

Table of Contents#

1. Why Governance Becomes Unavoidable at Scale
2. Sentinel — Policy as Code, HCP-Native
3. OPA and Conftest — Portable Policy as Code
4. Sentinel vs. OPA/Conftest — the Real Decision
5. Soft-Mandatory vs. Hard-Mandatory Policies
6. The 2026 Terraform Pricing Landscape, Applied
7. The Middle Ground: Third-Party TACOS Platforms
8. Cost Governance Beyond a Single PR's Infracost Diff
9. Tagging Strategy as the Foundation of Cost Attribution
10. A Module Registry as a Governance Surface
11. Provider Aliasing for Genuine Multi-Cloud Provisioning
12. When to Alias vs. When to Fully Separate
13. A Real Multi-Cloud Pattern: Active-Passive Disaster Recovery
14. Avoiding a False Abstraction Across Clouds
15. Choosing Terraform vs. OpenTofu, Revisited With Full Context
16. Audit Trails — Answering "Who Changed What, and Why"
17. Onboarding a New Team Onto the Platform
18. Building a Platform Team's Governance Charter
19. Measuring Whether Governance Is Actually Working
20. Cross-Team Communication — the Human Layer Above All of This
21. Worked Scenario: a Sentinel Policy That Blocked a Legitimate Emergency Change
22. Worked Scenario: the Free-Tier Migration, Revisited With a Real Budget
23. Worked Scenario: Standing Up checkout-service's Full DR Posture
24. Worked Scenario: the Governance Charter's First Annual Review
25. Part 9 Governance Cheat Sheet
26. Common Mistakes and Interview Traps
27. Worked Practice Problems
28. Summary and What's Next

Why Governance Becomes Unavoidable at Scale#

Everything through Part 8 makes one team's Terraform usage safe and fast. At the scale of dozens of teams, hundreds of services, and real budget accountability, a new class of problem appears that no single team's pipeline discipline solves on its own: how does an organization enforce a rule ("every S3 bucket must be encrypted," "no resource may cost more than $500/month without a named approver") consistently across every team's independent pipeline, without a human manually reviewing every single plan for policy compliance forever?

This chapter's caption: nothing about the individual-team practices from Parts 1-8 stops working at scale — the problem is purely one of consistency across many independent pipelines, which is exactly what policy as code exists to solve.

Sentinel — Policy as Code, HCP-Native#

HashiCorp Sentinel evaluates policy against a Terraform plan/state/config, deeply integrated with HCP Terraform/Enterprise's run pipeline — the native choice for an organization already committed to HCP Terraform.

import "tfplan/v2" as tfplan

mandatory_tags = ["Environment", "Service", "ManagedBy"]

ec2_instances = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_instance" and rc.change.actions contains "create"
}

mandatory_instance_tags = rule {
  all ec2_instances as _, instance {
    all mandatory_tags as tag {
      instance.change.after.tags contains tag
    }
  }
}

main = rule {
  mandatory_instance_tags
}

This policy directly enforces Part 4's naming/tagging convention — every new aws_instance in a plan must carry Environment, Service, and ManagedBy tags, or the run is blocked before it ever reaches apply. Sentinel's tfplan/v2 import gives policy code structured access to exactly the same plan data a human reviewer would read, but evaluated automatically and consistently on every single run.

OPA and Conftest — Portable Policy as Code#

Open Policy Agent (OPA), typically invoked via Conftest as a CLI wrapper, evaluates policy written in Rego against a Terraform plan's JSON output — vendor-neutral, works identically with Terraform or OpenTofu, and runs as an ordinary CI step (Part 8's pipeline) rather than requiring HCP Terraform at all.

package terraform.policies.no_open_ingress

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_security_group"
  rc.change.after.ingress[_].cidr_blocks[_] == "0.0.0.0/0"
  msg := sprintf("%v allows ingress from 0.0.0.0/0 — see Part 6's SG-widening incident", [rc.address])
}

terraform show -json tfplan > plan.json
conftest test plan.json --policy policies/

This is precisely Part 2's terraform show -json pattern, reused one more time — every programmatic tool this series has introduced (Infracost, custom CI notifications, and now OPA) consumes the same stable, documented JSON contract rather than parsing CLI text output.

Sentinel vs. OPA/Conftest — the Real Decision#

Soft-Mandatory vs. Hard-Mandatory Policies#

Not every policy should block a run outright — Sentinel and most OPA/Conftest CI wiring both support a graduated enforcement level, and picking the right level per policy is itself a governance decision.

The 2026 Terraform Pricing Landscape, Applied#

Part 1 introduced the licensing/pricing shift in the abstract; at governance scale, this is a real, recurring line-item decision a platform team owns. HCP Terraform's legacy Free plan reached end of life March 31, 2026; the replacement free tier caps at 500 managed resources, and paid tiers bill per resource under management — Essentials $0.10, Standard $0.47, Premium $0.99 per resource/month, published February 2026.

For the platform team's own footprint — checkout-service, catalog-service, inventory-service, each across dev/staging/prod, plus shared network/platform infrastructure — a rough count in the low thousands of resources puts a Standard-tier HCP Terraform bill in real four-figure monthly territory, which is exactly the kind of number that turns "self-hosted S3 backend + Atlantis" (Parts 2 and 8) from an academic alternative into a genuine budget conversation with a CFO.

The Middle Ground: Third-Party TACOS Platforms#

Between "fully self-hosted S3 backend plus Atlantis" (Parts 2 and 8) and "HCP Terraform" sits a third real option worth naming explicitly: commercial "Terraform Automation and Collaboration Software" (TACOS) platforms — Spacelift, env0, and Scalr among them — offering a managed run pipeline, policy engine, and cost visibility, similar in spirit to HCP Terraform but independently priced and, notably, first-class OpenTofu support.

For an organization that's already decided on OpenTofu (per Part 1's licensing discussion) but still wants a managed run pipeline rather than operating Atlantis themselves, a TACOS platform is often the actual answer — it isn't a compromise between the two options this chapter has emphasized so far, it's a genuine third point on the same tradeoff space, worth pricing out alongside HCP Terraform and the fully self-hosted option before committing.

Cost Governance Beyond a Single PR's Infracost Diff#

Part 7's Infracost integration shows the cost impact of one PR; org-wide cost governance needs the aggregate view across every service, every environment, continuously — a different scope than any single plan.

infracost breakdown --path . --format json --out-file infracost-report.json
# Aggregated across every environment/service in a scheduled job,
# feeding a dashboard or a monthly cost-review meeting

Tagging Strategy as the Foundation of Cost Attribution#

Part 4's common_tags local, applied consistently across every resource, is what makes any of this cost governance actually queryable — without consistent Environment/Service/Team tags, a cloud bill is an undifferentiated total with no way to attribute spend back to the team or service responsible for it.

# The SAME common_tags local from Part 4, now load-bearing for cost governance too
locals {
  common_tags = {
    Environment = var.environment
    Service     = var.service
    Team        = var.owning_team
    ManagedBy   = "terraform"
    CostCenter  = var.cost_center
  }
}

A Sentinel or OPA policy enforcing mandatory_instance_tags (this chapter's own example) is, in practice, often written specifically to guarantee this cost-attribution data exists on every resource — the security- sounding "policy as code" framing and the accounting-sounding "cost attribution" framing are frequently the exact same enforced tag set, serving two audiences from one mechanism.

A Module Registry as a Governance Surface#

Part 3 established modules as a reuse mechanism; at governance scale, a private module registry becomes the primary enforcement surface too — a well-designed "golden path" module bakes tagging, encryption, and naming compliance in by default, making the compliant choice the easy choice.

module "checkout_database" {
  source  = "app.terraform.io/meridian-platform/rds/aws"
  version = "~> 3.0"

  service        = "checkout"
  environment    = "prod"
  # storage_encrypted, mandatory tags, and backup retention are all
  # baked into the module's own defaults — a caller has to actively
  # override them to be non-compliant, not actively configure them
  # correctly from scratch every time.
}

Provider Aliasing for Genuine Multi-Cloud Provisioning#

Part 4 established cloud-level directory separation as the default; this section covers the narrower case where a single configuration genuinely needs to provision into more than one cloud at once — DNS failover records, a cross-cloud VPN tunnel, or (this chapter's own closing scenario) disaster-recovery replication.

provider "aws" {
  region = "us-east-1"
}

provider "google" {
  project = "meridian-dr-project"
  region  = "us-central1"
}

resource "aws_db_instance" "checkout_primary" {
  # ...
}

resource "google_sql_database_instance" "checkout_replica" {
  # References the AWS resource's endpoint directly —
  # this ONE configuration genuinely spans two clouds
  settings {
    ip_configuration {
      authorized_networks {
        value = aws_db_instance.checkout_primary.address
      }
    }
  }
}

This is the deliberate exception to Part 4's "split at the cloud level first" default — used specifically when the relationship between two clouds' resources (not just their independent existence) is what the configuration needs to express, and Terraform's own dependency graph (Part 1) is the actual mechanism making that cross-cloud reference safe and ordered.

When to Alias vs. When to Fully Separate#

A Real Multi-Cloud Pattern: Active-Passive Disaster Recovery#

Building on Part 4's GCP disaster-recovery scenario, the full pattern: AWS remains the active, primary environment for all three services; GCP holds a continuously-replicated standby, promoted only during an actual declared disaster.

This chapter's caption: the DNS failover record — not a shared Terraform state, not a shared provider block — is the actual cutover mechanism; both clouds' infrastructure stays independently managed (Part 4's default), with only the narrow "bridge" pieces (replication configuration, the failover record itself) genuinely spanning both providers.

Avoiding a False Abstraction Across Clouds#

Part 4's DR scenario already established this — worth restating here as the chapter's own explicit governance guidance: never build one shared module pretending AWS RDS and GCP Cloud SQL (or any two providers' conceptually-similar-but-structurally-different services) are interchangeable behind one interface.

# DON'T: a false abstraction hiding real provider differences
module "managed_database" {
  source = "./modules/cloud-agnostic-database"
  cloud  = "aws"  # or "gcp" — the module internally branches on this,
                   # accumulating conditionals for every real difference
}

# DO: genuinely separate, provider-native modules, each simple on its own
module "checkout_primary_db" {
  source = "./modules/aws-rds"
  # ...
}

module "checkout_dr_db" {
  source = "./modules/gcp-cloudsql"
  # ...
}

This is Part 3's "god module" anti-pattern, recurring one level up — a cross-cloud abstraction accumulates the same kind of ever-growing conditional complexity a single environment-spanning module does, for the same underlying reason: it's trying to hide genuine structural differences behind one interface instead of letting each concern (each cloud's own module) stay simple and provider-native.

Choosing Terraform vs. OpenTofu, Revisited With Full Context#

Part 1 opened with this decision in the abstract; by this point in the series, every factor that actually matters has a name and a chapter behind it:

Audit Trails — Answering "Who Changed What, and Why"#

Every practice across this series contributes to one governance question auditors and incident responders ask constantly: who changed this resource, when, why, and was it reviewed — answering it well is a natural consequence of the discipline this series built, not a separate system to bolt on.

Because every credential in this series' pipeline is short-lived and OIDC-derived (Part 8), and every apply consumes a specific, artifact-pinned plan (Part 8), a complete audit trail already exists as a natural byproduct — nobody had to build a separate change-tracking system, because Git history, CI logs, and state versioning together already answer every one of these questions.

Onboarding a New Team Onto the Platform#

Closing the practical loop on this chapter's governance charter — the actual checklist a new team (say, a future payments-service) works through to start using everything this series established, rather than reinventing any of it independently:

• Clone the infrastructure-live repository structure (Part 4) for the new service, under the correct domain-parent directory
• Consume the golden-path modules from the shared registry (this chapter) rather than writing raw resources for anything a golden-path module already covers
• Confirm the new service's OIDC trust policy is scoped correctly (Part 8) — a distinct role per environment, never a shared, broadly-scoped one
• Confirm state is split along real ownership/lifecycle boundaries (Part 2) from day one, rather than starting monolithic and needing a disruptive split later once the service has grown
• Wire the standard CI pipeline (Part 8) — validate, plan, environment-gated apply — using the shared reusable workflow rather than a bespoke one
• Confirm the mandatory tag set (this chapter) is applied via common_tags, not reinvented per service
• Add the new service to the scheduled drift-check rotation (Part 6) at the appropriate severity tier (Part 6's per-environment cadence table), and confirm alert routing matches an on-call rotation that actually exists for this team
• Review the governance charter's override/escalation path with the new team before their first incident, not during it
• Confirm the new team knows where the companion questions.md self-check and this series' worked scenarios live, as a reference for the incident classes this checklist exists to prevent

Building a Platform Team's Governance Charter#

Pulling this entire chapter into one operational artifact — the kind of short, living document a platform team actually maintains and points every consuming team at:

• Which policies are hard-mandatory, and why (a short list, deliberately kept short per this chapter's soft/hard-mandatory guidance)
• Which policies are soft-mandatory, and who is authorized to override, with what audit trail
• The mandatory tag set every resource must carry, and which module(s) bake it in by default
• The current HCP Terraform tier (or self-hosted equivalent) and the resource-count threshold that triggers a re-evaluation
• Which module registry is authoritative for "golden path" infrastructure, and the review process for adding a new golden-path module
• The escalation path for a policy blocking a genuine, time-sensitive change (this chapter's break-glass equivalent, mirroring Part 6's console-access break-glass process)

Measuring Whether Governance Is Actually Working#

A governance charter that nobody measures against tends to drift out of sync with reality the same way unreviewed infrastructure drifts (Part 6) — a small set of concrete, trackable metrics is what keeps it a living practice rather than a document nobody revisits.

A rising override rate for one specific policy (as in the illustrative chart above) is a genuine signal worth investigating, not just tolerating — it can mean the policy itself is miscalibrated (too strict for a legitimate, recurring case) or that a real process gap is being routinely worked around rather than fixed. Either conclusion is more useful than letting the override count climb unexamined.

None of these metrics need a dedicated dashboard product to start — a scheduled query against CI logs and the policy engine's own override log, summarized into a short quarterly document, is enough to make this review a real, recurring habit rather than an aspiration nobody gets back to. Start small and keep it going — a metric reviewed inconsistently is barely more useful than one nobody tracks at all.

Cross-Team Communication — the Human Layer Above All of This#

Every mechanism this series has built — modules, policies, pipelines, drift checks — still depends on actual communication between the platform team and the teams consuming what it builds; no amount of tooling substitutes for a genuine feedback channel.

• A visible, low-friction way for a consuming team to propose a change to a golden-path module (a PR against the module registry itself, reviewed by the platform team, not a request routed through a ticket queue)
• A regular (not just incident-triggered) forum where consuming teams can flag friction — a policy that blocks more than it should, a module missing a genuinely common configuration option
• A clear, documented distinction between "the platform team's opinion" and "an enforced policy" — not every recommendation in this series needs to become a hard-mandatory Sentinel/OPA rule; some are genuinely best left as strong defaults a team can deliberately override with justification

Worked Scenario: a Sentinel Policy That Blocked a Legitimate Emergency Change#

A hard-mandatory Sentinel policy required every aws_instance to be launched only within a specific, pre-approved set of instance types, with zero override path — reasonable as written, until a genuine capacity emergency during a traffic spike required an urgent, temporary instance-type change outside that approved list to keep checkout-service responsive. The policy blocked the change outright, with no mechanism for an authorized human to proceed anyway, even under a declared incident.

The team's response mirrored Part 6's break-glass fix directly: the policy was reclassified from hard-mandatory to soft-mandatory, with an explicit, audited override path (a specific on-call role, logged, requiring a linked incident ticket) — preserving the policy's normal-operations enforcement while adding exactly the escape valve a genuine emergency needs, the same lesson this series has now taught at the IAM layer (Part 6), the workflow layer (Part 8's OIDC scoping), and now the policy-engine layer.

Worked Scenario: the Free-Tier Migration, Revisited With a Real Budget#

Extending Part 1's opening worked scenario (the team that hadn't been tracking managed-resource count and landed just over the new 500-resource free-tier cap) with the full governance picture: post-migration, the platform team added managed-resource count as a standing line item in their governance charter's quarterly review, alongside the actual Standard-tier bill this chapter's pricing section modeled. The concrete follow-up decision — informed by real numbers, not a hypothetical — was migrating the lowest-stakes dev environments to a self-hosted S3 backend (Part 2) while keeping staging and prod on HCP Terraform for its managed run pipeline and Sentinel integration, a deliberate, split decision rather than an all-or-nothing migration.

Worked Scenario: Standing Up checkout-service's Full DR Posture#

Closing the series' throughline: checkout-service's complete disaster-recovery posture, assembled entirely from patterns this series already built — a network module (Part 3) and its own state (Part 2) in both AWS and GCP, provisioned independently (Part 4's directory-per-cloud default); a narrow, dedicated "DR bridge" configuration (this chapter) owning only the cross-cloud replication settings and the DNS failover record; Sentinel/OPA policy (this chapter) enforcing that both the primary and standby databases carry identical mandatory tags; and the entire DR bridge configuration running through the exact same Part 8 CI/CD pipeline — plan posted to a PR, reviewed, gated behind an environment approval — as every other piece of infrastructure in this series, with no special-cased, less-reviewed path for "the DR stuff."

Worked Scenario: the Governance Charter's First Annual Review#

One year after adopting the governance charter this chapter describes, the platform team ran their first full annual review — pulling together every metric from this chapter's measurement section across all three throughline services. The findings were mixed in exactly the way a healthy, honestly-measured governance practice should be: the mandatory-tagging policy's override rate had dropped to near zero (the golden-path modules had made compliance the default, exactly as this chapter's "primary enforcement layer" guidance predicted), while one specific Checkov check — a strict encryption-in-transit rule originally written for prod — was showing a rising override rate specifically in dev, where the team had never actually needed that strength of guarantee for genuinely disposable, non-production data.

Rather than treating the rising override count as a discipline problem to fix with more enforcement, the team read it as exactly the signal this chapter's measurement section describes — a policy miscalibrated for one environment, not a team ignoring governance. The fix was environment-scoping the check itself (hard-mandatory in staging/prod, advisory-only in dev), which immediately eliminated the override pattern because the policy now matched what each environment actually needed, rather than applying prod's strictness uniformly and relying on individual engineers to keep overriding it correctly.

This chapter's caption, and the series' own closing point: a metric showing a policy being worked around is a prompt to investigate why, not an automatic justification for more enforcement — the same "investigate before reacting" discipline Part 6 applied to drift, applied here one final time to governance itself.

Part 9 Governance Cheat Sheet#

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: An organization commits to OpenTofu specifically for its permissive MPL 2.0 license. A consultant recommends Sentinel for policy enforcement. What's wrong with this recommendation, and what should be used instead?

Answer: Sentinel only runs inside HCP Terraform/Enterprise's managed run pipeline and has no OpenTofu integration at all — recommending it to an OpenTofu-committed organization is a straightforward mismatch with the earlier licensing decision. OPA/Conftest is the correct recommendation: vendor-neutral, works identically against Terraform or OpenTofu plan JSON, and doesn't require any particular managed run pipeline to function.

Problem 2: A platform team builds a single cloud_database module accepting a cloud = "aws" or cloud = "gcp" variable, internally branching to create either aws_db_instance or google_sql_database_instance resources. Six months in, the module has 40 variables, half of which only apply to one cloud or the other. What's the underlying design mistake, and what's the fix?

Answer: This is a false abstraction — AWS RDS and GCP Cloud SQL are conceptually similar but structurally different enough that forcing them behind one shared interface accumulates exactly the kind of per-cloud-conditional sprawl this chapter's "avoiding a false abstraction" section warns against, the same underlying problem as Part 3's god-module anti-pattern. The fix is splitting into two genuinely separate, provider-native modules (aws-rds and gcp-cloudsql), each simple and idiomatic for its own cloud, composed together at the root-module level (Part 3) rather than hidden behind one shared, ever-growing interface.

Problem 3: A team's governance charter lists a mandatory tag policy as hard-mandatory with no override, justified as "tags are never actually urgent, so there's no legitimate reason to bypass this." A production incident requires an emergency resource creation where the on-call engineer doesn't have time to determine the correct CostCenter tag value before the fix needs to be live. Was the "tags are never urgent" reasoning sound?

Answer: No — the reasoning conflates "this specific policy's subject matter is rarely urgent" with "this policy should never need an emergency override," but the actual trigger for needing an override is the situation (a live incident with limited time), not whether the policy's subject matter sounds inherently urgent. Any hard-mandatory policy blocking infrastructure creation during a genuine incident creates exactly this chapter's Sentinel worked-scenario failure mode, regardless of whether the policy itself concerns tags, instance types, or anything else — the fix is the same soft-mandatory-with-audited-override pattern, applied here too, likely paired with a follow-up requirement to backfill the correct tag value once the incident is resolved.

Problem 4: An auditor asks a platform team to demonstrate that every change to production infrastructure over the last quarter was reviewed and approved by an authorized person before being applied. The team has no dedicated change-management system. What should they point to, and why is this sufficient?

Answer: The team should point directly to the existing pipeline artifacts this series already produces as a byproduct of normal operation — the PR history (each showing the actual diff and its plan), the GitHub Environment's required-reviewer approval records (Part 8) for every production apply, and the CI job logs tied to short-lived, OIDC-derived identities rather than a shared credential. This is sufficient because it answers exactly the audit question (who approved what, when, and what actually ran) with primary evidence generated automatically at the time each change happened, rather than a separately-maintained log that could drift out of sync with what actually occurred — a stronger, not weaker, form of evidence than a manually kept change log would provide.

Problem 5: A platform team notices a specific Checkov check's override rate climbing steadily in dev over two consecutive quarters, while the same check's override rate in staging and prod stays near zero. What does this pattern suggest, and what's the recommended response per this chapter's own closing worked scenario?

Answer: The pattern strongly suggests the check is well-calibrated for staging/prod but genuinely too strict for dev's actual risk profile — exactly the environment-specific miscalibration this chapter's governance-review scenario walks through in full. The recommended response is investigating why the pattern is environment-specific (not organization-wide) before assuming a discipline problem, then, if the investigation confirms a genuine mismatch, scoping the check's enforcement level per environment (hard- mandatory where it was already working, advisory-only or removed where it isn't) rather than either ignoring the trend or tightening enforcement further in the one environment where it's clearly not fitting the actual need.

Summary and What's Next#

Across nine chapters, this series went from a single terraform apply (Part 1) to a full, production-grade practice: state that's shared, locked, and recoverable (Part 2); modules with real interface discipline (Part 3); a repository and account structure that makes a dev-to-prod mistake structurally hard, not just conventionally discouraged (Part 4); providers, data sources, and provisioners used precisely and only when genuinely warranted (Part 5); drift treated as inevitable but manageable through deliberate, version-controlled mechanisms (Part 6); a layered test suite catching an entire class of mistake before a human ever has to (Part 7); a CI/CD pipeline where the plan a human reviews is exactly the plan that gets applied (Part 8); and, closing the series, the governance, cost, and multi-cloud discipline that keeps all of the above consistent across an entire organization rather than one team's private best practice.

The throughline — checkout-service, catalog-service, inventory-service, and the platform team behind them — started as a teaching device in Part 1 and, by this final chapter, looks like a genuinely complete, realistic platform engineering practice: not a toy example, but the shape a real team's Terraform usage converges toward once every chapter's lesson has actually been applied, incident by incident, exactly the way this series' worked scenarios showed it happening in practice.

Where to go from here depends on where your own team currently stands. If Terraform is brand new to your organization, revisit Part 1 through Part 4 first and get the foundation genuinely solid — a remote backend with locking, a real module boundary, and an account structure that makes a mistake structurally hard — before layering on Part 7's test suite or Part 9's policy engines; governance without a solid foundation underneath it mostly just formalizes existing problems rather than fixing them. If your team already runs Terraform at real scale but has been accumulating exactly the kind of ad hoc, undocumented practice this series' worked scenarios describe, start with an honest audit against Part 6's drift-detection and Part 8's plan-review disciplines specifically — those two chapters catch the highest-frequency, highest-severity real incidents this series covers, and are worth prioritizing over the more advanced governance material in this final chapter if something has to come first.

For hands-on practice putting these patterns together in a real, runnable repository, check the companion devops-msrashed-com-handson repo's growing Terraform examples as they're added — and this site's Kubernetes Deep Dive and AWS Cloud Architecture series for the infrastructure this series' own Terraform modules were built to provision in the first place, since the throughline system in all three series is the same one.