Describe the outcome you'd like
The existing per-account AFT customization pipelines should support a scheduled execution mode that runs terraform plan only (no apply) to detect configuration drift in vended accounts.
This can be achieved by introducing an environment variable (e.g., TF_ACTION) that controls whether the pipeline runs in plan or apply mode:
Scheduled trigger (EventBridge): starts the pipeline with TF_ACTION=plan — runs terraform plan -detailed-exitcode, fails the pipeline if drift is detected (exit code 2), enabling notification via existing mechanisms.
Normal provisioning trigger (AFT Step Functions / source changes): starts the pipeline with TF_ACTION=apply (or defaults to apply when unset) — behavior unchanged from today.
The schedule should be:
Configurable (default: weekly, e.g., cron(0 6 ? * MON *))
Automatically applied to all per-account pipelines
Drift detection failures should trigger notifications
Is your feature request related to a problem you are currently experiencing? If so, please describe.
Once an account is provisioned via AFT, there is no continuous validation that the account's actual state still matches the customizations defined in aft-global-customizations and aft-account-customizations. Manual changes, upstream module updates, or state divergence go undetected until the next provisioning event.
There is no scheduled mechanism to surface drift, which means compliance gaps can persist indefinitely without visibility.
Additional context
CodePipeline V2 supports pipeline-level variables that can be set at execution time — EventBridge can pass TF_ACTION=plan when triggering.
The buildspec logic would be a simple branch:
bash
if [[ "${TF_ACTION:-apply}" == "plan" ]]; then
terraform plan -no-color -detailed-exitcode
# exit 1 if changes detected (drift)
else
terraform apply -no-color --auto-approve
fi
This reuses existing pipeline infrastructure — no duplicate pipelines needed, just a mode toggle.
Only incremental cost is the additional CodeBuild execution minutes from scheduled runs.
Automatic remediation (auto-apply on drift) is out of scope — this is detection and notification only.
Describe the outcome you'd like
The existing per-account AFT customization pipelines should support a scheduled execution mode that runs terraform plan only (no apply) to detect configuration drift in vended accounts.
This can be achieved by introducing an environment variable (e.g.,
TF_ACTION) that controls whether the pipeline runs in plan or apply mode:Scheduled trigger (EventBridge): starts the pipeline with
TF_ACTION=plan— runs terraform plan -detailed-exitcode, fails the pipeline if drift is detected (exit code 2), enabling notification via existing mechanisms.Normal provisioning trigger (AFT Step Functions / source changes): starts the pipeline with
TF_ACTION=apply(or defaults to apply when unset) — behavior unchanged from today.The schedule should be:
Configurable (default: weekly, e.g.,
cron(0 6 ? * MON *))Automatically applied to all per-account pipelines
Drift detection failures should trigger notifications
Is your feature request related to a problem you are currently experiencing? If so, please describe.
Once an account is provisioned via AFT, there is no continuous validation that the account's actual state still matches the customizations defined in aft-global-customizations and aft-account-customizations. Manual changes, upstream module updates, or state divergence go undetected until the next provisioning event.
There is no scheduled mechanism to surface drift, which means compliance gaps can persist indefinitely without visibility.
Additional context
CodePipeline V2 supports pipeline-level variables that can be set at execution time — EventBridge can pass
TF_ACTION=planwhen triggering.The buildspec logic would be a simple branch:
bash
This reuses existing pipeline infrastructure — no duplicate pipelines needed, just a mode toggle.
Only incremental cost is the additional CodeBuild execution minutes from scheduled runs.
Automatic remediation (auto-apply on drift) is out of scope — this is detection and notification only.