Cloud infrastructure defined in Terraform, so you can review, repeat and rebuild it

Terraform provisions infrastructure, while Ansible and similar tools mainly configure software on servers that already exist. Terraform declares resources such as networks, databases and clusters and works out what to create, change or delete. Configuration tools install packages and manage files on machines. In container-based platforms much of that configuration moves into Docker images and Kubernetes manifests, so Terraform with containers often covers most needs.

Terraform works across AWS, Microsoft Azure, Google Cloud and many other services with one language and one workflow, which matters when your estate spans more than one provider or includes DNS, monitoring and SaaS tools. Native tools such as AWS CloudFormation or Azure Bicep are reasonable choices for single-cloud teams already invested in them, and they need no separate state file to manage. We default to Terraform for new work, and we do not recommend rewriting working native templates unless there is a clear trigger, such as adding a second provider.

Infrastructure drift is any difference between what your code declares and what actually exists in the cloud, usually caused by manual console changes or emergency fixes. We detect it by running Terraform plans on a schedule against each environment and alerting when a plan is not empty. Each drift item is then either written back into code, if the change was intended, or reverted through the normal reviewed workflow.

Yes. Terraform can import existing resources into its state so they are managed by code without being recreated. We write the matching configuration, import in small batches starting with non-production, and continue until a plan shows no unexpected changes. Resources that are badly configured are flagged and corrected afterwards through reviewed pull requests, rather than altered silently during the import itself.

We keep Terraform state in encrypted remote storage, such as an S3 bucket, an Azure Storage account or a Google Cloud Storage bucket, with locking so two changes cannot run at the same time. State is split by environment and component to limit the impact of any mistake. Access is restricted to the pipeline and a small group of named engineers, and versioning lets us recover an earlier state if needed.

We keep secrets out of the repository and, as far as possible, out of Terraform state, because state records resource attributes in plain text. Marking a variable as sensitive only hides it from command output. Where we can, the secret store generates the password itself, in AWS Secrets Manager, Azure Key Vault or Google Secret Manager, and we use ephemeral values and write-only arguments where recent Terraform versions support them. Anything left in state is encrypted and access-restricted, and pipelines use short-lived federated credentials.

An engineer edits the Terraform code on a branch and opens a pull request. The pipeline formats and validates it, runs security and policy checks, and posts a plan showing exactly which resources will be created, changed or destroyed. A reviewer approves, the change merges, and the pipeline applies it to each environment in order, with production normally requiring an extra approval step before anything runs.

Yes, it produces change-control evidence as a by-product of normal work. Each change has a pull request with an author, a reviewer, the saved plan output and a pipeline run showing when it was applied and by which identity. When only the pipeline holds permission to change production, console edits become exceptions that drift detection reports. That evidence supports an audit, but it does not certify anything by itself, and we can work within the controls your compliance lead defines.

Either can work, and the choice is mostly about licensing and governance rather than features. OpenTofu is an open-source fork created after HashiCorp moved Terraform to the Business Source Licence in 2023, and it keeps the same configuration language and a very similar workflow. Some organisations prefer it for that reason. Existing Terraform code can usually move across with limited changes, and the modules, pipelines and review process we set up are designed to run on either tool.

That depends mainly on how many accounts, environments and hand-built resources you have, and how consistent they are today. Codifying one well-understood environment with a review pipeline can often be done within a few weeks of discovery. Larger or older estates are handled in phases, usually starting with shared networking and non-production, so each phase leaves you with reviewable code you can use straight away.

Pricing depends mainly on the size and condition of your current estate: how many accounts and environments you run, how many resources must be imported rather than rebuilt, how far they have drifted, and whether you also want plan guardrails and scheduled drift detection. We start with a discovery call and an audit of what exists, then send a written proposal with a fixed quote for the agreed scope. Cloud running costs are separate and are paid directly to your provider under your own account.

Yes, and we design for that from the first module. We use clear structure, documented variables, consistent naming and a working example for each module, and we avoid abstractions only their author understands. Before handover your engineers make real changes through the pipeline with us reviewing, and they receive written guidance on adding environments, upgrading providers and dealing with drift.