Beyond IAM: observability and governance for multi-team Amazon MSK

Most Amazon MSK conversations about access control stop at IAM: who can connect, and what actions they can take on which resources. That covers the perimeter, but it does not answer what teams need once a cluster is genuinely shared: who actually produced a message, which consumer group is lagging and why, and whether a schema change from one team’s service broke a topic another team depends on.

In this session, Chad Harris, Solutions Architect at Factor House, looks at the gap between what IAM policies enforce and what a multi-team Amazon MSK cluster needs in practice. Drawing on his experience helping enterprise customers manage and govern shared Kafka infrastructure, Chad walks through the observability and governance patterns that let teams operate independently on a cluster they do not own outright.

You will leave with a clearer picture of where IAM’s coverage ends, what to put in its place, and how to introduce governance incrementally without slowing teams down or forcing a move to per-team clusters.

What the session covers

• Where IAM policies stop and operational visibility needs to begin
• Giving teams self-service access to their own topics, consumer groups, and connectors without exposing the rest of the cluster
• Audit trails for administrative changes across a shared MSK cluster
• Rolling out governance incrementally, starting with visibility before tightening access

This is a technical session aimed at platform engineers and data engineers running Amazon MSK for more than one team.