Chapter 4. Choose a LokiStack storage backend


If you chose Scenario 2 (Vector + Loki) or Scenario 3 (Vector + Loki + COO), you must select and plan for an S3-compatible object storage backend before installation. LokiStack stores all log data in object storage.

Important

This planning topic covers object storage selection and requirements. This is separate from the block storage (StorageClass) requirement that applies to all scenarios.

Both storage types are mandatory for Loki deployments:

  • Block storage (StorageClass): For LokiStack internal PVCs (ingesters, compactor)
  • Object storage (S3-compatible): For actual log chunks and indices

Plan for both before proceeding to installation.

4.1. Storage backend selection guide

Selecting the right object storage backend is critical for LokiStack performance, cost, and reliability. As a cluster administrator, you must confirm that your choice meets your log volume and retention requirements.

Table 4.1. Storage selection decision tree
EnvironmentRecommended BackendCA Bundle Required?

Public Cloud (AWS)

Amazon S3

Depends on configuration 1

Public Cloud (GCP)

Google Cloud Storage (GCS)

Depends on configuration 1

Public Cloud (Azure)

Azure Blob Storage

Depends on configuration 1

On-site

Red Hat OpenShift Data Foundation Ceph RGW (RADOS Gateway) 2

Depends on configuration 3

On-site

S3 Compatible storage 4

Depends on configuration 3

Edge and single-node

Forward to central hub

N/A

1 CA bundle required when using: custom endpoints with self-signed certificates, VPC endpoints with internal CAs, or private link configurations with custom certificate chains. Not required when using standard public cloud endpoints with publicly trusted certificates.

2 Ceph RGW (RADOS Gateway) is also known as NooBaa in Rook implementations of OpenShift Data Foundation.

3 CA bundle required when using self-signed certificates or internal certificate authorities. Not required when using publicly trusted certificates from a recognized CA.

4 S3 Compatible storage includes NetApp StorageGRID, Cloudian HyperStore, and other S3-compatible providers.

Key considerations:

  • Public Clouds: Use cloud-native options such as Amazon S3, GCS, or Azure Blob. These are the most tested and natively supported backends.
  • On-site: OpenShift Data Foundation (Ceph RGW) is the recommended solution for Red Hat OpenShift.
  • Sizing: Your choice of backend affects retention policies and query performance.
  • Air-gapped clusters: Ensure your internal storage provider is reachable from all nodes in the cluster.

4.2. Object storage permissions requirements

The credentials used to access S3-compatible object storage must have specific permissions to allow LokiStack to read, write, and manage log data.

Required S3 API permissions

The following S3 API permissions are required for LokiStack to function correctly:

PermissionPurpose

s3:ListBucket

List objects in the bucket. Required for LokiStack to query and retrieve stored log chunks.

s3:PutObject

Write log chunks and index files to the bucket. Required for log ingestion.

s3:GetObject

Read log chunks and index files from the bucket. Required for log queries and compaction.

s3:DeleteObject

Delete expired log chunks based on retention policies. Required for the compactor component.

s3:GetObjectTagging

Read object tags. Required for retention and lifecycle management.

s3:PutObjectTagging

Write object tags. Required for retention and lifecycle management.

Important

Without s3:DeleteObject permission, the LokiStack compactor cannot remove expired logs. This causes the bucket to grow indefinitely, even when retention policies are configured. The LokiStack shows Ready but old logs are never deleted.

Example IAM policy for AWS S3

If using Amazon S3, create an IAM policy with the following permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::<bucket_name>"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectTagging",
        "s3:PutObjectTagging"
      ],
      "Resource": "arn:aws:s3:::<bucket_name>/*"
    }
  ]
}

Replace <bucket_name> with your actual S3 bucket name.

Permissions for S3-compatible storage

For S3-compatible storage providers (NetApp StorageGRID, Cloudian HyperStore, and others), ensure the access credentials have equivalent permissions to the S3 API operations listed above. The exact configuration method varies by storage provider.

Consult your storage provider’s documentation for:

  • How to create users or service accounts
  • How to grant S3 API permissions to those accounts
  • Whether additional permissions are required for your specific storage implementation
Note

Some S3 Compatible storage providers use different permission models or naming conventions. Verify that your credentials can perform all six S3 operations listed above.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top