Infrastructure as Code: Why You Should Stop Clicking Servers in the Console

Almost every company that has been in the cloud for a few years has the same story. The first server was clicked together in the console because it was quick. Then came a database, a load balancer, a few firewall rules and a test environment “identical to production”. Before long nobody knows exactly why things are set up the way they are – and the person who clicked it may no longer work there.

Infrastructure as Code (IaC) solves this by describing the whole environment in text files that behave like ordinary source code.

What it means in practice

Instead of clicking through the console, you write down the state you want: two servers of this type, a database with daily backups, a network with these rules. A tool such as Terraform compares that description with what actually exists in the cloud and makes only the changes needed.

resource "aws_db_instance" "app" {
  engine                  = "postgres"
  instance_class          = "db.t4g.medium"
  allocated_storage       = 50
  multi_az                = true
  backup_retention_period = 14
  deletion_protection     = true
}

These few lines tell you straight away that the database runs in two availability zones, keeps backups for 14 days and cannot be deleted by accident. In the console you would be checking three different screens to find that out.

Why it pays off

Repeatability

A new environment – for testing, a new customer or another region – is built from the same code in minutes rather than days. And it really is the same, not “almost the same”.

History and review

The code lives in Git, so every change shows who made it, when and why. Changes go through code review like any other code, and before anything is applied you see an exact plan: what will be created, changed or destroyed.

Disaster recovery

If something breaks or you need to rebuild an environment, you have the exact recipe. Together with data backups, it is the foundation of any recovery plan.

Security and auditing

Security settings – encryption, access rights, open ports – are written down and can be checked automatically before deployment. Tools such as Checkov or tfsec will flag, for example, a publicly readable S3 bucket before it even exists.

Less dependence on individuals

Knowledge of your infrastructure no longer lives only in one administrator’s head but in the repository. A new colleague or an external partner can find their way around by reading the code.

Which tools to choose

• Terraform / OpenTofu – the most widely used tool, supporting almost every cloud and service. OpenTofu is its open-source fork under the Linux Foundation, created after Terraform’s licence change in 2023. A sensible choice for most projects.
• Pulumi – you write infrastructure in a regular programming language (Python, TypeScript, Go). A good fit for teams that want loops, functions and tests just like in application code.
• AWS CloudFormation / CDK – AWS’s native tools. They make sense if you are AWS-only and don’t want another tool.
• Ansible – better suited to configuring what runs inside servers (packages, configuration, users). It complements Terraform well.

The tool matters less than the discipline: every change goes through code, not by hand in the console.

How to adopt it without downtime

Adoption doesn’t have to be a big bang. This is how we approach existing infrastructure:

1. Inventory – we map what runs in the account and separate what can be deleted from what must be kept.
2. Import existing resources – both Terraform and OpenTofu can bring existing servers, networks and databases under management without recreating them. Users notice nothing.
3. State in a safe place – the infrastructure state file is stored centrally (for example in encrypted S3) with locking, so two changes never run at once.
4. Deploy through CI/CD – a change is proposed in a pull request, the pipeline shows the plan and applies it once approved. Manual console access is reduced to read-only.
5. Drift detection – we regularly check that reality hasn’t drifted from the code, for example after a “quick fix” made by hand at night.

It is best to start where it hurts most: often that is networking and access rights, or an environment that soon needs to be duplicated.

When it isn’t worth it (yet)

For a single small server running a website that never changes, IaC is unnecessary extra work. The tipping point comes when you have several environments, several people touching the infrastructure, or audit and recovery requirements. From then on the investment pays back very quickly.

⚙️ Want your infrastructure under control?

As part of our DevOps services we bring your existing infrastructure into code, set up deployment through CI/CD and document everything. The code stays in your repository. If you are building a new environment, IaC is part of our AWS architecture design from the start. Get in touch – the first consultation is free and comes with no obligation.