A Storage Area Network (SAN) is a dedicated, high-speed network built for one job: moving block data between servers and shared storage. Instead of putting disks inside each server (direct-attached storage) or sharing files over the LAN (NAS), a SAN presents consolidated storage as raw block volumes that appear to each server as local drives - over a separate fabric so storage traffic never competes with email or web traffic. That separation is why SANs became the backbone of enterprise data centers, powering databases, virtualization, and other workloads that demand consistent, low-latency access to shared storage.
Key takeaways
- A SAN provides block-level access to shared storage over a dedicated network, separate from the LAN.
- Servers (initiators) reach storage (targets) via HBAs, a fabric, and controllers presenting LUNs.
- Main protocols: Fibre Channel (FCP), iSCSI over Ethernet, and NVMe over Fabrics.
- SAN = block/dedicated; NAS = file/IP; DAS = local/single-server.
- It buys performance, scalability, and HA at the cost of money, complexity, and expertise.
Quick explanation
In simple terms
A separate high-speed network that lets many servers share the same storage as if each had its own local hard drives.
Technical definition
A dedicated network delivering block-level access to consolidated storage, connecting initiators to targets across a fabric using protocols such as FCP, iSCSI, or NVMe over Fabrics, with LUN masking and zoning controlling access.
Analogy
A SAN is like a dedicated highway just for storage trucks: keeping heavy storage traffic off the regular roads (the LAN) means both move faster and more predictably.
Definition
A Storage Area Network (SAN) is a dedicated, high-speed network that provides servers with block-level access to consolidated, shared storage, so remote storage appears to each server as if it were locally attached.
A Storage Area Network (SAN) is a computer network whose primary purpose is transferring block data between servers and shared storage systems. It is kept separate from the general-purpose LAN so that storage traffic doesn't compete with everyday network traffic. Because a SAN provides block-level access (not file-level), each server's own file system organizes the blocks into files and directories - the storage simply appears as raw disks. SNIA, the storage networking industry association, defines a SAN as a network whose primary purpose is the transfer of data between computer systems and storage elements. A SAN has three main parts: storage arrays, a network fabric (specialized switches), and host systems, connected using storage protocols such as Fibre Channel, iSCSI, or, increasingly, NVMe over Fabrics.
Why it matters
Core concepts
Block-level storage
The SAN presents raw storage blocks, not files, leaving the file system to the server.
A SAN delivers block-level access: storage appears to a server as unformatted disks, and the server's own file system decides how blocks become files and folders. This differs from file-level storage (NAS via NFS/SMB), where the storage device manages the file system. Notably, shared-disk file systems can be layered on top of a SAN to give coordinated file-level access to multiple hosts.
Example
A database server gets a raw LUN from the SAN and formats it with its own file system for maximum control over I/O.
Why it matters — Block access gives applications like databases and hypervisors the low-level control and performance they need.
SAN fabric
The dedicated switch network that interconnects servers and storage.
The fabric is the network of specialized switches (Fibre Channel or Ethernet for iSCSI) that connects hosts to storage, usually with multiple redundant paths for resilience and performance. Because it's dedicated to storage, the fabric isolates storage traffic from the LAN, delivering predictable latency.
Example
Dual redundant FC fabrics let a server keep reaching its storage even if one switch or path fails.
Why it matters — The fabric's redundancy and isolation are what make SAN performance consistent and highly available.
Initiators, targets, and HBAs
Servers (initiators) reach storage (targets) through host bus adapters.
In SAN terms, servers are initiators and storage systems are targets. Each server connects to the fabric through a Host Bus Adapter (HBA) (or a network adapter for iSCSI), which handles the storage protocol and presents remote storage to the operating system as local disks.
Example
A server's dual FC HBAs connect to two fabrics so storage stays reachable if one adapter or path fails.
Why it matters — The initiator/target model and HBAs are the basic plumbing every SAN design starts from.
LUNs, zoning, and LUN masking
Volumes are presented as LUNs, and access is controlled by zoning and LUN masking.
Storage controllers present logical volumes as Logical Unit Numbers (LUNs). Access is governed at two levels: zoning controls which hosts and storage ports can communicate at the fabric level, while LUN masking determines which hosts may see or use a specific LUN. Together they prevent unauthorized access and accidental data corruption.
Example
Zoning separates production from test, and LUN masking ensures only the intended cluster nodes see a shared database LUN.
Why it matters — Correct zoning and masking are essential for SAN security and for safely sharing storage among servers.
Storage protocols (FC, iSCSI, NVMe-oF)
The transport that carries storage commands and block data across the fabric.
Fibre Channel Protocol (FCP) carries SCSI commands over Fibre Channel and is prized for low latency and reliability (FC SANs commonly run at 32GFC and 64GFC). iSCSI encapsulates SCSI in TCP/IP over standard Ethernet, lowering cost and easing integration - popular with smaller organizations. NVMe over Fabrics (NVMe-oF) transports NVMe commands over RDMA/Ethernet, Fibre Channel, or InfiniBand, bypassing much of the storage server's I/O stack for very low latency. Other transports include FCoE and FC-NVMe.
Example
An SMB runs iSCSI over its existing 10/25GbE network; a bank runs FC for OLTP; an AI cluster adopts NVMe-oF for sub-millisecond latency.
Why it matters — Protocol choice drives cost, performance, distance, and how the SAN integrates with existing networking.
How it works
A server issues block I/O
An application on an initiator (server) reads or writes data; the request is handed to the server's HBA or iSCSI initiator as a block-level storage command.
Initiator I/O
Example — A database writes a transaction to what it sees as a local disk (actually a LUN).
The HBA places it on the fabric
The HBA (or network adapter) encapsulates the command in the storage protocol (FCP, iSCSI, or NVMe-oF) and sends it into the SAN fabric.
Onto fabric
Example — An FC HBA frames the SCSI command for the Fibre Channel fabric.
The fabric routes it - within zoning rules
Fabric switches route the request to the correct storage target over one of several redundant paths, honoring zoning that restricts which hosts and ports may communicate.
Route (zoning)
Example — Zoning ensures a test host can't reach a production array.
The controller serves the LUN - within masking rules
The storage controller receives the request, applies LUN masking so only authorized hosts see the volume, handles RAID and caching, and reads or writes the physical media.
Controller + LUN
Example — The array's cache satisfies a hot read without hitting disk.
Data returns and the file system takes over
The result travels back along the same path; on the server, the block appears as local disk and the server's own file system organizes it into files and directories.
Return + file system
Example — The OS writes the returned blocks into its NTFS/ext4/VMFS layout.
Use cases
Enterprise databases
DBAs, infrastructure adminsProvide the low-latency, high-IOPS block storage transactional systems and data warehouses need, plus shared storage for clustering.
An Oracle or SQL Server OLTP cluster on an FC SAN.
Benefit — Consistent performance and failover
Virtualization infrastructure
Virtualization adminsDeliver shared datastores so hypervisors can live-migrate VMs and centralize backup/DR.
A vSphere cluster using SAN datastores for vMotion.
Benefit — No-downtime VM mobility and HA
High-performance computing
Research/engineering ITGive many compute nodes concurrent, high-bandwidth access to shared datasets.
An HPC cluster reading a shared dataset over the SAN.
Benefit — Parallel access at scale
Media and content production
Media ITLet creative teams work on very large files collaboratively without local copies.
Video editors sharing project media on a SAN volume.
Benefit — Collaborative editing on big files
Backup and disaster recovery
Backup/DR teamsCentralize backups and use array snapshots and replication to protect and mirror data offsite.
Array-based replication of critical LUNs to a DR site.
Benefit — Point-in-time protection and DR
Benefits
High, consistent performance
A dedicated fabric removes contention with LAN traffic, delivering low latency and high IOPS.
OLTP latency stays stable during peak business hours.
Independent scalability
Storage capacity and performance scale separately from server resources.
Add array shelves without touching compute.
Centralized management
All storage is managed from one place, simplifying provisioning, monitoring, and capacity planning.
Provision a new LUN to a cluster from the array console.
High availability
Redundant paths, controllers, and multipathing keep storage reachable through failures.
A failed switch reroutes I/O automatically.
Storage sharing and advanced features
Multiple servers share storage, enabling clustering plus snapshots, replication, thin provisioning, and tiering.
A shared LUN backs a two-node database cluster.
Limitations
High cost
MediumSANs require investment in arrays, fabric switches, HBAs, redundancy, support, and skilled staff - more than simpler storage.
Workaround — Use iSCSI over existing Ethernet (or NVMe/TCP) to lower entry cost versus dedicated Fibre Channel; size to actual need.
Complexity
MediumDesigning, implementing, and troubleshooting zoning, masking, multipathing, and firmware requires specialized knowledge.
Workaround — Standardize designs, document zoning/LUN maps, and invest in training or a managed provider.
Potential vendor lock-in
MediumSome SAN stacks rely on proprietary features that complicate switching vendors or integrating other systems.
Workaround — Favor standards-based protocols (iSCSI, NVMe-oF) and portable data-protection tooling to reduce lock-in.
Distance limits (Fibre Channel)
LowTraditional FC has distance constraints, though it can be extended for DR and metro links.
Workaround — Use FC extension, iSCSI/NVMe over IP, or replication for long-distance and DR scenarios.
Risk concentration if misconfigured
MediumDespite HA design, a poorly configured SAN can create bottlenecks or single points of failure.
Workaround — Deploy redundant fabrics and controllers, enable multipathing, and test failover regularly.
Architecture
A SAN comprises host systems (initiators with HBAs), a dedicated network fabric (redundant specialized switches), and storage systems (arrays with controllers presenting LUNs). Storage commands travel over a chosen protocol (FCP, iSCSI, or NVMe-oF), with zoning and LUN masking enforcing access control, and advanced array features (snapshots, replication, thin provisioning, tiering) layered on top.
Storage arrays and controllers
Hold the physical media and present logical volumes (LUNs); handle RAID, caching, snapshots, replication
A dual-controller all-flash array
Network fabric (switches)
Interconnect hosts and storage over redundant paths, isolated from the LAN
Two Fibre Channel switches forming redundant fabrics
Host Bus Adapters (HBAs)
Connect servers to the fabric and present storage to the OS
Dual 32GFC HBAs per server
Storage protocol
Transports block commands across the fabric
FCP, iSCSI, or NVMe over Fabrics
Zoning and LUN masking
Control which hosts can communicate with and see which storage
Production/test zoning + per-host LUN masking
Data flow
Initiator issues block I/O then the HBA encapsulates it in the storage protocol; the fabric routes it (zoning); the controller applies LUN masking, RAID, and cache; data returns along the same path; and the server's file system organizes the blocks.
Integrations: VMware vSphere / Microsoft Hyper-V (shared datastores, live migration), Database clustering and failover, Backup and array-based replication / snapshots
Architecture limitations
Examples
Live-migrating VMs on shared storage
A hypervisor cluster needs to move running VMs between hosts without downtime.
Because all hosts see the same SAN LUNs as shared datastores, the VM's disk doesn't move - only its running state transfers between hosts.
OLTP database on a Fibre Channel SAN
A bank's transaction system needs predictable sub-millisecond storage latency.
An FC SAN gives the database dedicated, low-latency block access with redundant fabrics for resilience.
Comparisons
SAN vs NAS vs Network Attached Storage (NAS)
A SAN provides block-level storage over a dedicated fabric and appears as local disks; a NAS provides file-level storage over the standard IP network. SANs suit high-performance, shared block workloads; NAS suits file sharing and collaboration.
| Criterion | SAN vs NAS | Network Attached Storage (NAS) |
|---|---|---|
| Access level | Block-level (raw volumes) | File-level (NFS/SMB) |
| Network | Dedicated storage fabric | Standard IP/LAN |
| Typical performance | Very high, low latency | Moderate to high |
| Best for | Databases, virtualization, clustering | File shares, collaboration, backup targets |
| Cost and complexity | Higher | Lower to moderate |
When to choose — Choose a SAN for high-performance shared block storage (databases, VMs); choose NAS for file sharing and simpler, lower-cost needs. Many organizations run both.
Learn moreMyths, corrected
Myth
A SAN and a NAS are basically the same thing.
Correction
They differ fundamentally: a SAN serves block storage over a dedicated fabric and appears as local disks, while a NAS serves files over the IP network. The access level and network are different.
Why it happens: Both are 'shared network storage,' so the block-vs-file distinction gets lost.
Myth
A SAN means Fibre Channel.
Correction
Fibre Channel is common but not required. SANs also run on iSCSI over standard Ethernet, on FCoE, and increasingly on NVMe over Fabrics - so a SAN can use commodity networking.
Why it happens: FC was the original dominant SAN transport, so the two became synonymous in people's minds.
Myth
Cloud and software-defined storage made SANs obsolete.
Correction
SANs remain widely used for low-latency, consistent block workloads, and they're modernizing via NVMe over Fabrics. Cloud and SDS change the landscape but don't eliminate the need for high-performance on-prem block storage.
Why it happens: Cloud marketing implies everything moves off-prem, overlooking latency-sensitive and regulated workloads.
Myth
A SAN is inherently a single point of failure.
Correction
SANs are designed for HA with redundant fabrics, multiple controllers, and multipathing; a single point of failure usually indicates a design or configuration gap, not an inherent trait.
Why it happens: Centralizing storage feels risky, so people assume consolidation equals fragility.
Practical implications
For admins
Plan fabric redundancy, zoning, and LUN masking carefully; enable multipathing; monitor IOPS, latency, and queue depth; keep firmware and documentation current.
For MSPs
Standardize SAN designs across clients, document zoning/LUN maps, and consider iSCSI/NVMe-oF to control cost while meeting performance SLAs.
For business
A SAN is an investment that buys performance and resilience for critical systems; weigh it against NAS/DAS or hyperconverged/cloud options based on workload.
For security
Zoning and LUN masking are access controls - misconfiguration can expose or corrupt data; segment environments and audit LUN assignments.
For end users
Impact is indirect: faster, more reliable applications and less downtime when the SAN is well designed.
Cost impact
Costs vary widely by capacity, performance, and redundancy; Fibre Channel adds dedicated switches/HBAs, while iSCSI or NVMe/TCP can reuse Ethernet to lower entry cost. Budget for support and expertise, not just hardware.
Operational impact
Introduces storage-networking operations (fabric management, zoning changes, firmware, DR testing) that need dedicated skills and change control.
Decision guide
Use when
- You need low-latency, shared block storage for databases or virtualization
- You require clustering, live migration, or array snapshots/replication
- You want to scale storage independently of servers with central management
Avoid when
- Your need is file sharing/collaboration (a NAS fits better)
- A single server needs local storage with no sharing (DAS is simpler/cheaper)
- Budget and storage expertise are very limited
Requirements
- A dedicated fabric (FC switches, or Ethernet for iSCSI/NVMe-oF)
- HBAs or suitable network adapters in each host
- Storage-networking expertise for zoning, masking, and multipathing
Alternatives
- Network Attached Storage (NAS) for file workloads
- Direct-Attached Storage (DAS) for single-server needs
- Hyperconverged / software-defined storage
- Cloud block storage for off-prem workloads
Related terms
NAS (Network Attached Storage)
File-level shared storage over the standard IP network.
DAS (Direct-Attached Storage)
Storage connected directly to a single server.
LUN
A logical storage volume presented to hosts by a SAN.
Zoning
Fabric-level control of which hosts and ports may communicate.
A high-speed, low-latency SAN transport standardized by INCITS T11.
NVMe over Fabrics
Transports NVMe commands over a network fabric for very low latency.
Frequently asked questions
What is a SAN in simple terms?
A SAN (Storage Area Network) is a dedicated high-speed network that connects servers to shared storage. It lets multiple servers use the same storage as if it were local drives, with better performance and central management than putting disks in each server.
What is a SAN used for?
Mainly enterprise workloads needing fast shared block storage: databases, virtualization clusters, high-performance computing, media production, and centralized backup and disaster recovery.
Is a SAN the same as a NAS?
No. A SAN provides block-level storage over a dedicated fabric and appears as local disks; a NAS provides file-level storage over the standard IP network. SANs are typically faster but more complex and costly.
What are the main SAN protocols?
Fibre Channel Protocol (SCSI over Fibre Channel) for maximum performance, iSCSI (SCSI over TCP/IP Ethernet) for lower cost and easy integration, and increasingly NVMe over Fabrics for very low latency. FCoE and FC-NVMe also exist.
Is Fibre Channel or iSCSI better?
Fibre Channel offers very low latency and high reliability on a dedicated fabric but costs more; iSCSI runs over standard Ethernet at lower cost and is easier to integrate. Choose based on performance needs, budget, and existing networking.
Are SANs obsolete because of cloud storage?
No. SANs remain common for low-latency, consistent block workloads and are modernizing with NVMe over Fabrics. Cloud and software-defined storage change the landscape but don't remove the need for high-performance on-prem block storage.
How much does a SAN cost?
It varies widely with capacity, performance, and redundancy. The main cost drivers are storage arrays, fabric switches, and HBAs, plus support and expertise. Fibre Channel adds dedicated hardware, while iSCSI or NVMe/TCP can reuse existing Ethernet to lower the entry cost. Get vendor quotes for your specific requirements.
Conclusion
A SAN is a dedicated, high-speed network that gives servers block-level access to consolidated, shared storage. Initiators reach targets through HBAs and a redundant fabric, controllers present LUNs governed by zoning and LUN masking, and transport runs over Fibre Channel, iSCSI, or NVMe over Fabrics. SANs excel at databases, virtualization, HPC, media, and backup/DR - differing from NAS (file/IP) and DAS (local/single-server).
Main takeaway
Read a comparison of Fibre Channel vs iSCSI to choose a protocol, an explainer on NAS for file workloads, or a tutorial on configuring iSCSI targets and initiators for hands-on practice.
