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.
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 Copy linkLink copied to clipboard!
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.
| Environment | Recommended Backend | CA 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 Copy linkLink copied to clipboard!
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:
| Permission | Purpose |
|---|---|
|
| List objects in the bucket. Required for LokiStack to query and retrieve stored log chunks. |
|
| Write log chunks and index files to the bucket. Required for log ingestion. |
|
| Read log chunks and index files from the bucket. Required for log queries and compaction. |
|
| Delete expired log chunks based on retention policies. Required for the compactor component. |
|
| Read object tags. Required for retention and lifecycle management. |
|
| Write object tags. Required for retention and lifecycle management. |
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
Some S3 Compatible storage providers use different permission models or naming conventions. Verify that your credentials can perform all six S3 operations listed above.