Azure ML Registry
Does ZopNight manage Azure ML Registry?
Azure ML registries share models, components, and environments across workspaces and regions, with storage as their only meaningful cost. ZopNight inventories registries through the AML enricher for cross-workspace topology: which of 2, 10, or 50 workspaces consume a model matters more than the modest storage the registry itself holds.
Rules that fire on Azure ML Registry
No active rule family targets Azure ML Registry today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only. |
ML registries share models, components, and environments across workspaces and regions. Cost impact is modest (storage), but registries map how models flow through an organization.
Storage-priced, topology-valuable
A registry’s direct bill is the storage behind the model versions, components, and environments it holds. That is real spend, but rarely the number that matters. Its significance in a cost platform is structural: the registry is the organizational map of which models exist, which versions are canonical, and which workspaces and regions consume them. When the question is “can we retire this serving deployment,” the registry is where the answer about downstream consumers lives.
Registry rows in ZopNight’s inventory
Discovered via the AML enricher for inventory and cross-workspace ML asset topology. Registries are the connective tissue between otherwise siloed workspace inventories: the same model appearing in several workspaces resolves to one registry asset, which is what lets serving spend be discussed per model rather than per copy.
Read-only by nature
There is nothing to stop: ZopNight scopes registries to discovery only. No schedule applies, and no ZopNight action mutates registry contents. The registry earns its place in the inventory as context that makes the compute and serving entries interpretable. A deployment is just a VM bill until the registry says which model, and which consumers, it exists for.
Registry hygiene worth doing anyway
Cost-adjacent rot accumulates here. Model versions pile up indefinitely, each pinning storage for artifacts nobody will redeploy. Environments reference container images that linger in registries of their own. And a registry shared across regions replicates assets whose consumers exist in only one. Small charges individually, unbounded collectively, and all invisible until someone lists what the registry actually holds.
Browsing a registry’s contents
Azure ML studio → Registries opens each registry’s models, components, and environments with their versions and sharing scope; the Azure portal’s Machine Learning registries blade shows the underlying resource and its region replication.