Console-built infrastructure is undocumented infrastructure
An environment created by clicking through a console exists only in that console. Nobody can review it, nothing records why a setting is the way it is, and rebuilding it means remembering.
That is uncomfortable at the best of times. It is a genuine problem if the account becomes unavailable, because rebuilding elsewhere means reconstructing from memory under pressure.
What defining it in code gives you
- The environment can be recreated from scratch, on another account or another provider
- Changes go through review before they are applied
- The configuration is the documentation, and it cannot drift from reality unnoticed
- Environments can be genuinely identical, because they come from the same definition
- Mistakes can be reverted the same way code is reverted
Start small rather than all at once
Converting an existing estate wholesale is a large project that often stalls. A better path is to define new things in code from now on, and convert existing resources when you next need to change them.
Most tools can import existing resources into their state, so the conversion is incremental rather than a rewrite.
Provider-specific or portable
Provider-native tools integrate tightly with one platform. Portable tools describe several providers with one language and workflow.
If there is any chance of running on more than one provider, or of moving, the portable option is worth the slightly steeper start. It also means one workflow to learn rather than several.
Keep secrets out of it
Definitions belong in version control. Credentials do not. Use a secret manager or the provider’s own parameter store, and reference secrets rather than embedding them.
Be aware that some tools record resource attributes, including sensitive ones, in a state file. That state file needs to be treated as a secret itself: stored encrypted, with access controlled.
The payoff appears at the worst moment
The value of infrastructure as code is not felt during normal operation, where it feels like overhead. It is felt when you need to rebuild an environment quickly, on a different account, and the definition is sitting in a repository.
That is precisely the scenario worth preparing for on an account whose history you did not create.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Object Storage: When to Use It and What It Really Costs
- DigitalOcean vs Linode: Which Cloud Account Should You Buy?
- IBM Cloud vs Oracle Cloud: Which Cloud Account Should You Buy?
- The Cloud Account Security Checklist to Run on Day One
Frequently asked questions
For one static server, probably not. As soon as there are several resources, or the environment has to be reproducible, it pays for itself.
Yes. Most tools support importing existing resources into their state so you can convert incrementally.
Remotely, encrypted, with access control and locking. Never in the repository alongside the definitions.
