Native Object Storage on vSAN in VCF 9.1 The On-Platform S3 Story (Tech Preview)

This is Part 28 of the series, covering the Native Object Storage capability introduced in VCF 9.1 as Tech Preview. Object storage on-premises has historically required an external tier a dedicated object storage product (Dell ECS, NetApp StorageGRID, Cloudian HyperStore, MinIO, Scality) or a hyperscaler service used over a network link. VCF 9.1’s Native Object Storage changes that by delivering S3-compatible object storage as a vSAN capability.

Tech Preview matters this is not a GA capability yet, and customers shouldn’t plan production workloads on it as their primary object storage tier. But the architectural pattern is worth understanding now, because the use cases this enables are increasingly central to enterprise architecture, and the deployment patterns that work in Tech Preview will largely carry through to GA.

This article walks through what Native Object Storage is in VCF 9.1, the three primary use cases that justify its existence, how it compares to external object storage tiers, and the design considerations for architects evaluating adoption.

What Native Object Storage is in VCF 9.1

Native Object Storage on vSAN delivers S3-compatible object storage as a native capability of the vSAN ESA storage layer. No external object storage product. No separate cluster. The same vSAN nodes serving VM and container storage also serve object storage.

Key characteristics:

• S3-compatible API standard S3 protocol, usable by existing S3 client libraries and tools

• Backed by vSAN ESA inherits vSAN’s data protection, deduplication, compression, and encryption capabilities

• Bucket-and-object semantics the familiar S3 namespace model

• Identity integration IAM-style access controls integrated with VCF Identity Broker

• Tech Preview in 9.1 not yet a GA capability, intended for evaluation and adoption planning

• Cluster-scoped deployed and consumed within a vSAN cluster

• Capacity scales with the underlying vSAN cluster no separate object storage capacity planning

The architectural shift: object storage stops being a separate product and becomes a vSAN feature. The same management plane, the same operational surface, the same observability just an additional storage interface alongside block (VMFS / vVols), file (vSAN File Services), and now object.

The three use cases that justify it

Object storage on-premises is justified by three primary use cases. VCF 9.1’s Native Object Storage addresses all three.

Backup targets. Most enterprise backup software (Veeam, Cohesity, Rubrik, Commvault, Veritas) supports S3-compatible targets. Native Object Storage on vSAN becomes a backup target that’s collocated with primary storage, immutable where required, encrypted, dedup-and-compression-optimised. The architectural simplification is real no separate backup storage tier procurement, no dedicated backup repository hardware.

AI training data. Modern AI training pipelines expect S3 access for training datasets. Whether the AI workload is Private AI Foundation on the same VCF platform or external systems that need access to enterprise data, S3 access is the universal protocol. Native Object Storage means training data lives where the inference happens, with the data governance the platform provides.

Cloud-native application data. Applications increasingly assume object storage as a primary data tier. Photos, documents, logs, intermediate processing artefacts, container image registries all assume S3-style access. Cloud-native applications built originally for public-cloud environments port to on-prem VCF cleanly when the platform provides S3.

Outside these three use cases, object storage on-premises is harder to justify. Block storage handles transactional workloads better. File storage handles document collaboration better. Object storage is specifically for write-once-read-many patterns at scale which is exactly what these three use cases need.

Comparison to external object storage

Before Native Object Storage, on-prem object storage typically came from one of three sources. Each has architectural implications.

Dedicated object storage products. Dell ECS, NetApp StorageGRID, Cloudian HyperStore, IBM Cloud Object Storage, Scality. Mature, full-featured, but architecturally separate different cluster, different management plane, different lifecycle, different observability, different vendor relationship. The integration with VCF is layered on top, not native.

Open-source object storage. MinIO, Ceph (via RADOS Gateway). Lower cost, but architectural integration and operational ownership are the customer’s problem. Strong on standards compliance; weaker on enterprise integration features unless paired with commercial support.

Hyperscaler object storage with on-prem extensions. AWS Outposts, Azure Stack with Blob storage, GCP Anthos. Integrated with public cloud but introduces hyperscaler dependencies and pricing models on-prem. Architecturally complex when the primary platform is VCF.

Native Object Storage on vSAN sits in a different architectural position:

• Same platform as the rest of the workload stack one management plane, one operational surface

• No separate cluster procurement capacity within existing vSAN nodes

• No separate vendor relationship part of the VCF licensing and support model

• Native integration with VCF identity, encryption, observability

• Tech Preview limitation not yet matching dedicated object storage products in feature depth or scale

The right framing: Native Object Storage is the right choice for the three use cases above at moderate scale. At very large scale (petabytes-plus) or for object-storage-as-a-product scenarios, dedicated object storage products remain the right architectural choice. Mixed-mode deployments Native Object Storage for collocated use cases, dedicated object storage for at-scale or product-line scenarios are valid.

Architectural integration

Native Object Storage integrates with the broader VCF 9.1 capability surface in several ways.

Identity integration via VCF Identity Broker. IAM-style access controls federate to the enterprise IDP. Per-user, per-application authentication and authorisation. Service account patterns for application-to-storage integration.

Encryption. Data-at-Rest encryption inherited from vSAN ESA. KMS choice (Thales, Entrust, Fortanix, HashiCorp Vault, hyperscaler KMS) applied uniformly. Keys held with the same custody as block storage.

Data efficiency. vSAN ESA Global Deduplication and ZSTD compression apply to object data. Storage efficiency benefits realised across block, file, and object data on the same cluster.

Observability via VCF Operations. Object storage metrics surface in the same dashboards as other vSAN metrics. Capacity tracking, request rates, latency all in one place. Anomalies surface as Active Findings.

Backup and replication patterns. vSAN Protection multi-source replication (Part 18) can replicate object data alongside block data. Cross-site replication patterns work uniformly.

Native S3 features. Versioning, lifecycle policies (move to colder tier, expire), object lock for compliance retention, multipart upload for large objects the S3 feature set users expect.

Use case patterns in detail

Looking at each of the three use cases in more depth.

Backup target pattern

Native Object Storage as backup target:

• Backup software writes to Native Object Storage via S3 protocol

• Object Lock used for immutability ransomware protection at the storage layer

• Lifecycle policies move older backups to longer-retention tiers automatically

• vSAN Protection replication mirrors the backup tier to a secondary site for backup-of-backups protection

• Capacity planning: backup data is highly dedup-able plan for realised ratios from VCF Operations data

AI training data pattern

Native Object Storage as AI training data repository:

• Training datasets staged in Native Object Storage buckets with appropriate access controls

• Training workloads (in VKS clusters with GPU access) read training data via S3 protocol

• Identity Broker federation controls which training jobs can access which datasets

• Versioning for dataset evolution training reproducibility from versioned data

• Encryption ensures training data confidentiality at rest

• Sovereign AI patterns: training data never leaves the on-prem boundary, even for training-intensive workloads

Cloud-native application pattern

Native Object Storage as application data tier:

• Applications (cloud-native, often ported from public-cloud deployments) consume Native Object Storage via standard S3 SDKs

• Per-application service accounts via Identity Broker

• Per-application bucket allocation with appropriate access controls

• Object Lock and versioning available for applications that need them

• Lifecycle policies for application data retention management

Design considerations

For architects evaluating Native Object Storage adoption:

• Tech Preview status not for primary production workloads in 9.1. Adoption is for evaluation, planning, and non-critical use cases until GA

• Capacity planning object data shares vSAN capacity with block and file data. Plan total cluster capacity accordingly

• Feature parity with dedicated object storage evaluate whether required S3 features (specific bucket policies, replication patterns, complex lifecycle rules) are present in Tech Preview

• Scale considerations Native Object Storage in Tech Preview is best at moderate scale. Very large object storage deployments may still need dedicated products

• Existing object storage migration customers with significant existing object storage may have migration planning to do if they move workloads to Native Object Storage

• Coexistence patterns mixed-mode (Native Object Storage for some workloads, dedicated product for others) is valid and often the right pattern for transition

• Backup vendor compatibility confirm specific backup software vendor support for Native Object Storage as a target

• Compliance scope alignment if object data falls under specific compliance scope (PCI, HIPAA, etc.), validate Native Object Storage’s capabilities against requirements

• DR and replication plan how object data participates in DR topology

Closing

Native Object Storage on vSAN is the right architectural direction collapsing object storage from a separate product into a platform capability, with the operational and architectural simplification that follows. Tech Preview in 9.1 means full production adoption is ahead, but the pattern matters now.

For most enterprises, the question over the next 12–18 months will be: where do existing object storage workloads fit, where does Native Object Storage absorb new workloads, and what’s the longer-term consolidation strategy. Architects who think about this now have a head start when GA arrives.

In my design conversations, the Native Object Storage questions I work through:

• Which of the three use cases (backup, AI training, cloud-native app data) is the customer’s primary justification?

• What scale of object data is in scope moderate (Native Object Storage candidate) or very large (dedicated product candidate)?

• What existing object storage investment exists, and what’s the coexistence or migration plan?

• What S3 features are non-negotiable, and does Tech Preview meet them?

• What’s the capacity allocation between block, file, and object on shared vSAN clusters?

• How does object data participate in DR and backup-of-backup topology?

• Are backup vendors validated against Native Object Storage as target?

• What’s the adoption pace Tech Preview evaluation now, broader adoption at GA?

Get those answered and Native Object Storage becomes a deliberate architectural choice rather than a feature to be discovered.

Part 29 of the series covers vSphere Elastic Provisioning (Zero Touch Provisioning) and Fleet onboarding at scale the operations-team-and-MSP capability that turns new-host deployment from a manual project into a policy-driven workflow.

Sources

• Broadcom Native S3 Compatible Object Storage in VMware vSAN for VCF 9.1

• Broadcom Optimize, Modernize and Protect Your Private Cloud Storage with vSAN in VCF 9.1

• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience

• Broadcom VCF 9.1: The Secure, Cost-Effective Private Cloud Platform for Production AI

• Broadcom Simplifying Storage with the New Effective Capacity View in vSAN for VCF 9.1

• Broadcom Press Release Broadcom Announces VMware Cloud Foundation 9.1