Request for a selector on the AWS::ECS::TaskDefinition kind in the AWS v3 integration that limits ingestion to task definitions currently referenced by an ECS service.

Today the integration lists task definitions with status ACTIVE and no family or service filter. AWS keeps every registered revision ACTIVE until it is explicitly deregistered, so the integration ingests an account's entire registration history rather than what is actually in use. Where CI registers a new revision per build, that history is the overwhelming majority of the data: in one real environment ~16k task definition records are ingested per account while only ~600 are referenced by an ECS service, and a single task definition family had accumulated more than 19,000 revisions.

The result is an ECS Task Definition blueprint that runs into the 20k entity limit, consumes licensed entity quota on revisions nobody can act on, and syncs slowly, since each revision requires its own DescribeTaskDefinition call.

Proposed: a configuration option on the task definition kind to ingest only revisions referenced by a synced ECS service, and optionally a family-level include/exclude selector for accounts that need a wider window than just the live revision.

Benefits:

Implementation note: the filter cannot rely on the ECS service relation already present on the task definition blueprint, which is empty in practice. The referenced set likely has to be resolved integration-side, by collecting task definition ARNs from the ECS services being synced and restricting the task definition kind to that set, rather than listing every ACTIVE revision and filtering afterwards.