{"id":519,"date":"2026-04-14T08:51:41","date_gmt":"2026-04-14T08:51:41","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-elastic-san-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-storage\/"},"modified":"2026-04-14T08:51:41","modified_gmt":"2026-04-14T08:51:41","slug":"azure-elastic-san-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-storage","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-elastic-san-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-storage\/","title":{"rendered":"Azure Elastic SAN Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Storage"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Storage<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure Elastic SAN is a managed <strong>block storage<\/strong> service that provides SAN-like (Storage Area Network) capabilities in Azure using <strong>iSCSI<\/strong>. It is designed for workloads that want shared, high-performance block volumes without you having to build and operate traditional SAN infrastructure.<\/p>\n\n\n\n<p>In simple terms: <strong>you create an Elastic SAN, carve it into volumes, and attach those volumes to servers over the network<\/strong>\u2014similar to how an on\u2011prem SAN presents LUNs to hosts, but delivered as a managed Azure service.<\/p>\n\n\n\n<p>Technically, Azure Elastic SAN is an Azure resource that contains provisioned capacity and performance, then exposes one or more <strong>volume groups<\/strong> with network connectivity to your virtual network. Within a volume group, you create <strong>volumes<\/strong> that are accessed by clients (for example, Azure VMs) using the iSCSI protocol over private networking. Control-plane operations are handled through Azure Resource Manager (ARM), while data-plane traffic flows directly between your hosts and the iSCSI target endpoints.<\/p>\n\n\n\n<p>The main problem it solves is: <strong>shared, centrally managed block storage at scale<\/strong>. Compared to attaching many individual managed disks across many VMs, Elastic SAN gives you pooled capacity, consolidated performance management, and SAN-style operations (volume creation, resizing, access control) in a single service.<\/p>\n\n\n\n<blockquote>\n<p>Service status \/ naming: As of this writing, the official product name is <strong>Azure Elastic SAN<\/strong> in Azure Storage. If Microsoft renames or rebrands the service, verify the latest name and features in the official documentation: https:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Elastic SAN?<\/h2>\n\n\n\n<p>Azure Elastic SAN is a managed Azure Storage service that delivers <strong>SAN-like, network-attached block storage<\/strong> to compute resources in Azure using <strong>iSCSI<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (what it\u2019s for)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provide centrally managed, scalable block storage volumes that can be attached over the network to one or more hosts.<\/li>\n<li>Reduce operational complexity compared to self-managed iSCSI targets or traditional SAN appliances.<\/li>\n<li>Offer pooled capacity\/performance and flexible volume provisioning for enterprise-style workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provision an Elastic SAN instance (capacity + performance) and subdivide it into volumes.<\/li>\n<li>Organize volumes into <strong>volume groups<\/strong>, which represent a network-accessible iSCSI target boundary and access configuration.<\/li>\n<li>Attach volumes to hosts using iSCSI initiators (commonly Linux or Windows VMs).<\/li>\n<li>Resize volumes and manage lifecycle via Azure Portal, ARM, Azure CLI, PowerShell, and APIs (availability depends on current tooling support\u2014verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Elastic SAN<\/strong>: The top-level resource where you provision overall capacity\/performance.<\/li>\n<li><strong>Volume group<\/strong>: A container for volumes that also defines how volumes are exposed to your network (iSCSI target endpoints and access\/network rules).<\/li>\n<li><strong>Volume<\/strong>: The block device presented to hosts (similar to a LUN).<\/li>\n<li><strong>(Optional\/feature-dependent) Snapshots \/ backups<\/strong>: Some SAN products support snapshots; Azure Elastic SAN has evolving capabilities. Verify the current snapshot\/backup support and limitations in the official docs for your region and SKU.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed block storage over the network (iSCSI)<\/strong>.<\/li>\n<li>Control plane: Azure Resource Manager.<\/li>\n<li>Data plane: iSCSI traffic from initiators to target endpoints in\/through your Azure virtual network.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global, subscription, etc.<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional service<\/strong>: You deploy an Elastic SAN into an Azure region. Hosts typically need to be in the same region for best latency and to avoid cross-region complexity\/cost. (Verify any cross-region access guidance in official docs.)<\/li>\n<li><strong>Azure subscription\/resource group scoped<\/strong>: Managed like other Azure resources with RBAC, tags, policies, and locks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Azure ecosystem<\/h3>\n\n\n\n<p>Azure Elastic SAN complements other Azure Storage offerings:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Managed Disks<\/strong>: Per-VM block disks (simple, common default).<\/li>\n<li><strong>Azure Files<\/strong>: SMB\/NFS file shares (file storage).<\/li>\n<li><strong>Azure NetApp Files<\/strong>: Enterprise NFS\/SMB with NetApp features (file storage and some block-style workflows through NetApp capabilities).<\/li>\n<li><strong>Azure Elastic SAN<\/strong>: A SAN-style, shared, pooled block storage service for architectures that benefit from centralized volume management and iSCSI connectivity.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Elastic SAN?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduced operational burden<\/strong>: No need to deploy, patch, and manage iSCSI target servers or third-party SAN VMs.<\/li>\n<li><strong>Faster provisioning<\/strong>: Storage teams can provision volumes quickly without complex infrastructure lead time.<\/li>\n<li><strong>Better cost governance<\/strong>: Pooled capacity\/performance can reduce overprovisioning compared to \u201cone managed disk per workload\u201d sprawl (depending on usage patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Shared block storage model<\/strong>: For workloads and clustering patterns that require SAN-like behavior.<\/li>\n<li><strong>Centralized capacity and performance<\/strong>: Provision capacity once at the SAN level, then allocate volumes to applications as needed.<\/li>\n<li><strong>Network-based attachment<\/strong>: Hosts connect over iSCSI; volumes aren\u2019t tied to one VM the way a managed disk typically is.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardized storage operations<\/strong>: Volume creation, resizing, access boundaries via volume groups.<\/li>\n<li><strong>Easier fleet management<\/strong>: Large environments can manage many volumes under fewer top-level resources.<\/li>\n<li><strong>Separation of duties<\/strong>: Storage admins can manage SAN\/volume lifecycle while app teams manage OS\/filesystems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Private networking patterns<\/strong>: Data traffic can stay within Azure VNets\/private connectivity (implementation depends on current Elastic SAN networking model\u2014verify in docs).<\/li>\n<li><strong>Azure RBAC and governance<\/strong>: Use resource-level access control, tags, policies, and activity logs.<\/li>\n<li><strong>Encryption at rest<\/strong>: Azure Storage services generally encrypt data at rest by default; confirm Elastic SAN specifics in the service documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale by pooling<\/strong>: Add capacity and performance to the SAN, then distribute to volumes.<\/li>\n<li><strong>Multi-host access patterns<\/strong>: iSCSI supports multi-pathing and redundant connectivity patterns (host configuration required).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Azure Elastic SAN when you need:\n&#8211; SAN-style shared block storage patterns\n&#8211; Centralized management of many volumes\n&#8211; iSCSI connectivity in Azure\n&#8211; Predictable performance planning at a pool level<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid Azure Elastic SAN when:\n&#8211; You only need simple per-VM storage: <strong>Azure Managed Disks<\/strong> are usually simpler.\n&#8211; You need file protocols (SMB\/NFS): use <strong>Azure Files<\/strong> or <strong>Azure NetApp Files<\/strong>.\n&#8211; You require features not supported by Elastic SAN (advanced snapshot\/replication\/backup integrations, cross-region replication, etc.). Verify current feature support.\n&#8211; You need Kubernetes-native persistent volumes without custom iSCSI workflows. (Most AKS users use Azure Disk CSI or Azure Files CSI; iSCSI is possible but adds operational complexity.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Elastic SAN used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and trading (latency-sensitive databases, standardized storage governance)<\/li>\n<li>Healthcare (regulated environments, centralized control)<\/li>\n<li>Manufacturing (ERP workloads, plant systems migrating to Azure)<\/li>\n<li>Retail\/e-commerce (databases, analytics staging)<\/li>\n<li>Media and gaming (build pipelines, asset processing requiring fast block storage)<\/li>\n<li>Government (centralized governance and compliance patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building shared infrastructure<\/li>\n<li>Storage\/infra teams migrating SAN workflows to cloud<\/li>\n<li>SRE\/operations teams standardizing block storage provisioning<\/li>\n<li>DevOps teams supporting stateful services at scale (outside of purely cloud-native patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Databases and transactional systems that prefer block devices (verify best practices for your specific database)<\/li>\n<li>Legacy enterprise applications that expect SAN-backed LUNs<\/li>\n<li>Clustering solutions that use shared block storage (compatibility and support matrices must be verified)<\/li>\n<li>Build systems needing many volumes across many build agents<\/li>\n<li>Large fleets of VMs where per-VM disk management is cumbersome<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hub-and-spoke networks where shared services live in hub VNets (networking model must be verified against Elastic SAN requirements)<\/li>\n<li>Multi-tier apps with a storage tier providing block volumes to app\/data tier VMs<\/li>\n<li>\u201cStorage platform\u201d internal service where storage is offered to multiple app teams via volume groups<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production: central SAN per environment (prod\/non-prod) with strict access boundaries and monitoring<\/li>\n<li>Dev\/test: smaller SANs used to reproduce SAN-based workloads with lower cost controls (capacity\/performance kept minimal)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Azure Elastic SAN is a strong fit. Always validate workload support (OS, clustering, multipath, filesystem, and any vendor requirements).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Shared block volumes for VM clusters<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple VMs need access to shared block storage for clustering or coordinated access patterns.<\/li>\n<li><strong>Why it fits<\/strong>: iSCSI SAN model is designed for shared LUN workflows (with proper host-side coordination).<\/li>\n<li><strong>Example<\/strong>: A Windows Server cluster that requires shared disks for specific roles (verify supported architectures).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Consolidating \u201cdisk sprawl\u201d across hundreds of VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Large environments create and manage thousands of managed disks, making lifecycle and governance complex.<\/li>\n<li><strong>Why it fits<\/strong>: Elastic SAN provides pooled capacity and centralized volume management.<\/li>\n<li><strong>Example<\/strong>: A CI fleet with many ephemeral worker VMs that need fast scratch volumes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Lift-and-shift of SAN-backed enterprise apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: An on-prem app is tightly coupled to SAN volumes and expects SAN-like operational processes.<\/li>\n<li><strong>Why it fits<\/strong>: Similar operational model (LUNs\/volumes, access controls, centralized provisioning).<\/li>\n<li><strong>Example<\/strong>: Migrating a line-of-business application that documents \u201ciSCSI LUN required.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Database storage modernization (SAN model)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Database teams want dedicated volumes with predictable performance and centralized monitoring.<\/li>\n<li><strong>Why it fits<\/strong>: You can allocate volumes from a performance pool and manage changes centrally.<\/li>\n<li><strong>Example<\/strong>: A SQL Server VM deployment using separate volumes for data, logs, and temp (validate vendor guidance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) High-performance scratch or staging for ETL<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: ETL jobs need fast block storage for intermediate data sets, not long-term file sharing.<\/li>\n<li><strong>Why it fits<\/strong>: Block volumes can deliver consistent performance; volumes can be created and destroyed as pipelines change.<\/li>\n<li><strong>Example<\/strong>: Nightly batch ETL stages data on Elastic SAN volumes, then writes results to a data lake.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Standardized storage service for internal platform teams<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: App teams need storage, but platform team wants a consistent model and guardrails.<\/li>\n<li><strong>Why it fits<\/strong>: Volume groups can represent tenants\/environments; RBAC and policy can enforce standards.<\/li>\n<li><strong>Example<\/strong>: Platform team creates \u201cprod\u201d and \u201cnonprod\u201d volume groups and allocates volumes to teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Rapid provisioning of many small block volumes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Per-disk overhead makes it tedious to manage many small disks across VMs.<\/li>\n<li><strong>Why it fits<\/strong>: SAN pooling and volume creation workflows are designed for high volume.<\/li>\n<li><strong>Example<\/strong>: A lab environment that spins up dozens of training VMs, each with one dedicated volume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Migration off self-managed iSCSI target VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams run iSCSI targets on Linux\/Windows VMs, causing patching, HA, and operational overhead.<\/li>\n<li><strong>Why it fits<\/strong>: Managed service removes target server management burden.<\/li>\n<li><strong>Example<\/strong>: Replace a pair of Linux iSCSI target VMs with Elastic SAN volume groups.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Separate capacity planning from VM lifecycle<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Storage planning is hard when each VM owns its disks; resizing is frequent.<\/li>\n<li><strong>Why it fits<\/strong>: Capacity is pooled at SAN level; you can resize volumes without touching VM definitions.<\/li>\n<li><strong>Example<\/strong>: A microservices platform where stateful components come and go, but storage pool stays.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Controlled multi-tenant storage boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple teams need storage, but you must prevent accidental cross-access.<\/li>\n<li><strong>Why it fits<\/strong>: Use separate volume groups (and RBAC) to isolate teams\/environments.<\/li>\n<li><strong>Example<\/strong>: One Elastic SAN per department, one volume group per application domain.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Performance isolation by design<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Mixed workloads interfere with each other\u2019s disk performance.<\/li>\n<li><strong>Why it fits<\/strong>: Allocate performance at the SAN\/volume group level (exact controls depend on current product capabilities\u2014verify).<\/li>\n<li><strong>Example<\/strong>: Separate volume groups for latency-sensitive OLTP vs batch processing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Consistent iSCSI connectivity for specialized appliances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Some third-party VM appliances support iSCSI and are easier to integrate with LUNs than with cloud-native disk models.<\/li>\n<li><strong>Why it fits<\/strong>: iSCSI is widely supported across OSes and appliances.<\/li>\n<li><strong>Example<\/strong>: A vendor VM that only documents iSCSI LUN attachment for data storage.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on practical, commonly used capabilities of Azure Elastic SAN. Exact feature availability can vary by region or service updates\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Elastic SAN resource (pooled provisioning)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you provision storage capacity (and performance) once, then allocate volumes from that pool.<\/li>\n<li><strong>Why it matters<\/strong>: Avoids managing capacity\/performance per disk across many VMs.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster provisioning and easier capacity planning.<\/li>\n<li><strong>Caveats<\/strong>: You still need to plan for headroom, growth, and performance allocation. Pricing is based on provisioned dimensions (see Pricing section).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: Volume groups (network + administrative boundary)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Groups volumes and defines how they\u2019re exposed over the network (iSCSI target endpoints) and managed as a unit.<\/li>\n<li><strong>Why it matters<\/strong>: Clean separation of environments\/tenants and networking configuration.<\/li>\n<li><strong>Practical benefit<\/strong>: Create \u201cprod\u201d vs \u201cdev\u201d boundaries; isolate teams\/apps.<\/li>\n<li><strong>Caveats<\/strong>: Volume group networking may require specific subnet\/delegation\/private connectivity patterns. Confirm requirements in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Volumes (block devices\/LUNs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides block storage devices that hosts can format with filesystems (XFS\/ext4\/NTFS\/ReFS, etc.) or use as raw devices.<\/li>\n<li><strong>Why it matters<\/strong>: Enables enterprise and legacy apps that expect block devices.<\/li>\n<li><strong>Practical benefit<\/strong>: Familiar storage operations: partition, format, mount, resize (host steps required).<\/li>\n<li><strong>Caveats<\/strong>: Multi-host access requires correct clustering\/filesystem coordination. Block devices are not inherently \u201cshared file systems.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: iSCSI-based data plane<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Hosts connect using iSCSI initiators to iSCSI target endpoints provided by the volume group.<\/li>\n<li><strong>Why it matters<\/strong>: Standard protocol, widely supported; works across many OS types.<\/li>\n<li><strong>Practical benefit<\/strong>: Straightforward connectivity from Linux\/Windows; supports multipath with proper configuration.<\/li>\n<li><strong>Caveats<\/strong>: iSCSI security is heavily reliant on private networking and correct access controls. If CHAP or other auth features are supported, configure them\u2014verify current options.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Host-side multipath support (architecture pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: iSCSI typically supports multiple paths\/portals for redundancy and performance (host configuration).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces impact of a single network path failure and can improve throughput.<\/li>\n<li><strong>Practical benefit<\/strong>: Better resilience for critical workloads.<\/li>\n<li><strong>Caveats<\/strong>: Multipath is configured on the host OS (e.g., <code>multipath-tools<\/code> on Linux, MPIO on Windows). Misconfiguration can cause data corruption or inconsistent device names.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Resizing volumes (capacity changes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Increase volume size as needs grow (and potentially adjust SAN pool capacity).<\/li>\n<li><strong>Why it matters<\/strong>: Avoids migrations when storage needs expand.<\/li>\n<li><strong>Practical benefit<\/strong>: Scale up with minimal disruption (host filesystem resize still required).<\/li>\n<li><strong>Caveats<\/strong>: Shrinking volumes is often restricted in block storage systems; confirm what Elastic SAN supports. Always validate app\/filesystem procedure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Azure RBAC and ARM governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Control management-plane actions (create\/delete\/resize volumes, change volume groups) through Azure roles.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents unauthorized changes and supports separation of duties.<\/li>\n<li><strong>Practical benefit<\/strong>: Least privilege, auditability, policy enforcement.<\/li>\n<li><strong>Caveats<\/strong>: RBAC protects control plane; you still must enforce data-plane access via network and iSCSI configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: Monitoring via Azure Monitor (metrics\/logging)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes metrics and (depending on support) diagnostic logs for operational visibility.<\/li>\n<li><strong>Why it matters<\/strong>: Storage issues often manifest as latency, IOPS saturation, and connectivity problems.<\/li>\n<li><strong>Practical benefit<\/strong>: Alert on key SLO indicators like latency and throughput, and correlate with VM metrics.<\/li>\n<li><strong>Caveats<\/strong>: Confirm which metrics\/logs are available for Elastic SAN in your region and how to route them to Log Analytics\/Event Hub\/Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 9: Private networking patterns (typical deployment)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Keep iSCSI endpoints reachable only via your Azure virtual network(s) using private addressing\/private access.<\/li>\n<li><strong>Why it matters<\/strong>: iSCSI should not be exposed broadly.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduces attack surface and data exfiltration risk.<\/li>\n<li><strong>Caveats<\/strong>: Exact networking implementation (delegated subnet, private endpoints, allowed subnets, DNS) must follow current Elastic SAN docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 10: Automation support (CLI\/PowerShell\/ARM\/Bicep)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables infrastructure-as-code for provisioning SANs, volume groups, and volumes.<\/li>\n<li><strong>Why it matters<\/strong>: Storage should be reproducible and governed like other infrastructure.<\/li>\n<li><strong>Practical benefit<\/strong>: Standardized environments, safer changes, CI\/CD integration.<\/li>\n<li><strong>Caveats<\/strong>: Tooling evolves; verify the latest Azure CLI\/PowerShell modules and API versions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>Azure Elastic SAN has two major planes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Control plane (management)<\/strong><br\/>\n   &#8211; You create and manage Elastic SAN resources via Azure Portal\/CLI\/ARM.\n   &#8211; Operations include provisioning capacity, creating volume groups and volumes, setting access\/network configurations, and monitoring.<\/p>\n<\/li>\n<li>\n<p><strong>Data plane (I\/O path)<\/strong><br\/>\n   &#8211; Your hosts (e.g., Azure VMs) connect using <strong>iSCSI<\/strong> to the SAN\u2019s target endpoints.\n   &#8211; Reads\/writes traverse your Azure network path to the iSCSI target and storage backend.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Provisioning<\/strong>:<br\/>\n  User \u2192 Azure Resource Manager \u2192 Elastic SAN resource provider \u2192 Elastic SAN created\/updated.<\/li>\n<li><strong>Attachment\/IO<\/strong>:<br\/>\n  VM (iSCSI initiator) \u2192 VNet \u2192 iSCSI target endpoints (volume group) \u2192 Volume storage.<\/li>\n<li><strong>Monitoring<\/strong>:<br\/>\n  Elastic SAN emits metrics\/logs \u2192 Azure Monitor \u2192 alerts\/dashboards \u2192 ITSM\/incident workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related Azure services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Azure Virtual Network (VNet)<\/strong>: required for private connectivity patterns.\n&#8211; <strong>Azure VMs<\/strong>: typical compute initiators for iSCSI volumes.\n&#8211; <strong>Azure Monitor + Log Analytics<\/strong>: monitoring and diagnostics aggregation.\n&#8211; <strong>Azure Policy<\/strong>: enforce tags, allowed regions, required diagnostic settings (policy coverage varies; validate).\n&#8211; <strong>Microsoft Defender for Cloud<\/strong>: posture management (coverage depends on resource type support).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Resource Manager for provisioning and governance.<\/li>\n<li>Azure networking for connectivity and isolation.<\/li>\n<li>Azure Monitor for metrics\/logging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Management plane<\/strong>: Azure AD + Azure RBAC controls who can create\/modify SAN resources.<\/li>\n<li><strong>Data plane<\/strong>: iSCSI connectivity is typically protected by private networking and access rules. If iSCSI authentication (e.g., CHAP) is supported, use it\u2014verify in current Elastic SAN docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (practical view)<\/h3>\n\n\n\n<p>Most designs follow these principles:\n&#8211; Keep Elastic SAN endpoints <strong>private<\/strong> in a dedicated subnet.\n&#8211; Restrict which subnets\/hosts can reach the iSCSI target endpoints.\n&#8211; Allow required traffic (typically TCP 3260 for iSCSI) within trusted VNets.<\/p>\n\n\n\n<p>Because the exact Elastic SAN network configuration model can change (delegated subnet vs private endpoint vs network rules), <strong>follow the current \u201cNetworking\u201d section of the official docs<\/strong>:\nhttps:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track latency, IOPS, throughput, queue depth indicators (as provided).<\/li>\n<li>Use Azure Activity Log for who changed what (RBAC-protected operations).<\/li>\n<li>Configure diagnostic settings (if supported) to Log Analytics.<\/li>\n<li>Enforce tags (cost center, environment, owner, data classification).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  subgraph AzureVNet[Azure Virtual Network]\n    VM[Azure VM\\n(iSCSI initiator)]\n  end\n\n  subgraph ElasticSAN[Azure Elastic SAN]\n    VG[Volume Group\\n(iSCSI target endpoints)]\n    VOL[Volume (LUN)]\n  end\n\n  VM -- \"iSCSI (TCP 3260)\\nread\/write\" --&gt; VG --&gt; VOL\n  Admin[Admin\/CI Pipeline] -- \"ARM\/Portal\/CLI\" --&gt; ElasticSAN\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Mgmt[Management Plane]\n    AAD[Azure AD]\n    RBAC[Azure RBAC]\n    ARM[Azure Resource Manager]\n    Policy[Azure Policy]\n  end\n\n  subgraph Net[Azure Networking]\n    Hub[Hub VNet]\n    Spoke1[Spoke VNet: App\/Data]\n    DNS[Private DNS (if required)]\n  end\n\n  subgraph Compute[Compute Layer]\n    VM1[VMs \/ Cluster Nodes\\nLinux\/Windows iSCSI initiators]\n    VM2[Batch\/ETL Workers]\n  end\n\n  subgraph Storage[Storage Layer]\n    ESAN[Azure Elastic SAN]\n    VG1[Volume Group: prod]\n    VG2[Volume Group: nonprod]\n    V1[Volumes: data\/log\/temp]\n    V2[Volumes: scratch]\n  end\n\n  subgraph Ops[Operations]\n    Mon[Azure Monitor Metrics]\n    LA[Log Analytics Workspace]\n    Alert[Alerts\/Action Groups]\n  end\n\n  AAD --&gt; RBAC --&gt; ARM --&gt; ESAN\n  Policy --&gt; ESAN\n\n  Hub --- Spoke1\n  Spoke1 --- Compute\n  Compute -- \"iSCSI (TCP 3260)\\nMultipath recommended\" --&gt; VG1 --&gt; V1\n  Compute -- \"iSCSI (TCP 3260)\" --&gt; VG2 --&gt; V2\n\n  ESAN --&gt; Mon --&gt; Alert\n  ESAN --&gt; LA\n  DNS --- Spoke1\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/subscription\/tenant requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong>.<\/li>\n<li>Ability to create resources in a resource group in a region that supports Azure Elastic SAN.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum, you typically need:\n&#8211; <strong>Contributor<\/strong> on the resource group (for creating SAN, networks, and VM), or more scoped roles:\n  &#8211; Roles that can create\/manage Elastic SAN resources (service-specific roles may exist\u2014verify).\n  &#8211; <strong>Network Contributor<\/strong> for VNet\/subnet changes.\n  &#8211; <strong>Virtual Machine Contributor<\/strong> for VM creation.<\/p>\n\n\n\n<p>Principle of least privilege:\n&#8211; Storage admins: can manage Elastic SAN and volume groups\/volumes.\n&#8211; App\/ops teams: can connect and format volumes inside the OS but not delete SAN resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Elastic SAN is a paid service. Ensure your subscription is allowed to create it (no policy blocks) and has a valid billing method.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Portal (web)<\/li>\n<li>Azure CLI (recommended for scripting): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/li>\n<li>If <code>az elastic-san<\/code> commands aren\u2019t available in your CLI version, you may need an extension or an update. Verify via:\n    <code>bash\n    az version\n    az elastic-san -h<\/code><\/li>\n<li>SSH client (for Linux VM access)<\/li>\n<li>On the VM:<\/li>\n<li>Linux: <code>open-iscsi<\/code> package; optionally <code>multipath-tools<\/code>.<\/li>\n<li>Windows: iSCSI Initiator + (optionally) MPIO.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Elastic SAN is not available in every region. Check:<\/li>\n<li>Product availability: https:\/\/azure.microsoft.com\/explore\/global-infrastructure\/products-by-region\/<\/li>\n<li>Elastic SAN documentation region notes: https:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expect limits such as max SANs per subscription\/region, max volume groups, max volumes, max capacity, and performance ceilings.<\/li>\n<li>Quotas can change; verify current limits in the official docs and in Azure Portal quota pages for your subscription\/region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Virtual Network (VNet) and subnets for compute and Elastic SAN connectivity.<\/li>\n<li>Azure VM(s) (for this lab) to act as iSCSI initiators.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Elastic SAN pricing is <strong>usage- and provisioning-based<\/strong>. Exact rates vary by region and may change over time, so use official sources for current numbers.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/azure.microsoft.com\/pricing\/details\/elastic-san\/  <\/li>\n<li>Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>Typical cost dimensions for managed SAN-style services include (verify exact Elastic SAN meters on the pricing page):\n1. <strong>Provisioned capacity<\/strong> (how much SAN storage you allocate)\n2. <strong>Provisioned performance<\/strong> (IOPS and\/or throughput capacity, often configurable separately from capacity)\n3. <strong>Snapshots \/ backup capacity<\/strong> (if snapshot features are enabled and billed)\n4. <strong>Networking components<\/strong> that your architecture requires (indirect):\n   &#8211; Private Link \/ private endpoints (if used)\n   &#8211; VNet peering (if spanning VNets)\n   &#8211; NAT gateways, firewalls, or routing appliances (if used)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Elastic SAN generally does <strong>not<\/strong> have a meaningful free tier for production usage. You might get limited free Azure credits via trials, Visual Studio subscriptions, or training subscriptions, but the service itself is billed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Provisioned SAN size<\/strong>: Larger pools increase cost even if not fully used.<\/li>\n<li><strong>Provisioned performance<\/strong>: Higher IOPS\/throughput allocations increase cost.<\/li>\n<li><strong>Number of environments<\/strong>: Multiple SANs (prod\/nonprod) multiply fixed provisioning charges.<\/li>\n<li><strong>Operational design<\/strong>: If you add Private Link, firewalls, or complex routing, networking costs can exceed storage costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute<\/strong>: VMs that consume Elastic SAN volumes are billed separately.<\/li>\n<li><strong>Backups<\/strong>: If you implement backups via app-level tools or snapshots + copy workflows, storage and data movement costs add up.<\/li>\n<li><strong>Monitoring<\/strong>: Log Analytics ingestion\/retention can be significant if diagnostics are verbose.<\/li>\n<li><strong>Cross-zone or cross-region traffic<\/strong>: If your design causes inter-zone or inter-region data transfer, you may incur bandwidth charges and latency penalties (verify Azure bandwidth pricing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In-region VNet traffic patterns are usually the cheapest and lowest latency.<\/li>\n<li>If you connect from a different VNet via peering, verify:<\/li>\n<li>Whether Elastic SAN supports your desired topology.<\/li>\n<li>Whether peering\/egress charges apply.<\/li>\n<li>Whether additional DNS\/private endpoint configurations are needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical guidance)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size <strong>capacity<\/strong>: Don\u2019t provision large pools \u201cjust in case\u201d without growth plans.<\/li>\n<li>Right-size <strong>performance<\/strong>: Increase IOPS\/throughput only when metrics show sustained saturation.<\/li>\n<li>Separate environments: Use smaller SAN for dev\/test with strict auto-shutdown for VMs.<\/li>\n<li>Use tagging and budgets:<\/li>\n<li>Tags: <code>env<\/code>, <code>app<\/code>, <code>costCenter<\/code>, <code>owner<\/code>, <code>dataClassification<\/code><\/li>\n<li>Azure Budgets + alerts for storage and monitoring spend<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A minimal lab typically includes:\n&#8211; 1 small Elastic SAN with minimal provisioned capacity\/performance (service minimums apply)\n&#8211; 1 small Linux VM for a few hours\n&#8211; Minimal logging retention<\/p>\n\n\n\n<p>Because exact prices are region- and meter-dependent, build an estimate with the Azure Pricing Calculator using:\n&#8211; Your target region\n&#8211; Expected provisioned capacity\n&#8211; Expected performance units (IOPS\/throughput as applicable)\n&#8211; Expected runtime (for VM)\n&#8211; Monitoring retention (Log Analytics)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, estimate:\n&#8211; SAN provisioned capacity for 12\u201324 months growth\n&#8211; Performance headroom for peak workloads\n&#8211; Redundant host connectivity (may require extra networking components)\n&#8211; Backup strategy costs (snapshot storage, backup vaults, or app-native replication)\n&#8211; Monitoring and alerting (Log Analytics volume, retention, dashboards)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab provisions a small Azure environment and attaches an Azure Elastic SAN volume to a Linux VM over iSCSI, formats it, mounts it, and validates I\/O.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create an Azure Elastic SAN, volume group, and volume<\/li>\n<li>Connect a Linux VM to the volume using iSCSI<\/li>\n<li>Format and mount the block device<\/li>\n<li>Validate read\/write<\/li>\n<li>Clean up resources safely<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:\n&#8211; Resource group\n&#8211; VNet with:\n  &#8211; <code>subnet-vm<\/code> (VM lives here)\n  &#8211; <code>subnet-esan<\/code> (used for Elastic SAN volume group connectivity; may require delegation per current docs)\n&#8211; Ubuntu VM\n&#8211; Azure Elastic SAN + volume group + volume\n&#8211; iSCSI connection from VM to Elastic SAN<\/p>\n\n\n\n<p>Cost control tips:\n&#8211; Use one small VM size\n&#8211; Keep SAN capacity\/performance minimal\n&#8211; Delete everything at the end<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a resource group and network (Azure CLI)<\/h3>\n\n\n\n<p>1) Sign in and select your subscription:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account show\naz account set --subscription \"&lt;SUBSCRIPTION_ID_OR_NAME&gt;\"\n<\/code><\/pre>\n\n\n\n<p>2) Set variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">LOCATION=\"eastus\"              # choose a region that supports Azure Elastic SAN\nRG=\"rg-elasticsan-lab\"\nVNET=\"vnet-elasticsan-lab\"\nSUBNET_VM=\"subnet-vm\"\nSUBNET_ESAN=\"subnet-esan\"\n<\/code><\/pre>\n\n\n\n<p>3) Create the resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group create --name \"$RG\" --location \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Resource group exists in your chosen region.<\/p>\n\n\n\n<p>4) Create the VNet and VM subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet create \\\n  --resource-group \"$RG\" \\\n  --name \"$VNET\" \\\n  --address-prefixes 10.50.0.0\/16 \\\n  --subnet-name \"$SUBNET_VM\" \\\n  --subnet-prefixes 10.50.1.0\/24\n<\/code><\/pre>\n\n\n\n<p>5) Create the Elastic SAN subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet create \\\n  --resource-group \"$RG\" \\\n  --vnet-name \"$VNET\" \\\n  --name \"$SUBNET_ESAN\" \\\n  --address-prefixes 10.50.2.0\/24\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; VNet with two subnets is ready.<\/p>\n\n\n\n<blockquote>\n<p>Note: Elastic SAN volume group networking may require a <strong>delegated subnet<\/strong> and\/or specific network settings. The safest approach is to apply the required delegation in the Azure Portal during volume group creation (it will show the exact delegation name). Follow current docs: https:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a Linux VM (Azure CLI)<\/h3>\n\n\n\n<p>1) Create an Ubuntu VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM_NAME=\"vm-iscsi-initiator-01\"\nADMIN_USER=\"azureuser\"\n\naz vm create \\\n  --resource-group \"$RG\" \\\n  --name \"$VM_NAME\" \\\n  --image Ubuntu2204 \\\n  --admin-username \"$ADMIN_USER\" \\\n  --generate-ssh-keys \\\n  --vnet-name \"$VNET\" \\\n  --subnet \"$SUBNET_VM\" \\\n  --public-ip-sku Standard\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; VM is created and you receive public IP info in the output.<\/p>\n\n\n\n<p>2) Capture the VM public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM_IP=$(az vm show -d -g \"$RG\" -n \"$VM_NAME\" --query publicIps -o tsv)\necho \"$VM_IP\"\n<\/code><\/pre>\n\n\n\n<p>3) SSH to the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh ${ADMIN_USER}@${VM_IP}\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; You have a shell on the VM.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create Azure Elastic SAN, volume group, and volume (Azure Portal)<\/h3>\n\n\n\n<p>Because Elastic SAN fields and CLI parameters can evolve, this lab uses the Azure Portal for the service-specific provisioning steps to keep the workflow executable.<\/p>\n\n\n\n<p>1) In the Azure Portal, go to <strong>Create a resource<\/strong> \u2192 search for <strong>Azure Elastic SAN<\/strong> \u2192 <strong>Create<\/strong>.<\/p>\n\n\n\n<p>2) In <strong>Basics<\/strong>:\n&#8211; Subscription: your subscription\n&#8211; Resource group: <code>rg-elasticsan-lab<\/code>\n&#8211; Name: <code>esanlab01<\/code> (must be unique in the RG)\n&#8211; Region: same region as the VM (e.g., East US)\n&#8211; Configure <strong>capacity<\/strong> and <strong>performance<\/strong> at minimal values allowed in the portal.<\/p>\n\n\n\n<p>3) Create a <strong>volume group<\/strong>:\n&#8211; Go to your Elastic SAN \u2192 <strong>Volume groups<\/strong> \u2192 <strong>+ Create<\/strong>\n&#8211; Name: <code>vg-lab-01<\/code>\n&#8211; Network:\n  &#8211; Select your VNet: <code>vnet-elasticsan-lab<\/code>\n  &#8211; Select subnet: <code>subnet-esan<\/code>\n  &#8211; If the portal prompts for subnet delegation or requires changes, allow it (this is common for managed service endpoint injection patterns).<br\/>\n  &#8211; Restrict access to only required VNets\/subnets as recommended by the portal\/docs.<\/p>\n\n\n\n<p>4) Create a <strong>volume<\/strong> in the volume group:\n&#8211; Go to volume group <code>vg-lab-01<\/code> \u2192 <strong>Volumes<\/strong> \u2192 <strong>+ Create<\/strong>\n&#8211; Volume name: <code>vol-lab-01<\/code>\n&#8211; Size: choose a small size for the lab (e.g., tens of GiB; use portal minimums)\n&#8211; Keep defaults unless you have a specific need.<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; You have one Elastic SAN, one volume group, and one volume in a <strong>Succeeded<\/strong> provisioning state.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Obtain iSCSI connection details (Azure Portal)<\/h3>\n\n\n\n<p>1) In the Azure Portal, open:\n&#8211; Elastic SAN \u2192 Volume group <code>vg-lab-01<\/code> \u2192 Volume <code>vol-lab-01<\/code><\/p>\n\n\n\n<p>2) Find the <strong>Connect<\/strong> \/ <strong>iSCSI<\/strong> connection panel (naming can differ slightly).\nCapture:\n&#8211; One or more <strong>target portal IPs\/FQDNs<\/strong>\n&#8211; The <strong>target IQN<\/strong> (iSCSI Qualified Name)\n&#8211; The <strong>LUN<\/strong> identifier if shown (often <code>0<\/code> for a single volume)<\/p>\n\n\n\n<p>Expected outcome:\n&#8211; You have the connection details required for <code>iscsiadm<\/code> on Linux.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Connect from Linux to the Elastic SAN volume (Linux commands)<\/h3>\n\n\n\n<p>Run the following on the VM (SSH session).<\/p>\n\n\n\n<p>1) Install iSCSI tools:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get install -y open-iscsi\nsudo systemctl enable --now iscsid\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; <code>iscsid<\/code> service is running.<\/p>\n\n\n\n<p>2) (Optional but recommended) Install multipath tools:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get install -y multipath-tools\nsudo systemctl enable --now multipathd\n<\/code><\/pre>\n\n\n\n<p>3) Discover targets (use one portal IP from the portal):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Replace with one target portal IP\/FQDN from Azure Portal:\nPORTAL=\"&lt;TARGET_PORTAL_IP_OR_FQDN&gt;\"\n\nsudo iscsiadm -m discovery -t sendtargets -p \"$PORTAL\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Output lists one or more targets including an IQN.<\/p>\n\n\n\n<p>4) Log in to the target (replace IQN with your target IQN):<\/p>\n\n\n\n<pre><code class=\"language-bash\">IQN=\"&lt;TARGET_IQN_FROM_PORTAL&gt;\"\n\nsudo iscsiadm -m node -T \"$IQN\" -p \"$PORTAL\" --login\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Successful login message; a new block device appears.<\/p>\n\n\n\n<p>5) Make the login persistent across reboots:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo iscsiadm -m node -T \"$IQN\" -p \"$PORTAL\" --op update -n node.startup -v automatic\n<\/code><\/pre>\n\n\n\n<p>6) Identify the new disk:<\/p>\n\n\n\n<pre><code class=\"language-bash\">lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL\n<\/code><\/pre>\n\n\n\n<p>Look for a new disk (often <code>sdb<\/code> or similar) with the size you created.<\/p>\n\n\n\n<p>If multipath is enabled, check:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo multipath -ll || true\nls -l \/dev\/mapper\/ || true\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; You can identify the device path to format (either <code>\/dev\/sdX<\/code> or <code>\/dev\/mapper\/mpathX<\/code>).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Partition, format, and mount the volume<\/h3>\n\n\n\n<blockquote>\n<p>Choose <strong>one<\/strong> device path carefully. Formatting the wrong disk will destroy data.<\/p>\n<\/blockquote>\n\n\n\n<p>1) Set a variable for the device (examples shown; pick the correct one):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example if the new disk is \/dev\/sdb (single path)\nDEV=\"\/dev\/sdb\"\n\n# Example if multipath created a device like \/dev\/mapper\/mpatha\n# DEV=\"\/dev\/mapper\/mpatha\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a GPT partition table and a single partition:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo parted -s \"$DEV\" mklabel gpt\nsudo parted -s \"$DEV\" mkpart primary 0% 100%\n<\/code><\/pre>\n\n\n\n<p>3) Format it (XFS is common for data volumes; ext4 is also fine):<\/p>\n\n\n\n<pre><code class=\"language-bash\">PART=\"${DEV}1\"\nsudo mkfs.xfs -f \"$PART\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Filesystem created successfully.<\/p>\n\n\n\n<p>4) Mount the filesystem:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkdir -p \/mnt\/esan\nsudo mount \"$PART\" \/mnt\/esan\ndf -h \/mnt\/esan\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; <code>\/mnt\/esan<\/code> shows mounted capacity.<\/p>\n\n\n\n<p>5) Make it persistent in <code>\/etc\/fstab<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">UUID=$(sudo blkid -s UUID -o value \"$PART\")\necho \"UUID=$UUID \/mnt\/esan xfs defaults,_netdev,nofail 0 2\" | sudo tee -a \/etc\/fstab\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; VM will remount after reboot ( <code>_netdev<\/code> helps ensure network is up before mounting).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run these checks on the VM:<\/p>\n\n\n\n<p>1) Confirm iSCSI session:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo iscsiadm -m session\n<\/code><\/pre>\n\n\n\n<p>2) Confirm mount is writable:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo sh -c 'echo \"hello from Elastic SAN $(date)\" &gt; \/mnt\/esan\/hello.txt'\ncat \/mnt\/esan\/hello.txt\n<\/code><\/pre>\n\n\n\n<p>3) (Optional) Quick I\/O test (small and safe):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get install -y fio\nfio --name=quicktest --directory=\/mnt\/esan --size=256M --bs=64k --rw=write --iodepth=8 --numjobs=1 --time_based --runtime=30\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Write test completes without I\/O errors.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common problems and fixes:<\/p>\n\n\n\n<p>1) <strong>Discovery returns nothing \/ cannot reach portal<\/strong>\n&#8211; Verify the VM and Elastic SAN are in the <strong>same region<\/strong> (recommended).\n&#8211; Verify volume group networking is correctly configured (subnet selection and any required delegation).\n&#8211; Ensure no NSG\/route table blocks traffic from <code>subnet-vm<\/code> to <code>subnet-esan<\/code>.\n&#8211; Confirm you used the correct portal IP\/FQDN from the <strong>Connect<\/strong> panel.<\/p>\n\n\n\n<p>2) <strong><code>iscsiadm --login<\/code> fails<\/strong>\n&#8211; Re-check the target IQN.\n&#8211; If authentication (e.g., CHAP) is configured, ensure credentials match (verify whether Elastic SAN supports and how to configure it).\n&#8211; Check system logs:\n  <code>bash\n  sudo journalctl -u iscsid --no-pager | tail -n 200<\/code><\/p>\n\n\n\n<p>3) <strong>Disk appears but mount is unstable after reboot<\/strong>\n&#8211; Ensure <code>node.startup = automatic<\/code> is set.\n&#8211; Ensure <code>\/etc\/fstab<\/code> includes <code>_netdev,nofail<\/code>.\n&#8211; If multipath is used, ensure you mount the <strong>multipath device\/partition<\/strong>, not a single path.<\/p>\n\n\n\n<p>4) <strong>Multipath shows multiple devices \/ wrong device naming<\/strong>\n&#8211; Use <code>\/dev\/disk\/by-id\/<\/code> or <code>\/dev\/mapper\/<\/code> stable names rather than <code>\/dev\/sdX<\/code>.\n&#8211; Validate <code>multipath -ll<\/code> output and confirm only one multipath device per LUN.<\/p>\n\n\n\n<p>5) <strong>Performance lower than expected<\/strong>\n&#8211; Check if you\u2019re hitting provisioned performance limits (IOPS\/throughput).\n&#8211; Check VM size limits and NIC throughput.\n&#8211; Confirm your test pattern and filesystem alignment.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, clean up in this order.<\/p>\n\n\n\n<p>On the VM:\n1) Unmount:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo umount \/mnt\/esan\n<\/code><\/pre>\n\n\n\n<p>2) Remove the fstab entry (optional):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo sed -i '\\|\/mnt\/esan|d' \/etc\/fstab\n<\/code><\/pre>\n\n\n\n<p>3) Log out and delete iSCSI node records:<\/p>\n\n\n\n<pre><code class=\"language-bash\">PORTAL=\"&lt;TARGET_PORTAL_IP_OR_FQDN&gt;\"\nIQN=\"&lt;TARGET_IQN_FROM_PORTAL&gt;\"\n\nsudo iscsiadm -m node -T \"$IQN\" -p \"$PORTAL\" --logout || true\nsudo iscsiadm -m node -o delete -T \"$IQN\" -p \"$PORTAL\" || true\n<\/code><\/pre>\n\n\n\n<p>In Azure:\n1) Delete the volume (<code>vol-lab-01<\/code>)\n2) Delete the volume group (<code>vg-lab-01<\/code>)\n3) Delete the Elastic SAN (<code>esanlab01<\/code>)\n4) Delete the resource group (fastest way to ensure everything is removed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete --name \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; All lab resources are deleted and billing stops (after Azure finalizes deletion).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep it regional<\/strong>: Place compute and Elastic SAN in the same Azure region for latency and cost predictability.<\/li>\n<li><strong>Separate subnets<\/strong>:<\/li>\n<li>One subnet for initiators (VMs)<\/li>\n<li>One dedicated subnet for Elastic SAN volume group endpoints if required by the service model<\/li>\n<li><strong>Design for multipath<\/strong>: Use redundant paths and host-side multipath where supported and appropriate.<\/li>\n<li><strong>Use volume groups as boundaries<\/strong>: Split by environment (prod\/nonprod) or tenant\/application domain.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>least privilege<\/strong>:<\/li>\n<li>Storage admins: manage SAN\/volume groups\/volumes<\/li>\n<li>Operators: read-only monitoring access<\/li>\n<li>App teams: no delete permissions on SAN resources<\/li>\n<li>Use <strong>resource locks<\/strong> on production SAN and volume groups to prevent accidental deletion.<\/li>\n<li>Enforce tag compliance via Azure Policy if possible (or CI checks).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start small and scale:<\/li>\n<li>Avoid large pools without a growth plan.<\/li>\n<li>Monitor performance to avoid over-provisioning:<\/li>\n<li>Increase provisioned performance only after confirming sustained bottlenecks.<\/li>\n<li>Use budgets and alerts:<\/li>\n<li>Alert on unexpected increases in storage and monitoring spend.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Validate VM and network limits:<\/li>\n<li>VM size can cap network throughput and IOPS.<\/li>\n<li>Use appropriate filesystem and mount options:<\/li>\n<li>For Linux, XFS is common; ensure correct alignment and queue settings when recommended.<\/li>\n<li>Benchmark realistically:<\/li>\n<li>Use <code>fio<\/code> patterns matching your production workload (block size, read\/write mix, concurrency, sync mode).<\/li>\n<li>Avoid noisy neighbors in the OS:<\/li>\n<li>Ensure your app and OS tuning do not create unnecessary sync writes if not needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use multipath for higher resilience (host configuration).<\/li>\n<li>Plan maintenance windows for major resizing or configuration changes.<\/li>\n<li>Implement backups at the appropriate layer:<\/li>\n<li>App-consistent backups (database-native)<\/li>\n<li>Filesystem snapshots (if supported)<br\/>\n  Verify the best approach for Elastic SAN and your workload.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize naming:<\/li>\n<li><code>esan-&lt;org&gt;-&lt;env&gt;-&lt;region&gt;-01<\/code><\/li>\n<li><code>vg-&lt;app&gt;-&lt;env&gt;<\/code><\/li>\n<li><code>vol-&lt;app&gt;-&lt;purpose&gt;-&lt;nn&gt;<\/code><\/li>\n<li>Instrument everything:<\/li>\n<li>Azure Monitor alerts for latency\/IOPS saturation<\/li>\n<li>VM metrics for disk queue\/IO wait<\/li>\n<li>Document runbooks:<\/li>\n<li>\u201cHow to add a new volume\u201d<\/li>\n<li>\u201cHow to resize a volume and filesystem\u201d<\/li>\n<li>\u201cHow to recover from iSCSI login issues\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<p>Recommended tags:\n&#8211; <code>env<\/code> (prod\/dev\/test)\n&#8211; <code>app<\/code>\n&#8211; <code>owner<\/code>\n&#8211; <code>costCenter<\/code>\n&#8211; <code>dataClassification<\/code>\n&#8211; <code>criticality<\/code>\n&#8211; <code>rpo<\/code> \/ <code>rto<\/code> (optional)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure AD + Azure RBAC<\/strong> secures management operations:<\/li>\n<li>Create\/modify\/delete Elastic SAN resources<\/li>\n<li>Create volume groups\/volumes<\/li>\n<li>Update networking settings<\/li>\n<li>Use <strong>separation of duties<\/strong>:<\/li>\n<li>Storage operators should not automatically have Owner rights.<\/li>\n<li>Prefer <strong>managed identities<\/strong> for automation (CI\/CD) rather than user credentials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Encryption at rest<\/strong>: Azure Storage services typically encrypt at rest by default using platform-managed keys; verify Elastic SAN encryption specifics and whether customer-managed keys are supported for your scenario.<\/li>\n<li><strong>Encryption in transit<\/strong>: iSCSI traffic is not inherently encrypted like TLS. Security usually relies on:<\/li>\n<li>Private networking and isolation<\/li>\n<li>Optional iSCSI authentication features (e.g., CHAP) if supported<br\/>\n  Confirm current Elastic SAN capabilities and recommendations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not expose iSCSI endpoints publicly.<\/li>\n<li>Restrict access to:<\/li>\n<li>Approved VNets\/subnets<\/li>\n<li>Approved hosts<\/li>\n<li>Consider additional controls:<\/li>\n<li>NSGs with minimal required rules (be careful not to block required service behavior)<\/li>\n<li>Azure Firewall\/NVA only if your design requires inspection (it may add latency)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If iSCSI authentication secrets are used (CHAP or similar), store them securely:<\/li>\n<li>Azure Key Vault for secret storage<\/li>\n<li>Do not hardcode in scripts or images<\/li>\n<li>Rotate secrets and document rotation procedures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Azure Activity Log<\/strong> to track control-plane changes.<\/li>\n<li>Enable diagnostic settings for Elastic SAN if available.<\/li>\n<li>Log host-side events:<\/li>\n<li>Linux: <code>journalctl -u iscsid<\/code>, multipath logs<\/li>\n<li>Windows: Event Viewer iSCSI\/MPIO logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Classify data and align with required controls (encryption, network isolation, access logging).<\/li>\n<li>Validate service compliance offerings and certifications in Azure compliance documentation (service-by-service coverage can vary).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overly broad RBAC (giving too many users Contributor\/Owner)<\/li>\n<li>Flat networks where any VM can reach storage endpoints<\/li>\n<li>No monitoring\/alerts for performance saturation (can become a security issue if it impacts availability)<\/li>\n<li>No deletion protection (locks) for production SAN resources<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use private networking only.<\/li>\n<li>Enforce least privilege and locks.<\/li>\n<li>Centralize logging and alerting.<\/li>\n<li>Treat iSCSI volumes like critical infrastructure: document, monitor, and change-control.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Azure Elastic SAN is a specialized service, confirm these areas early:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (verify in docs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Region availability<\/strong>: Not all regions support the service.<\/li>\n<li><strong>Feature availability<\/strong>: Some features may be in preview or not supported in all regions\/SKUs.<\/li>\n<li><strong>Snapshots\/backup<\/strong>: Snapshot and backup integrations can differ from managed disks\u2014verify current support.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maximum number of SANs per subscription\/region<\/li>\n<li>Maximum volumes per volume group \/ per SAN<\/li>\n<li>Maximum volume size<\/li>\n<li>Performance ceilings (IOPS\/throughput)<\/li>\n<li>Portal-enforced minimums for capacity\/performance provisioning<\/li>\n<\/ul>\n\n\n\n<p>All of these can change\u2014verify current values in:\nhttps:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cross-region access is generally not recommended for low-latency block I\/O. Even if technically possible via networking, it can be costly and slow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provisioned performance can be a major cost driver even if average IOPS is low.<\/li>\n<li>Private networking components (Private Link, firewalls, NAT) can add meaningful cost.<\/li>\n<li>Log Analytics ingestion\/retention costs can grow quickly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multipath requires correct OS configuration.<\/li>\n<li>Some clustered filesystems and cluster stacks have strict requirements\u2014validate with vendor documentation and testing.<\/li>\n<li>Device naming can change if not using stable identifiers (<code>\/dev\/disk\/by-id<\/code>, UUIDs, multipath aliases).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Resizing storage usually requires:<\/li>\n<li>Azure-side resize<\/li>\n<li>OS rescan<\/li>\n<li>Partition resize (if used)<\/li>\n<li>Filesystem resize<br\/>\n  Missing one step can make capacity appear unchanged.<\/li>\n<li>iSCSI login persistence:<\/li>\n<li>Must ensure services start and <code>node.startup=automatic<\/code> is set<\/li>\n<li>Use <code>_netdev<\/code> in fstab to avoid boot failures<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from managed disks to iSCSI volumes is a migration project:<\/li>\n<li>Data copy, downtime planning, filesystem changes, app reconfiguration<\/li>\n<li>Moving from on-prem SAN may require:<\/li>\n<li>iSCSI initiator differences<\/li>\n<li>Windows\/Linux multipath differences<\/li>\n<li>Different snapshot\/backup model<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Elastic SAN like a managed platform service: you control configuration and usage, but not the underlying storage fabric.<\/li>\n<li>Follow Azure\u2019s published SLA, support boundaries, and documented maintenance behaviors.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Elastic SAN is not the default choice for every storage need. Use this comparison to decide.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Elastic SAN<\/strong><\/td>\n<td>SAN-style shared block storage via iSCSI<\/td>\n<td>Pooled capacity\/performance, centralized volume management, iSCSI standard protocol<\/td>\n<td>Added complexity vs managed disks; iSCSI ops and multipath required; feature set varies<\/td>\n<td>You need SAN-like LUN workflows and centralized block storage<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Managed Disks<\/strong><\/td>\n<td>Per-VM block storage (most VM workloads)<\/td>\n<td>Very simple, tight VM integration, broad ecosystem support<\/td>\n<td>Disk sprawl in large fleets; not SAN-style shared model<\/td>\n<td>Default for VM-based apps unless you specifically need SAN behavior<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Files (SMB\/NFS)<\/strong><\/td>\n<td>Shared file storage<\/td>\n<td>Easy sharing across hosts, simple mounts<\/td>\n<td>File semantics (not raw block), performance\/latency differs from block<\/td>\n<td>You need shared file access rather than block devices<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure NetApp Files<\/strong><\/td>\n<td>Enterprise NFS\/SMB (and advanced storage features)<\/td>\n<td>High performance file storage, mature enterprise features<\/td>\n<td>Cost model can be higher; different operational model<\/td>\n<td>Enterprise file workloads and advanced data management needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed iSCSI target on Azure VMs<\/strong><\/td>\n<td>Custom SAN features or tight control<\/td>\n<td>Full control, can use open-source stacks<\/td>\n<td>You manage HA, patching, scaling, security<\/td>\n<td>Only when managed services don\u2019t meet requirements and you accept ops burden<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS EBS<\/strong> (other cloud)<\/td>\n<td>Per-instance block storage in AWS<\/td>\n<td>Mature, simple, strong integration<\/td>\n<td>AWS-only; not SAN-pool model<\/td>\n<td>If you are on AWS and need per-instance block storage<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS FSx for NetApp ONTAP<\/strong> (other cloud)<\/td>\n<td>Managed NetApp storage (file + iSCSI LUNs)<\/td>\n<td>Enterprise ONTAP features<\/td>\n<td>Different cost\/ops model; AWS-only<\/td>\n<td>If you need NetApp ONTAP features and are on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Persistent Disk<\/strong> (other cloud)<\/td>\n<td>Per-VM block storage in GCP<\/td>\n<td>Simple, integrated<\/td>\n<td>GCP-only; not SAN-pool model<\/td>\n<td>If you are on GCP and need per-VM block storage<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Centralized storage platform for regulated workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A regulated enterprise has many VM-based applications that require block storage and a storage team that must enforce strict access boundaries, auditing, and standardized provisioning.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>One Azure Elastic SAN per region per environment (prod\/nonprod)<\/li>\n<li>Volume groups per business unit\/application domain<\/li>\n<li>Dedicated subnets for SAN connectivity<\/li>\n<li>Multipath configured on all critical VMs<\/li>\n<li>Azure Monitor alerts on latency and saturation<\/li>\n<li>Azure Policy enforcing tags and required diagnostic settings (where supported)<\/li>\n<li><strong>Why Azure Elastic SAN was chosen<\/strong>:<\/li>\n<li>Centralized pool model reduces disk sprawl<\/li>\n<li>SAN-like provisioning maps to existing storage processes<\/li>\n<li>Private network connectivity supports security requirements<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster provisioning (hours to minutes)<\/li>\n<li>More consistent performance governance<\/li>\n<li>Improved auditability of storage changes via Azure Activity Log and RBAC<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Migrating a legacy app that requires iSCSI<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team is migrating a legacy VM-based product from on-prem where it used iSCSI LUNs; rewriting for cloud-native storage would delay the move.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Single Elastic SAN in one region<\/li>\n<li>One volume group for production<\/li>\n<li>Two Linux VMs attached via iSCSI (with careful application-level coordination)<\/li>\n<li>Simple monitoring and a runbook for reconnect\/rescan<\/li>\n<li><strong>Why Azure Elastic SAN was chosen<\/strong>:<\/li>\n<li>Minimal infrastructure management compared to self-hosted iSCSI<\/li>\n<li>Faster migration path that preserves the app\u2019s storage assumptions<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Migration completed without redesigning the storage layer<\/li>\n<li>Reduced operational burden vs maintaining iSCSI target VMs<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure Elastic SAN block storage or file storage?<\/strong><br\/>\nAzure Elastic SAN provides <strong>block storage<\/strong> volumes accessed using <strong>iSCSI<\/strong>.<\/p>\n\n\n\n<p>2) <strong>How do clients connect to Azure Elastic SAN volumes?<\/strong><br\/>\nTypically via <strong>iSCSI initiators<\/strong> on supported operating systems (Linux\/Windows). You use portal-provided target portals and IQNs.<\/p>\n\n\n\n<p>3) <strong>Do I attach an Elastic SAN volume like an Azure managed disk?<\/strong><br\/>\nNo. Managed disks attach through Azure\u2019s VM\/disk attachment model. Elastic SAN volumes are connected at the OS level over iSCSI networking.<\/p>\n\n\n\n<p>4) <strong>Is Azure Elastic SAN regional?<\/strong><br\/>\nYes, it\u2019s deployed into an Azure region. For best results, place compute in the same region.<\/p>\n\n\n\n<p>5) <strong>Can I use Azure Elastic SAN with AKS?<\/strong><br\/>\nIt\u2019s technically possible to use iSCSI-backed persistent volumes in Kubernetes, but it\u2019s not the default Azure approach. Most AKS users use Azure Disk CSI or Azure Files CSI. Evaluate operational complexity carefully.<\/p>\n\n\n\n<p>6) <strong>Does Azure Elastic SAN support snapshots?<\/strong><br\/>\nFeature availability changes over time. Verify current snapshot support and billing in the official docs and pricing page.<\/p>\n\n\n\n<p>7) <strong>How is performance managed?<\/strong><br\/>\nElastic SAN typically uses provisioned capacity and provisioned performance dimensions. Check the pricing page for the current model and the portal for configurable performance options.<\/p>\n\n\n\n<p>8) <strong>Is the data encrypted at rest?<\/strong><br\/>\nAzure Storage commonly encrypts at rest by default, but always verify Elastic SAN encryption details and any customer-managed key support in the official documentation.<\/p>\n\n\n\n<p>9) <strong>Is iSCSI traffic encrypted in transit?<\/strong><br\/>\niSCSI is not TLS by default. Use private networking and access restrictions. If Elastic SAN supports CHAP or other mechanisms, configure them\u2014verify in docs.<\/p>\n\n\n\n<p>10) <strong>What ports must be open?<\/strong><br\/>\niSCSI commonly uses <strong>TCP 3260<\/strong>. Confirm any additional ports\/endpoints required by Elastic SAN and your OS multipath configuration.<\/p>\n\n\n\n<p>11) <strong>Can multiple hosts connect to the same volume?<\/strong><br\/>\nBlock volumes can be connected by multiple hosts, but safe multi-host usage depends on the filesystem\/cluster stack. For most filesystems, concurrent mounting can corrupt data. Use a cluster-aware filesystem or clustering solution if required, and validate support.<\/p>\n\n\n\n<p>12) <strong>How do I resize a volume?<\/strong><br\/>\nUsually you resize in Azure (volume size), then rescan on the host, then resize partition\/filesystem. Confirm Elastic SAN supports your desired resize direction (grow vs shrink).<\/p>\n\n\n\n<p>13) <strong>What is a volume group?<\/strong><br\/>\nA volume group is a container for volumes that also acts as a boundary for iSCSI exposure\/network settings and administration.<\/p>\n\n\n\n<p>14) <strong>How do I monitor Elastic SAN health and performance?<\/strong><br\/>\nUse Azure Monitor metrics and diagnostic logs (where supported). Also monitor host-level disk latency and I\/O wait.<\/p>\n\n\n\n<p>15) <strong>What are common causes of connection failures?<\/strong><br\/>\nIncorrect subnet\/network configuration, blocked traffic (NSG\/UDR), wrong portal\/IQN, missing iSCSI services, or authentication mismatch (if configured).<\/p>\n\n\n\n<p>16) <strong>Is Azure Elastic SAN a replacement for Azure NetApp Files?<\/strong><br\/>\nNot directly. NetApp Files is primarily enterprise <strong>file<\/strong> storage (NFS\/SMB). Elastic SAN is <strong>block<\/strong> storage over iSCSI with a SAN-like operational model.<\/p>\n\n\n\n<p>17) <strong>Is Azure Elastic SAN cheaper than managed disks?<\/strong><br\/>\nIt depends. For some pooled, high-scale scenarios it can be cost-effective. For many simple workloads, managed disks may be cheaper and simpler. Use the pricing calculator with your workload assumptions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Elastic SAN<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Elastic SAN documentation<\/td>\n<td>Primary source for concepts, how-tos, limits, and networking requirements: https:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Azure Elastic SAN pricing page<\/td>\n<td>Current meters and region-dependent pricing: https:\/\/azure.microsoft.com\/pricing\/details\/elastic-san\/<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Azure Pricing Calculator<\/td>\n<td>Build estimates for SAN + VM + monitoring: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<\/tr>\n<tr>\n<td>Product availability<\/td>\n<td>Azure Products by Region<\/td>\n<td>Confirm Elastic SAN is available in your region: https:\/\/azure.microsoft.com\/explore\/global-infrastructure\/products-by-region\/<\/td>\n<\/tr>\n<tr>\n<td>Azure CLI docs<\/td>\n<td>Install Azure CLI<\/td>\n<td>Required to automate labs and operations: https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Azure Architecture Center<\/td>\n<td>Broader Azure storage + networking patterns (useful context): https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Monitoring<\/td>\n<td>Azure Monitor overview<\/td>\n<td>How to build alerts and dashboards: https:\/\/learn.microsoft.com\/azure\/azure-monitor\/<\/td>\n<\/tr>\n<tr>\n<td>Identity\/RBAC<\/td>\n<td>Azure RBAC documentation<\/td>\n<td>Secure management-plane operations: https:\/\/learn.microsoft.com\/azure\/role-based-access-control\/overview<\/td>\n<\/tr>\n<tr>\n<td>Storage concepts<\/td>\n<td>Azure Storage documentation<\/td>\n<td>Context for Azure Storage services and common concepts: https:\/\/learn.microsoft.com\/azure\/storage\/<\/td>\n<\/tr>\n<tr>\n<td>Community (use with care)<\/td>\n<td>Microsoft Tech Community (Azure Storage)<\/td>\n<td>Practical tips and announcements; validate against official docs: https:\/\/techcommunity.microsoft.com\/t5\/azure-storage\/bd-p\/AzureStorageBlog<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, SREs<\/td>\n<td>Azure operations, DevOps practices, automation fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM\/DevOps basics, CI\/CD, cloud fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>CloudOps practices, monitoring, reliability operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers<\/td>\n<td>SRE principles, observability, reliability, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/SRE\/ITSM teams<\/td>\n<td>AIOps concepts, monitoring analytics, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify specific offerings)<\/td>\n<td>Beginners to intermediate<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tools and practices (verify course catalog)<\/td>\n<td>DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance\/contract DevOps services and guidance (verify training\/services)<\/td>\n<td>Teams needing short-term help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement resources (verify offerings)<\/td>\n<td>Ops and DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service list)<\/td>\n<td>Architecture, migrations, automation, operations<\/td>\n<td>Elastic SAN adoption assessment, secure network design, IaC pipelines<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting (verify service list)<\/td>\n<td>DevOps transformation, CI\/CD, cloud operations<\/td>\n<td>Standardized storage provisioning runbooks, monitoring\/alerting integration<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service list)<\/td>\n<td>Toolchain setup, automation, operations improvements<\/td>\n<td>Landing zone readiness for storage services, governance and cost controls<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure Elastic SAN<\/h3>\n\n\n\n<p>Foundations:\n&#8211; Azure fundamentals (subscriptions, resource groups, ARM)\n&#8211; Azure networking:\n  &#8211; VNets, subnets, NSGs, route tables, peering\n&#8211; Storage fundamentals:\n  &#8211; Block vs file storage\n  &#8211; IOPS, throughput, latency, queue depth\n&#8211; iSCSI basics:\n  &#8211; IQN, portals, LUNs\n  &#8211; Discovery vs login\n&#8211; OS storage administration:\n  &#8211; Linux: partitions, filesystems, <code>fstab<\/code>, <code>iscsiadm<\/code>, multipath\n  &#8211; Windows: iSCSI Initiator, Disk Management, MPIO (if applicable)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Elastic SAN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production reliability:<\/li>\n<li>Multipath design, failure testing, runbooks<\/li>\n<li>Monitoring and SRE practices:<\/li>\n<li>Azure Monitor alerts, SLOs for storage latency\/availability<\/li>\n<li>Backup and DR patterns:<\/li>\n<li>App-consistent backups, replication strategies (service-dependent)<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Bicep\/Terraform (verify Elastic SAN resource support in your chosen IaC tool)<\/li>\n<li>Governance:<\/li>\n<li>Azure Policy, tagging standards, cost management<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ cloud infrastructure engineer<\/li>\n<li>Platform engineer<\/li>\n<li>SRE \/ operations engineer<\/li>\n<li>Storage engineer (cloud)<\/li>\n<li>Solutions architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Azure certifications don\u2019t usually focus on a single storage service, but these are relevant:\n&#8211; <strong>AZ-900<\/strong> (Azure Fundamentals)\n&#8211; <strong>AZ-104<\/strong> (Azure Administrator)\n&#8211; <strong>AZ-305<\/strong> (Azure Solutions Architect Expert)\n&#8211; <strong>AZ-500<\/strong> (Azure Security Engineer) for secure deployment patterns<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build an \u201cinternal storage platform\u201d:<\/li>\n<li>One SAN, multiple volume groups, RBAC per team, tagging, budgets<\/li>\n<li>Implement a resize automation runbook:<\/li>\n<li>Resize volume + host filesystem + validation checks<\/li>\n<li>Create a monitoring dashboard:<\/li>\n<li>SAN metrics + VM IO wait + alerts for saturation<\/li>\n<li>Test failure scenarios:<\/li>\n<li>Path failure (simulate NSG blocks) and validate multipath recovery<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Block storage<\/strong>: Storage presented as a raw device (like a disk) to an operating system.<\/li>\n<li><strong>SAN (Storage Area Network)<\/strong>: A network-based system for presenting block storage volumes to hosts.<\/li>\n<li><strong>iSCSI<\/strong>: Internet Small Computer Systems Interface; a protocol to carry SCSI commands over TCP\/IP networks.<\/li>\n<li><strong>IQN<\/strong>: iSCSI Qualified Name; a unique identifier for iSCSI targets and initiators.<\/li>\n<li><strong>LUN<\/strong>: Logical Unit Number; identifies a logical storage device presented by a target.<\/li>\n<li><strong>Initiator<\/strong>: The client (host) that initiates iSCSI sessions (e.g., a Linux VM).<\/li>\n<li><strong>Target<\/strong>: The storage endpoint that provides LUNs\/volumes over iSCSI.<\/li>\n<li><strong>Multipath (MPIO)<\/strong>: Host configuration that uses multiple network paths to the same storage device for redundancy\/performance.<\/li>\n<li><strong>Volume group<\/strong>: In Azure Elastic SAN, a grouping of volumes and a boundary for network exposure and management.<\/li>\n<li><strong>RBAC<\/strong>: Role-Based Access Control; Azure authorization model for management-plane operations.<\/li>\n<li><strong>NSG<\/strong>: Network Security Group; Azure firewall-like rules for subnets\/NICs.<\/li>\n<li><strong>ARM<\/strong>: Azure Resource Manager; Azure control plane for provisioning and managing resources.<\/li>\n<li><strong>IOPS<\/strong>: Input\/output operations per second; a measure of storage performance.<\/li>\n<li><strong>Throughput<\/strong>: Data transfer rate (e.g., MB\/s or GB\/s).<\/li>\n<li><strong>Latency<\/strong>: Time taken to complete an I\/O request, often measured in milliseconds.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Elastic SAN is an Azure Storage service that provides <strong>managed SAN-style block storage<\/strong> over <strong>iSCSI<\/strong>, enabling centralized provisioning of volumes from a pooled capacity\/performance resource. It matters when you need <strong>shared, centrally managed block volumes<\/strong> and want to reduce the operational overhead of self-managed iSCSI targets or large-scale managed disk sprawl.<\/p>\n\n\n\n<p>Architecturally, Elastic SAN fits best for <strong>regional<\/strong>, private-network deployments where hosts connect via iSCSI and teams enforce strict <strong>RBAC<\/strong>, network isolation, and operational runbooks. Cost is primarily driven by <strong>provisioned capacity and provisioned performance<\/strong>, plus indirect networking and monitoring costs\u2014so right-sizing and metrics-driven tuning are essential.<\/p>\n\n\n\n<p>Use Azure Elastic SAN when SAN-like workflows are required; prefer Azure Managed Disks or Azure Files when simpler block-per-VM or shared file storage meets the need. Next, deepen your skills by automating provisioning (ARM\/Bicep\/Terraform where supported) and building production-grade monitoring and multipath runbooks using the official docs: https:\/\/learn.microsoft.com\/azure\/storage\/elastic-san\/<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Storage<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,7],"tags":[],"class_list":["post-519","post","type-post","status-publish","format-standard","hentry","category-azure","category-storage"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/519","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=519"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/519\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=519"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=519"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=519"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}