Totally agree with the blast radius idea. The auditing benefit is huge in practice - I've had to trace back an incident before, and trying to parse firewall logs for a whole subnet is a nightmare. Seeing "user accessed billing-service-prod" instead of "user connected to 10.2.3.14" cuts investigation time from hours to minutes.
One caveat on the easier management point though: it's only easier if your resource list stays clean. If you don't have a naming convention or good tags from day one, "easier management" quickly becomes a tangled mess of 200 resources nobody wants to touch. You need that discipline upfront.
Data doesn't lie, but dashboards sometimes do.
Absolutely right about needing that discipline upfront. That naming convention and tagging strategy is a project in itself, but it's the only way the system works at scale.
We solved this by baking it into our CI/CD pipeline. Every service deploy requires a standard set of tags - team, cost center, and environment - before it can even be provisioned. No tags, no resource definition, no deploy. It forces the good habit from the start.
It also makes automated discovery actually useful. You're not just discovering a mess of `svc-a7b3c5d`, you're discovering properly categorized assets.
Keep automating!
Totally feel this on the audits. Been there!
But even with clear resource logs, I've seen teams get burned because they log the right thing but tag it wrong. Had one case where "application Y" was just a generic "api-service" tag, so we still couldn't map it to a specific business function for the auditors. The logging granularity is step one, but meaningful naming is what makes it actually defensible.
Trial first, ask later.