Om de paar maanden deelt een klant zijn frustraties over onvindbare, niet-interoperabele, geïsoleerde data en hoe alles een bottleneck wordt, of schetst hij zijn visie op bedrijfsbrede datatoegang. Ze willen governance per team en veilige AI-workloads die putten uit de assets van elke afdeling zonder privacy of compliance te schenden. Ze beschrijven de architectuur die ze voor ogen hebben, de problemen die ze zijn tegengekomen en de politiek waar ze doorheen navigeren. Dan zeggen wij: "Wat u beschrijft, zijn twee woorden: Data Mesh. Heeft u daar weleens van gehoord?"
Negen van de tien keer is het antwoord nee. Het is het patroon dat wij vaak implementeren voor onze klanten, maar degenen die het het hardst nodig hebben, hebben de term zelden gehoord. Deze gids is voor hen en voor iedereen die vermoedt dat het dataprobleem van hun organisatie een eigenaarschapsprobleem is, en geen technologieprobleem.
De Data Mesh op AWS SageMaker Unified Studio is architecturaal eenvoudig. AWS heeft het control plane geproduktiseerd. Wat het verschil maakt, is of uw organisatie gefedereerd eigenaarschap kan omarmen zonder bureaucratie te creëren. Deze gids behandelt wat Data Mesh betekent, hoe SageMaker Unified Studio het implementeert, de drie architectuurbeslissingen die alles downstream bepalen, en de organisatorische patronen die bepalen of uw mesh de confrontatie met de werkelijkheid overleeft.
Wat Data Mesh werkelijk betekent (en waarom uw CDO er waarschijnlijk nog nooit van heeft gehoord)
Data Mesh is geen technologie. Het is geen specifieke AWS-service. Het is geen vervanging voor uw data lake, en het is zeker geen reden om uw organigram van de ene op de andere dag te herstructureren. Het is een organisatiearchitectuur voor data-eigenaarschap: vier principes, geoperationaliseerd met behulp van technologie.
Die vier principes, zoals gedefinieerd door Zhamak Dehghani en conform de AWS Well-Architected Data Analytics Lens:
- Domeingeoriënteerd eigenaarschap. Data behoort tot het team dat het produceert, niet tot een gecentraliseerd "Data"-team dat probeert ieders assets te beheren.
- Data als product. Elk domein publiceert vindbare, kwaliteitsgecontroleerde datasets met gedefinieerde SLA's. Zie het als een intern API-contract, maar dan voor data.
- Self-serve dataplatform. Infrastructuur die domeinteams in staat stelt autonoom te opereren, zonder tickets aan te maken of te wachten op een centraal knelpunt.
- Gefedereerde computationele governance. Centrale standaarden, decentrale uitvoering. De regels komen van bovenaf; de implementatie ligt bij de teams.
Winston Churchill zei: "Wij geven vorm aan onze gebouwen; daarna geven zij vorm aan ons." Hetzelfde geldt voor de manier waarop bedrijven hun teams structureren. Als uw bedrijf mensen groepeert op technische specialisatie (een "Data"-team dat alle bedrijfsdata beheert, ongeacht eigenaarschap), zal uw architectuur die centralisatie weerspiegelen. Het loopt snel uit de hand naarmate bedrijven groeien. Data Mesh keert dit om.
De analogie die het meest resoneert bij technische doelgroepen is domain-driven development. U begrijpt het groeperen van code per businessdomein: een Payments-module, niet "alle Python-scripts" of "alle Stripe-gerelateerde bestanden." Data Mesh past hetzelfde principe toe op data-assets. Amazons beroemde two-pizza-teams volgen hetzelfde idee: kleine, autonome, cross-functionele, resultaatgerichte groepen die hun domein end-to-end beheersen.
Net zoals applicatie-architectuur evolueerde van monolithische naar microservices-architecturen, modulariseren datateams hun platformen naar gefedereerde, decentrale oplossingen. De AWS Well-Architected Framework Data Analytics Lens trekt expliciet deze parallel.
Waarom missen ervaren CDO's dit? Omdat het concept denken op een ander abstractieniveau vereist. Het gaat niet om nieuwe tools, maar om wie wat bezit en waarom. Die cognitieve verschuiving is moeilijk, zelfs voor mensen die al tientallen jaren met data werken. Het is vooral lastig voor datamanagers die dichter bij de hands-on-implementatie zitten op het management-uitvoeringsspectrum.
Hoe SageMaker Unified Studio Data Mesh implementeert
AWS SageMaker Unified Studio, algemeen beschikbaar sinds maart 2025, is AWS' concrete implementatie van de Data Mesh-principes. Het zit bovenop SageMaker Catalog (de evolutie van Amazon DataZone), Lake Formation, de Glue Data Catalog en Athena. Samen vormen deze het control plane voor een gefedereerde data-architectuur.
De hiërarchie: domains, domain units, projects
De volledige structuur mapt direct op de organisatorische realiteit:
AWS Account → Domain(s) → Domain Unit(s) → Project(s) → Member(s)
Een domain vertegenwoordigt een grote business line. De meeste bedrijven hebben er slechts één nodig. De uitzonderingen zijn grote, gediversifieerde ondernemingen, zoals Siemens, waar aparte domeinen voor energie, consumentenelektronica en transport logisch zouden zijn. Toen wij de event-driven datapipeline voor Siemens Energy bouwden, werd de cross-accountarchitectuur natuurlijk op hun divisiestructuur afgestemd, een patroon dat Data Mesh formaliseert. Als vuistregel: domains mappen op de grote business lines van bedrijven die hun handen hebben in veel losjes gerelateerde activiteiten.
Het aanbevolen ontwerp is één governance-domain dat geen data of domain units bevat en uitsluitend dient als control plane voor de mesh. Hier worden regels en best practices afgedwongen. Andere datarijke domains worden onboarded om deel te nemen. Dataproducenten hebben data-eigenaren en engineers. Dataconsumenten omvatten data engineers, rapportbouwers en data scientists. Houd indien mogelijk het AWS-governanceaccount gescheiden van de overige accounts. Anders plaatst u ze naast elkaar in één AWS-account.
Domain units zijn organisatorische onderverdelingen binnen een domain, zoals afdelingen, teams en capabilities. Hier bevindt zich het grootste deel van de structuur.
De vuistregel: één governance-domain, één root business domain met veel domain units en veel projecten per domain unit. Vervolgens wordt deze structuur herhaald in development-, UAT- en productie-accounts.
Projects als werkeenheid
Een projectteam is geen permanent team. Het is een cross-functionele doorsnede van mensen uit verschillende fysieke teams, gegroepeerd rond een specifiek bedrijfsdoel. Leden zijn Contributors of Owners en ze komen en gaan naarmate het project hen nodig heeft.
Dit is waar de weerstand tegen de vraag "Wilt u dat ik een data engineer aanneem voor elke afdeling?" sneuvelt. Data engineers voegen zich tijdelijk bij een specifiek project, configureren de benodigde mechanismen en vertrekken weer om terug te keren wanneer het eigenaarsteam hulp nodig heeft. Dezelfde mensen als vandaag. Andere abstractieniveaus.
Projects omvatten de middelen die nodig zijn om hun bedrijfsdoelen te bereiken: een Data Lakehouse voor databronnen, ETL-tools (scripts, notebooks, Airflow-orchestratie) voor verwerking en migratie, en MLflow-trackingservers voor data science-werkzaamheden. Elk project selecteert blueprints die deze resources provisioneren, en wij raden sterk aan om alle blueprints op ONDEMAND te zetten in plaats van ONCREATE (zie de kostensectie hieronder voor meer details).
Een corporate domain gebruikt de Tooling-blueprint; een persoonlijk IAM-domain gebruikt de nieuwere, maar minder capabele ToolingLite. De verschillen tussen deze twee en wanneer welke te gebruiken zijn zijn een onderwerp voor een volgend artikel in deze serie.
De catalogus: producer/consumer-patroon
De Data Mesh komt tot leven door het producer/consumer-patroon, dat direct mapt op de Well-Architected referentiearchitectuur:
- Producer-projects publiceren data-assets naar SageMaker Catalog, compleet met metadata, glossaristermen, kwaliteitsinformatie en lineage.
- Consumer-projects abonneren zich op die assets en bevragen ze via Athena vanuit Unified Studio.
- Lake Formation dwingt partitie-level toegang af en fungeert als governance-laag tussen producers en consumers.
Elke laag (producer, governance, consumer) bevindt zich in een eigen AWS-account, conform de Well-Architected-richtlijnen. Deze best practice is niet altijd haalbaar. Veel bedrijven, zelfs grote, hebben workloads die hetzelfde AWS-account delen in plaats van gesegregeerd te zijn. De meest voorkomende conventie is één AWS-account per omgeving (dev/uat/prd).
Master Data producer-projects: onze aanbeveling
Wij raden aan om dedicated projects in te richten rondom kritieke databronnen, met "Master Data" in de naam: "CRM Master Data", "Website Analytics Master Data." Deze worden gevoed door een databron die door meerdere consumers wordt gebruikt binnen verschillende projecten.
Een nuance die verduidelijking verdient: elk project kan zowel dataproducent als dataconsument zijn. De meeste zullen dat ook zijn. Master Data-projecten zijn echter essentiële, atomaire bladeren. Doorgaans consumeren ze niet. Ze stellen één databron beschikbaar voor de mesh-catalogus. Het Well-Architected Framework raadt aan deze producers zo snel mogelijk op te zetten, maar de realiteit is genuanceerder. Wij kwamen uitzonderingen tegen: het polisbeheersysteem van een verzekeringsklant en zijn voorganger werden als aparte datasets beschikbaar gesteld, plus een samengevoegd overzicht dat het oude schema in het nieuwe terugpaste. Consumenten konden de polisrepository bevragen alsof er nooit een migratie had plaatsgevonden. De interne werking en historische zakelijke beslissingen werden afgeschermd, wat de koppeling vergemakkelijkte.
Alleen de data-eigenaren (de salesafdeling voor CRM en het marketingteam voor hun analytics) zijn permanente leden. Data engineers worden tijdelijk uitgenodigd om blueprints en verbindingen te configureren en vervolgens verwijderd te worden totdat ze weer nodig zijn. Deze Master Data-projecten stellen opgeschoonde datasets beschikbaar met vriendelijke namen, glossarytermen, metadata, beschrijvingen, lineage en kwaliteitsinformatie. Ze vormen de bouwstenen voor al het downstream analytics-, BI- en AI-werk.
Drie beslissingen die alles bepalen
Voordat u infrastructuurcode schrijft, bepalen drie beslissingen de complexiteit van uw implementatie, de granulariteit van uw governance en uw maandelijkse rekening.
Beslissing | Optie A | Optie B | Onze aanbeveling | Reden |
|---|---|---|---|---|
AWS-accountstrategie | Eén account per omgeving (dev/uat/prod) met alle domains & projects | Eén account per domain (bij multi-domain) of per project (bij uni-domain) | Eén per domain/project (elk dev/uat/prod) | Spiegelt de SDLC en respecteert de best practice van één AWS-account per workload + omgevingscombinatie. |
Identiteitsmodel | SSO via AWS Identity Center | IAM | SSO | Per-user granulariteit, traceerbaarheid, fijnmazige Lake Formation-governance, aanbevolen door AWS. |
Netwerkposture | Geen VPC (standaard) | Alleen VPC | Start open tenzij beleid anders vereist | Alleen-VPC voegt aanzienlijke complexiteit toe; bewijs de waarde eerst, verscherp later. |
1. AWS-accountstrategie
Het ideaal is één AWS-account per workload en per omgeving. Voor een uni-domain mesh betekent dat doorgaans één account per omgeving (dev/uat/prd), met de volledige domeinstructuur gerepliceerd in elk account. Voor multi-domainondernemingen krijgt elk domein (of zelfs elk groot project) zijn eigen set accounts. Het principe: isoleer de blast radius en spiegel uw SDLC.
Elk account heeft zijn eigen root domain. Ontwikkel de mesh als een applicatie: bouw in dev, promoveer naar UAT en deploy naar productie.
Verwar het environment-concept van AWS (binnen Unified Studio) niet met dev-, UAT- en prod-omgevingen. Dat zijn verschillende dingen. Elke SDLC-omgeving zal de volledige domeinstructuur hebben gerepliceerd.
2. Identiteitsmodel: SSO vs IAM
SSO via AWS Identity Center heeft de voorkeur. Het biedt per-user-granulariteit voor governance, traceerbaarheid en fijnmazige controle over datatoegang. SSO werkt waar IAM tekortschiet. De SageMaker Unified Studio AWS console blijft u vragen om SSO te configureren totdat u dat doet.
Het alternatief, IAM met gefedereerde groepen, verliest granulariteit. De kleinste toegangscontrole-eenheid wordt een groep, wat te grof is voor betekenisvolle datagovernance. Als uw bedrijf gefedereerde groepen zonder Identity Center verplicht stelt, offert u traceerbaarheid en per-user auditability op.
De politieke realiteit: SSO is vaak een van de moeilijkste dingen om klanten mee te laten ondersteunen. Hun handen zijn gebonden door mensen hoger in de hiërarchie. IAM-domeinen werken als IAM-gebruikers zijn toegestaan, maar dat is vaak niet gegarandeerd.
Wij zien regelmatig verwarring waarbij klanten IAM/SSO (infrastructuurtoegang, wie kan inloggen op de AWS-console) vermengen met Lake Formation (datagovernance, wie welke rijen en kolommen in tabellen mag zien). Dit zijn gescheiden toegangscontrolevlakken. De meeste technologen kennen IAM goed, maar zijn niet bekend met Lake Formation-concepten zoals rijgebaseerde toegang, kolomgebaseerde toegang, role-based access control (RBAC) of tag-based access control (TBAC). Elke implementatie begint met een whiteboard-sessie waarin dit onderscheid wordt uitgelegd.
3. Netwerkposture: alleen-VPC vs open
Alleen-VPC-domeinen zijn veiliger, maar vergroten de implementatiecomplexiteit aanzienlijk. Verwacht dat u VPC-service-endpoints moet configureren, security groups moet aanpassen en moet afstemmen met IT over netwerkwijzigingen. In organisaties die hub-and-spoke-architecturen gebruiken met Transit Gateways, waarbij spoke-VPC's geen internetverkeer hebben, neemt de complexiteit nog verder toe.
Als een alleen-VPC vereist is (door beleid of regelgeving), begin er dan meteen mee. Stel het niet uit. Het achteraf toevoegen van alleen-VPC aan een bestaande mesh is veel moeilijker dan het vanaf dag één inbouwen.
Voor eerste deployments waar alleen-VPC niet verplicht is, start met de standaard open posture, bewijs de waarde van de mesh en verscherp daarna. Maar alleen als dat werkelijk een optie is voor uw organisatie.
Een praktische verdediging tegen toekomstige beveiligingsscrutinie is het toevoegen van CDK NAG vanaf dag één. De overhead is reëel, maar geeft u een voorsprong wanneer (niet als) iemand vraagt: "Is dit gevalideerd tegen AWS best practices?"
Het operationeel model: waar implementaties slagen of falen
Technologie is verantwoordelijk voor ongeveer 30% van een Data Mesh-implementatie. De overige 70% is organisatorisch verandermanagement: rollen, eigenaarschap en de politiek over wie de data beheert.
Waarom domeinteams eigenaarschap afwijzen
De meest voorkomende weerstand is: "Wilt u dat ik een data engineer aanneem voor elke afdeling?" Managers horen "gedefedereerd eigenaarschap" en zien meteen headcountverzoeken voor elk team.
De herformulering: een projectteam kan flexibel zijn in plaats van permanent. Een datateam (de huidige "Data-afdeling") is een vaste groep mensen. Een project is een tijdelijke doorsnede van verschillende teams, samengesteld rond een bedrijfsdoel. Data engineers bestaan al. We nemen geen nieuwe aan. We groeperen dezelfde mensen per project op verschillende manieren. Als een team consequent een technisch lid bezighoudt, dan heeft u als manager een kritieke lokale behoefte ontdekt en kan het aannemen van een dedicated full-time employee (FTE) een goed idee zijn.
De wet van Conway garandeert dat uw huidige organisatiestructuur uw huidige architectuur produceert. Data Mesh keert dit om: groepeer op bedrijfsresultaat, niet op technische specialisatie.
De governance-paradox
Centrale governance definieert de standaarden: naamgevingsconventies, kwaliteitsdrempels, retentiebeleid en classificatieregels. Domeinteams implementeren en onderhouden de contracten voor hun eigen dataproducten.
Het moeilijkste is niet de technologie. Het is het overtuigen van stakeholders die paranoïde zijn over datatoegang om het eens te worden over wat "delen" betekent. Om hen te laten inzien dat het niet alles-of-niets is. De beveiligingsparadox duikt weer op: hoe minder volwassen de governance van een organisatie is, hoe hoger de lat die zij legt voor het nieuwe systeem.
Datacontracten en verantwoordelijkheid
Elk dataproduct heeft een gedefinieerd contract nodig: een schema, kwaliteitsregels, een versheids-SLA en een benoemde eigenaar. De Well-Architected Data Analytics Lens specificeert dat dataproducten autonoom, vindbaar, veilig en herbruikbaar moeten zijn.
De data steward-rol (conform de AWS-referentiearchitectuur) waarborgt gefedereerde besluitvorming en metadata-auditability. Zonder contracten en stewardship degenereert een mesh tot een gedistribueerde chaos, erger dan het gecentraliseerde lake dat het verving.
Draagvlak creëren
Implementatie is evenzeer politiek als engineering. Begin met één Master Data producer-project. Bewijs dat gecontroleerde toegang werkt: dat het salesteam zijn CRM-data kan zien, het marketingteam website-analytics kan bevragen, en dat geen van beiden toegang heeft tot de tabellen van de ander, met granulaire, per-project-controle.
Het "Marie Kondo"-argument: voordat u AI-workloads op bedrijfsschaal kunt draaien, heeft u granulaire, contextspecifieke toegang nodig tot goed beheerde data. Data Mesh is geen luxe naast uw AI-roadmap. Het is de randvoorwaarde die AI mogelijk maakt.
Wat het kost (en wat mensen verrast)
De mesh-infrastructuur zelf is goedkoop. De verrassingskosten komen voort uit blueprints die u activeert zonder te begrijpen welke resources ze provisioneren.
De blueprint-kostenval
De setup van SageMaker Unified Studio brengt geen kosten per domein met zich mee. Lake Formation, Glue Catalog en projectbeheer zijn in wezen op kleine schaal gratis. De rekening komt van de compute-resources die de blueprints provisioneren. (Zie SageMaker pricing voor de actuele tarieven.)
De duurste verrassing: de MLFlow tracking server. Geactiveerd door een ML-georiënteerde blueprint, kost deze in de lage duizenden per maand, zelfs voor de kleinste compute-optie, zelfs wanneer niemand hem gebruikt. Wij hebben klanten weken na activatie zien ontdekken die zich afvroegen waar de rekening vandaan kwam. (Let op: AWS kondigde eind 2025 een serverless MLflow-optie aan zonder extra kosten, maar de managed tracking server die door oudere blueprints wordt geprovisioneerd brengt deze kosten nog steeds met zich mee.)
Code spaces (de remote JupyterLab- en VS Code-compute-omgevingen waarin u scripts schrijft) zijn betaalbaar maar niet gratis. Een t3.medium instance kost ongeveer $0,60 per 10 uur gebruik, en de laagste idle timeout vóór automatische shutdown is 1 uur.
GP3-opslag kost ongeveer $2 per 15 GB per maand. Verwaarloosbaar.
Het patroon: Infrastructuur (domains, projects, catalogus) = in wezen gratis. Compute (endpoints, tracking servers, code spaces) = waar de rekening groeit. Governance (Lake Formation, permissions) = gratis. Opslag = goedkoop.
Onze aanbeveling: als u vooraf niet weet welke functionaliteit uw project nodig heeft, kunt u het "All Capabilities"-projectprofiel aanmaken met alle blueprints toegevoegd en ze allemaal op ONDEMAND zetten, niet op ONCREATE. Als u niet weet wat een blueprint biedt, activeer hem dan niet. Onze komende artikelen in deze serie zullen elke blueprint en de bijbehorende provisioning uitleggen.
Hoe wij helpen met kosten
Als AWS-partner helpen wij klanten toegang te krijgen tot kostenvoordelen die verder gaan dan standaard compute-optimalisatie: besparingen die niet beschikbaar zijn wanneer u rechtstreeks met AWS werkt. Alle klanten ontvangen DoIt PartnerOps, een cross-cloud FinOps- en complianceplatform, zonder extra kosten. Het biedt inzicht in precies welke resources via blueprints zijn geprovisioneerd en welke uitgaven die veroorzaken. Wij hebben klanten het equivalent van ons adviestarief besparen door alleen al kostenoptimalisatietooling.
Het pragmatische pad: begin klein, bewijs waarde
Niet alles tegelijkertijd. Kies één kritieke databron, één domain unit en één consumer, en bewijs dat het patroon werkt voordat u iemand anders vraagt het te veranderen.
Stap 1: Identificeer uw meest gevraagde dataset, degene die elk project momenteel verkrijgt via Slack-DM's, gedeelde drives of handmatige exports. Als alternatief: kies een pijnpunt: "We besteden te veel uit aan dit bestaande SAS-platform en moeten migreren naar een moderne architectuur."
Stap 2: Creëer een Master Data Producer-project, wijs de data-eigenaar toe en configureer Lake Formation-toegang via SageMaker Unified Studio in plaats van rechtstreeks in de Lake Formation-console.
Stap 3: Publiceer naar SageMaker Catalog met metadata, glossaristermen en kwaliteitsregels.
Stap 4: Onboard één consumerproject. Bewijs dat zij de data kunnen vinden en bevragen zonder iemand te hoeven vragen. Sluit AWS QuickSight aan zodat zakelijke stakeholders kunnen chatten met het BI-dashboard. De reactie is doorgaans onmiddellijk.
Stap 5: Vier het succes. Doe dan de volgende dataset. Als het goed wordt gedaan, creëert elke succesvolle onboarding minstens één interne evangelist: iemand die het heeft gezien en het aan collega's vertelt. Deze evangelisten zijn cruciaal. Consultants genieten niet hetzelfde vertrouwen. Peer advocacy verspreidt de Data Mesh-filosofie veel effectiever dan welk top-downmandaat ook.
Dit is precies wat de Well-Architected lens aanbeveelt: snelle leveringscycli met iteratie op basis van de geleerde lessen. Het alternatief (een big-bang mesh-uitrol die vereist dat iedereen tegelijk verandert) sterft in de governance-commissievergaderingen.
Voor teams die dit proces willen automatiseren met Infrastructure as Code: wij onderhouden een eigenzinnige open-source L2-constructbibliotheek voor SageMaker Unified Studio, beheerd met projen. Het provisioneert domains, domain units, projects en blueprints in één CDK-deploy. We publiceren naar NPM en PyPI zodra het stabiel is, dus volg ons op GitHub voor updates.
Een paar praktische opmerkingen voor teams die de IaC-route nemen: naarmate uw mesh groeit, raakt u de 500-resource-limiet per stack van CloudFormation. Onze aanpak is een aparte CDK-stage voor Data Mesh-resources, één stack per domein, nested stacks voor projecten. Dit geeft ruimte om te schalen zonder de hele deployment te refactoren.
Automatiseer uw CDK-tests vanaf dag één. Er zal significante code-evolutie plaatsvinden en u wilt de tijd die u besteedt aan het wachten op mislukte deployments minimaliseren. Die verspilde minuten stapelen op.
AWS biedt ook nuttige startpunten: een CI/CD CLI voor SageMaker Unified Studio en een officiële utilities-repository met CloudFormation-templates voor veelvoorkomende patronen.
Conclusie
Data Mesh in SageMaker Studio is architecturaal eenvoudig. AWS heeft het control plane geproduktiseerd: domains, projects, de catalogus en Lake Formation-permissies. De technologie werkt. Wat uw implementatie maakt of breekt, is of uw organisatie gefedereerd eigenaarschap kan omarmen zonder meer bureaucratie te genereren dan die elimineert.
Het fundamentele inzicht is niet veranderd: er is geen manier om veilige AI-workloads op bedrijfsschaal te draaien zonder granulaire, contextspecifieke toegang tot beheerde data. De piramide van AI-behoeften is hier van toepassing: schone, beheerde en toegankelijke data vormen het fundament waarop al het andere rust. Data Mesh is geen zijproject naast uw AI-roadmap. Het is wat corporate AI mogelijk maakt.
Als dit uw uitdaging beschrijft (een visie op bedrijfsbrede datatoegang zonder duidelijk pad van hier naar daar), dan is dat waar wij mee helpen. Als AWS-partner brengen wij certificeringen, kostenvoordelen en praktijkervaring mee.
