- Newest
- Most votes
- Most comments
In AWS DataZone, the concept of domains is key to structuring and managing data across an organization. To answer your question, here's a breakdown of how domains and domain units work in AWS DataZone, and how data can be shared across them.
DataZone Domains A DataZone domain is essentially a logical boundary for organizing and governing data. Domains are typically aligned with business units, such as Sales, Marketing, or Finance. Each domain can manage and govern its own data assets and provide those assets to other domains via publishing and subscribing.
Sharing Data Across Domains Yes, it is possible to share data across DataZone domains. This is where the publish/subscribe model comes in:
Publishing Data: One domain (e.g., Sales) can publish its data assets to be accessible to other domains.
Subscribing to Data: Another domain (e.g., Marketing) can subscribe to those data assets to use them in their own context.
However, in practice, data sharing across domains can involve some complexity due to the need for proper permissions, governance, and data lineage tracking. DataZone uses data products (sets of data assets) as the unit of sharing, and these products can be published to the DataZone catalog, where other domains can discover and subscribe to them.
DataZone Domains and Business Areas You could structure your DataZone organization in two main ways depending on your use case:
Option 1: Separate Domains for Business Units If you are focusing on isolating data by business unit or department (e.g., Sales, Marketing, Finance), you can create multiple DataZone domains. This will allow different business areas to manage their data independently, but they can share data across domains by subscribing to the published data products from other domains.
For example:
The Sales domain could publish data products related to sales performance, customer information, etc. The Marketing domain could subscribe to the Sales data to use for campaigns, targeting, etc. In this case, the publish/subscribe model enables data flow between these domains.
Option 2: Single Domain with Domain Units Alternatively, if you want a simpler structure and don’t need strict separation, you could create a single DataZone domain for the entire organization and use domain units to represent departments or teams (e.g., Marketing, Sales, Finance). This approach would allow for more straightforward data sharing within a single domain while maintaining some level of organization.
For example:
The Sales team would create and manage its own data assets The Marketing team could subscribe to relevant data from Sales within the same domain. In this case, you wouldn't have the complex cross-domain data sharing but would still maintain logical separation of data by teams.
Best Practice for Demonstrating a Data Mesh For your Data Mesh demonstration, you could start by creating a single domain for simplicity. Within that domain, you can set up domain units for each business area (e.g., Sales, Marketing, Finance). This way, you can simulate the concept of a data mesh by allowing different teams to own and manage their own data (in separate domain units) while still being able to share data across these units.
When your demonstration expands, you can transition to multiple domains for each business unit, which would involve more complex governance, security, and data sharing mechanisms. regards, M Zubair https://zeonedge.com
Relevant content
- asked a year ago
- asked a year ago
- asked a year ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 10 months ago