Summary
SSMAssociation does not currently expose custom properties through a
Properties() method. As a result, configuration filters cannot match individual
SSM associations by name, document, targets, or tags.
The filter handler also reports that SSMAssociation does not support custom
properties.
Current behavior
SSMAssociation exposes only its association ID through String(). Users who
need to protect a particular association from deletion must exclude the entire
SSMAssociation resource type, which also prevents cleanup of every other
association.
For example, filters like these cannot currently be used:
filters:
SSMAssociation:
- property: AssociationName
type: exact
value: install-monitoring-agent
- property: DocumentName
type: glob
value: AWS-*
- property: tag:Environment
type: exact
value: production
Proposed change
Implement Properties() types.Properties for SSMAssociation and expose:
AssociationId
AssociationName
DocumentName
- Legacy target instance ID, when available
- Association targets and target maps
- Target instance IDs derived from association targets, when available
- Resource tags as
tag:<Key> properties
Tags should be retrieved while listing associations using
ListTagsForResource with ResourceType=Association.
These properties should support the standard exact, contains, glob, and regex
filter types.
Error handling
Associations without a name, targets, or tags should remain listable and should
not cause nil-pointer errors.
If tag retrieval fails for one association, listing should log a warning and
skip only that association. Returning associations without their tags could
cause tag-based filters to be evaluated incorrectly, while aborting the entire
listing would cause all associations to evade cleanup.
This follows the per-resource enrichment error-handling guidance tracked in
#907.
Expected outcome
Users can protect individual SSM associations while continuing to clean up
unmatched associations, and filtering no longer reports that
SSMAssociation lacks custom-property support.
Summary
SSMAssociationdoes not currently expose custom properties through aProperties()method. As a result, configuration filters cannot match individualSSM associations by name, document, targets, or tags.
The filter handler also reports that
SSMAssociationdoes not support customproperties.
Current behavior
SSMAssociationexposes only its association ID throughString(). Users whoneed to protect a particular association from deletion must exclude the entire
SSMAssociationresource type, which also prevents cleanup of every otherassociation.
For example, filters like these cannot currently be used:
Proposed change
Implement
Properties() types.PropertiesforSSMAssociationand expose:AssociationIdAssociationNameDocumentNametag:<Key>propertiesTags should be retrieved while listing associations using
ListTagsForResourcewithResourceType=Association.These properties should support the standard exact, contains, glob, and regex
filter types.
Error handling
Associations without a name, targets, or tags should remain listable and should
not cause nil-pointer errors.
If tag retrieval fails for one association, listing should log a warning and
skip only that association. Returning associations without their tags could
cause tag-based filters to be evaluated incorrectly, while aborting the entire
listing would cause all associations to evade cleanup.
This follows the per-resource enrichment error-handling guidance tracked in
#907.
Expected outcome
Users can protect individual SSM associations while continuing to clean up
unmatched associations, and filtering no longer reports that
SSMAssociationlacks custom-property support.