If you followed my previous posts, you will see we will go another step deeper in this article. EDRA, published earlier, is a stable architectural reference independent of any specific technology. Here, we map it to the most relevant technology landscapes an enterprise architect encounters today, what will these mappings reveal? First, I want to say EDRA holds up as a framework remarkably well regardless of the technology underneath it! The architecture is the constant, and an organisation has its flexibility only when the technology is a variable.
A brief note on timing before we go further. This article was in writing and research for more than a month. During that time, the AI Governance and Trust landscape shifted significantly across every platform we mapped. What started as predictions in the mapping work became confirmed capabilities while the first draft was still being finalised. The most striking example is our suggestion for what we called Unity Trust, a cloud-agnostic AI governance layer for Databricks. By the time this article was ready to publish, Databricks had shipped exactly that capability under the name Unity AI Gateway. Snowflake shipped AI governance capabilities at Snowflake Summit 2026 in early June. AWS shipped Bedrock AgentCore at Summit New York in mid-June. All three platforms answered the same gap within months of each other. We have adjusted the analysis in real time, and the story is more interesting for it.
Of all technology landscapes mapped, Microsoft Azure provides the most complete single-vendor coverage of EDRA. Almost every capability has a named Azure product, and many of the AI-era additions were built into the architecture map directly to Microsoft’s recent product investments.
Figure 1 NeatenMyData EDRA Miscrosoft Mapping
Microsoft Purview stands out. It covers data governance ownership, metadata cataloguing, lineage, data protection, and business glossary natively. MDM and data contracts are technically in scope, but Purview functions as the governance plane rather than the mastering engine: MDM typically requires a partner platform, and data contracts are composed from Data Products and Data Quality rules rather than existing as a first-class object.
Microsoft Fabric is the unifying data platform. It appears across the Data Intelligence zone, Data Engineering, the Semantic Layer, and Enterprise Data Products. The OneLake architecture, where all data sits in one logical lake regardless of workload, is an architectural bet that maps cleanly to the EDRA Lakehouse concept.
Azure AI Foundry is the AI glue. The Model Catalogue, LLM Gateway, RAG Orchestration, Agent Framework, and Human Oversight capabilities all point to it as the central AI platform. Microsoft has clearly made a strategic decision to consolidate the AI engineering experience into one product, and the EDRA mapping reflects that consolidation.
The AWS mapping tells a different story. Where Microsoft consolidates, AWS distributes. Almost every EDRA capability is covered, but across a broader set of services that you must wire together yourself. This gives AWS users more flexibility and more responsibility in equal measure.
Figure 2 NeatenMyData EDRA AWS Mapping
Amazon DataZone is doing for AWS what Microsoft Purview does for Azure, but it is doing it from a younger starting point. Many AWS data teams supplement it with the Glue Data Catalog, Lake Formation, and Glue Schema Registry to cover what DataZone does not yet reach.
Amazon Bedrock is the AI Foundry equivalent. It covers the model catalogue, RAG orchestration via Bedrock Knowledge Bases, guardrails, and agent frameworks via Bedrock Agents. Bedrock is more modular: each service is independently invokable, which gives experienced teams more control but requires more deliberate integration design.
It is also worth noting that AWS is actively shipping into the AI Governance and Trust space. Amazon Bedrock AgentCore Harness reached general availability in June 2026, bringing a production runtime for agents with embedded guardrails, Cedar-powered authorisation, memory management, and observability built in. AWS Context, a knowledge graph that maps relationships across an organisation’s data for agents to query at runtime, was announced at the same Summit but remains in gated preview and is not yet generally available. Amazon Quick, the successor to Amazon Q Business, has also gained autonomous agent capabilities. The direction is clear: the AI Governance gap in the mapping is closing, though not yet fully closed.
The semantic layer seems to be a gap on AWS. QuickSight has a metrics layer, but some AWS organisations might use dbt to complete the functionality, which works well but introduces a third-party dependency.
The AWS philosophy of composable, best-of-breed services is powerful for teams with deep cloud engineering capability. For organisations looking for a more opinionated, integrated data and AI platform, the assembly cost is real. The mapping shows that covering every EDRA capability on AWS requires individual service decisions, integration work including ongoing maintenance.
If you have to choose between Microsoft and AWS coverage of EDRA, which do you pick? And what happens if, a few years from now, that choice turns out to be wrong? And, this is not a hypothetical question.
About two decades ago, the dominant approach was single-cloud commitment. The logic was sound: standardise the skill set, negotiate enterprise agreements, benefit from deep integration between services. AWS dominated the early years, particularly in data and analytics services. Azure dominated in organisations already running Microsoft stacks for security and integration reasons. Google Cloud attracted the data science and ML community early. To cut a long story short, back then, the data teams inherited migration projects that could run for years.
Years later, multi-cloud strategies became a serious conversation in boardrooms and architecture forums. The reasoning was appealing: avoid lock-in by spreading workloads across clouds, negotiate pricing leverage, use best-of-breed services from each vendor. In theory, it addressed the portability problem and the negotiating leverage with vendors was a compelling bonus.
In practice, multi-cloud introduced a different set of problems. Skills must be maintained across two or more ecosystems. Data gravity, the tendency for processing to happen where data lives, means governance becomes harder to standardise and internal costs can increase. Neither single-cloud nor multi-cloud has cleanly solved the fundamental tension: organisations want architectural consistency and portability. Single cloud gives you integration at the cost of portability, and multi-cloud gives you portability at the cost of complexity.
This is where Databricks changed the conversation for me. Databricks is not a cloud provider. It runs on Azure, AWS, and Google Cloud. Databricks offers a data and AI engineering layer IP that is genuinely portable across clouds, it belongs to you, and it moves with you. So, what does Databricks mapping to EDRA reveal? Before looking at what the mapping reveals, it is worth being clear about scope. This analysis covers the data and AI platform layer: how data is ingested, processed, governed, and served. Source systems, identity providers, and operational applications are separate enterprise decisions, made on entirely different timescales by different people, and are not part of this comparison. With that boundary in mind, the gaps in the Databricks mapping fall into three distinct clusters.
Figure 3 NeatenMyData EDRA DataBricks Mapping
When mapped against those data and AI capabilities, Databricks covers the great majority and leaves a meaningful cluster as genuine gaps, shown as grey boxes in the mapping diagram. The gaps are instructive, but not in the way you might expect.
The first cluster reflects the platform scope boundary described above: content and records management, event messaging, manual input. Traditionally, these are not considered as data platform capabilities. Although it’s unfair to count them as gaps, content and records are just another type of data to me.
The second cluster sits at the infrastructure layer: event messaging, backup and archive, API management, networking. The question here is not which infrastructure services Databricks covers. It is whether your pipelines, your models, your governance rules, and your data transformations are insulated from the cloud choice decision when it comes. That is what data IP portability means in practice: the investment you have made in your data intelligence moves with you, regardless of what happens due to cloud infrastructure changes.
The third cluster was the most strategically significant finding in the mapping: the AI Governance and Trust layer. At the very start of our analysis, guardrails, model risk assessment, explainability, and human oversight were all absent from Databricks. That observation is now partly historic. Unity AI Gateway, launched in April 2026, closed the guardrails, human oversight, audit, and cost governance gaps. Model risk assessment has real building blocks today, MLflow, SHAP, MLflow Evaluate, Agent Evaluation, but no single turnkey product yet. Human oversight is shipped: guardrails, audit logging, cost/usage governance, rate limiting, and PII detection are real, but human-in-the-loop approval is currently governance guidance, not a built-in Gateway feature. The fact that these gaps were nameable, and that the mapping made them visible, is what made the following observation possible.
Databricks has made a compelling case that your data and AI IP should live in the platform, not in the cloud underneath it. The EDRA mapping largely validates that. Delta Lake, Unity Catalog, Mosaic AI, and the Agent Framework cover the engine room of a modern data architecture with remarkable completeness.
It was an observation that turned into a prediction, and then into a product. The fact that AWS shipped Bedrock AgentCore into general availability in 2026, specifically targeting enterprise AI agent governance, and that Databricks launched Unity AI Gateway in the same period, confirms that this gap was real and that the industry recognised it simultaneously.
One more platform worth noting here is Snowflake, and it is worth noting precisely because it reinforces the same pattern and the same race. Snowflake is also cloud-agnostic, also running on Azure, AWS, and Google Cloud. When we first completed the mapping, SQL analytics, governed data sharing, and the Snowflake Marketplace were standout strengths, and now AI Agent Identity is generally available, giving every agent cryptographic identity, per-agent access controls, and a complete audit trail.
Figure 4 NeatenMyData EDRA SnowFlakes Mapping
Cortex Guard and AI Security Posture Management address guardrails and security posture. The Natoma acquisition adds MCP governance for agentic workflows across external tools. And Snowflake is previewing Cortex Training, aimed at closing the model training gap we had identified, though it has not yet shipped. Two platforms, similar cloud-agnostic architecture, different capability profiles, and the same AI governance gap closing almost at the same moment.
A note on timing: this space moved faster than any article can keep up with. Treat the mapping tables as a snapshot of a landscape in motion, not a final verdict on any platform. The architecture they map to, however, is not moving.
In conclusion, the central finding of this mapping work is an architectural principle: organisational data IP can be deliberately contained and segregated from the cloud infrastructure layer, so the two can change independently. The EDRA mapping demonstrates this is achievable today, across multiple platforms and using open standards as the foundation. The exercise of mapping to four technology landscapes, Microsoft Azure, AWS, Databricks, and Snowflake, confirmed what I suspected but could not prove without doing the work. The differences between vendors are real, but they are differences in how completely, how natively, and at what cost of assembly that architectural separation is achieved. Choosing a platform is not just a technology decision. It is a decision about whether the work your team invests in processing, governing, and serving that data remains yours when the infrastructure changes. Moving an established data platform between clouds does carry a real cost: data needs to travel, cloud-native services need reconfiguring. But that is a one-time cost of transition or a strategic trade-off, which I’d like to argue is predictable, whereas the cost of developing new data warehouse, data lake, Lakehouse, or other business-critical data products have been more often unpredictable. The financial mechanics of that portable architecture option include the egress costs cloud providers charge for moving data out. Achieving commercial portability requires negotiating egress waivers during the initial enterprise cloud agreements.
For organisations making technology decisions right now, the practical takeaway is start with the architecture, not the vendor. Use EDRA or a similar framework to define what you need before you evaluate what any vendor offers. Then use the mapping to see how completely each option covers your requirements and where the gaps are. The gaps will tell you as much as the coverage.
This work raised these questions for me:
As AI governance becomes a board-level concern, which vendor or platform will own the trust layer for enterprise AI? Will it be the cloud providers, the data platform, or a dedicated third-party category?
Worth noting on this question: a third-party category of specialised AI governance platforms is already forming, and growing fast. Vendors including Credo AI, OneTrust, Monitaur, ModelOp, and Holistic AI are building dedicated governance lifecycle platforms covering policy workflows, model registries, audit trails, regulatory alignment, and production oversight.
The connection between data governance and AI governance runs deeper than it might first appear. As one vendor puts it concisely, an agent inherits the governance rules of the data it reads. Without governed data, AI agents have no trusted foundation to operate from. This is precisely why the data IP argument matters beyond portability. Organisations that invested in solid data governance foundations are already closer to trustworthy AI governance than those that did not.
This is also where the mapping work points to a structural answer, even without naming a winner. The architecture in this article argues that data IP should be deliberately segregated from the cloud infrastructure layer, so the two can change independently. The same logic applies to the trust layer. Wherever AI governance ends up living, the closer it sits to the cloud-agnostic data platform rather than to any single cloud provider, the more the portability argument holds. Governance rules anchored inside a cloud-native AI service move only with that cloud. Governance rules built into a platform designed to run anywhere move with the organisation. This does not settle which vendor or category wins. It does suggest which architectural position is more defensible.
The mapping documents, including the full EDRA diagram and the Microsoft, AWS, Databricks, and Snowflake comparison tables, are available as part of this series on neatenmydata.com.
PS: If you are wondering where Google Cloud fits in this picture, that answer deserves its own article. Google Cloud Next ’26 changed enough that it warrants a separate conversation entirely. Watch this space.
Copyright © NeatenMyData
