You inherited an account with 300 resources created by hand over three years, and you were asked to "put it in Terraform". You have two paths: generate the code automatically from the infrastructure that already exists (import, reverse-engineering tools), or sit down and write it by hand. The easy answer is "generate it, obviously". The right answer is "it depends what you are trying to achieve".
What generated Terraform gives you
Generating the code has one enormous virtue: speed and fidelity. Instead of guessing the exact configuration of 300 resources, a tool reads them from the cloud and emits HCL describing them exactly as they are. It is the right path when your goal is to capture the current state quickly — for example, to bring something under control that has none today.
- Fast: minutes rather than days for a large estate.
- Faithful: it reflects what is REALLY running, including the manual patches nobody documented.
- A good starting point when there is nothing and you need to close the "infrastructure without code" gap now.
The cost is that generated code tends to be ugly: automatic resource names, zero modules, everything flat, hardcoded values where variables belong, and the noise of every attribute the cloud sets by default. It is correct, but it is not code you want to maintain.
What hand-written Terraform gives you
Writing the code yourself forces you to understand what you are modelling. It is slow, but the result is code built to live: reusable modules, variables where they belong, names that mean something, and a structure that reflects how you want the infrastructure to be — not the historical accident of how it ended up.
- Maintainable: modules, variables, conventions, written so somebody else can read it in six months.
- Intentional: you model the desired state instead of cloning the existing mess.
- It teaches the team: writing it is the fastest way to genuinely understand what you have.
Generated Terraform answers "what do I have?". Hand-written Terraform answers "what do I want to have?". They are two different questions, and you almost always need both.
The pattern that works: generate to discover, write to maintain
In practice the best path is not to pick one: it is to use them in sequence. You generate first to get a faithful, honest inventory of what exists — without that snapshot you are writing blind. Then you use that snapshot as the reference for writing, by hand and clean, the code you will actually maintain. The generated version is the discovery draft; the written one is the final artefact.
The step almost everyone skips
Both generating and writing assume you already know what is in your account. And that is exactly the problem: in three years of hand-built infrastructure, nobody holds the complete inventory in their head. Before choosing to generate or to write, step zero is to SEE — to have the real map of resources and dependencies, so you do not discover halfway through the project that there was a critical subnet nobody mentioned.
Control Cloud gives you that map: it draws what exists across your clouds with the dependencies visible, so you start the Terraform work — generating or writing — knowing what is really there. See first, code after.
Top comments (0)