How IaC changed the way we manage infrastructure
Until a few years ago, infrastructure operations was a fairly hands-on job. You logged in to the cloud console to create servers and configure networks, and when something broke, you traced the cause by asking yourself "where did I touch the wrong thing?" Infrastructure changes were infrequent, so each change was a fairly big event. But as cloud environments matured and service architectures grew more complex, this approach started to hit its limits. The number of servers grew fast, environments split into development, test, and production, and multi-region and multi-account setups became common. The scale had already grown too large for people to manage all of it by hand.
The concept that emerged naturally from this shift is Infrastructure as Code (IaC). It is a change in perspective: infrastructure is no longer something managed through people's memory and experience, but something to be defined in code and created and managed automatically. Gartner stresses that IaC ensures consistent deployment and management of infrastructure resources and is a key tool for enabling cloud governance and self-service for application teams (Gartner, 2024).
In this post, we walk through how IaC is structured and operated, covering the full flow from provisioning to Git repositories for managing code and registries for sharing modules.
1. Why manage infrastructure as "code"?
IaC (Infrastructure as Code) means defining infrastructure configuration such as servers, networks, and storage in code, managing its versions, and deploying it automatically, instead of having people configure it by hand. The important point is that IaC does not simply mean automation.
💡 The core of IaC is a perspective: infrastructure is not something you build once, but something you must manage continuously and keep in a consistent state.
In the past, configuring infrastructure by hand was the norm. People were involved at every step: creating servers, connecting networks, and entering configuration values one by one. This worked fine while environments were simple, but it started to show its limits with the move to the cloud. As the amount of infrastructure grew and change cycles got shorter, knowing "what state it is in now" became harder than knowing "how it was built."
This is where "declarative management" comes in. In the declarative approach, you define "what" you need rather than "how" to build it. The system uses this definition to calculate the difference from the current state and applies only the changes needed. IaC can be seen as extending this declarative management approach to infrastructure.
When you adopt an IaC tool like Terraform, infrastructure configuration is managed around code and history, not individual experience or memory. It becomes clear who made what change and when, and it is easier to trace the cause when problems occur. This plays an important role in shifting infrastructure operations away from dependence on specific people and toward a team-level management system.
As a result, IaC is not just a technology trend but a change in how we look at infrastructure. Managing infrastructure as code means building a structure that controls change, maintains consistency, and reduces operational risk.
2. Provisioning: the moment code becomes real infrastructure
In IaC, provisioning is the process of creating, changing, and deleting real infrastructure resources based on what is defined in code. The declared configuration does not just stay as a document; it is applied to the cloud environment as is, creating servers and connecting networks. It also sets up the access permissions you need.
Provisioning is the point in the IaC flow where an abstract definition turns into real infrastructure.
IaC-based provisioning calculates the difference between the desired end state and the current environment, and configures infrastructure to close that gap. Thanks to this, running the same code multiple times still produces consistent results, and when only some resources change, work happens only within the necessary scope.
Also, in an IaC environment, provisioning goes through a step that reviews the changes first rather than running immediately. At this point, you can see in advance which resources will be created, modified, or removed, and predict how the infrastructure change will affect the service. This structure turns provisioning into an infrastructure change process under operational control, not just an automated creation task.
3. The repository: the reference point for infrastructure code
3-1. How IaC code relates to the repository
In IaC, a repository means more than just a place to store code. Because the code that defines infrastructure becomes the standard for operations, where that code is stored and how it is managed are directly tied to infrastructure stability. If provisioning is the step that builds infrastructure, the repository is the foundation that keeps managing the result.
IaC code stored in a repository becomes the reference point that defines "what state the infrastructure should be in." You can trace at the code level who changed which setting, when, and with what intent. This helps you manage infrastructure operations according to clear records instead of relying on a particular person's experience or memory.
3-2. Why Git-based management matters
Git-based repositories are widely used in IaC environments not just because Git is a familiar tool. Git records the change history of code and lets you roll back to a previous state, which meets the basic requirements of infrastructure management. The more complex infrastructure configuration gets, the more knowing exactly when and how a change was made becomes key to operational stability.
Git repositories also let related teams review and agree on infrastructure code. By merging changes after review instead of applying them right away, you can reduce mistakes such as unintended configuration changes. This turns infrastructure changes from individual work into a team-level operations process.
This naturally extends into an operating model called GitOps. The repository is the starting point for every change, and the declared code becomes the standard for operations. This post does not go deep into GitOps, but understanding IaC and repositories alone is enough to see why the repository becomes the center of infrastructure operations.
4. Registries: how to roll out well-built infrastructure reliably
4-1. Registries and modules
Once IaC is used in earnest, the amount of infrastructure code grows quickly. Writing every configuration from scratch each time is not efficient. A registry emerged to solve this problem: it is a store that organizes frequently repeated infrastructure components into modules and shares them.
A module defines an infrastructure pattern used across multiple environments, such as a network setup or a basic set of servers, as a single unit. Register it in a registry, and teams across the organization can reuse the same structure. This keeps infrastructure configuration consistent while laying the groundwork to expand into new environments quickly.
If the repository is the "management standard" for infrastructure code, the registry handles how verified code spreads across the whole organization. Well-organized modules and registries lift IaC from individual automation to an organization-wide operating system.
4-2. Operational points to consider when using a registry
Registries improve the reusability and scalability of IaC, but there are clear operational points to consider. The main one is version management. When a module is updated, it can affect every environment that uses it at the same time, so if you do not tightly control the scope of change, unintended infrastructure changes can occur. Modules registered in a registry should therefore be managed as carefully as application code.
Another point is visibility. As modules simplify infrastructure configuration, it can become harder to see at a glance which resources are being created inside them. This can make it harder to trace the cause when a problem occurs, so operators need to keep an understanding of how modules work internally along with enjoying their convenience.
In the end, a registry is about balancing convenience and control. Make active use of standardized modules, but the benefits of IaC only really show when you also have an operating system that keeps change history and impact scope clearly visible.
5. IaC is an operating model, not a tool
Provisioning, repositories, and registries are not separate concepts; they form a single flow. IaC defines infrastructure in code, builds the real environment from that definition, manages change history, and spreads verified patterns across the organization. Once you understand this flow, infrastructure operations becomes a management system built on consistency and stability, not just an automation task.
As infrastructure scales, what matters is less "how fast can we build it" and more "can we know and control what is changing, and how." IaC is one answer to that need, and the structure that runs from provisioning to repositories and registries is the basic framework for putting that answer into practice.
What should infrastructure operators think about in an IaC environment?
Sources
Use Infrastructure as Code to Unlock Your Organization’s Cloud Potential - Gartner (2024.10.18)
Related articles
