Insights — Cloud and Terraform
Writing your infrastructure is not a project: it is a way of working.
Nobody hands their servers to a script nobody re-reads. Terraform does not replace the console: it makes it reproducible, reviewable and reversible. Here is the order in which we put it in place in an SME, with no dedicated platform team.
01 — The problem
Without code, your infrastructure has no history.
The question is not technical, it is documentary: in two years, who will know why this subnet was opened, who changed that rule, and how to rebuild the environment identically after an incident?
The console answers "what is the current state". Code answers "who changed what, when, and why". That second answer is missing in most SMEs — and it is the one that costs the most the day somebody leaves.
01Why code, and not the console
An infrastructure described in code reads like a recipe: the change goes through review, the history keeps a trace of the intent, and rolling back is possible. It is also the only way to rebuild an environment identically, which makes a recovery plan credible instead of being a document nobody has tested.
- Every change is reviewed before it is applied
- The history says who wanted what, and when
- An environment can be recreated identically
- The documentation becomes the code itself
- Guardrails are enforced, not merely written down
02The five steps, in order
The most common mistake is to start with the network, then discover six months later that no account is isolated. We always start with governance: an administration account, an organisation, a locked state bucket and an audit log already switched on.
The network comes next, then the application, then monitoring, and finally detection. Only at that point can you talk seriously about cost optimisation, because you know who consumes what.
- Administration account, organisation and organisation audit log
- Remote state, encrypted and locked — never a local state file in production
- Network: availability zones, private subnets, private endpoints
- Application: containers, databases, queues, backups
- Guardrails: detection, budgets, progressive alerts
03The three mistakes that cost the most
The first is local state: a state file kept on a workstation, without locking, applied by two people on the same day. The second is writing home-made modules before having applied a first version: you generalise an architecture you do not yet master. The third, the most common, is to keep changing production by hand — in that case the code becomes a lie, and the map no longer matches the territory.
02 — Common questions
What we are asked before starting
Do we have to rewrite the whole existing infrastructure?
No. We start by describing in code what is being created — often a staging environment, a new service — then progressively import what exists, as real changes occur. A full rewrite in one go is an unnecessarily risky project.
How long for a usable foundation?
Allow two to three weeks for governance, network and the guardrails of a first application, provided you start from a clear specification. The commented examples we publish already cover those steps.
Do we need a dedicated team to maintain all this?
No, provided you stay sober: few modules, pinned versions, and a code review on every change. A platform where only one person knows how to apply changes is a risk; that is precisely what shared code fixes.
Do you want to see what a readable AWS foundation looks like?
We put the foundation in place, document it and leave it with your teams, with the audit trail, the guardrails and the alarms already running.