# Object Storage for AI Agents: S3, R2, GCS, Azure Blob, MinIO, and IronShard Compared (2026)

Agents read constantly, act on their own, and provision what they need. This comparison looks at six object storage options through that lens: can an agent set itself up, what do reads cost at agent volume, does your existing S3 tooling survive the switch, and can agents work on real production data without touching production.

## TL;DR

| Platform | Agent-native provisioning | Egress model | S3 compatibility | Production fork and branching | Per-agent access scoping | Audit evidence |
|---|---|---|---|---|---|---|
| **AWS S3** | None, human sets up IAM and buckets | Paid, roughly $0.09/GB out | Native | Versioning only, no branch primitive | IAM policies, powerful but built for humans and services | CloudTrail logs |
| **Cloudflare R2** | None | $0 egress | High, minor API gaps | None | Scoped API tokens, bucket level | Basic logs |
| **Google Cloud Storage** | None | Paid | Via XML API, partial | Versioning only | IAM, uniform bucket level | Cloud Audit Logs |
| **Azure Blob** | None | Paid | None, different API | Snapshots per blob, no branch | RBAC and SAS tokens | Activity logs, immutable tiers |
| **MinIO** | None | Your own bandwidth | Native | Versioning only | IAM style policies per key | Standard logs, self-managed |
| **IronShard** | Yes, `create_bucket` on a public MCP server with no account and no human approval | $0 egress by default, per-credential latency dial | Native, single endpoint change | Live governed fork with instant branches, promote and rollback | Per-agent credentials, policy-scoped operations | Cryptographically signed, immutable record |

**Short version:** S3 wins on maturity and scale. R2 wins on egress cost alone. MinIO wins on self-hosted control. None of the five incumbents lets an agent provision its own scoped storage, and none has a production fork primitive. IronShard is built around those two capabilities, and it is in early access, so evaluate it as such.

## What agents break about object storage

Object storage was designed for humans and applications with predictable behavior. Autonomous agents break four assumptions at once.

**Production blast radius.** Agents need real data to be useful, but pointing them at production means one bad write away from an incident. Staging copies go stale; manual snapshots do not scale to agents that run hourly.

**Egress at machine volume.** A read-heavy agent fleet touches data orders of magnitude more often than the human workflows your storage bill was modeled on. At $0.09/GB, retrieval-augmented pipelines and repeated context fetches turn into an unbounded line item.

**All-or-nothing keys.** A shared S3 key gives every agent the same reach. Scoping individual agents to specific prefixes, verbs, and datasets means hand-rolling IAM policy per agent and rotating credentials yourself.

**No evidentiary record.** When someone asks what your AI actually touched, standard access logs are mutable, unsigned, and scattered across services. A log you could have edited is not evidence.

## How we evaluated

Weights reflect what matters for agent workloads specifically, not general storage procurement. Stated openly so you can re-weight for your own case.

- **Agent-native provisioning (20%).** Can an agent discover the service, authenticate, and provision scoped storage end to end, without a human building IAM policy first?
- **Egress economics (20%).** What do read-heavy, automated access patterns cost, and is the cost predictable?
- **S3 and tooling compatibility (20%).** Do boto3, AWS CLI, rclone, Terraform, LangChain, Spark, and the rest of your stack work with an endpoint change, or is this a migration?
- **Production isolation and branching (20%).** Can agents work on live production data in isolation, branch it, promote good results, and roll back, without production ever being at risk?
- **Access control granularity (10%).** Can each agent be scoped to exactly the paths and operations it needs?
- **Audit evidence quality (10%).** Is the record of agent activity signed and immutable, or just a log?

## Platform by platform

### AWS S3

The industry standard, and for good reason. Eleven nines of durability, objects up to 5TB, the deepest IAM model available, and native integration with Bedrock and SageMaker. If your training data is measured in petabytes and your team is AWS-native, S3 is the default for a reason.

For agent workloads the gaps are structural, not missing features. There is no branch primitive: versioning protects individual objects but cannot give an agent an isolated, writable copy of a bucket. Egress is billed on every read that leaves AWS. And IAM, for all its power, assumes a human or a deploy pipeline writes the policy; an agent cannot provision its own scoped credentials.

Full head-to-head: [IronShard vs. Amazon S3](/compare/ironshard-vs-s3).

### Cloudflare R2

R2 solved one problem completely: egress is $0, full stop. Combined with an S3-compatible API and $0.015/GB storage, it is the obvious answer when bandwidth cost is your only pain. The S3 compatibility is high but not total; check your dependency list against their documented API gaps.

Everything else is standard object storage. No fork or branch primitive, access tokens scope to the bucket rather than to per-agent policy, and there is no path for an agent to provision storage on its own.

Full head-to-head: [IronShard vs. Cloudflare R2](/compare/ironshard-vs-cloudflare-r2).

### Google Cloud Storage

The right choice if your AI stack lives on Vertex. Dual-region replication, uniform bucket-level access, competitive long-term storage pricing, and first-party integration with Google's model tooling.

S3 compatibility runs through the XML API and is partial; most teams treat GCS adoption as a migration, not an endpoint swap. Egress is billed, there is no branching, and agents cannot self-provision.

Full head-to-head: [IronShard vs. Google Cloud Storage](/compare/ironshard-vs-google-cloud-storage).

### Azure Blob Storage

The enterprise pick for Azure OpenAI shops. Immutable storage tiers are genuinely useful for retention requirements, and the hot, cool, and archive tiering is mature.

The API is not S3-compatible at all, so your existing S3 tooling does not come with you. Snapshots operate per blob, not as a branchable copy of a container. Egress is billed and provisioning is human-driven through RBAC and SAS tokens.

Full head-to-head: [IronShard vs. Azure Blob Storage](/compare/ironshard-vs-azure-blob).

### MinIO

If you need storage inside your own perimeter, MinIO is the standard answer. Native S3 API, IAM-style policies, versioning, and full control of the deployment, including air-gapped environments.

The trade is that you operate it: capacity, patching, replication, and credential lifecycle are your problem. Zero egress fees only in the sense that you already pay for your own bandwidth and hardware. No branching primitive, no agent self-provisioning.

Full head-to-head: [IronShard vs. MinIO](/compare/ironshard-vs-minio).

### IronShard

IronShard is governed, S3-compatible object storage built for agent workloads, currently in early access. Autonomous agents can create real buckets through the public Agent MCP server today, with no human approval, no tenant OAuth, no existing account, and no payment required.

Where it differs from the five above:

- **Agents provision over MCP, with no account and no human in the loop.** An agent connects to the public Agent MCP server at `https://mcp.agent.ironshard.ai/mcp`, calls `create_bucket` with no authentication, and receives a real, governed bucket with bucket-scoped credentials. Full specification in the [Agent Buckets documentation](/docs/agent-buckets). Human setup remains available through the console and S3 API.
- **$0 egress by default.** Read-heavy agents stay on a zero-egress storage mix; [Trim](/trim) analyses access patterns and routes data to the cheapest compatible provider. Latency-sensitive credentials can trade toward speed, away from the zero-egress mix; each credential sets its own point on the dial.
- **S3 compatibility as an endpoint change.** boto3, AWS CLI, rclone, Terraform, LangChain, MLflow, Spark, and existing scripts work by swapping the endpoint URL. Existing data imports over the S3 API.
- **Fork production instantly.** [Mirror](/mirror) keeps a live, governed copy of production in sync. Agents [branch](/branch) it in seconds, work in isolation with copy-on-write, promote what is good, or roll back to any point in time. Branching and merging are autonomous; when you want oversight, promotion can be gated on human approval, with a full diff of what changed. Production stays locked and untouched.
- **Per-agent credentials, policy-scoped.** [AI Agent Storage](/agents) authenticates every request, checks every action against the credential's defined scope and permitted operations, and denies and records out-of-scope requests.
- **A signed record, not a log.** Every file an agent touches lands in [Log](/log), an immutable, cryptographically signed, searchable record.

Honest caveats: IronShard is early-stage relative to the incumbents, and it orchestrates across underlying providers rather than operating its own datacenters, which is a different trust model than buying from AWS directly. The flip side of that model is [resilience](/docs/resilience): data is fragmented and distributed so that no single provider outage affects availability, and no single provider can reconstruct a file. Public agent buckets carry policy-defined storage, request, and egress limits. If you need petabyte-scale training storage inside one hyperscaler today, use that hyperscaler.

## Beyond the big five

Four more names come up when teams evaluate storage for agent workloads, and each has its own head-to-head:

- [Tigris](/compare/ironshard-vs-tigris) is the closest capability overlap in this space: S3-compatible, zero-egress, with bucket forking and its own MCP server. The comparison comes down to governance, no-account agent provisioning, signed audit evidence, and trust model.
- [Wasabi](/compare/ironshard-vs-wasabi) offers flat-price hot storage with free egress under a fair-use policy that expects reads to stay at or below stored volume, a ratio agent fleets routinely break.
- [Backblaze B2](/compare/ironshard-vs-backblaze-b2) is the budget veteran, with free egress up to 3x stored volume and prefix-scoped application keys, but no agent-native layer.
- [fast.io](/compare/ironshard-vs-fastio) is a different category: agent file workspaces over MCP and REST rather than S3-compatible object storage infrastructure.

## The two capabilities no incumbent has

### A production fork agents can actually use

Every incumbent answer to "agents need real data safely" is a copy job: replicate the bucket, hand the copy to the agent, reconcile later. That fails at agent cadence. Copies go stale in hours, storage doubles, and nothing tracks what changed.

A fork primitive changes the shape of the problem. Mirror syncs continuously from locked production. A branch is instant and copy-on-write, so an agent gets a private, writable view of current production data without duplicating it. Training runs, regression tests, and RAG index builds each get their own branch. Good results get promoted, autonomously or behind a human approval gate with a full diff when oversight is required; everything else is discarded or rolled back to a point in time. The failure mode goes from "agent corrupted production" to "agent corrupted its own branch," which is not an incident.

### Provisioning as an agent capability

On every incumbent, storage provisioning is a human ceremony: create the bucket, write the policy, mint the credential, paste it into the agent's config. That ceremony is where scoping discipline dies, because the path of least resistance is one broad key shared by everything.

When provisioning happens over MCP, the scoped credential is the default artifact, not the aspirational one. IronShard's public Agent MCP server is exactly that: an MCP server for object storage. The agent calls `create_bucket` and receives credentials bound to that bucket and evaluated against policy on every subsequent request. Deny decisions are recorded alongside reads and writes in the signed record, so the access model and the evidence of its enforcement are the same system.

## Which should you choose

- **Choose AWS S3** if you are AWS-native, operate at petabyte scale, or need Bedrock and SageMaker adjacency. It remains the safest default for massive training storage.
- **Choose Cloudflare R2** if egress cost is your only problem and standard object storage semantics are otherwise fine.
- **Choose Google Cloud Storage** if your stack is Vertex-first.
- **Choose Azure Blob** if you are committed to Azure OpenAI and can absorb a non-S3 API.
- **Choose MinIO** if the data cannot leave your perimeter and you have the team to operate storage.
- **Choose IronShard** if agents are first-class users of your storage: they need scoped self-provisioning, zero-egress reads at machine volume, isolated branches of production data, and a signed record of everything they touch, all behind your existing S3 tooling.

## FAQ

**What is the best cloud storage for AI agents?**
There is no single answer; it depends on what your agents do. For petabyte-scale training data inside one cloud, AWS S3 remains the safest choice. For standard object storage with zero egress, Cloudflare R2 is hard to beat. For agent-native capabilities, meaning self-provisioning over MCP, isolated forks of production data, per-agent credentials, and a signed audit record, IronShard is built for exactly that profile and is S3-compatible, though still in early access.

**Can an AI agent provision its own storage bucket?**
Not on S3, R2, GCS, Azure Blob, or MinIO; all five require a human to create buckets and credentials first. On IronShard, an agent connects to the public Agent MCP server at `https://mcp.agent.ironshard.ai/mcp` and calls `create_bucket`; no authentication, no existing account, and no human approval required. The bucket is real, governed by bucket-scoped credentials, and subject to policy-defined limits. See the [Agent Buckets documentation](/docs/agent-buckets).

**Is there zero-egress object storage for agent workloads?**
Cloudflare R2 charges no egress on any workload. IronShard defaults agent credentials to a zero-egress storage mix and lets individual credentials trade toward lower latency instead. All other major providers bill egress per GB, which compounds quickly under read-heavy automation.

**How do I let agents work on production data without risking production?**
On incumbent platforms the answer is periodic copies, which go stale and double storage. IronShard's [Mirror](/mirror) maintains a live, governed fork of production that agents branch instantly with copy-on-write; work is isolated, promotable, and reversible to any point in time while production stays locked.

**Can I scope what an individual agent can read or write in object storage?**
On AWS you can, by authoring IAM policy per agent and managing credential rotation yourself. R2 scopes tokens to buckets. IronShard issues per-agent credentials with policy-defined scopes (read-only, write-only, or custom) and records denied requests in the same signed audit record as successful ones.

**How do I prove which files my AI actually accessed?**
Standard access logs (CloudTrail, Cloud Audit Logs) are records you administer and could alter, which weakens them as evidence. IronShard's [Log](/log) seals every access event, including denials, into an immutable, cryptographically signed, searchable record designed to answer the audit question directly.

**Is there GDPR-compliant object storage for AI workloads?**
Yes. IronShard fragments, encrypts, and distributes every file across multiple providers and regions, so no single provider ever holds a complete file, and data in every storage class is stored only in GDPR-compliant regions and providers. The incumbents can be operated in GDPR-aligned configurations, but the burden of region pinning and access governance falls on you. Details in [GDPR Everywhere](/docs/gdpr-everywhere).

**Will my existing S3 tools work if I switch?**
With R2 and MinIO, mostly yes, subject to documented API gaps. With IronShard, yes by design: boto3, AWS CLI, rclone, Terraform, and data tooling work by changing a single endpoint line, and existing data imports over the S3 API. GCS is a partial migration and Azure Blob is a full one.

---

*Deeper head-to-heads: [IronShard vs. Amazon S3](/compare/ironshard-vs-s3), [vs. Cloudflare R2](/compare/ironshard-vs-cloudflare-r2), [vs. Google Cloud Storage](/compare/ironshard-vs-google-cloud-storage), [vs. Azure Blob](/compare/ironshard-vs-azure-blob), and [vs. MinIO](/compare/ironshard-vs-minio).*

*A markdown version of this page is available at [/compare/object-storage-comparison.md](/compare/object-storage-comparison.md){target="_blank"}. Agent-readable site index: [/llms.txt](/llms.txt){target="_blank"}.*