# A Resource Your Tags Cannot See Is a Resource Your Rules Cannot Touch > Tags are the join key of cloud governance. Source: https://zop.dev/resources/blogs/ecr-repositories-discovered-with-aws-tags Published: 2026-07-24 · Author: riya-mittal · Tags: aws, cloudgovernance, sre, database --- Tags are the join key of cloud governance. A resource discovered without them is not just missing labels, it is missing from every policy those labels drive. Amazon ECR was that resource. ZopNight now discovers ECR repositories with their AWS tags, so your container registries join the same governance as the rest of your fleet. ## Tags are the join key for governance Almost everything you do to manage a cloud at scale routes on tags. [Cost attribution](https://zop.dev/resources/blogs/smart-tags-derived-cost-attribution) groups spend by tag. Rules decide what to act on by tag. Filters select what you are looking at by tag. Tags are how a policy written once finds the resources it applies to, without anyone naming each one. So a resource that arrives in your inventory without its tags is not a small metadata gap. It is invisible to the attribution that would bill it to a team, to the rules that would act on it, and to the filters that would surface it. It runs and it bills, sitting just outside the reach of the systems meant to govern it. Architecture diagram ## ECR was the resource that opted out ZopNight already discovered EC2 instances and RDS databases with their AWS tags, so those [resource types](https://zop.dev/resources/blogs/sagemaker-run-duration-costing-not-monthly) flowed into tag-based cost attribution, filtering, and rule routing without a second thought. Amazon ECR repositories came in without their tags. The registries were in your inventory, but the tag-driven governance that covered compute and databases skipped them. Now ZopNight discovers ECR repositories with their AWS resource tags. The same attribution, filtering, and rule routing that already worked for EC2 and RDS applies to ECR too. Existing repositories are not a [special case](https://zop.dev/resources/blogs/observability-bill-cardinality-limit-one-knob): they pick up their tags on the next discovery run, with nothing to backfill by hand. ## What tags on ECR turn back on The change is small to state and wide in effect, because it reconnects one resource type to three systems at once. | Tag-driven system | ECR before | ECR now | |---|---|---| | Cost attribution | Unattributed | Grouped by tag, like EC2 and RDS | | Rule routing | Skipped | Rules match and act | | Filtering | Not selectable by tag | Selectable by tag | | Existing repositories | No tags | Tags on next discovery run | ## When it matters, and when it does not If you do not tag your resources, or you do not run tag-based attribution and rules, this changes nothing for you: there was no join key to miss. It matters when tags are how you actually run governance. There, a whole resource type discovered without them is the most dangerous kind of gap, a [blind spot](https://zop.dev/resources/blogs/event-driven-discovery-from-cloud-audit-logs) sitting exactly where you assumed you had coverage. Closing it means the reports, rules, and filters you already trust now tell the truth about your container registries too.