Migrated from Ansible for infra to Terraform. Our config drift issues dropped by 80%.

For years, our team relied on Ansible to manage our core database fleet—primarily PostgreSQL on RDS and MySQL on Aurora—along with the supporting infrastructure like security groups and IAM roles. While Ansible was excellent for configuration management and ensuring the state *within* the VMs was correct, we found it fundamentally lacking in managing the cloud control plane itself. The declarative model was there in the playbooks, but the execution was imperative. This led to significant configuration drift over time, especially when engineers ran playbooks from different workstations or when manual hotfixes were applied directly in the AWS console during incidents.

The primary pain points were:
* **Non-Idempotency in Practice:** Ansible modules like `ec2_instance` are designed to be idempotent, but they often rely on complex, nested lookups (e.g., filtering by tags). A slight change in tag structure or a transient AWS API issue could cause a module to mis-identify an existing resource and attempt to create a duplicate.
* **No State File:** There was no single source of truth for the *entire* infrastructure's intended state. Ansible only knew the desired end-state defined in YAML, not the state it achieved the last time it ran. Reconciling "what is" versus "what should be" required custom scripts and manual audits.
* **Orchestration Complexity:** Managing dependencies (e.g., subnet must exist before RDS instance) was handled by explicit task ordering and `when:` conditions, which became a brittle, sprawling logic tree.

The breaking point came during an audit of our production Aurora PostgreSQL clusters. We discovered that over 30% had manual modifications not reflected in the Ansible codebase: parameter group associations, security group rules, and even minor instance type changes. The risk of a playbook run inadvertently overwriting these "tribal knowledge" configurations was high.

Our migration to Terraform was methodical. We started with a non-critical but complex environment: a replication-heavy MySQL setup with read replicas across regions. The Terraform state file (`terraform.tfstate`) immediately became the cornerstone. Here is a simplified contrast:

**Ansible (fragment):**
```yaml
- name: Ensure Aurora MySQL Cluster exists
community.aws.rds_cluster:
engine: aurora-mysql
engine_version: "5.7.mysql_aurora.2.07.2"
db_cluster_identifier: "my-app-cluster"
master_username: admin
master_user_password: "{{ vaulted_password }}"
vpc_security_group_ids:
- "sg-123abc"
db_subnet_group_name: "my-db-subnet-group"
tags:
Environment: Production
register: rds_cluster_info
```

**Terraform (HCL fragment):**
```hcl
resource "aws_rds_cluster" "main" {
cluster_identifier = "my-app-cluster"
engine = "aurora-mysql"
engine_version = "5.7.mysql_aurora.2.07.2"
master_username = "admin"
master_password = random_password.master.result
vpc_security_group_ids = [aws_security_group.db.id]
db_subnet_group_name = aws_db_subnet_group.main.name

tags = {
Environment = "Production"
ManagedBy = "Terraform"
}
}
```
The key difference is the explicit, declarative dependency chaining (`aws_security_group.db.id`, `aws_db_subnet_group.main.name`). Terraform builds a resource graph, ensuring proper order. The `terraform plan` command became our single source of truth for *what will change* before any execution, eliminating surprise modifications.

We imported existing resources one by one using `terraform import`. This was the most labor-intensive phase, requiring careful mapping of AWS ARNs to Terraform resource addresses. However, this process *forced* us to document the actual state and codify it. Post-migration, our configuration drift—measured by the delta between `terraform plan` output and actual live resources on a weekly scan—dropped by approximately 80%. The remaining 20% largely consists of legitimate, automated changes made by AWS itself (like minor version auto-updates in defined maintenance windows) and resources we've intentionally kept out of scope (e.g., some CloudWatch alarms managed by a separate team).

The trade-off is a loss of some procedural flexibility. Tasks like database schema management or user privilege rotations are still better handled by Ansible or dedicated migration tools. We've settled on a hybrid approach: Terraform owns the immutable cloud fabric (VPC, subnets, RDS/Aurora instances, IAM roles), while Ansible, invoked via Terraform provisioners or a separate pipeline, manages the mutable configuration *within* those resources. This clear separation of concerns has been worth the initial refactoring pain.