Amazon SageMaker AI now supports synchronizing Managed MLflow model registrations across AWS accounts, and the latest blog post adds two cross‑account topologies. The hub‑and‑spoke pattern shares a single MLflow instance via AWS Resource Access Manager, while the hybrid pattern isolates each development account and promotes models through a local approval step before they reach the central hub. Both approaches extend the single‑account workflow from Part 1 to multi‑account environments.
Persona Overview
The expanded model‑governance flow introduces two additional roles. The administrator performs the one‑time configuration: creating RAM shares, adjusting bucket policies, and defining destination groups. In the hybrid layout a model owner in each development account validates models locally before they are promoted. Existing roles – the data scientist who registers models through MLflow and the governance officer who approves them in the SageMaker Studio UI – remain unchanged.
Hub‑and‑Spoke Cross‑Account Governance
In this topology a single SageMaker Studio domain hosts the Managed MLflow app in the hub account. The hub creates a RAM resource share that includes the MLflow endpoint and underlying storage. Each spoke account accepts the share, gaining read‑write access to the shared MLflow service. When a data scientist in a spoke registers a model, the automatic registration feature creates a Model Package Group and version in the hub account instantly. The hub then attaches a resource policy granting the AllowDeploy managed permission back to the spoke, enabling deployment without additional manual steps. Governance officers retain central visibility and can approve models directly in the hub registry.
Hybrid Isolation Topology
The hybrid pattern keeps the development accounts completely separate from the hub. Each development account runs its own Managed MLflow instance and registers models locally. A model owner reviews and approves a model, after which a promotion workflow copies the model metadata to the hub’s SageMaker Model Registry. The hub’s governance officer then performs the final approval, triggering a CI/CD pipeline that deploys the model to a production endpoint. This approach satisfies regulated environments that forbid any write‑back from development to production accounts.
Operational and Security Implications
Both topologies rely on IAM condition keys and RAM resource shares to enforce separation of duties. The hub‑and‑spoke model reduces operational overhead by centralizing the MLflow service, but it requires careful bucket policy configuration to prevent unintended data leakage between spokes. The hybrid model adds extra steps for model promotion, increasing latency but providing a clear audit boundary. CI/CD pipelines must be configured to react to approval events in the SageMaker Model Registry, ensuring that only vetted models reach production. Practitioners should verify that the resource policies attached to Model Package Groups correctly limit Describe and Deploy actions to authorized spokes.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Choose the hub‑and‑spoke pattern if you need a shared MLflow service and can manage cross‑account bucket policies. Opt for the hybrid pattern when regulatory constraints demand strict isolation of development workloads. In either case, confirm that IAM condition keys, RAM shares, and Model Registry policies align with your organization’s separation‑of‑duties requirements, and integrate the approval events into your existing CI/CD tooling to automate safe model promotion.
