Everpure's FlashArray Just Learned a New Trick: Native Object Storage

For years, FlashArray has done two things really well: block and file. If you wanted S3-compatible object storage from Everpure, FlashBlade was the answer, full stop. As of Purity//FA 6.10.5, that's no longer the whole story; FlashArray now speaks S3 natively, and storage admins finally get a single platform for block, file and object. Three protocols, one array, zero new acronyms to memorize.

Here's what's actually in the release, how it felt to set up, where the rough edges still are, and how to try it yourself.

What's new: FlashArray Object Services

FlashArray Object Services is a native S3-compatible implementation, not a gateway bolted on top, but a first-class citizen running as its own tenant alongside your existing Block and File workloads. At launch, it covers the S3 operations most applications actually need day to day:

• Full CRUD (GET, PUT, DELETE)
• Object listing
• Object versioning
• Custom metadata
• Lifecycle policies (expiration, incomplete multipart cleanup)
• Both path-style and virtual-host-style addressing

It's supported on Purity//FA 6.10.5 and later, across FlashArray//XL, //X, //C and //E, on R4 and R5 generation arrays.

And here's the part storage admins will appreciate most: this arrives as a non-disruptive software upgrade. Everpure doesn't sell separate feature licenses; current and new capabilities come native with the hardware purchase or an as-a-service subscription, so there's no additional license to buy, no forklift, no new array, no separate SKU to chase down. If your FlashArray is on the right generation and Purity version, Object is just… there, waiting in Storage > Object Store.

Setting it up: Refreshingly uneventful

We'll be honest; we went in expecting some friction. We got none. With an S3 VIP in place, the workflow follows a logical, six-step path, and every step maps to something you already understand from FlashArray's file services model:

1. Create an account: the logical container for everything else, similar in spirit to a file system.
2. Add local users: each user gets an Access Key and Secret Key for S3 client access.
3. Attach a policy: pick from predefined policies (there's no custom policy authoring yet, more on that below).
4. Create a bucket, and optionally turn on versioning.
5. Point an S3 client at it: grab your S3 VIF from Settings > Connectors, plug it into whatever tool you like (AWS CLI, s3cmd, S3 Browser, Cyberduck), and start doing LIST/PUT/GET.
6. Clean up when you're done: buckets get a 24-hour "Destroy" grace period before you have to commit to "Eradicate." Consider it a safety net for admins who fat-finger a delete on a Friday afternoon.

From account creation to a working S3 client connection, it's a handful of clicks and a couple of pop-up dialogs. If you've provisioned a FlashArray file system before, this will feel familiar enough that you could probably do it half-asleep. (Please don't actually do it half-asleep. Coffee first.)

Where it stands today (and where it's headed)

This is a launch release, and Everpure has been straightforward that it's the beginning of a roadmap, not the finished product. As of today, FlashArray Object does not support:

• Object Lock or Object SafeMode
• Native object replication (no cross-array or cross-site consistency guarantees)
• Multi-tenant deployments
• Custom IAM policies: you're working with predefined, Pure-defined policies only
• External authentication integration

There are also scale ceilings to plan around: 250 buckets per array, 250 million objects per array and 1 million objects per bucket at launch. And because there's no Object Lock or native replication yet, data protection today means leaning on object versioning at the bucket level and, for anything mission-critical, backing up to FlashBlade via third-party software.

None of this is a knock on the release; it's a v1. Everpure has stated the intent to bring FlashArray Object toward feature parity with FlashBlade Object over time. If you've watched FlashArray File Services mature over the past few years, you already know the pattern: launch lean, then layer in capability release by release with a goal towards FlashBlade-level functionality.

FlashArray Object vs. FlashBlade: Which one do you reach for?

Short answer: This isn't really a competition; it's a fit question.

Reach for FlashArray Object when:

• You're at the edge or in a space- and power-constrained environment and want to consolidate block, file and object onto one array instead of managing a separate system for object.
• Your object footprint is modest: think application integration, internal content workflows or test/dev, not a multi-petabyte data lake.
• You already have a FlashArray in place and just need S3 access for an application, without justifying a second platform.

Reach for FlashBlade when:

• You're building a large-scale, centralized object environment: data lakes, AI/ML pipelines with heavy vector-database-as-backing-store use cases or workloads that need the object feature depth FlashBlade already has today (Object Lock, SafeMode, replication, multi-tenancy).
• Scale requirements exceed what FlashArray's launch limits support.

In summary, FlashArray Object is the right tool for "I need S3 next to the block and file I already run today" whereas FlashBlade remains the right tool for when "object storage is the primary workload, and it needs to scale".

Try it yourself

Reading about a new feature is one thing; seeing it in action is another. WWT has a brand new on-demand lab, Everpure FlashArray - Object Storage Lab, so you can walk through the same six-step setup on WWT's ATC infrastructure and see how it behaves before you implement it in your own environment.

Have questions about where FlashArray Object fits in your storage strategy, or want help scoping an Everpure engagement? Reach out to your WWT account team.