Infrastructure as code is a documentation decision

Infrastructure as code gets sold on automation and repeatability, which undersells it. Plenty of teams automate deploys perfectly well with a shell script.

The real argument is that without it, the authoritative description of your production environment exists only in the console and in the head of whoever set it up. That is a documentation problem wearing an operations costume.

The test is simple

Delete your staging environment. Can you rebuild it, exactly, from the repository, without asking anyone anything?

Most teams cannot, and the gap is always in the same places. Security group rules added during an incident. A parameter someone changed in the console to unblock a launch. An IAM policy widened in a hurry and never narrowed. The DNS record nobody remembers creating.

Each of those is a piece of production behaviour that exists nowhere in version control, which means it is invisible in code review, absent from your history, and impossible to reason about when it eventually causes a problem.

Drift is the actual enemy

The state that breaks you is rarely the state you wrote down. It is the difference between what you wrote down and what is running.

Console changes are how drift happens, and they happen because the console is right there during an incident and Terraform is not. This is a real tension and pretending otherwise leads to policies nobody follows.

The workable compromise we use: console changes are allowed during an incident and must be reconciled into code within the week, tracked as an actual ticket. Run drift detection on a schedule so the reconciliation list is generated rather than remembered. What you are protecting is not purity, it is the property that the repository stays a true description of production.

Start with what hurts

Teams often stall because converting everything feels like a quarter of work with no visible output. It does not have to be all at once.

Import the pieces that have burned you. The security groups, the IAM roles, the RDS parameter groups, the things where a small misconfiguration has a large consequence. Leave the stable, boring resources for later or forever.

Partial infrastructure as code is genuinely better than none, and the usual argument against it, that mixed ownership is confusing, matters far less than the argument for it, which is that your most dangerous resources are now reviewable.

What you get on the bad day

The payoff is not felt on a normal Tuesday. It is felt when a region has a problem, or an account is compromised, or someone deletes something important.

On that day the difference between a team that can stand up a known-good environment in an hour and a team that is reconstructing it from screenshots and memory is the difference between an incident and a very long week. That is what you are buying, and it is why it is worth doing before you need it.