Skip to content

PATTERN Cited by 1 source

Single-bus multi-account

Split ownership of an event-driven system along two orthogonal axes: one shared event bus lives in a central account owned by a platform / DevOps team, while service teams own their own accounts containing their application stacks (publishing code, consumer code, business logic). Logical separation between service teams happens via rules on the bus, not via account boundaries.

Shape

  • Central DevOps account owns:
  • The event bus itself.
  • Cross-account resource policies admitting per-team accounts to publish/consume.
  • Routing rules matching events to targets.
  • Target configurations (Lambda / SQS / SNS / cross-account event bus / API destinations).
  • Monitoring, alerting, compliance checks on the event flow.
  • Per-service-team accounts own:
  • Application stacks (business logic, storage, compute).
  • Publisher code using the shared client library.
  • Subscriber infrastructure provisioned via reusable constructs.
  • Their own IAM, quotas, cost center.
  • Schema registry (custom or EventBridge-native) spans accounts as a shared artifact — both central and service-team accounts consume it.

Why this split

Named benefits (Amazon Key):

  1. Clear ownership boundaries. Service teams focus on business logic; platform team focuses on the bus + routing surface. No ambiguity about who owns what when something breaks.
  2. Centralized governance. Consistent routing patterns + security controls + monitoring applied once, inherited by every service team.
  3. Simplified operations. One event bus instead of N buses per team; logical separation via rules keeps mental model tractable.
  4. Enhanced security. Multi-account is AWS's natural isolation boundary; cross-account event flows are explicitly authorized via resource policies, not implicit.
  5. Streamlined compliance. Centralized data-exchange patterns make it easier to implement + maintain compliance requirements (PII handling, audit trails, data-residency); one audit surface, not N.

AWS reference

AWS ships an official single-bus multi-account pattern as a reference architecture — resource policies, IAM permissions, and CDK samples.

Variants

  • Single-bus single-account (simplest; fine for small orgs).
  • Multi-bus multi-account (per-team buses + bus-to-bus replication; maximum isolation but duplicates governance + rules across buses; the anti-pattern the single-bus model addresses).
  • Federated buses (multiple regional / domain buses under one governance model; a middle ground for very large orgs).

Tradeoffs

  • Central team is a governance bottleneck for new rules + target changes. Mitigated by self-service tooling (+ code review) so service teams can propose changes via PR rather than ticket.
  • Cross-account resource policy complexity. Requires careful IAM design; bugs here are silent authorization failures that manifest as "events mysteriously not delivered".
  • Single bus = single compliance scope. A single misconfiguration can leak across accounts; this is why centralized automated compliance checks are named as load-bearing — Amazon Key reports "100% unauthorized data exchange patterns" caught automatically.
  • Not a substitute for data-plane isolation. PII / restricted-data streams should still go on separate buses with stricter access control; single-bus + rules is for the common case.

Seen in

Last updated · 200 distilled / 1,178 read