01 · Challenge
The problem
Cloud resources are provisioned inconsistently, environments drift from their intended configuration, and teams lack clear cost ownership.
Symptoms the team sees
- Some resources live in Terraform, others were created in the console and never recorded.
- Staging and production differ in ways nobody can fully list.
- The monthly bill rises, but no team can say which of their services drives it.
- Old snapshots, unattached volumes and test environments linger for months.
- Infrastructure changes are applied from laptops with no review.
Root causes
- No shared module library — each environment was written from scratch.
- No pipeline or approval process for infrastructure changes.
- Tagging was optional and inconsistent, so costs could not be attributed.
- No retention policies for logs, backups and snapshots.
02 · Approach
Implementation steps
- 01
Inventory and import
Inventory existing resources, then import hand-built resources into Terraform state in planned batches.
- 02
Reusable Terraform modules
Build versioned modules for networking, compute, databases and IAM with sensible, secure defaults.
- 03
Separate environments and config
Keep environment-specific values separate from module code, with remote state and locking per environment.
- 04
Plan review and approvals
Run fmt, validate, lint and plan in CI on every pull request, and require approval before apply.
- 05
Tagging and ownership
Enforce mandatory tags (owner, service, environment, cost-center) through policy checks.
- 06
Measurement-driven cost review
Review compute, storage, networking and retention using actual usage data to identify idle or oversized resources.
- 07
Budgets and dashboards
Configure budget alerts and cost dashboards per team or service.
03 · Architecture
Solution architecture
Infrastructure changes follow a pull-request workflow: Terraform is validated and planned automatically, checked against policy, approved by a reviewer, then applied. Tagging and cost reporting close the loop.
Terraform provisioning workflow
- Source
- Build
- Security
- Gate
- Deploy
- Observe
- 01Version-controlled TerraformReusable modules, per-environment config
- 02Validate & planfmt, validate, lint and terraform plan
- 03Policy checksSecurity and tagging rules as code
- 04ApprovalPlan reviewed before apply
- 05Cloud provisioningApply with remote state and locking
- 06Monitoring & cost reportingDrift detection, budgets and dashboards
Technology stack
- Terraform
- Terraform Cloud / Atlantis / CI-based workflow
- TFLint
- Checkov or OPA policies
- AWS Cost Explorer / Azure Cost Management / GCP Billing
- Infracost
- Ansible for configuration
04 · Validation
How the result is validated
- Confirm imported resources produce an empty plan — Terraform matches reality before any change is made.
- Run drift detection on a schedule and review any differences.
- Verify policy checks block untagged or non-compliant resources in a test change.
- Review each cost recommendation with the owning team before acting; some 'idle' resources exist for good reasons.
05 · Expected impact
Business impact
- Consistent, reproducible environments created from version control.
- Reviewed, auditable infrastructure changes instead of ad-hoc console edits.
- Clear cost attribution by team and service, so owners can make informed decisions.
- Measurement-driven reviews that can reveal savings opportunities — any actual savings depend on the environment and must be measured, not assumed.
These are expected directions of improvement, not measured results. Actual impact depends on the starting point and is tracked with the client's own metrics.
06 · Lessons learned
What tends to matter most
- Import before refactoring. Change one thing at a time so plans stay understandable.
- Tagging only works when it is enforced automatically.
- Cost optimization is ongoing; a one-off clean-up drifts back without ownership and budgets.