Cloud Security Configuration Drift: Detection and Remediation Across AWS, Azure, and GCP
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Cloud infrastructure is designed to be easy to change, which makes it easy to drift. A security engineer enables a debug port in a security group to investigate an incident and forgets to close it. A developer makes an S3 bucket temporarily public to share a file with a vendor and the access is never reverted. An IAM policy is broadened to resolve a production access issue and is never scoped back down. Each individual change is understandable in context. The accumulated effect is an environment that passed its last compliance assessment but is currently non-compliant in ways that represent real attack surface.
Drift detection and remediation addresses this by continuously comparing actual resource state against defined baselines and either alerting on or automatically fixing deviations. This guide covers the native cloud tools, the auto-remediation patterns, and the GitOps workflow that makes drift the exception rather than the accumulated norm.
Deploying drift detection with native cloud tools
AWS Config, Azure Policy, and GCP Organization Policy each provide native mechanisms for continuous compliance evaluation that require no third-party tooling to get started. AWS Config records every resource configuration change and evaluates it against managed rules covering the most common security baselines; Azure Policy can block non-compliant resource creation outright using the Deny effect; GCP Organization Policy applies constraints at the organization level that propagate to all projects. Deploying these tools takes hours and immediately surfaces the drift that has been silently accumulating since the last compliance assessment. Start with conformance packs and policy initiatives that match your framework (CIS Benchmark, PCI DSS, NIST 800-53) before tuning individual rules.
AWS Config: enable conformance packs for your compliance framework
Deploy AWS Config in all regions and accounts via AWS Organizations delegated administrator. Select a conformance pack matching your compliance requirements: CIS AWS Foundations Benchmark (recommended starting point for general security), NIST 800-53, or PCI DSS. Conformance packs deploy as CloudFormation stacks: aws configservice put-conformance-pack --conformance-pack-name CIS-Benchmark --template-s3-uri s3://aws-configservice-us-east-1/conformance-packs/CIS_AWS_Foundations_Benchmark_Level2.yaml --delivery-s3-bucket your-config-bucket. Review Config Dashboard for NON_COMPLIANT resources. Enable auto-remediation for the specific rules that represent your highest-risk drift patterns (S3 public access, security groups with unrestricted ingress, EC2 instances with public IPs in private subnets).
Azure Policy: use Deny effects for critical security baselines
Assign the Azure Security Benchmark policy initiative to your subscriptions (this initiative covers the most critical security baselines and is maintained by Microsoft). For controls that represent critical drift risks, modify the policy effect from Audit to Deny: this prevents non-compliant resources from being created via the portal, CLI, or Terraform without exemption. Example: change the 'Storage accounts should restrict network access' policy from Audit to Deny so that new storage accounts cannot be created with public access enabled. Use Azure Policy exemptions for resources with legitimate exceptions, documenting the business justification and expiry date for each exemption. Monitor Azure Policy compliance via the Compliance blade in the Azure portal or via Azure Monitor alerts on compliance state changes.
GCP Organization Policy: constraints that prevent drift categories
GCP Organization Policy applies constraints at the organization, folder, or project level. Key constraints for drift prevention: constraints/compute.restrictPublicIp (prevents VM instances from having public IP addresses in specified projects), constraints/iam.disableServiceAccountKeyCreation (prevents creation of long-lived service account keys, a common credential sprawl source), constraints/storage.publicAccessPrevention (prevents GCS buckets from being made public), constraints/compute.vmExternalIpAccess (restricts which VMs can have external IPs). Apply these constraints at the organization level to enforce across all projects, then create folder-level exemptions for projects with legitimate requirements (public-facing web applications). gcloud org-policies set-policy policy.yaml applies constraints via the Organization Policy API.
Auto-remediation: fixing drift without manual intervention
Detection alone leaves a window between when drift occurs and when a human acts on the alert, and that window can be hours or days depending on team bandwidth. Auto-remediation closes that window by triggering a programmatic fix the moment a resource transitions to a non-compliant state. In AWS, Config remediation actions invoke Systems Manager Automation documents that execute specific fix procedures such as enabling S3 public access block or removing unrestricted security group ingress rules. For IaC-managed environments, a schedule-based Terraform drift detection job surfaces manual changes and either triggers automated revert or creates a tracked remediation ticket. The key design decision for each remediation is whether to execute automatically or require approval: automatic execution works well for low-impact fixes, while approval workflows are safer for changes that could affect production data access.
AWS: Lambda-triggered auto-remediation for critical drift
Create a Lambda function that receives AWS Config NON_COMPLIANT notifications via EventBridge and takes remediation action. Example for S3 bucket public access drift: the Lambda receives the Config rule finding, extracts the bucket name from the finding resource ID, calls s3.put_public_access_block(Bucket=bucket_name, PublicAccessBlockConfiguration={'BlockPublicAcls': True, 'IgnorePublicAcls': True, 'BlockPublicPolicy': True, 'RestrictPublicBuckets': True}), and sends a Slack notification with the bucket name, the drift detected, the remediation taken, and a timestamp. Configure with maximum safety by: limiting IAM permissions to the minimum required for the specific remediation, logging all remediation actions to CloudTrail and a dedicated S3 bucket, and requiring a manual approval step for remediations that affect production data (deleting IAM policies, removing database access).
Terraform: schedule-based drift detection and remediation tickets
For IaC-managed infrastructure, schedule nightly Terraform plan runs in CI: terraform plan -detailed-exitcode -out=drift.tfplan. Exit code 0 = no changes (no drift). Exit code 2 = changes detected (drift exists). When exit code 2: store the plan output as an artifact, parse the changed resources, create a Jira or GitHub issue with the drift details and the commands to remediate (terraform apply drift.tfplan after review), and notify the infrastructure team via Slack. For clearly unintentional drift (manual console changes by anyone other than the IaC pipeline), implement a 'drift tax' policy: any resource with detected drift that is not remediated within 5 business days is automatically reverted to its IaC state. This creates accountability for manual console changes without blocking emergency fixes.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Cloud configuration drift is continuous and inevitable without active detection and remediation. Deploy AWS Config conformance packs, Azure Policy initiatives, and GCP Organization Policy constraints to establish baseline compliance monitoring. Enable auto-remediation for the highest-risk drift patterns (public storage, unrestricted ingress, logging disabled) to reduce remediation time from hours to minutes. Implement the GitOps workflow (console read-only, all changes via IaC PR) to address the root cause of drift rather than just the symptoms. Run scheduled Terraform drift detection to catch any changes that bypassed the IaC workflow. The combination of detection, auto-remediation, and prevention reduces the average drift window from weeks to hours, significantly shrinking the attack surface available between compliance assessments.
Frequently asked questions
What is cloud configuration drift and why does it happen?
Cloud configuration drift occurs when the actual state of cloud infrastructure diverges from its intended secure baseline. It happens through: manual console changes made by engineers who need to fix something urgently and bypass the IaC workflow, automated processes (Lambda functions, scripts, CI/CD pipelines) that modify resources without updating the IaC baseline, permission creep where IAM policies are broadened temporarily and never reverted, and cloud provider changes to default settings that affect existing resources. Each change individually may seem minor, but accumulated drift means resources that passed a compliance assessment at deployment may be non-compliant within weeks without any intentional violation of policy.
How does AWS Config detect configuration drift?
AWS Config records a configuration snapshot whenever an AWS resource is created, modified, or deleted. Config Rules evaluate each resource change against a compliance rule and mark the resource as COMPLIANT or NON_COMPLIANT. AWS provides over 200 managed Config Rules for common security baselines (s3-bucket-public-read-prohibited, ec2-instance-no-public-ip, iam-password-policy, rds-storage-encrypted). Custom Config Rules use Lambda functions for rules not covered by managed rules. AWS Config Dashboard shows compliance status across all rules and resources in a single view. Config conformance packs bundle multiple rules into a deployment package that mirrors compliance frameworks (CIS AWS Foundations Benchmark, NIST 800-53, PCI DSS).
What is auto-remediation in AWS Config and how do I implement it?
AWS Config auto-remediation triggers an AWS Systems Manager Automation document when a resource transitions to NON_COMPLIANT. Example: when Config detects an S3 bucket with public access enabled (s3-bucket-public-read-prohibited NON_COMPLIANT), the auto-remediation action runs the AWS-DisableS3BucketPublicReadWrite automation document, which programmatically disables public access on the bucket. Configure auto-remediation in the Config console: select the Config Rule, click Edit, enable Remediation action, select the SSM Automation document, and configure whether remediation is automatic or requires approval. For destructive remediations (deleting security group rules, terminating instances), use manual approval workflows rather than fully automatic execution.
How does Azure Policy prevent and detect configuration drift?
Azure Policy evaluates resource compliance against defined policy rules continuously as resources are created or modified. Policy effects determine the action when a resource is non-compliant: Deny prevents non-compliant resources from being created or modified at all (the strongest drift prevention); Audit logs non-compliant resources without blocking them; DeployIfNotExists automatically deploys a remediation resource (e.g., enables diagnostic settings) when a resource is created without them. Azure Policy initiatives (policy sets) bundle multiple policies into a compliance package. The Azure Policy compliance dashboard shows compliance percentage per policy and per resource group. Policy enforcement blocks the console change that would create drift, making it the most effective approach for controlled Azure environments.
How does Terraform detect drift against the deployed infrastructure?
Terraform drift detection compares the Terraform state file (the last known deployed state) against the actual current state of cloud resources. Run terraform plan: Terraform queries each resource's current state via the cloud provider API and compares against what is recorded in state. Differences appear as changes in the plan output. Terraform Cloud and Terraform Enterprise offer scheduled drift detection: the platform automatically runs terraform plan on a defined schedule and notifies you of any detected drift without applying changes. Example CI/CD integration for drift detection: run terraform plan -detailed-exitcode in CI on a schedule; exit code 2 means drift was detected; route to a notification channel and create a drift remediation ticket.
What is the most common cloud configuration drift vulnerability pattern?
The most commonly drifted security configurations are: S3 bucket public access (enabled to 'temporarily' share a file, never reverted), security group rules (inbound 0.0.0.0/0 rules added for debugging, never removed), IAM policies and roles (permissions broadened to fix a production issue, never scoped back down), database snapshots made public for support troubleshooting, and CloudTrail or logging disabled for a test account that was promoted to production. These patterns share a common root cause: an urgent operational need leads to a configuration change that relaxes security, with the intent to revert later, but the revert never happens because the urgency has passed and the change is no longer top of mind.
How do I implement a GitOps workflow that prevents drift from accumulating?
The GitOps approach requires that all infrastructure changes go through version-controlled IaC (Terraform, Pulumi, CloudFormation) rather than the cloud console. Implementation steps: restrict console IAM permissions to read-only for all engineers except break-glass emergency access. Require all changes via pull request to the IaC repository. Run terraform plan on every PR and require approval before merging. Configure a CI/CD pipeline that applies Terraform on merge to main, ensuring the deployed state tracks the IaC state. Run daily drift detection (terraform plan with exit-code checking) to catch any changes that bypassed the workflow (emergency break-glass access, cloud provider default changes, automated processes). Alert on any detected drift and create a remediation ticket to either update the IaC to reflect the intentional change or revert the console change.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.