Infrastructure Drift Detection with Terraform and Driftctl

Infrastructure as Code (IaC) ensures that your cloud deployments are reproducible and secure. However, as emergency fixes are made directly in the AWS console, your actual cloud resources begin to differ from your Terraform code. This deviation is known as infrastructure drift.

Why Drift is Dangerous

Drift causes subsequent Terraform runs to fail or inadvertently overwrite manual updates. More importantly, it creates security vulnerabilities—such as open security groups or unencrypted S3 buckets—that go undetected because they are not reflected in the git-managed Terraform codebase.

Detecting Drift Natively

You can run terraform plan -detailed-exitcode to check for differences. However, this only scans resources defined in your codebase—it won't detect orphaned or unmanaged resources created directly via the console or APIs.

Using Driftctl for Comprehensive Audits

Driftctl is an open-source CLI tool that compares your cloud account's actual resources against your Terraform state files. It generates detailed reports highlighting: managed resources, drift status, and completely unmanaged resources. Integrate driftctl into your weekly CI/CD schedules to enforce absolute configuration integrity.

Production Terraform Infrastructure Config

Below is a Terraform configuration snippet implementing secure VPC subnets, an Auto Scaling Group, and auto-scaling triggers based on CPU utilization:

# Security Group for ECS Task Service
resource "aws_security_group" "ecs_tasks" {
  name        = "mirahlabs-tasks-sg"
  description = "Allow traffic from load balancer only"
  vpc_id      = var.vpc_id

  ingress {
    protocol        = "tcp"
    from_port       = 8080
    to_port         = 8080
    security_groups = [aws_security_group.lb.id]
  }
  egress {
    protocol    = "-1"
    from_port   = 0
    to_port     = 0
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# ECS Fargate Auto Scaling policy
resource "aws_appautoscaling_policy" "ecs_policy_cpu" {
  name               = "ecs-cpu-scaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = "service/${var.cluster_name}/${var.service_name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 65.0
  }
}

Cloud Infrastructure Performance Profile

Below is a comparative latency and throughput profile of this infrastructure pattern deployed under a simulated load of 10,000 concurrent requests:

US & UK DevOps Governance & Infrastructure Security

Automating infrastructure and deployment workflows must respect regional privacy laws. Under the UK GDPR and US California Consumer Privacy Act (CCPA), system administrators must ensure that data pipelines respect strict boundaries regarding where user telemetry and system logs are stored (data residency). Implementing secure deployment methods (such as the NIST Secure Software Development Framework - SSDF) ensures that pipeline secrets are securely managed in systems like HashiCorp Vault, and that container configurations undergo automated security scanning before being shipped to production environments.