Back

Blog details

How to Use AIOZ Storage Effectively: A Practical Checklist

AIOZ Network
6 min readAugust 28, 2026
aioz-storage
Laptop screen showing colorful syntax-highlighted code in a dark editor

AIOZ Storage best practices come down to seven decisions, most of them one-time setup choices that are cheap to get right on day one and expensive to fix after data is already flowing. This checklist pulls together what's already documented and verified across AIOZ Storage's SDKs, encryption model, access control system, and billing policy into one practical list, ordered by how early in a project each one actually matters.

TL;DR:

  • Get client configuration (endpoint, region, path-style addressing) right before writing any other code, it's the single most common setup failure.
  • Choose encryption mode, credential scope, and passphrase backup deliberately, not by accepting whatever's easiest.
  • Design around two real gaps, no native object versioning and a 3-day balance grace period, rather than discovering them under pressure.

1. Configure the Client Correctly the First Time

Every AIOZ Storage integration needs three things: the custom endpoint (https://s3.aiozstorage.network), a placeholder region (us-east-1, required by SDK constructors even though AIOZ Storage isn't region-partitioned), and path-style addressing explicitly enabled, forcePathStyle: true in JavaScript, addressing_style: path in boto3's Config, the CLI's default auto mode falling back to path-style automatically. Skip that last setting specifically and requests fail before they reach a bucket, since the SDK defaults to virtual-hosted-style URLs that don't resolve against AIOZ Storage's single endpoint. This is covered in full, with working code, in the JavaScript, Go, Python, and CLI quickstarts.

2. Choose Your Encryption Mode Deliberately

Server-side encryption is the default, no setup required, and AIOZ's servers decrypt your data momentarily to serve it back to you on each request. End-to-end encryption keeps AIOZ's servers out of that path entirely, but it's a deliberate opt-in: either the AIOZ Storage CLI directly, or a self-hosted gateway you stand up yourself. Both modes share the same underlying guarantee, AIOZ never stores your bucket passphrase either way, but only end-to-end mode keeps your plaintext away from AIOZ's infrastructure at any point. Decide which one your use case actually needs before you start uploading real data, since switching modes later means re-encrypting everything under the new path.

Server room aisle with rows of dark server racks

3. Scope Every Credential Narrowly

AIOZ Storage gives you two tools for this, and using the wrong one for a given job is the most common access-control mistake. For a teammate who needs standing access, create a member with Read, Write, List, or Delete scoped to exactly the buckets they need, not All on everything. For a script, a one-off integration, or a contractor with a known end date, generate an access grant instead, expiring on a schedule from 24 hours up to a year, rather than a credential that lives forever by default. For genuinely temporary access, a single download or upload, a presigned URL beats both, no standing credential at all. This is the same principle NIST's least-privilege guidance describes generally, and the same one AWS's own IAM best practices push toward on the S3 side: grant only the access a task needs, for only as long as it needs it, applied here as three concrete tools instead of one shared master credential.

4. Back Up Your Bucket Passphrase Before You Need It

AIOZ does not have or store your bucket's encryption passphrase, under either encryption mode. That's the same guarantee that keeps your data private, and it cuts both ways: lose the passphrase with no backup, and the bucket's contents are gone permanently, with no support ticket that can recover them. Download it or write it down the moment a bucket is created, not after the first incident makes it obvious why that mattered.

5. Design Around No Native Object Versioning

AIOZ's documentation doesn't describe an object versioning feature, the ability to recover a prior copy of something after it's overwritten. If a pipeline or a person can overwrite a key in place, plan for that gap now: put a version identifier in the object key itself (dataset/v3/file.csv instead of always overwriting dataset/file.csv), or reach for a tool built for this specifically, like DVC, which layers real versioning on top of any S3-compatible remote AIOZ Storage included. This matters most for anything you'd genuinely regret losing: model checkpoints, configuration files, anything without a second copy elsewhere.

6. Watch Your Pre-Paid Balance

AIOZ Storage has no free tier and no invoice-then-pay model, it's pre-paid, metered hourly against a funded balance. Let that balance drop below the minimum, calculated from your prior cycle's bill, and the account locks: no upload, no download, though your data stays intact for a 3-day grace period. Miss that window and AIOZ deletes the unpaid data permanently. Set a monitoring alert on your balance well before it gets close, the same discipline you'd apply to any pre-paid infrastructure bill, not something to discover from a locked account mid-pipeline-run.

7. Respect the Rate Limit and Account Caps When You Design for Scale

Three hard limits apply per account: 100 buckets, 100 sub-users, and 100 requests per second. AIOZ's documentation doesn't specify what happens to a request past that rate limit, so building in backoff and retry logic for high-throughput workloads is a reasonable default rather than an assumption that every burst of concurrent requests will simply succeed. If your architecture is likely to approach any of these three numbers, plan bucket and sub-user allocation deliberately from the start rather than restructuring under pressure later.

Frequently Asked Questions

What's the single most common AIOZ Storage setup mistake?
Forgetting path-style addressing (forcePathStyle or addressing_style: path). Without it, requests fail before reaching a bucket, since the SDK defaults to virtual-hosted-style URLs that don't work against AIOZ Storage's single endpoint.

Should I use server-side or end-to-end encryption?
Server-side is the default and needs no setup, with AIOZ's servers briefly decrypting data to serve it. End-to-end, via the CLI or a self-hosted gateway, keeps AIOZ's infrastructure out of the decryption path entirely. Choose based on whether that distinction matters for your use case, before you start storing real data under one mode.

What happens if I lose my bucket passphrase?
The bucket's contents become permanently undecryptable. AIOZ does not store your passphrase under either encryption mode, so there's no recovery path, back it up the moment a bucket is created.

Should I create a member or generate an access grant for a new integration?
A member for standing team access with its own login. An access grant for anything scoped and temporary, a script, a contractor engagement, or an integration with a known end date, since it expires automatically instead of persisting until someone remembers to revoke it.

Does AIOZ Storage support undoing an accidental overwrite?
Not through a documented versioning feature. Put a version identifier in the object key itself, or use a tool like DVC that adds real versioning on top of any S3-compatible remote.

How much warning do I get before AIOZ Storage deletes data for an unpaid balance?
A 3-day grace period after the account locks for insufficient balance. Data stays retained during the lock; only unresolved non-payment past that window results in permanent deletion.

What are AIOZ Storage's hard account limits?
100 buckets per account, 100 sub-users per account, and a 100 request-per-second rate limit, per AIOZ's published usage-limit documentation.

References

We only send updates when meaningful changes ship, and you can unsubscribe anytime

Related Content

blog thumbnail

How to Build an MCP Server for AIOZ Storage, Step by Step

AIOZ Storage has no official MCP server yet. Here is a working MCP server for AIOZ Storage, built with the official Python SDK and boto3, tools included.

aioz-storage
6 min readSeptember 19, 2026
blog thumbnail

What Is an MCP Server? How AI Agents Access Storage

What is an MCP server: a standard letting AI agents like Claude use tools and data through one protocol. How MinIO and Azure apply it to object storage.

aioz-storage
6 min readSeptember 16, 2026
blog thumbnail

S3 Access Logs vs CloudTrail: Which Should You Use?

S3 access logs vs CloudTrail: AWS recommends CloudTrail, but each one catches real events the other misses. Speed, cost, and coverage, compared directly.

aioz-storage
5 min readSeptember 15, 2026
blog thumbnail

Eventual vs Strong Consistency: How S3 Made the Switch

Eventual vs strong consistency: whether a read right after a write sees the new data immediately. S3 ran on the first model for 14 years, then changed it.

aioz-storage
6 min readSeptember 14, 2026
blog thumbnail

Bucket Policy vs IAM Policy: What Is the Real Difference?

Bucket policy vs IAM policy: one attaches to the resource, one attaches to the identity. What each can do that the other can't, and how S3 evaluates both.

aioz-storage
6 min readSeptember 13, 2026
blog thumbnail

SSE-S3 vs SSE-KMS vs SSE-C: S3 Encryption Types Explained

SSE-S3 vs SSE-KMS vs SSE-C: who manages the encryption key, and what that decision actually costs you. Includes the real 2026 default change to SSE-C.

aioz-storage
6 min readSeptember 12, 2026