---
title: Configure object storage
description: Configure InfluxDB 3 Enterprise to connect to and use different object storage providers.
url: https://docs.influxdata.com/influxdb3/enterprise/admin/object-storage/
estimated_tokens: 1153
product: InfluxDB 3 Enterprise
version: enterprise
publisher: InfluxData
canonical: https://docs.influxdata.com/influxdb3/enterprise/admin/object-storage/
date: '2025-07-17T14:14:17-06:00'
lastmod: '2025-07-17T14:14:17-06:00'
---

InfluxDB 3 Enterprise can be configured to use different object storage providers
to store time series data in Parquet format. The process of configuring and
connecting to different object storage providers varies.
The following guides walk through configuring, connecting to, and using
different object storage providers as your InfluxDB 3 Enterprise object store.

### [Amazon S3](/influxdb3/enterprise/admin/object-storage/s3/)

Use [Amazon S3](https://aws.amazon.com/s3/) as the object store for your
InfluxDB 3 Enterprise instance.

### [MinIO](/influxdb3/enterprise/admin/object-storage/minio/)

Use [MinIO](https://min.io) as the object store for your InfluxDB 3 Enterprise instance.
InfluxDB uses the MinIO S3-compatible API to interact with your MinIO server or
cluster.

### [Google Cloud Storage](/influxdb3/enterprise/admin/object-storage/gcs/)

Use [Google Cloud Storage](https://cloud.google.com/storage) as the object
store for your InfluxDB 3 Enterprise instance.

### [Azure Blob Storage](/influxdb3/enterprise/admin/object-storage/azure/)

Use [Azure Blob Storage](https://azure.microsoft.com/products/storage/blobs)as the object store for your InfluxDB 3 Enterprise instance.

## Object store requirements

InfluxDB 3 Enterprise uses the object store as the source of truth for catalog
state.
The catalog write path relies on conditional PUT (PUT-if-not-exists) to
serialize catalog log writes, and every node depends on immediate visibility
of writes made by any other node.
Your object store deployment must provide the object store semantics
InfluxDB 3 Enterprise depends on.

### Consistency semantics

InfluxDB 3 Enterprise requires at least the following from any object store:

* **Strong read-after-write consistency**: a `GET` immediately after a
  successful `PUT` returns the new object.
* **Strong list-after-write consistency**: a `LIST` immediately after a
  successful `PUT` includes the new key.
* **Conditional PUT (PUT-if-not-exists) semantics**: concurrent creates of the
  same key serialize so that exactly one write succeeds and the other returns`AlreadyExists`.

A backend that violates these semantics can cause catalog split-brain, stale
reads on node startup, and unexpected node-state warnings.

### Verify your object store

InfluxDB 3 Enterprise 3.10.0 and later includes the[`influxdb3 debug object-store-check`](/influxdb3/enterprise/reference/cli/influxdb3/debug/object-store-check/)command that validates an object store against the preceding semantic requirements.
Run it against your object store endpoint before putting the deployment into
production, and again after any change to its topology or backing storage:

```bash
influxdb3 debug object-store-check \
  --object-store s3 \
  --bucket influxdb3 \
  --aws-endpoint http://localhost:9000 \
  --aws-access-key-id MINIO_USERNAME \
  --aws-secret-access-key MINIO_PASSWORD \
  --aws-allow-http \
  --check-prefix CHECK_PREFIX
```

Replace the following:

* `CHECK_PREFIX`:
  a prefix for the tool’s synthetic test objects, such as `oscheck`.`--check-prefix` is required.

1. The tool writes and deletes synthetic test objects under`<CHECK_PREFIX>/oscheck-<uuid>/`, where `oscheck-<uuid>` is a fixed,
   tool-generated subdirectory name (not user-configurable) that’s unique
   to each run, and reports any semantic violation it finds.
2. If every check passes, your object store meets the semantics
   InfluxDB 3 Enterprise depends on.
3. If a check fails, resolve the reported issue in your object store or its
   configuration, and then rerun the command.
4. If the synthetic checks pass but a real catalog is still failing to load,
   add `--probe-prefix <your-catalog-prefix>` to also replay the loader’s
   object store operations against your real catalog.
   The probe itself is read-only, but the command still runs the synthetic
   write and delete checks under `--check-prefix` first, so that prefix must
   remain writable and the credentials need read, write, delete, and list
   permissions on it–for example, an AWS IAM policy needs `s3:GetObject`,`s3:PutObject`, `s3:DeleteObject`, and `s3:ListBucket`(see [Create IAM credentials](/influxdb3/enterprise/admin/object-storage/s3/#create-iam-credentials)for a sample policy).

See [`influxdb3 debug object-store-check`](/influxdb3/enterprise/reference/cli/influxdb3/debug/object-store-check/)for the full flag reference.

#### Related

* [InfluxDB 3 Enterprise configuration options](/influxdb3/enterprise/reference/config-options/)

[object storage](/influxdb3/enterprise/tags/object-storage/)[S3](/influxdb3/enterprise/tags/s3/)