Overview
Use WAF to design the right Fabric workload and CAF to adopt Fabric the right way across the enterprise.
Microsoft now provides two complementary planning lenses for Microsoft Fabric. The Well-Architected Framework (WAF) helps solution teams evaluate whether a specific Fabric workload is reliable, secure, cost-conscious, operationally manageable, and performant. The Cloud Adoption Framework (CAF) helps enterprise leaders decide how Fabric fits into a broader data platform strategy, operating model, and governance structure.
A practical way to separate them is this: WAF is about design excellence for an individual workload—how to build a Fabric solution correctly once you know what you are delivering. CAF is about adoption strategy at scale—how to organize teams, landing zones, governance, and standards so multiple domains can adopt Fabric without creating a new sprawl problem.
Most organizations need both. Platform teams can use CAF to define the enterprise guardrails, then use WAF during architecture reviews for each lakehouse, warehouse, real-time, or BI solution that lands on the platform. That sequencing keeps business adoption moving while avoiding inconsistent workspace design, weak controls, or surprise capacity costs later.
Data Architect Platform Owner IT Admin Cloud Architect — This page is for people who need to turn Fabric from a promising platform into an operating model: selecting patterns, defining guardrails, sizing environments, and aligning solution teams to Microsoft guidance.
🏗️ Well-Architected Framework
Use WAF when you are designing or reviewing a single Fabric workload. It is best suited to architecture boards, project teams, and platform engineers who need concrete design guidance across the five Azure Well-Architected pillars.
Typical outputs: trade-off decisions, workload guardrails, SLOs, recovery patterns, security controls, and performance tuning priorities.
🌐 Cloud Adoption Framework
Use CAF when you are deciding how Fabric should be adopted across business units, domains, subscriptions, and operating teams. It focuses on leadership alignment, landing zones, governance baselines, and operational standards.
Typical outputs: domain model, adoption roadmap, governance policies, security baseline decisions, and enterprise platform responsibilities.
Well-Architected Framework
Fabric-specific design guidance layered onto the five Azure Well-Architected pillars.
The Microsoft Fabric Well-Architected Framework guidance was published in May 2026 and lives under the Azure Well-Architected documentation set at /azure/well-architected/microsoft-fabric/overview. It takes the familiar Azure WAF model and adapts it to the realities of Fabric: shared capacity, OneLake as a common data foundation, multiple compute engines, and a fast-moving SaaS platform.
The key value of the Fabric extension is specificity. Instead of generic cloud advice, it speaks directly to capacity sizing, workspace isolation, OneLake replication, Spark and Power BI workload coexistence, managed identities, deployment pipelines, and the operational trade-offs that Fabric teams face every day. This makes it useful as both a design review checklist and a remediation guide when an existing Fabric estate becomes hard to operate.
WAF works best when you treat it as a repeated review cadence, not a one-time read. Use it at the start of a project, before production go-live, after major architecture changes, and when incidents expose weaknesses. The official overview is here: Microsoft Fabric Well-Architected Framework overview.
Reliability
Can the workload meet uptime targets, recover from failure, and survive capacity or regional events without unacceptable business disruption?
Security
Are identity, workspace boundaries, network paths, encryption choices, and monitoring controls strong enough for the data and users involved?
Cost Optimization
Is the team actively controlling CU consumption, storage growth, mirroring cost, and licensing exposure across environments?
Operational Excellence
Can the solution be deployed, tested, monitored, and restored consistently through engineering discipline instead of heroics?
Performance Efficiency
Does the workload scale predictably under shared-capacity conditions while keeping user-facing queries responsive?
Reliability Pillar
Design Fabric workloads to tolerate failure, recover quickly, and behave predictably under shared-capacity pressure.
Reliability in Fabric starts with realism. Fabric is a managed SaaS platform, so Microsoft handles a meaningful amount of platform resilience for you, but workload-level reliability is still your responsibility. Pipelines can fail because of upstream systems, notebooks can be retried incorrectly, semantic models can miss refresh windows, and capacity contention can turn a healthy design into an unreliable one.
The WAF guidance is strongest when you translate platform capabilities into workload promises. If a business process depends on daily ingestion by 6 AM, or executives need morning dashboards by 8 AM, define the reliability objectives around those workflows rather than around vague claims like “high availability.” That lets you decide where redundancy, failover, and graceful degradation are actually worth the cost and complexity.
For Fabric teams, the reliability conversation should connect architecture and operations. Capacity planning, workspace boundaries, retry logic, geo-replication, and failover testing are not separate topics. They are all part of proving that the workload will keep serving the business when something inevitably goes wrong.
Start with constraints
Document capacity limits, subscription quotas, workspace boundaries, and any cross-region dependencies before designing recovery patterns. In Fabric, architectural choices are bounded by the SKU and topology you actually own.
Define SLOs explicitly
Fabric provides a 99.9% platform uptime target, but critical teams should set tighter operational objectives for pipelines, Spark jobs, semantic model refreshes, and report availability. Measure business workflows, not just platform status.
Understand redundancy layers
Instance redundancy is automatic. Zone redundancy is handled through Azure Availability Zones where supported. Region redundancy depends on customer choices such as OneLake BCDR and cross-region recovery design.
Build self-healing behavior
Favor idempotent operations, exponential backoff, circuit breakers, and graceful degradation. A retry pattern that duplicates writes or overwhelms an upstream API is not resilient—it just fails louder.
Plan for bursts safely
Use Fabric elasticity as a buffer for temporary demand spikes, and enable capacity overage billing as a safety net where business continuity matters more than a strict cap. Otherwise, one bad day can become a throttling incident.
Test disaster recovery
OneLake geo-replication is asynchronous, so plan for a small but real RPO. Run failover exercises regularly, confirm downstream connection changes, and verify that teams know which datasets or reports must be revalidated first.
Security Pillar
Treat identity, workspace boundaries, data protection, and monitoring as the baseline—not as post-go-live hardening.
Fabric simplifies collaboration, which is exactly why security design matters early. The same features that make it easy to share data, publish semantic models, and connect BI experiences can also create quiet sprawl if workspaces, identities, and sharing rules are left too open. In most environments, security failures come from permissive defaults and unclear ownership more often than from sophisticated attacks.
The Fabric WAF guidance emphasizes identity-first security and layered controls. Because Fabric is built around Entra ID, workspace roles, item permissions, data security rules, and network controls need to align to one identity model. That supports Zero Trust, reduces exceptions, and gives audit teams a consistent way to review who can do what.
A strong Fabric security posture also depends on operational discipline. Labels, approvals, private connectivity, Key Vault-backed secrets, and Sentinel analytics only help if the deployment process enforces them consistently across new workspaces and promoted content.
Baseline first
Align to the Azure security baseline for Microsoft Fabric and use it as the minimum bar before solution-specific exceptions are discussed.
Use workspace isolation deliberately
Map workspaces to teams, products, or projects with clear ownership. Security gets easier when collaboration boundaries and operational boundaries are the same.
Adopt identity-first controls
Everything flows through Entra ID. Prefer workspace identity or managed service principals for automation, and enforce privileged access through PIM rather than permanent elevation.
Harden network paths
Use managed VNets, private endpoints, Private Link, IP allow lists, and TLS 1.2+ to reduce exposure. Apply network isolation where the data sensitivity or compliance requirement justifies it.
Protect data end to end
Fabric uses AES-256 encryption at rest, and customer-managed keys through Azure Key Vault are available for selected scenarios. Validate artifact coverage before treating CMK as universal.
Reduce permissive sharing
Restrict workspace creation, require sensitivity labels, and disable broad sharing patterns such as “anyone with the link” where governance matters. Convenience sharing becomes a governance debt very quickly.
Monitor behavior continuously
Route Fabric audit logs into Microsoft Sentinel, then alert on risky sign-ins, mass exports, unusual sharing patterns, and high-risk privilege changes rather than relying on occasional manual review.
Embed security in delivery
Use Git integration, deployment pipeline approvals, and Azure Key Vault-backed secrets as part of the SDL. The safest control is one that ships by default with every promoted change.
Cost Optimization Pillar
Control Fabric spending by understanding what really drives cost and by automating the easy savings first.
Fabric can feel deceptively simple from a pricing perspective because so many workloads run on the same capacity. That simplicity helps with procurement, but it can hide where money is actually going. One team may think a report issue is a Power BI problem while the root cause is Spark or warehouse activity consuming the same CU pool. Cost optimization starts by making shared-consumption behavior visible.
The WAF guidance encourages teams to think in loops rather than one-time sizing exercises. Observe real usage, attribute it to domains and workloads, then apply controls such as reservations, pauses, autoscaling, or environment-specific SKUs. The best cost outcome usually comes from governance and operating habits, not from one perfect SKU decision on day one.
Cost conversations should also include the expenses around the capacity itself. Storage, mirroring, cross-region transfer, and Power BI licensing for smaller SKUs all affect the real operating cost of a Fabric platform and often surprise teams that only budgeted for compute.
Know the pricing model
Fabric capacity is billed in Capacity Units (CUs) either as pay-as-you-go by minute or through 1-year and 3-year reservations. Match commitment length to workload stability.
Track the real cost drivers
Compute consumption, OneLake storage, data processing intensity, and cross-region transfer all matter. Treat them as separate levers with different owners.
Watch hidden costs
Storage keeps accumulating even when compute is paused, and smaller SKUs can still require Power BI Pro licenses for report consumers. Low compute cost does not always mean low total cost.
Run a governance loop
Use a recurring loop of Observe → Account → Control. The Capacity Metrics App shows usage, chargeback tooling explains who drove it, and policy decisions constrain the next cycle.
Use Microsoft tools first
Start with the Fabric Capacity Estimator, the Azure Pricing Calculator, and the Fabric Cost Analysis tool on GitHub before building your own spreadsheet heuristics.
Automate low-risk savings
Auto-pause dev and test capacities overnight, scale Spark and warehouse environments when supported, and remove idle environments that linger after projects close.
Right-size by environment
Use small and pausable capacities for Dev, medium with test windows for Test, and dedicated reserved capacity for Prod. Production economics should not dictate developer ergonomics.
Operational Excellence Pillar
Run Fabric like an engineered platform with repeatable delivery, monitoring, and recovery discipline.
Operational excellence is the difference between a Fabric platform that scales cleanly and one that depends on tribal knowledge. Because Fabric blends data engineering, analytics, warehousing, and BI into one service boundary, operational mistakes in one area often spill into others. That makes deployment rigor and environment discipline more important than in a fragmented toolchain.
The WAF guidance pushes teams to define who owns capacity monitoring, who approves promotions, how incidents are triaged, and what recovery path exists when a release goes wrong. Those answers should exist before production, especially for shared capacities where one bad deployment can affect many downstream consumers.
A useful rule of thumb is to separate the things you can redeploy from the things you must reconcile. Fabric items can often be redeployed from source control, but the hard part during an incident is usually data correctness across lakehouses, warehouses, and semantic models. Operational excellence means planning for both.
Prepare the team
Invest in certifications such as DP-600 and DP-700, and assign explicit owners for capacity health, deployment approvals, and production support rotations.
Deploy in layers
Treat deployment as a stack: Subscription → Capacities → Workspaces → Items → Promotion. IaC should cover everything it can, and promotion should be predictable.
Use a real test pyramid
Run unit, integration, data quality, load, and UAT checks. Practical tool choices include pytest, nutter, and Great Expectations depending on the workload.
Monitor with multiple signals
Combine the Capacity Metrics App, Workspace Monitoring, OneLake diagnostics, Fabric Activator, and FUAM so operators see both platform symptoms and business-impacting events.
Practice incident response
Zone redundancy is automatic, BCDR is customer-enabled, and content recovery usually depends on Git-backed redeployment. Rehearse the runbook instead of assuming SaaS means zero recovery work.
Accept the rollback reality
Fabric has no universal rollback button. Your safety net is source control and disciplined promotion. The real operational risk is data inconsistency across stores after a partial failure.
Performance Efficiency Pillar
Keep queries, pipelines, notebooks, and reports fast by planning for shared capacity instead of hoping workloads will coexist nicely.
Performance in Fabric is rarely about one engine in isolation. Lakehouse jobs, semantic model refreshes, warehouse queries, shortcuts, and streaming workloads can all contend for the same capacity pool. That means performance tuning must start at the platform level, then drill into workload-specific optimizations only after capacity contention and poor isolation are ruled out.
The WAF perspective is especially helpful here because it frames performance as a design choice, not just a post-deployment troubleshooting exercise. If you know a business domain needs predictable interactive reporting, you can isolate heavy engineering work away from presentation workloads instead of waiting for users to complain and then scaling reactively.
Capacity sizing, workload separation, and engine-level tuning all matter together. Teams that skip the first two often spend too much time optimizing SQL, DAX, or Spark code when the actual bottleneck is a crowded capacity with no prioritization strategy.
Baseline before scaling
Start with the Fabric Capacity Estimator and capture a workload baseline. You need an initial model of concurrency, refresh windows, and engineering demand before any tuning conversation is credible.
Understand smoothing behavior
Background workloads are smoothed over a 24-hour window, so simply moving a heavy job to the middle of the night might not deliver the performance relief you expect.
Choose the right scaling path
Vertical scaling means upgrading the SKU quickly. Horizontal scaling means distributing workloads across capacities, which aligns well with data mesh and domain isolation patterns.
Watch the right signals
High CU utilization, memory failures, slower query completion, queueing, and steadily increasing latency are better indicators than isolated user complaints.
Use workload isolation
Separate data preparation, orchestration, and presentation onto different capacities when business criticality or concurrency patterns justify the extra cost.
Optimize each engine intentionally
Use Delta partitioning and parallelism for Spark, query folding and incremental refresh for Power BI, and result caching or model tuning where supported to reduce repeated compute work.
Cloud Adoption Framework
Prescriptive guidance for unifying data platforms with Fabric without forcing an all-at-once migration.
The Microsoft Cloud Adoption Framework guidance for Fabric is aimed at executives, platform leads, and enterprise architects who need to unify a broader data estate. It now lives at the new CAF data platform strategy location and positions Fabric as the hub of a governed, reusable data platform for analytics and AI.
The most important idea in the guidance is that unification does not require a full migration. Microsoft explicitly recommends combining shortcuts for virtualization with mirroring for selective replication so teams can create value quickly while keeping existing systems in place. That message matters for organizations that have been stalled by the assumption that platform modernization must begin with a disruptive rewrite.
CAF is therefore not a product deployment guide. It is a strategy-and-operating-model guide that helps an organization decide how domains, landing zones, governance, security, and standards should evolve so Fabric becomes a durable platform instead of another isolated analytics island. The official entry point is Executive strategy to unify your data platform.
Use Fabric to unify access to data products first, not to force every source system into OneLake immediately. Shortcuts let you virtualize trusted data in place, and mirroring lets you selectively replicate where performance, governance, or downstream reuse requires it.
CAF Adoption Steps
A four-step adoption path for organizing people, platforms, guardrails, and standards around Fabric.
The CAF guidance breaks Fabric adoption into four steps that are deliberately broader than technology implementation. That is useful because many Fabric programs fail for organizational reasons long before they fail technically: domains are unclear, ownership is fuzzy, landing zones are incomplete, and governance is introduced too late.
Use these four steps as a decision sequence. Start by deciding who owns which data and what business value matters. Then choose the architecture that supports that ownership model. Only after that should you lock in governance baselines and operational standards. If you reverse the order, you usually end up with controls that are either too generic or too hard for domain teams to follow.
The walkthrough below turns the CAF themes into practical adoption checkpoints that platform teams can use in steering committees, architecture reviews, or domain onboarding playbooks.
1. Organizational Readiness
Define data domains that align to business units, appoint domain leadership, and make ownership explicit. Domains should manage their own capacity and data products within enterprise guardrails rather than waiting for a central team to do everything.
Publish domain-owned data products through the OneLake catalog so reuse becomes the default behavior instead of an afterthought.
2. Architecture
Position Fabric as the unified OneLake hub for analytics and AI while using Azure landing zones for data management, policy, and supporting services. Design for integration with Azure Databricks, Azure Machine Learning, and adjacent Azure services where needed.
Make an explicit choice between a Fabric-centric architecture and a broader Azure landing zones architecture based on how much of the estate remains outside Fabric.
3. Governance & Security Baselines
Use Microsoft Purview for visibility and governance across the entire data estate, not just Fabric. Then define Fabric-specific baselines for the OneLake layer, workspace controls, sensitivity labels, access boundaries, and compliance expectations.
Decide these baselines before scale-up so every new domain inherits them automatically.
4. Operational Standards
Standardize how data is processed, secured, published, monitored, and consumed. This includes ingestion rules, data quality checks, release patterns, monitoring and alerting conventions, and how data products are retired.
Operational standards are what turn governance from theory into day-to-day platform behavior.
WAF vs CAF Comparison
Use both frameworks together, but ask each one a different question.
A common mistake is to treat WAF and CAF as competing guidance sets. They are not. WAF helps solution teams validate that a particular Fabric workload is well designed. CAF helps leaders decide how Fabric should be adopted, governed, and operated across domains. One is workload-facing; the other is organization-facing.
In practice, CAF usually sets the enterprise context and WAF is applied repeatedly within that context. A platform team might define domain ownership, landing zones, security baselines, and operational standards through CAF, then ask each new workload team to complete a WAF-style review before production sign-off. That pairing creates consistency without freezing innovation.
| Aspect | WAF | CAF |
|---|---|---|
| Focus | Workload design excellence | Organizational adoption |
| Scope | Single workload/solution | Entire data platform |
| When to use | Designing or reviewing a Fabric solution | Planning enterprise-wide adoption |
| Output | Design decisions and trade-offs | Adoption plan and governance policies |
| Key question | “Is my workload well-designed?” | “How do I adopt at scale?” |
Resources & Links
Official Microsoft documentation to go deeper on both frameworks and the supporting platform controls.
If you are building an internal architecture standard, bookmark the WAF overview and the CAF executive strategy page first. Those are the best entry points for cross-functional teams because they frame the problem before diving into one pillar or one adoption stage.
From there, use the links below to assign follow-up reading by role. Reliability and performance links usually go to solution architects and engineering leads; governance and security links go to platform and compliance teams; capacity planning links go to the people who own SKU decisions and budget accountability.
- WAF Overview
- WAF Reliability Pillar
- WAF Security Pillar
- WAF Cost Optimization Pillar
- WAF Operational Excellence Pillar
- WAF Performance Efficiency Pillar
- CAF Executive Strategy
- CAF Organizational Readiness
- CAF Architecture
- CAF Governance & Security Baselines (Purview)
- CAF Governance & Security Baselines (Fabric)
- CAF Operational Standards
- Azure Security Baseline for Microsoft Fabric
- Fabric Capacity Estimator