A high-level resource is an infrastructure resource whose existence or configuration depends on another resource or module. The dependency places it higher in the infrastructure stack: a firewall rule can depend on an application’s IP address, while servers and clusters can depend on a network. section 4.1 section 9.2.2
High-level resources make low-level changes consequential. A new network may require new servers, clusters, and applications configured for its attributes. Unidirectional dependencies keep that impact predictable; circular dependencies make update order uncertain and can disrupt connectivity. section 9.2.2 section 4.1
Manage high-level resources through explicit dependency boundaries:
- Expose required low-level attributes, such as network identifiers, through module outputs or an abstraction layer. section 4.2.1 section 10.2.2
- Pass those attributes into the dependent resource instead of embedding direct references to the lower-level implementation. section 4.2.1 section 10.2.2
- During blue-green changes, deploy a new high-level resource set against the new low-level resource rather than altering live dependencies in place. section 9.2.2
Refactoring a monolithic configuration
Start with high-level resources that have no dependencies, such as project-level IAM accounts and roles. Copy their configuration into a separate directory, initialize state, import the existing resources, verify a no-change plan, and remove them from the monolith. Next, extract dependent resources such as a container cluster, using the provider API to retrieve network and subnet identifiers. Repeat toward lower-level resources, testing each isolated change. section 10.2.1 section 10.2.2 section 10.2.3
Figure 4.3 With inversion of control, the high-level resource or module calls the low-level module for information and parses its metadata for any dependencies.
Diagram the dependency boundary: a high-level module requests low-level attributes and consumes the returned metadata. section 4.2.1
