Infrastructure as code best practices turn cloud changes into a controlled engineering workflow: define infrastructure in code, review every change, test plans before apply, protect state, enforce policy, and watch for drift after deployment. This is the practical shift from console edits and one-off scripts to repeatable delivery across dev, staging, and production.
IaC works because infrastructure definitions live in version control and move through the same review discipline as application code. A subnet change, Kubernetes node pool, database parameter group, or IAM role should leave a trace: who changed it, why it changed, what plan was approved, and what happened after apply.
Start with standards, ownership, and state control
Before choosing modules or CI runners, set the operating model. Decide which teams can change networks, clusters, databases, IAM, and shared platform services. Define repository layout, naming, tagging, state storage, approvals, and rollback paths. These infrastructure as code best practices reduce surprises because every cloud change has an owner, review trail, and repeatable path.
Set these standards before broad rollout:
- Repository layout: choose whether infrastructure lives in one platform repository, per-product repositories, or a hybrid model. Avoid a structure where no team owns shared resources.
- Environment boundaries: separate dev, staging, and production through accounts, subscriptions, projects, or workspaces based on your cloud model.
- State storage: use remote state with locking, encryption, access logs, and restricted access. Treat state as sensitive because it may contain generated passwords, IDs, outputs, or provider-returned values.
- Naming and tags: require owner, product, environment, cost center, data class, and lifecycle tags where the cloud provider supports them.
- Module ownership: define who maintains shared modules for networking, IAM, databases, Kubernetes, observability, and baseline security.
- Approval rules: set different approval paths for low-risk dev resources and high-risk production changes.
- Break-glass access: document when manual changes are allowed, who can approve them, and how those changes move back into code.
| Practice | Why it matters | Owner | Failure signal |
|---|---|---|---|
| Remote state with locking and restricted access | Prevents concurrent applies, lost changes, and local state sprawl | Platform engineering | State files sit on laptops or are shared in chat |
| Versioned modules for shared patterns | Keeps VPCs, IAM roles, clusters, and databases consistent across teams | Platform engineering | Each product team copies old code and edits it manually |
| Pull request plan review | Gives reviewers a readable view of what will change before apply | Service team plus platform reviewer | A plan replaces many resources and no one can explain why |
| Policy-as-code checks | Blocks non-approved regions, open networks, missing tags, and unsafe defaults | Security plus platform engineering | Policy rules live only in wiki pages |
| Secret handling rules | Keeps tokens and passwords out of code and limits exposure through outputs or state | Security | Variables files contain plain-text secrets |
| Drift detection | Catches console edits, hotfixes, and unmanaged resources | Platform engineering | Production differs from code after every release |
| Cost and owner tags | Makes spend traceable and supports chargeback or showback | FinOps plus service owner | Cloud bills contain unowned resources |
| Break-glass process | Lets incident teams act fast without hiding permanent changes | SRE or operations lead | Manual fixes remain outside code for weeks |
The first standard to protect is state. A weak state setup can make a strong IaC tool dangerous. Lock state, limit who can read it, back it up, and separate state per environment or blast-radius boundary. Avoid one huge state file that holds every network, cluster, database, and application resource.
Build the IaC workflow around review, plan, apply, and drift
CI/CD for infrastructure as code should be more conservative than application delivery because an apply can modify networks, databases, IAM, and running compute. A safe workflow separates planning from applying, gives reviewers readable change output, limits who can approve production, and records what changed when drift appears.
HashiCorp describes Terraform as a workflow for provisioning and continuously managing cloud, private datacenter, and SaaS infrastructure. Its recommended practices point toward collaborative IaC workflows rather than isolated local apply commands.
Terraform best practices are mostly delivery practices that also apply to other IaC tools:
- Create a branch for the infrastructure change. Keep the change small enough for a reviewer to understand.
- Run formatting and validation. Fail early on syntax, provider version, variable, or module errors.
- Generate a plan. Use controlled credentials and avoid production applies from engineer laptops.
- Post the plan to the pull request. Reviewers should see creates, updates, replacements, and destroys.
- Require approval based on risk. Production IAM, networking, data stores, and cluster changes need stricter review.
- Apply through CI or a remote execution service. The runner identity should have only the permissions needed for that environment.
- Run post-apply checks. Confirm endpoints, health checks, policies, and monitoring after provisioning.
- Schedule drift checks. Detect console edits and provider-side changes that did not pass through code.
For Terraform teams, HCP Terraform can host remote state, remote runs, and policy checks. A self-managed pipeline can also work if it enforces the same review, state, and access rules.
Be careful with saved plan artifacts. They can contain sensitive values depending on provider behavior and module outputs. Restrict access, set retention rules, and avoid posting full sensitive output into broad chat channels.
Drift needs a decision path. When drift appears, choose one of three actions:
- codify the intentional manual change;
- revert the unauthorized change;
- approve a temporary exception with an expiry date.
A CI/CD workflow is only useful when teams trust it. If plan output is too noisy, reviewers will skim it. Keep modules focused, avoid giant changes, and make destructive changes visible. If the pipeline itself is slow or brittle, review your DevOps pipeline optimization process before adding more gates.
Put security and policy checks where engineers work
IaC security best practices work when checks run before a risky plan reaches production. Security teams should express guardrails as code, keep them visible to engineers, and fail builds for issues that have no approved exception. The goal is early feedback, clear ownership, and fewer emergency fixes after provisioning.
The OWASP Infrastructure as Code Security Cheat Sheet treats IaC as code-defined infrastructure and places security practices inside the software delivery lifecycle. That means security checks should run during pull requests, CI/CD, and drift review, not only after resources are live.
Open Policy Agent provides a general-purpose policy engine and declarative language for policy as code across applications, CI/CD, Kubernetes, gateways, and other systems. For infrastructure delivery, it can help teams express rules that are consistent, testable, and reviewed like code.
Security gates worth implementing:
- Secret scanning: block secrets in repositories, variable files, module defaults, and outputs. Use secret managers and short-lived credentials.
- Least-privilege runner identities: CI runners should not use broad administrator roles by default.
- Network exposure checks: deny public databases, broad inbound rules, and admin ports open to
0.0.0.0/0. - Encryption rules: require encryption for supported storage, databases, queues, backups, and logs.
- IAM rules: detect wildcard permissions, broad trust policies, and unused high-privilege roles.
- Approved regions and services: block deployment to non-approved regions or services when compliance requires it.
- Tagging and data classification: require owner, environment, data class, and retention tags.
- Module and provider version pinning: reduce surprise changes from unreviewed dependency updates.
- Exception handling: require owner, reason, expiry date, and review for every policy bypass.
Policies should be specific enough to guide action. A failed check that says "database is public" is easier to fix than a vague security score. Where possible, include remediation text in the pipeline output: which resource failed, which rule it violated, and what the engineer should change.
Choose infrastructure as code tools by operating model
Infrastructure as code tools differ in language model, cloud coverage, state handling, and fit with existing teams. Pick the tool that supports your delivery controls, licensing needs, provider coverage, and audit process. Tool choice should follow governance requirements rather than developer preference or a single proof of concept.
Declarative tools describe the desired state. Imperative tools describe steps. Terraform, OpenTofu, CloudFormation, and Bicep are commonly used for declarative provisioning. Pulumi uses general-purpose programming languages to model infrastructure while still managing desired state. Ansible is often strongest for configuration management and procedural automation around provisioning.
| Tool | Best fit | Strengths to consider | Watchouts and governance needs |
|---|---|---|---|
| Terraform / HCP Terraform | Multi-cloud, SaaS, private datacenter, and larger platform workflows | Broad provider model, module ecosystem, remote workflows through HCP Terraform | State design, provider credentials, approval flow, and module ownership still need formal rules |
| OpenTofu | Teams that want Terraform-style workflows with long-term open-source licensing as a decision factor | Created after Terraform relicensed from MPL to Business Source License; supports a familiar workflow for many Terraform users | Check provider compatibility, module support, state migration, and enterprise support needs |
| CloudFormation / Bicep | AWS-native or Azure-native organizations that prefer provider-owned tooling | Tight integration with native cloud services and identity models | Portability is limited; multi-cloud teams may need separate standards per cloud |
| Pulumi | Teams that want to use TypeScript, Python, Go, C#, Java, or YAML for infrastructure | Strong fit for software engineering patterns, typed abstractions, and custom logic | Requires code review discipline; abstractions can hide risky infrastructure changes if reviews are weak |
| Ansible | Configuration management, OS setup, bootstrapping, and procedural automation around provisioning | Mature automation model and readable playbooks | Resource lifecycle and drift handling can become harder for large declarative cloud estates |
OpenTofu is a credible option when licensing policy is part of the platform decision. Terraform remains widely used, especially where HCP Terraform or existing modules are already part of delivery. For provider-native teams, CloudFormation and Bicep can be the simpler path. For teams with strong software engineering practices, Pulumi can fit well. For configuration and operational tasks, Ansible still has a place.
The tool should answer practical questions:
- Can it separate planning from applying?
- Can state be locked, backed up, and restricted?
- Can policies run before production apply?
- Can plans be reviewed in pull requests?
- Can modules or packages be versioned and tested?
- Can drift be detected without giving every engineer broad cloud access?
- Can the team support it for the next several years?
Most IaC failures come from weak process rather than the syntax of the chosen tool. A disciplined Bicep or CloudFormation workflow can outperform a careless Terraform rollout. A well-designed Terraform workflow can support multiple clouds without giving up review control.
Roll out IaC without stalling delivery
Migration from manual cloud changes to governed IaC should start with high-risk and high-change resources, then expand through repeatable modules and CI/CD gates. Trying to codify every resource at once often creates long branches and unclear ownership. A phased rollout gives teams working code, audit trails, and space to fix state issues.
Use this rollout sequence:
- Inventory the estate. List accounts, subscriptions, projects, networks, clusters, databases, IAM roles, storage, queues, DNS, monitoring, and unmanaged resources.
- Classify resources by risk. Shared networking, IAM, production data stores, and Kubernetes control planes need stricter controls than short-lived dev resources.
- Pick one pilot. Choose one product, one shared service, or one environment with clear ownership.
- Decide import or rebuild. Import existing resources where the tool supports it. Rebuild disposable environments when that is safer and faster.
- Create the state backend. Lock it down before production use. Separate state by environment and blast-radius boundary.
- Write baseline modules. Start with networking, IAM boundaries, databases, compute, and logging patterns that repeat across teams.
- Add CI/CD gates. Run format, validation, plan, peer review, approval, apply, and post-apply checks.
- Add policy gates. Start with the rules that prevent the largest incidents: public data stores, broad IAM, open admin ports, missing encryption, and missing owner tags.
- Freeze manual edits. Allow console changes only through break-glass rules, then bring those changes back into code.
- Measure drift and delivery health. Track drift count, failed policy checks, plan review time, rollback events, and unowned resources.
IaC can support cost control, but only when cost rules are part of delivery. Require owner, product, environment, and cost-center tags. Add policy for approved instance families and regions. Tear down preview environments on schedule. Set autoscaling ceilings. Review plan output for large resource count changes. Run drift checks so abandoned resources do not survive outside code. For a broader operating model, see our guide to cloud capacity planning and cost optimization.
Need safer infrastructure delivery?
We can assess your cloud estate, IaC workflow, security gates, and delivery process, then design a practical DevOps roadmap.
Know when to bring in DevOps and cloud help
Outside support is useful when IaC touches production systems, regulated data, shared networking, Kubernetes platforms, or multi-account cloud estates. Bring in help before state is fragmented across laptops, policies live only in wiki pages, and production access depends on tribal knowledge. Early design work is cheaper than cleanup.
Bring in DevOps services when the team needs help designing CI/CD gates, remote execution, state storage, drift checks, module standards, or platform ownership. If infrastructure work is part of a broader move to the cloud, pair IaC rollout with a structured cloud migration plan. For operating model, vendor selection, or governance decisions, use IT consulting before committing to a toolchain.
Warning signs that the current process needs intervention:
- production applies run from local machines;
- state files are stored in personal folders;
- every release needs manual console changes;
- reviewers cannot understand plan output;
- CI runners have broad owner-level permissions;
- policies are written as wiki guidance rather than code;
- drift appears often and no one owns the fix;
- cloud bills contain resources with no product owner.
A practical IaC program starts small, protects state, reviews every change, and adds policy where engineers already work. Once that foundation is stable, scaling across teams becomes a governance exercise rather than a series of manual cloud fixes.
