Infrastructure as code (IaC) is the practice of describing servers, networks, storage, security rules and cloud services in text files, keeping those files under version control, and using tools to create or change the real infrastructure to match them. Instead of an engineer clicking through a cloud console or logging into devices one at a time, the desired setup is written down once, reviewed like software and applied consistently. IaC is a core practice in DevOps and in most well-run cloud environments.
At a glance
- Infrastructure is defined in files, usually in a declarative format that states the desired end result, and tools make the environment match.
- The files live in version control, so changes are recorded with an author and date and can be reviewed before they are applied. A previous definition can be restored and reapplied where the change is reversible; destructive or stateful changes, such as deleting a database, still need backups, migration plans and tested recovery.
- The same code can build identical test, staging and production environments, or rebuild one after a failure.
- It is most common for public cloud resources, and many tools also manage private cloud, virtualization, network devices and SaaS settings.
- IaC is a method, not a product: open-source tools, cloud providers’ own template services and commercial platforms all support it.
What problem it solves
When infrastructure is built by hand, it slowly becomes a mystery. A server was set up years ago by someone who has left; a firewall rule was added during an outage and never documented; the test environment no longer matches production, so changes that worked in testing break in the real one. Rebuilding after a disaster turns into guesswork, and audits turn into screenshots.
IaC replaces that with a written, reviewable description of what should exist. New environments can often be built in minutes from the same code. Changes can go through review before they are applied, which catches mistakes and gives auditors a record of who changed what and why. Because the code documents the setup, much of the knowledge stays with the company when people leave. For organizations running many cloud accounts or regions, it is often the most practical way to keep them consistent.
How it works
Writing the definition. Engineers describe resources such as networks, virtual private clouds, virtual machines, databases, storage buckets, access policies and DNS records in configuration files. Most modern tools are declarative: you state the end result (“three servers of this size behind this load balancer”) and the tool works out the steps. Some are procedural, running a sequence of steps you write.
Version control and review. The files sit in a version control repository. A proposed change is reviewed by a colleague, often checked automatically for errors and security problems, and then merged. That history becomes an audit trail.
Planning and applying. Before changing anything, many tools show a plan of what they will create, change or delete. Once approved, the tool calls the cloud provider’s or device’s interfaces to make the change. Many teams run this through an automated pipeline so nobody applies changes from a personal laptop.
State and drift. Tools track what they have built, either in a state file or by reading the live environment. Comparing that with the code reveals drift, changes made outside the code, so they can be reverted or written back in.
Configuration management. A related layer of tools configures what runs inside servers (packages, settings, users). Some teams treat it as part of IaC; others use container images or prebuilt machine images instead.
Our public cloud page covers how buyers choose and run cloud platforms where IaC is commonly used.
When it matters for buyers
- Moving to or expanding in public cloud. Building cloud accounts by hand works for a pilot and becomes hard to control at scale; starting with IaC is easier than retrofitting it.
- Running several clouds or regions. IaC is one of the main ways to keep multi-cloud or multi-region setups consistent, though each provider’s resources are still defined differently.
- Audits and compliance. Reviewed, versioned infrastructure changes are easier to evidence than screenshots, and the code can be scanned for policy violations before deployment.
- Hiring a managed service provider. Ask whether the provider builds your environment with IaC, and who owns that code if you change providers.
- Disaster recovery planning. Code that can rebuild infrastructure shortens recovery, provided it is tested.
Questions to ask vendors
- Do you build and change our environment using infrastructure as code, and which tools do you use?
- Who owns the code, where is it stored, and will we have full access to it during and after the contract?
- How are changes reviewed and approved before they are applied to production?
- How do you detect and handle drift when someone changes a setting outside the code?
- How are passwords, keys and other secrets kept out of the code?
- Do you scan the code for security and compliance issues before it is applied?
- Has the code been used to rebuild an environment from scratch, and when was that last tested?
How it differs from IaaS
The names sound alike, but infrastructure as a service (IaaS) is something you buy and IaC is something you do. IaaS is a cloud model in which a provider rents you servers, storage and networking on demand. IaC is a way of managing infrastructure, wherever it runs, by defining it in code. You can rent IaaS and still build everything by hand in the provider’s console; you can also use IaC to manage on-premises virtualization or network gear that has nothing to do with IaaS. In practice they often go together, because cloud platforms expose the interfaces IaC tools need, and IaC is how many teams keep IaaS environments under control.