Skip to main content

Clean-up failure: Elasticache default.iam-user / default.iam-user-group

Clean-up failure: Elasticache default.iam-user / default.iam-user-group

This page describes a specific account clean-up failure caused by AWS-managed default Elasticache resources, how to recognise it in the logs, and how to fix it.

Symptom

The account clean-up (AWS Nuke) CodeBuild job fails, and the account is moved to Quarantine. In the nuke log, the scan completes with only two nukeable resources, both of which are AWS-managed Elasticache defaults:

Scan complete: 279 total, 2 nukeable, 277 filtered.

would remove  ElasticacheUserGroup  default.iam-user-group
would remove  ElasticacheUser       default.iam-user

Nuke then retries the deletion a few times and finally aborts with a fatal error:

InvalidParameterValue: User group id must begin with a letter; must contain only ASCII
letters, digits, and hyphens; and must not end with a hyphen or contain two consecutive hyphens.

InvalidParameterValue: User id must begin with a letter; must contain only ASCII letters,
digits, and hyphens; and must not end with a hyphen or contain two consecutive hyphens.

fatal: failed

Cause

default.iam-user and default.iam-user-group are AWS-managed default Elasticache resources that are created automatically when ElastiCache (or its service-linked role) is first used in a region. They cannot be deleted — the ElastiCache API rejects the delete call because the resource name contains a dot (.), which violates the naming rules the delete API enforces.

AWS Nuke has built-in handling that automatically skips the plain default Elasticache user:

filtered: cannot delete default user   default   ElasticacheUser

However, nuke does not have built-in handling for the IAM-authentication defaults (default.iam-user / default.iam-user-group). These only get skipped if the nuke configuration explicitly filters them. If the config in effect for the account is missing those filters, nuke treats them as deletable, repeatedly fails, and the whole clean-up aborts — even when every other resource in the account filtered cleanly.

Note: This typically appears after AWS enables ElastiCache IAM-auth defaults in an account/region. Because they are created automatically, an account that cleaned up fine previously can start failing without any user action.

Fix

Add the following filters to the Nuke configuration used by the failing deployment (stored in AWS AppConfig as the NukeConfig hosted configuration). The filters can be placed in the relevant presets/global filter block or in the per-account filters block:

      ElasticacheUser:
        # AWS-managed default Elasticache user; cannot be deleted (the delete API
        # rejects the "default.iam-user" name), causing nuke to fail fatally.
        - type: exact
          value: default.iam-user
        - property: UserName
          type: exact
          value: default.iam-user
      ElasticacheUserGroup:
        # AWS-managed default Elasticache user group; not deletable.
        - type: exact
          value: default.iam-user-group

Once the filters are in place, the scan reports these resources as filtered instead of nukeable, and the clean-up completes successfully.

Verifying the fix

  1. Confirm the live NukeConfig AppConfig hosted configuration version contains the ElasticacheUser and ElasticacheUserGroup filters above.
  2. Re-run the clean-up for the quarantined account (see Resolving clean-up failures).
  3. In the new nuke log, confirm the two resources now appear as filtered, for example: 
    filtered: filtered by config   default.iam-user        ElasticacheUser
filtered: filtered by config   default.iam-user-group  ElasticacheUserGroup
  4. Confirm the job finishes without fatal: failed and the account returns to the pool.

Important: check which config the job actually used

The clean-up CodeBuild job retrieves its nuke config from AWS AppConfig at run time (see the Retrieving nuke config file from AWS AppConfig step in the build log). If a clean-up is still failing even though a NukeConfig version containing the fix exists, confirm that the deployment/environment the failing job pulls from is the one that carries the fix — the Hub account running the clean-up may be reading a different AppConfig application/environment than the one that was updated. The cat nuke-config.yaml output near the top of the build log shows exactly which filters were in effect for that run.

  • Resolving clean-up failures
  • Investigating accounts in Quarantine state
Back to top