Hitachi Vantara has brought its enterprise-grade block storage software to Microsoft Azure, making Virtual Storage Platform One Software-Defined Storage (VSP One SDS) available through the Azure Marketplace as of August 19, 2025. The move completes a deliberate multi‑cloud rollout that started with AWS and then Google Cloud, and it signals the company’s ambition to let customers run a single storage fabric across on‑premises data centers and all three major public clouds. For Windows shops and Azure‑focused IT teams, the listing means they can now provision, pay for, and govern Hitachi block volumes directly through their existing Azure subscription—without leaving the console they already use every day.

What VSP One SDS Brings to Azure

Hitachi Vantara designed VSP One SDS as the cloud‑native block storage element of its broader VSP One data plane, which also covers file and object workloads. Inside Azure, it delivers a set of capabilities that storage admins have traditionally associated with on‑premises arrays:

  • Thin provisioning: allocate logical capacity and only consume physical storage as data grows, reducing upfront overprovisioning.
  • Enterprise‑grade compression: inline compression shrinks data volumes before they hit Azure disks, potentially lowering both storage and IOPS bills.
  • Two‑way asynchronous replication: pair on‑prem volumes with Azure‑based replicas—or vice versa—to build hybrid disaster‑recovery topologies without identical hardware at each end.
  • Centralized management via VSP 360: a single control plane that automates provisioning, collects telemetry, and applies AIOps across on‑prem, Azure, and other clouds.

The entire package is now available as a transactable offer in the Azure Marketplace, which means organizations can deploy it with standard Azure billing, policy, and governance controls. That integration alone shortens pilot cycles and lets procurement teams move faster than negotiating a separate agreement.

The Multi‑Cloud Strategy Behind the Announcement

Hitachi Vantara’s Azure debut is not a one‑off; it is the third chapter in a staged hyperscaler push. The company first placed VSP One SDS in the AWS Marketplace, then followed with Google Cloud, and now Azure. This sequence shows a deliberate commitment to multi‑cloud parity—a recognition that large enterprises rarely standardize on a single public cloud.

By delivering the same block‑storage features, the same management interface, and the same procurement experience across all three platforms, Hitachi aims to position VSP One as a genuine hybrid‑cloud fabric. Octavian Tanase, chief product officer at Hitachi Vantara, framed the strategy plainly: “By bringing VSP One to Microsoft Azure, we’re helping Azure customers extend the value of their existing investments while introducing new levels of resiliency, efficiency and simplicity.” Jake Zborowski, general manager of the Microsoft Azure Platform, added that the listing helps customers “do more with less by increasing efficiency, buying confidently and spending smarter.”

Operational and Business Impacts

For IT teams already running Hitachi arrays on‑premises, the Azure offering can dramatically simplify hybrid operations. Provisioning workflows, replication topologies, and data‑management policies remain consistent, which reduces the cognitive load on storage admins and speeds up cloud‑adjacent projects. This continuity is especially valuable for regulated workloads and legacy application estates where rewriting applications for native cloud storage is cost‑prohibitive.

From a FinOps perspective, putting enterprise storage into Azure changes the cost arithmetic. The headline vendor claim—up to 40% reduction in cloud storage costs—originates from the combination of thin provisioning and compression. However, that figure is dataset‑dependent and represents a best‑case scenario. Encrypted files, already‑compressed media, and densely packed archives will see little to no shrinkage. To get an accurate picture, teams must also layer in the cost of the Azure VMs that run the SDS software, network egress fees for replication, snapshot metadata charges, and any extra IOPS consumption. A full TCO model is essential before signing on.

On the business‑continuity front, two‑way asynchronous replication enables cloud‑based DR targets without requiring matching hardware at the secondary site. When tethered to VSP 360’s orchestration, failover and failback runbooks can become more automated, potentially cutting recovery‑time objectives. But the actual RPO and RTO will depend on replication bandwidth, network latency between regions, and the volume of change data.

Under the Hood: Performance, Data Reduction, and Availability Caveats

Software‑defined storage that runs on cloud VMs behaves very differently from purpose‑built hardware arrays. Key technical factors demand close scrutiny:

Performance Variability

  • Instance type matters: IOPS and throughput are capped by the Azure VM SKU. Choose oversized instances and you waste compute; choose undersized ones and latency‑sensitive workloads suffer.
  • Noisy neighbors: Shared virtualization can introduce jitter, especially for workloads with low latency tolerances.
  • Network constraints: Azure’s per‑VM bandwidth limits and inter‑AZ throughput caps will bound replication speed and rebuild times. Benchmark representative datasets—transactional databases, virtual desktops, analytics stores—under sustained load before going live.

Data Reduction Realities

Hitachi’s “up to 40%” claim is an engineering estimate, not a guarantee. In a proof‑of‑concept, measure:

Metric What to Watch For
Raw vs. effective capacity Compression ratio for your exact data mix
CPU overhead VM CPU burn during inline compression and deduplication
Deduplication ratio Savings on repeated patterns (e.g., VM golden images)
Latency impact I/O response time with data‑reduction features enabled

Text‑heavy logs, configuration files, and certain virtual disk formats often compress well; encrypted volumes and rich media typically do not.

Availability and SLA Mapping

A target of 99.999% uptime—five nines—sounds impressive, but it is a vendor engineering goal, not a contractual service‑level agreement. End‑to‑end availability in Azure is a composite of:
- Azure VM and region SLA
- Network and platform dependencies
- Hitachi SDS software lifecycle and support boundaries

Before production rollout, map Hitachi’s uptime commitments to Microsoft’s SLAs, and get explicit terms on remedies and joint responsibility for incidents.

How Hitachi’s Move Fits the Hybrid‑Fabric Race

NetApp arguably wrote the hybrid‑fabric playbook years ago, and Dell, HPE, and Pure Storage have all since launched their own cloud‑block‑storage offers. Hitachi Vantara is now charging into the same arena, and the Azure listing makes its portfolio competitive across the big three clouds. The strategic question for buyers remains: do you want a single vendor’s unified data plane that spans private and public clouds, or a best‑of‑breed approach that leverages native Azure services like Azure Disk Storage and Azure NetApp Files?

The answer depends on existing investments, regulatory constraints, and the cost of refactoring applications. Hitachi’s pitch resonates with organizations that:
- Already run VSP arrays on‑prem
- Need consistent enterprise features (synchronous replication, immutable snapshots, storage‑side encryption) everywhere
- Prefer to manage storage through a single pane of glass (VSP 360) rather than juggle cloud‑native tools

Strengths, Risks, and a Practical Evaluation Checklist

Strengths and Opportunities

  • Operational consistency: Familiar provisioning and replication workflows reduce training and runbook churn.
  • Simplified procurement: Azure Marketplace billing and policy integration shortens time‑to‑pilot.
  • Hybrid DR flexibility: Two‑way async replication enables affordable, non‑identical DR targets.
  • Centralized observability: VSP 360’s AIOps and telemetry can cut mean‑time‑to‑detect for cross‑site issues.

Risks and Blind Spots

  • Marketing claims vs. measurable outcomes: “Up to 40%” savings and “99.999% uptime” are vendor planning numbers—pilot data and contract terms must validate them.
  • Hidden cloud costs: Egress charges, snapshot metadata fees, and SDS host VM compute can erode nominal storage savings. Build a complete FinOps model.
  • Operational surface area: Running SDS inside Azure adds a managed software layer. Patching, host sizing, and incident escalation increase day‑two overhead.
  • Performance jitter: Not every workload is a good fit; latency‑sensitive apps may suffer from cloud resource contention.
  • Vendor lock‑in: Proprietary replication formats or compression could increase exit friction. Test data portability and recovery procedures early.

Ten questions to answer in a proof‑of‑concept

  1. What effective capacity does VSP One deliver on our actual datasets after compression and deduplication?
  2. How much CPU and memory does the SDS host consume under peak write loads?
  3. What are the measured IOPS and latency for hot transactional data, warm analytics, and cold archive volumes?
  4. What are the full monthly costs, including VM compute, Azure storage fees, egress, and Hitachi licensing?
  5. Can VSP 360 integrate with our existing SIEM, ticketing, and automation platforms?
  6. What are the exact support boundaries between Hitachi and Microsoft, and where do escalations hand off?
  7. How do replication failover and failback times map to our RTO and RPO requirements under realistic loads?
  8. Which Azure VM types deliver predictable performance for our workload profiles?
  9. Does the solution meet our encryption and key‑management policies (customer‑managed keys, regional residency)?
  10. What is the documented process to export all data and repatriate it to on‑prem or another cloud?

A Phased Path to Adoption

A disciplined rollout minimizes risk while building institutional knowledge:

Phase Duration Activities
Pilot 0–3 months Deploy in a single Azure region for non‑latency‑sensitive workloads; run the full PoC checklist; benchmark compression, performance, and costs.
Controlled production 3–9 months Migrate low‑risk production workloads; enable on‑prem‑to‑Azure replication for DR; automate routine snapshots and provisioning; validate runbooks.
Scale and optimize 9–18 months Expand to additional regions or clouds; tune FinOps policies; integrate SDS lifecycle into broader governance frameworks.

The Bottom Line for Windows‑centric Shops

For Microsoft‑first organizations, Hitachi’s Azure Marketplace entry is more than a procurement convenience—it’s a signal that enterprise block storage features are now a native‑feeling part of the Azure experience. The promise of a single control plane spanning on‑prem VSP arrays and Azure‑hosted SDS volumes can simplify hybrid architectures and reduce the time engineers spend context‑switching between management tools. But the path from promise to production is paved with rigorous testing. Teams that invest in a thorough proof‑of‑concept—one that measures real compression ratios, benchmarks I/O under load, and models every direct and indirect cost—stand to gain a resilient, cost‑effective hybrid fabric. Those that skip the homework risk surprise bills, missed availability targets, and a muddled support chain. With VSP One SDS now available in Azure, the practical next step is a tightly scoped PoC that translates vendor claims into your own data‑center realities.