Terraform consulting: reliable, readable and reproducible Infrastructure as Code

The problem: infrastructure nobody dares to touch

Many companies already have “some Terraform”. The difficulties come afterwards: a single repository whose plan takes many minutes and touches everything at once, a local state on a former contractor’s laptop, changes made in the console that are not in the code, environments that diverge with nobody knowing which one is the reference. The result: every change is frightening, and the infrastructure becomes manual again.

Infrastructure as Code only delivers value if the code remains the source of truth, if every change is reviewed before it is applied, and if the team can evolve the whole without its original author. This page describes how we put those principles into practice.

Feekr’s founder builds and operates AWS infrastructure as code (Terraform, Terraspace, OpenTofu), including in the regulated context of HDS (Hébergement de Données de Santé, the French certification for hosting health data). This page reflects that day-to-day practice.

What we do

Structure the code

• Split into stacks by domain and lifecycle: networking, identities, data, compute, applications. An application change should not produce a plan on the network.
• Versioned internal modules, with explicit inputs, safe defaults (encryption, logging, tags) and generated documentation. We use public modules when they are maintained and fit for purpose, and we pin them to a version.
• Environments described by variables and configuration files, not by copies of code. Staging and production share the same code, with different parameters.
• Conventions: naming, tags, file layout, and minimum versions of Terraform or OpenTofu and providers fixed in the code and in a committed lock file.

Secure the state

• An encrypted remote backend (S3, Azure Storage) with versioning to roll back, and locking to prevent two concurrent applies. On AWS, locking has historically relied on DynamoDB; recent versions of Terraform and OpenTofu offer native locking on S3.
• One state per stack and per environment, to limit the blast radius of a mistake.
• Restricted access to the state, since it contains sensitive values. Secrets themselves stay in a vault (AWS Secrets Manager, Azure Key Vault), referenced rather than copied.

Automate with CI/CD

• On every merge request: formatting, validation, static security analysis, then a plan posted as a comment for review.
• After approval: apply run by the pipeline with a dedicated identity (OIDC federation between your code platform and the cloud rather than stored keys), never from a laptop.
• Promotion between environments: the same code goes to staging, then to production after approval.
• Works with GitLab CI, GitHub Actions or Azure DevOps, depending on your platform.

Review the plans

Plan review is where incidents are prevented. We train your teams to read a plan: spot an unexpected destroy or replacement, an attribute change that forces a database to be recreated, an IAM policy change broader than intended. Protection rules (prevent_destroy, policies on sensitive resources) back up human attention.

Detect drift

A scheduled plan on each stack flags the gap between the code and reality. Each drift is handled in one of two ways: either the manual change was legitimate and is brought into the code, or the code is reapplied. Combined with guardrails that limit manual changes in production, this is what keeps the code faithful to the infrastructure.

Concrete deliverables

• Audit of existing code: structure, state, security, pipelines, technical debt, with a prioritised remediation plan.
• Documented repository and module foundation, with written conventions.
• State backends configured and secured, with migration of existing states if needed.
• CI/CD pipelines for plan, review and apply.
• Import of existing resources: resources created by hand brought into the code, until the plan shows no changes.
• Operations guide: adding an environment, upgrading a provider, handling drift, restoring a state.

Selection criteria and common pitfalls

Topic	Question to ask	Common pitfall
Tool	Terraform, OpenTofu, or a wrapper (Terragrunt, Terraspace)?	Adding a wrapper before you need one
Structure	What changes together, and how often?	A single state for the whole infrastructure
Modules	Who maintains them, and how are they versioned?	Overly generic modules with dozens of variables
Environments	Same code, different parameters?	Copy-pasting one folder per environment
Execution	Who is allowed to apply in production?	Applies run from laptops, with no audit trail
Versions	Are providers and the tool pinned?	A silent upgrade that changes a plan

Choosing between Terraform and OpenTofu is not only a technical question: it involves licensing, support and your pipeline tooling. We work through it with you and document the decision.

How we work with your teams

Scope: audit, objectives, conventions and target structure. Build: modules, backends, first scopes migrated. Industrialise: pipelines, plan review, drift detection, security policies. Improve: new scopes, upgrades, support for your teams’ first contributions.

We pair with your engineers, through merge requests reviewed together. The code belongs to you, architecture decisions are written down, and the explicit goal is for your team to maintain the infrastructure without us.

Who it is for, and when to call us

Teams starting out on AWS or Azure who want solid foundations, companies whose infrastructure is still manual, or teams that have inherited Terraform code that has become hard to evolve. Infrastructure as Code is also the foundation of our cloud migration, security and governance and FinOps work. We are based in Villeneuve-d’Ascq, in the Lille metropolitan area (northern France), and work on site or remotely.

[ YOUR QUESTIONS ]

Frequently asked questions

What does a Terraform consultant do?

A Terraform consultant designs or takes over your infrastructure code: repository structure, modules, state management, deployment pipelines and review rules. They also move infrastructure built by hand into code, and train the team so it can maintain everything on its own.

Do you also work with OpenTofu?

Yes. OpenTofu is a fork of Terraform maintained under the Linux Foundation, created after HashiCorp changed Terraform’s licence. The two share most of the language and providers, with features that are gradually diverging. The choice depends on your position on licensing, your existing tools and the features you need.

How do I import existing infrastructure into Terraform?

Inventory the resources, write the target code module by module, then import the existing resources into the state with import blocks. The success criterion is a plan with no changes: the code describes exactly what is running. Work scope by scope, starting with the least critical.

Where should Terraform state be stored?

In an encrypted remote backend with versioning and locking: an S3 bucket on AWS, an Azure storage account, or a dedicated platform. Never in the Git repository or on a developer’s laptop, because the state contains sensitive information and must be shared without concurrent writes.

Do I need to rewrite everything to take over existing Terraform code?

Rarely. We start from what exists, secure the state and pipelines first, then refactor in steps using moved blocks and imports, checking at each step that the plan destroys nothing. A full rewrite is only justified when the current structure blocks any further change.