Skip to content

chore(devops): add teardown script for v2-v3 redirect monitoring - #2690

Open
dougmartin wants to merge 2 commits into
mainfrom
v2-v3-redirect-monitoring-teardown
Open

chore(devops): add teardown script for v2-v3 redirect monitoring#2690
dougmartin wants to merge 2 commits into
mainfrom
v2-v3-redirect-monitoring-teardown

Conversation

@dougmartin

Copy link
Copy Markdown
Member

Adds devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh, the reverse of deploy-monitoring.sh. It removes the cutover soak dashboard, its five alarms, the error-fallthrough metric filter, both Synthetics canaries along with their generated cwsyn-* Lambdas and log groups, the canary artifact bucket, and the canary execution role.

The script sources config.env for the function name, artifact bucket, and role ARN so those values are not duplicated from the deploy script. Canary Lambda log groups are discovered by prefix rather than by exact name, which also catches the orphans left behind by earlier canary generations (Synthetics leaves a log group per generation when a canary is replaced by delete-and-recreate). A RUNNING canary cannot be deleted, so the script stops it and polls until the state settles before deleting.

The redirect itself is out of scope. The CloudFront function, the clone distribution, the temp subdomain, and the Route 53 records are untouched, and the function's own log group is kept because the live function still writes to it: only the metric filter on that log group is removed.

The script defaults to a dry run that prints every AWS call it would make; deletion requires an explicit --apply.

Related to the redirect work tracked in CODAP-1323.

Reverses deploy-monitoring.sh, removing the cutover soak dashboard, its five
alarms, the error-fallthrough metric filter, both Synthetics canaries with their
generated Lambdas and log groups, the canary artifact bucket, and the canary
execution role.

Sources config.env for the function name, artifact bucket, and role ARN so those
values are not duplicated from the deploy script. Discovers the canary Lambda log
groups by prefix, which catches the orphans left by earlier canary generations.

Defaults to a dry run; deletion requires an explicit --apply.

The redirect itself is out of scope: the CloudFront function, clone distribution,
temp subdomain, and Route 53 records are untouched, and the function's own log
group is kept since the live function still writes to it.
@dougmartin
dougmartin requested a balanced review from Copilot September 3, 2026 12:19
@dougmartin
dougmartin marked this pull request as ready for review September 3, 2026 12:20

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

AWS discovery failures can be suppressed, and canary deletion may proceed after a stop timeout.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a dry-run-by-default script for removing V2-to-V3 redirect monitoring resources.

Changes:

  • Removes CloudWatch monitoring and Synthetics resources.
  • Preserves redirect infrastructure and the function log group.
  • Supports destructive execution via --apply.
File summaries
File Description
devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh Implements monitoring teardown and resource discovery.
Review details

Suppressed comments (2)

devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh:138

  • The same process-substitution behavior suppresses failures from list-attached-role-policies, so the script can skip required detaches and only surface a later DeleteConflict. Capture the listing before passing it to mapfile so the actual AWS error stops the script.
  mapfile -t ATTACHED_POLICIES < <(
    aws iam list-attached-role-policies --role-name "$role_name" \
      --query "AttachedPolicies[].PolicyArn" --output text | tr '\t' '\n'

devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh:130

  • A failure from list-role-policies is hidden by process substitution because mapfile itself still succeeds. The teardown then proceeds without deleting discovered inline policies and fails later with a less useful DeleteConflict; capture the AWS output in a normal command substitution so set -e preserves the original failure.
  mapfile -t INLINE_POLICIES < <(
    aws iam list-role-policies --role-name "$role_name" \
      --query "PolicyNames" --output text | tr '\t' '\n'
  • Files reviewed: 1/1 changed files
  • Comments generated: 2
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh Outdated
Comment thread devops/cloudfront-functions/v2-v3-redirect/teardown-monitoring.sh Outdated
@dougmartin
dougmartin requested a review from kswenson September 4, 2026 20:36
mapfile returns success regardless of what the command feeding it did, so a
failed AWS listing was indistinguishable from an empty one. A denied or
throttled describe-log-groups or IAM list call left its resources in place
while the script ran to completion and exited 0. Capture each listing in a
command substitution first so set -e aborts on the original error.

Wait for a canary to reach a state delete-canary accepts rather than only
polling a RUNNING one, and fail with an explicit message when it has not
settled before the deadline. Previously the poll could expire with the canary
still running and fall through to a delete that AWS rejects, aborting the
teardown partway with a bare ConflictException. A canary found already
STOPPING skipped the wait entirely and hit the same rejection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants