What is infrastructure as code?
Infrastructure as code describes cloud resources in text files: networks, clusters, databases, DNS records, identity and access policies. A tool such as Terraform, OpenTofu, Pulumi or CloudFormation compares those files with what exists and applies the difference. The files live in Git, so every change has an author, a review and a history.
The point is repeatability and control. A new environment is created from the same code as the last one, a reviewer sees exactly what a change will do before it runs, and an auditor can trace who opened which port and when. Without it, environments drift apart and every incident starts with the question of what is actually deployed.
Our scope covers greenfield platforms and existing estates built by hand, which is the more common case. We import what exists, structure it into modules, secure the state and connect it to your pipelines. The work fits into our DevOps consulting practice alongside pipelines, observability and orchestration.
Signs you need infrastructure as code
Some teams have no infrastructure code at all. More often they have some, but it no longer matches reality, and people have stopped trusting it. Both situations produce the same symptoms in day-to-day operations.
Production was built by clicking in a console
If nobody could rebuild production from scratch, a lost region or a deleted resource turns into a long, improvised recovery.
Plans show changes nobody admits to making
Unexpected diffs mean someone changed resources by hand. Teams then stop applying code for fear of reverting an urgent fix.
Every team copies and edits the same code
Copied network or database code diverges quickly, so a security fix must be applied in many places, and some get missed.
State files sit on a laptop or shared folder
Local or unlocked state leads to concurrent applies, corrupted state and secrets stored in plain text where anyone can read them.
An auditor asks who changed a firewall rule
When changes do not go through reviewed code, answering a compliance question means digging through console logs for days.
Partial infrastructure code can be riskier than none, because it gives a false sense of control. The audit measures how far code and reality have diverged before anything is changed, so the plan starts from facts.
What our IaC engagement covers
We begin by comparing what your code describes with what actually runs, account by account. Every resource is classified: already in code, importable, to rebuild or to delete. How teams lay out repositories and promote changes is detailed in our guide to scaling and versioning infrastructure code across environments.
Inventory and drift report
Resources per account and environment, matched against existing code, with drift and unmanaged resources listed and ranked by risk.
Tool choice and repository layout
Terraform, OpenTofu, Pulumi or CloudFormation chosen with your team, and a repository structure for modules, environments and ownership.
Reusable, versioned modules
Network, compute, database and identity modules with sensible defaults, semantic versions and examples, so teams compose instead of copying.
Remote state and safe applies
Encrypted remote state with locking, separated per environment, and applies that run only from a pipeline after a reviewed plan.
Policy as code and secrets handling
Automated checks on plans for open ports, missing encryption or tags, and secrets read from a vault instead of written in code.
Imports happen in small batches, each accepted only when the plan shows no changes, so production is never modified while it is being brought under code. Your engineers run the imports with us, which is the fastest way for them to learn the new structure.
How much of production is code?
An IaC audit typically takes 2 to 3 weeks and ends with a drift report and a codification plan.
How we codify infrastructure: four phases
The order matters. We secure state and structure before we import, and we import before we enforce. Enforcing too early blocks teams who still need console access to do their daily work.
PHASE 01
Inventory
Accounts, resources, existing code and drift mapped and ranked.
PHASE 02
Structure
Tool, repository layout, state backends and first modules agreed.
PHASE 03
Import
Existing resources brought under code with zero-change plans.
PHASE 04
Enforce
Pipeline-only applies, policy checks, drift alerts and handover.
Once applies run only through the pipeline, console write access shrinks to a logged break-glass role. A scheduled plan runs against each environment and raises an alert when reality moves away from the code, so drift is caught within days rather than discovered during the next incident.
Terraform, OpenTofu, Pulumi or CloudFormation?
The tool matters less than the discipline around it, but the choice still shapes hiring, reuse and lock-in for years. We recommend the one your team can maintain, and we document the reasons so the decision can be revisited.
| Tool | Fits best when | Watch out for |
|---|---|---|
| Terraform | Multi-cloud or SaaS providers, large existing module ecosystem | Review the licence terms against your use case |
| OpenTofu | You want Terraform syntax under an open-source licence | Check provider and feature parity for your needs |
| Pulumi | Engineers prefer TypeScript, Python or Go to a DSL | General-purpose code invites over-engineered abstractions |
| CloudFormation | AWS only, with a preference for native services | Ties infrastructure code to a single provider |
Switching tools is rarely the first priority. A team with working Terraform gains more from modules, state hygiene and policy checks than from a rewrite. We recommend a change only when licence terms, language skills or a multi-cloud plan make the current tool a real constraint.
Risks when codifying a live estate
Bringing running infrastructure under code is delicate, because the tool will happily delete what it does not expect to find. We plan each step around that risk and keep a reviewer between every plan and every apply.
An apply that destroys a resource
A wrong import or a renamed block can plan a replacement. Every plan is reviewed, and destroying a stateful resource requires explicit approval.
Corrupted or lost state
State is stored remotely with locking, versioning and backups, and nobody edits it by hand outside a documented procedure.
Secrets written into code or state
Credentials come from a secrets manager at apply time, and state storage is encrypted with access limited to the pipeline.
Modules nobody dares to upgrade
Modules are versioned and pinned per environment, with a changelog, so upgrades move from staging to production in a controlled order.
Testing infrastructure code catches most of these before they reach production. Our guides on a testing strategy for infrastructure as code and on keeping secrets out of Terraform code show the checks we add to the pipeline.
Infrastructure as code pricing
Every engagement starts with a diagnosis of your accounts and existing code, and ends with a fixed quote. Durations are typical, not promised, and depend mostly on how much of the estate was built by hand.
| Format | Duration | Price |
|---|---|---|
| IaC audit and drift report | 2 to 3 weeks | Fixed quote after diagnosis |
| Codification of an existing estate | 6 to 12 weeks | Fixed quote after the assessment |
| Within a full DevOps transformation | 3 to 6 months | Fixed quote after the assessment |
What changes the price: number of cloud accounts and environments, share of resources built by hand, number of teams consuming modules and compliance requirements.
The quote covers senior consultants only, a defined set of accounts and the deliverables of each phase. Cloud resources, state storage and any commercial licence for an IaC platform or policy tool are billed by their providers, separately from our fees.
Infrastructure as code FAQ
Can you bring existing infrastructure under code without downtime?
Yes. Resources are imported into state rather than recreated, in small batches, and each batch is accepted only when the plan shows no changes. Production keeps running while the code catches up with it.
Should we move from Terraform to OpenTofu?
Not automatically. OpenTofu keeps the Terraform language under an open-source licence, which matters to some organizations. We check your licence position, providers and features, and recommend a move only for a concrete reason.
How do you stop people changing resources by hand?
By making the pipeline the only path for writes. Console access becomes read-only, a logged break-glass role covers emergencies, and scheduled drift detection flags any change that bypassed the code.
Should we use one repository or many?
It depends on team boundaries. We usually separate shared modules from environment configuration, and split environments by ownership, so each team can change its own infrastructure without waiting for another team’s review.
Do you write policy as code?
Yes. Plans are checked automatically against rules such as encryption, public exposure, tagging and allowed regions. Rules start as warnings, then block merges once the team has fixed the existing violations.
Which clouds do you cover?
AWS, Azure and Google Cloud. We are vendor-neutral, so the same discipline applies whichever provider you use, and modules can be designed for more than one cloud when that is a real requirement.