ICYMI, Lambda can subscribe to DynamoDB streams in another account. Previously, if you had Lambda in account A and a DynamoDB table in account B, you had to either duplicate the table, forward events via EventBridge, or build your own streaming mechanism. All of which meant extra work, extra latency, extra cost, and more things that can break. Now you just set a resource-based policy on the DynamoDB Stream, and the Lambda function in account A reads from it directly. This is great for many multi-account environments! BUT, think carefully before you wire cross-account services directly to each other's storage layers. When service A reads directly from service B's DynamoDB Stream, you've created tight coupling between them. What happens when team B decides to switch from DynamoDB to Aurora, or moves to an event-driven model with EventBridge? Now they can't refactor their storage without breaking every consumer in every other account. They've leaked an implementation detail across an account boundary. But it gets worse... because there's also schema coupling between the two services. Team B can't even refactor the schema of the data they save to their own table without risking breaking other teams' services. Yikes! Ultimately, this pattern works well when the two accounts are owned by the same team, or when the stream is genuinely a stable public interface (e.g. a platform team explicitly versioning their change feed). It's the wrong call to consume another team's internal table directly, as it creates tight coupling between the two teams. For genuine cross-team integrations, EventBridge or SNS is still the way to go, and the extra hop is worth the loose coupling.
If a DynamoDB stream could have more than 2 readers, I'd see more use for this. Because of the limit, I'd probably use an SNS topic as the reader if I need multi-account fan out.
The pattern described here maps exactly to what the Anti-Corruption Layer addresses in distributed system design. When service A consumes service B's DynamoDB Stream directly, it forces A to understand B's internal data model — every field name, every type, every schema decision. The Anti-Corruption Layer pattern solves this by putting a translation boundary between the two: B publishes a stable, intentionally designed event contract via direct access Lambda access, EventBridge or SNS, and A consumes that contract without ever touching B's storage schema. It will give team B the freedom to refactor their internals without coordinating with every consumer across every account.
Uriel Bitton
1w
This is very valuable for larger teams with different accounts per environnement
Convenience now vs flexibility later
Datadog•8K followers
1wThis honestly feels like a feature AWS shouldn't have built. Have we not learned the lesson of reaching directly into another database is almost always a bad idea 😂