OCIStoragebeginner

OCI Object Storage & Tiers

Manage OCI Object Storage with Standard, Infrequent Access, and Archive tiers, lifecycle policies, and pre-authenticated requests.

CloudToolStack Team16 min readPublished Mar 14, 2026

Prerequisites

Basic understanding of object storage concepts
OCI account with object storage permissions

OCI Object Storage Overview

OCI Object Storage is a high-performance, scalable storage platform for unstructured data of any content type. It provides regional durability by automatically replicating data across multiple fault domains within a region, ensuring data survives hardware failures without any additional configuration. Object Storage on OCI is designed for high throughput and low latency access, making it suitable for everything from website assets and application data to backups, archives, and data lake storage.

One of OCI Object Storage's standout features is its generous data transfer pricing: the first 10 TB of outbound data transfer per month is free across all OCI services, compared to just 100 GB on AWS or Azure. This makes OCI particularly attractive for data-intensive workloads where egress costs can dominate the bill on other cloud providers.

This guide covers Object Storage architecture, storage tiers, lifecycle policies, Pre-Authenticated Requests (PARs), replication, versioning, retention rules, and integration patterns with other OCI services.

Always Free Object Storage

OCI's Always Free tier includes 10 GB of Standard tier Object Storage and 10 GB of Infrequent Access storage. Additionally, you get 50,000 API requests per month for Standard storage and 10,000 for Infrequent Access. These allowances never expire, making Object Storage an excellent option for personal projects, backups, and learning at zero cost.

Object Storage Architecture

OCI Object Storage uses a flat structure with three organizational levels:namespace (unique to each tenancy, auto-generated),bucket (a logical container within a namespace), andobject (the actual data along with metadata). Unlike a file system, there is no directory hierarchy; what appears as "folders" in the console are simply prefixes in object names separated by forward slashes.

Key Concepts

Concept	Description	Limit
Namespace	Tenancy-level container, globally unique	One per tenancy (immutable)
Bucket	Logical container for objects	Unlimited per namespace
Object	Data blob + metadata + name (key)	Up to 10 TiB per object
Object Name	Unique identifier within a bucket	Up to 1024 characters
Metadata	Custom key-value pairs on objects	Up to 10 user-defined metadata entries
Multipart Upload	Upload large objects in parts	Up to 10,000 parts per upload

bash

# Get your Object Storage namespace
NAMESPACE=$(oci os ns get --query 'data' --raw-output)
echo "Namespace: $NAMESPACE"

# Create a standard bucket
oci os bucket create \
  --compartment-id $C \
  --namespace $NAMESPACE \
  --name "application-data" \
  --storage-tier "Standard" \
  --public-access-type "NoPublicAccess" \
  --versioning "Enabled" \
  --auto-tiering "InfrequentAccess"

# List buckets
oci os bucket list \
  --compartment-id $C \
  --namespace $NAMESPACE \
  --query 'data[].{name:name, tier:"storage-tier", created:"time-created", versioning:"versioning"}' \
  --output table

# Get bucket details
oci os bucket get \
  --namespace $NAMESPACE \
  --bucket-name "application-data"

Storage Tiers

OCI Object Storage offers three storage tiers, each optimized for different access patterns and cost requirements. You choose the default tier when creating a bucket, and you can also set individual objects to different tiers within the same bucket.

Tier Comparison

Feature	Standard	Infrequent Access	Archive
Access pattern	Frequent (hot data)	Occasional (warm data)	Rare (cold data)
Retrieval time	Immediate	Immediate	1 hour (must restore first)
Minimum storage	None	None	None
Minimum retention	None	31 days (billed)	90 days (billed)
Storage cost	$$$ (highest)	$$ (lower)	$ (lowest)
Retrieval cost	None	Per GB retrieved	Per GB restored
Use cases	Active data, web assets, logs	Backups, infrequent reports	Compliance archives, old backups

bash

# Upload to standard tier (default)
oci os object put \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --file report.pdf \
  --name "reports/2026/q1-report.pdf" \
  --storage-tier "Standard"

# Upload directly to infrequent access tier
oci os object put \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --file old-backup.tar.gz \
  --name "backups/2025/old-backup.tar.gz" \
  --storage-tier "InfrequentAccess"

# Change an object's tier
oci os object update-storage-tier \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --object-name "reports/2025/q3-report.pdf" \
  --storage-tier "InfrequentAccess"

# Restore an archive object (takes up to 1 hour)
oci os object restore \
  --namespace $NAMESPACE \
  --bucket-name "archive-bucket" \
  --object-name "compliance/2020/audit-log.gz" \
  --hours 24  # How long to keep the restored copy available

# Check restore status
oci os object head \
  --namespace $NAMESPACE \
  --bucket-name "archive-bucket" \
  --object-name "compliance/2020/audit-log.gz" \
  --query '{"archival-state": "archival-state", "time-of-archival": "time-of-archival"}'

Use Auto-Tiering for Unpredictable Access

If you are unsure about access patterns, enable Auto-Tiering on your bucket. OCI automatically moves objects that have not been accessed for 30 days to the Infrequent Access tier, reducing storage costs. When an object is accessed, it remains in the Infrequent Access tier but is served immediately. Auto-Tiering only moves objects from Standard to Infrequent Access; it does not use the Archive tier. This is the easiest way to optimize storage costs without managing lifecycle policies.

Lifecycle Policies

Object lifecycle policies automate the transition of objects between storage tiers and the deletion of objects based on rules you define. Rules can match objects by name prefix, creation time, or both. Lifecycle policies are essential for managing storage costs over time, especially for log data, backups, and compliance archives.

bash

# Create a lifecycle policy
oci os object-lifecycle-policy put \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --items '[
    {
      "name": "archive-old-logs",
      "action": "ARCHIVE",
      "timeAmount": 90,
      "timeUnit": "DAYS",
      "isEnabled": true,
      "objectNameFilter": {
        "inclusionPrefixes": ["logs/"]
      }
    },
    {
      "name": "delete-temp-files",
      "action": "DELETE",
      "timeAmount": 7,
      "timeUnit": "DAYS",
      "isEnabled": true,
      "objectNameFilter": {
        "inclusionPrefixes": ["tmp/", "temp/"]
      }
    },
    {
      "name": "infrequent-access-backups",
      "action": "INFREQUENT_ACCESS",
      "timeAmount": 30,
      "timeUnit": "DAYS",
      "isEnabled": true,
      "objectNameFilter": {
        "inclusionPrefixes": ["backups/"]
      }
    },
    {
      "name": "delete-old-backups",
      "action": "DELETE",
      "timeAmount": 365,
      "timeUnit": "DAYS",
      "isEnabled": true,
      "objectNameFilter": {
        "inclusionPrefixes": ["backups/"]
      }
    }
  ]'

# Get current lifecycle policy
oci os object-lifecycle-policy get \
  --namespace $NAMESPACE \
  --bucket-name "application-data"

Pre-Authenticated Requests (PARs)

Pre-Authenticated Requests (PARs) provide time-limited, pre-signed URLs that allow access to objects or buckets without requiring OCI credentials. PARs are useful for sharing files with external users, enabling temporary upload access, or integrating with systems that cannot authenticate via OCI APIs. Each PAR has an expiration date and specified access type (read, write, or read-write).

bash

# Create a PAR for reading a specific object
oci os preauthenticated-request create \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --name "share-report-q1" \
  --access-type "ObjectRead" \
  --object-name "reports/2026/q1-report.pdf" \
  --time-expires "2026-04-14T23:59:59Z"

# The response includes the full URL to access the object
# https://objectstorage.us-ashburn-1.oraclecloud.com/p/<par-id>/n/<namespace>/b/<bucket>/o/reports/2026/q1-report.pdf

# Create a PAR for writing to a prefix (upload access)
oci os preauthenticated-request create \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --name "upload-access" \
  --access-type "AnyObjectReadWrite" \
  --bucket-listing-action "ListObjects" \
  --time-expires "2026-03-21T23:59:59Z"

# List active PARs
oci os preauthenticated-request list \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --query 'data[].{name:name, access:"access-type", expires:"time-expires", id:id}' \
  --output table

# Delete a PAR (revoke access)
oci os preauthenticated-request delete \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --par-id <par-id>

PAR Security Considerations

PARs bypass OCI IAM authentication, so anyone with the PAR URL can access the resource. Treat PAR URLs like passwords: share them securely, set short expiration times, use the most restrictive access type possible, and revoke (delete) PARs when they are no longer needed. PARs cannot be updated after creation; if you need to change the expiration or access type, delete the PAR and create a new one. Monitor PAR usage through OCI Audit logs.

Object Versioning

Versioning maintains a complete history of every object in a bucket. When versioning is enabled, overwriting an object creates a new version instead of replacing the existing one. Deleting an object creates a "delete marker" that hides the object but does not remove previous versions. Versioning protects against accidental deletion and corruption, and is essential for compliance and audit requirements.

bash

# Enable versioning on a bucket
oci os bucket update \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --versioning "Enabled"

# List object versions
oci os object list-object-versions \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --prefix "reports/" \
  --query 'data[].{name:name, version:"version-id", size:size, "time-created":"time-created", "is-delete-marker":"is-delete-marker"}' \
  --output table

# Get a specific version of an object
oci os object get \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --object-name "reports/2026/q1-report.pdf" \
  --version-id <version-id> \
  --file report-old-version.pdf

# Permanently delete a specific version
oci os object delete \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --object-name "reports/2026/q1-report.pdf" \
  --version-id <version-id> \
  --force

# Disable versioning (existing versions are preserved)
oci os bucket update \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --versioning "Suspended"

Replication

Object Storage replication asynchronously copies objects from a source bucket to a destination bucket in a different region. Replication provides geographic redundancy for disaster recovery, regulatory compliance (data must exist in multiple regions), and data locality (serve data from a region closer to users). Replication copies objects, metadata, tags, and lifecycle policies.

bash

# Create a replication policy
oci os replication create-replication-policy \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --name "cross-region-dr" \
  --destination-bucket-name "application-data-dr" \
  --destination-region "us-phoenix-1"

# List replication policies
oci os replication list-replication-policies \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --query 'data[].{name:name, destination:"destination-bucket-name", "dest-region":"destination-region-name", status:status}' \
  --output table

# Check replication status
oci os replication get-replication-policy \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --replication-id <replication-policy-id>

# Delete a replication policy
oci os replication delete-replication-policy \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --replication-id <replication-policy-id>

Retention Rules

Retention rules prevent objects in a bucket from being modified or deleted for a specified duration. This is essential for regulatory compliance (HIPAA, SOX, GDPR) and legal hold requirements. Retention rules can be time-bound (objects are locked for N days) or indefinite (objects are locked until the rule is manually removed).

bash

# Create a time-bound retention rule (1 year)
oci os retention-rule create \
  --namespace $NAMESPACE \
  --bucket-name "compliance-data" \
  --display-name "1-year-retention" \
  --time-rule-locked "2027-03-14T00:00:00Z" \
  --duration '{"timeAmount": 365, "timeUnit": "DAYS"}'

# Create an indefinite retention rule (objects locked until rule is removed)
oci os retention-rule create \
  --namespace $NAMESPACE \
  --bucket-name "legal-hold" \
  --display-name "legal-hold-rule"
  # No duration = indefinite retention

# List retention rules
oci os retention-rule list \
  --namespace $NAMESPACE \
  --bucket-name "compliance-data" \
  --query 'data[].{name:"display-name", duration:duration, "time-rule-locked":"time-rule-locked"}' \
  --output table

Locked Retention Rules Cannot Be Removed

Once a retention rule is locked (by setting time-rule-locked), it cannot be deleted or modified until the lock date passes. This means objects in the bucket cannot be deleted, even by administrators, until the retention period expires. Test retention rules thoroughly in a non-production bucket before applying them to critical data. Locked rules are designed to meet SEC Rule 17a-4(f) and similar regulatory requirements.

Bulk Operations

The OCI CLI provides efficient bulk operations for uploading, downloading, and deleting large numbers of objects. These commands handle parallelism, retry logic, and multipart uploads automatically.

bash

# Bulk upload a directory
oci os object bulk-upload \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --src-dir ./local-data/ \
  --object-prefix "uploads/2026-03/" \
  --parallel-upload-count 10 \
  --overwrite

# Bulk download objects by prefix
oci os object bulk-download \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --prefix "reports/" \
  --download-dir ./downloaded-reports/ \
  --parallel-download-count 10

# Bulk delete objects by prefix
oci os object bulk-delete \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --prefix "tmp/" \
  --force

# Multipart upload for large files (automatic for files > 128 MB)
oci os object put \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --file large-database-backup.tar.gz \
  --name "backups/db-backup-2026-03.tar.gz" \
  --part-size 128 \
  --parallel-upload-count 5

# List incomplete multipart uploads
oci os multipart list \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --query 'data[].{object:object, "upload-id":"upload-id", "time-created":"time-created"}' \
  --output table

# Abort a failed multipart upload (cleanup)
oci os multipart abort \
  --namespace $NAMESPACE \
  --bucket-name "application-data" \
  --object-name "backups/db-backup-2026-03.tar.gz" \
  --upload-id <upload-id>

S3 Compatibility API

OCI Object Storage provides an Amazon S3-compatible API that allows you to use existing S3-compatible tools, libraries, and applications with OCI Object Storage without code changes. This includes the AWS CLI, s3cmd, Cyberduck, and any application using the AWS S3 SDK.

bash

# Configure AWS CLI for OCI S3 Compatibility
# Create an S3 compatibility key in OCI Console:
# Profile > User Settings > Customer Secret Keys > Generate Secret Key

aws configure --profile oci-s3
# AWS Access Key ID: <access-key-from-oci>
# AWS Secret Access Key: <secret-key-from-oci>
# Default region name: us-ashburn-1
# Default output format: json

# Use the S3 compatibility endpoint
export OCI_S3_ENDPOINT="https://$NAMESPACE.compat.objectstorage.us-ashburn-1.oraclecloud.com"

# List buckets
aws s3 ls --profile oci-s3 --endpoint-url $OCI_S3_ENDPOINT

# Upload a file
aws s3 cp report.pdf s3://application-data/reports/ \
  --profile oci-s3 \
  --endpoint-url $OCI_S3_ENDPOINT

# Sync a directory
aws s3 sync ./local-dir s3://application-data/sync-dir/ \
  --profile oci-s3 \
  --endpoint-url $OCI_S3_ENDPOINT

Object Storage Best Practices

Area	Recommendation
Security	Never enable public access unless required. Use PARs for temporary sharing. Encrypt with customer-managed keys.
Cost	Enable auto-tiering. Use lifecycle policies to archive old data. Use the Service Gateway for free internal access.
Performance	Use multipart uploads for large files. Distribute objects across prefixes for high throughput.
Durability	Enable versioning for critical data. Use cross-region replication for DR. Set retention rules for compliance.
Organization	Use consistent naming conventions. Tag buckets for cost tracking. Separate environments into different compartments.

OCI Cost Optimization Strategies OCI Security Best Practices Getting Started with Oracle Cloud

Key Takeaways

1OCI Object Storage uses a flat namespace with buckets and objects, similar to S3.
2Three storage tiers (Standard, Infrequent Access, Archive) optimize cost by access frequency.
3Pre-authenticated requests (PARs) provide time-limited access without OCI credentials.
4Lifecycle policies automate tier transitions and object deletion.

Frequently Asked Questions

How does OCI Object Storage pricing compare to AWS S3?

OCI Object Storage Standard tier is approximately $0.0255/GB/month, compared to AWS S3 Standard at $0.023/GB/month. However, OCI includes 10 TB/month of outbound data transfer free (vs 100 GB for AWS), which makes OCI significantly cheaper for data-heavy workloads. OCI also does not charge for PUT/GET requests in most regions.

What is a Pre-Authenticated Request (PAR)?

A PAR is a URL that provides time-limited access to an object or bucket without requiring OCI credentials or API keys. PARs can be created for read-only, write-only, or read-write access and automatically expire after a specified date. They are useful for sharing files with external parties or enabling simple file uploads.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.