Skip to main content
Cloud DevOps Solutions
Get a quote Talk to an engineer

Terraform for AWS

We design and implement production-grade Terraform for AWS, modular structure, S3 remote state with locking, Atlantis for PR-based workflows, OIDC authentication, and policy guardrails that help prevent out-of-policy infrastructure from being deployed.

Book a working session Request a quote

Problems we solve

  • AWS infrastructure built via Console, undocumented, unreproducible, impossible to audit changes
  • Terraform state stored locally or in an S3 bucket without locking, state corruption risk
  • Monolithic Terraform root module, plans are slow and every change touches everything
  • No module reuse, every team reinvents VPC, EKS, and RDS configurations from scratch
  • Provider versions unpinned, terraform init installs different versions on different machines

What's included

Terraform project structure: root modules, reusable child modules, and environment workspaces
Remote state configuration: S3 backend with state locking, per-environment state files
AWS provider and module version pinning via .terraform.lock.hcl
Module library for common patterns: VPC, EKS, RDS, S3 with standard tagging
Atlantis or HCP Terraform for PR-based plan/apply workflow
OIDC-based AWS authentication for CI/CD (no long-lived access keys)
Sentinel or OPA policies for policy guardrails (required tags, approved regions)
Import existing resources into state with minimal disruption

Our approach

  1. 01

    Infrastructure audit

    We review your AWS account: what exists, what is in Terraform already, and what is ClickOps-only. We produce a prioritised list of resources to bring under IaC control.

  2. 02

    Module design

    We design the module hierarchy: root modules per environment (dev/staging/prod), reusable child modules per resource type, and a module registry (Terraform Registry or internal).

  3. 03

    State bootstrap

    S3 bucket provisioned with state locking (via a bootstrap module). Existing resources imported into state using terraform import or OpenTofu import blocks.

  4. 04

    CI/CD integration

    Atlantis or GitHub Actions runs terraform plan on every PR and posts the output as a PR comment. terraform apply runs automatically after merge on non-production, or requires manual approval for production.

  5. 05

    Policy and documentation

    Sentinel or OPA policies enforce required tags (Environment, Owner, CostCenter) and block deployments to unapproved regions. Runbook documents the full Terraform workflow for your team.

Tech stack

TerraformAWS ProviderS3 (state)AtlantisGitHub ActionsOIDC (AWS federation)Sentinel / OPATerragrunt (optional)tflintcheckov

Results

We publish results only when a client has approved them. See how we publish case studies and a sample report.

FAQ

Should I use Terraform Cloud or Atlantis for remote execution?
HCP Terraform (formerly Terraform Cloud) is a managed service from HashiCorp, so there is less to operate. Atlantis is open source, self-hosted, and integrates tightly with GitHub/GitLab PRs. For teams wanting no external SaaS dependency, Atlantis on EKS is a common choice. Note that Terraform is source-available under the BSL; OpenTofu is the open-source fork, and Atlantis can run either.
What is Terragrunt and do I need it?
Terragrunt is a wrapper that adds DRY helpers to Terraform: automatic backend configuration, dependency management between modules, and before/after hooks. Useful for large projects with many environments. For smaller setups, plain Terraform with workspaces or separate root modules is simpler.
How do I import existing AWS resources into Terraform?
Use terraform import for single resources or the import block (Terraform 1.5+) for bulk imports. We also use Terraformer to generate Terraform configuration from existing resources, then clean up the generated code.
What are required tags and how do I enforce them?
Required tags (Environment, Owner, CostCenter, Project) are enforced via Sentinel policies (HCP Terraform / Terraform Enterprise) or OPA/Conftest (open source). A pre-commit hook runs tflint and checkov locally before any PR is raised.
How should I structure Terraform for multiple environments?
Two common patterns: (1) separate root modules per environment (clearest separation, most explicit) or (2) workspaces with a single module and environment-specific variable files. We prefer separate root modules for production-critical infrastructure to avoid accidental cross-environment state sharing.

Related services

Related articles

Ready to get started?

Book a free technical consultation. No commitment, just an honest conversation about your goals.

Book a working session Request a quote
Written by Saddique Khan, AWS & Azure Certified · Last updated October 2025