5.2 OCI Object Storage Service

5.2 OCI Object Storage Service

[!NOTE] Foundations Blueprint Focus: OCI Object Storage is heavily evaluated in the 1Z0-1085-26 exam. Candidates must understand the flat object namespace, bucket containers, the operational trade-offs across storage tiers (Standard, Infrequent Access, Archive), Auto-Tiering mechanics, Object Lifecycle Management rules, Pre-Authenticated Requests (PARs), object versioning, and Write Once Read Many (WORM) retention policies.

Modern cloud architectures generate vast amounts of unstructured data—including multimedia files, system backups, database export dumps, application log streams, and big data analytic datasets. Unlike block or file systems that organize data into fixed sectors or hierarchical directory trees, OCI Object Storage is an internet-scale, high-performance storage platform engineered specifically for unstructured content.

---

Object Storage Architecture & Fundamentals

OCI Object Storage is a fully managed, multi-tenant cloud service that stores an unlimited amount of raw unstructured data. It provides high throughput, extreme resilience, and global accessibility.

Foundational Architecture Components

• Regional Scope: Object Storage is a regional service. Unlike Block Volumes (which are tied to a single Availability Domain), Object Storage automatically spans all Availability Domains and Fault Domains within an OCI region. If an entire Availability Domain experiences an outage, data stored in Object Storage remains accessible without interruption.
• Eleven Nines of Durability (99.999999999%): Data durability is achieved through automated multi-server replication, erasure coding, and continuous data integrity verification across physical storage nodes within the region.
• Flat Namespace Hierarchy: Object Storage does not utilize a traditional nested folder file system. Data is stored in a completely flat hierarchy. When users view "folders" in the OCI Console, these are merely visual simulated directories created by including forward slashes (/) in the object name string (for example, finance/2026/q3_report.pdf).
• Tenancy Namespace: Each OCI tenancy is assigned a unique, immutable, system-generated string known as the Namespace (which can also be customized with a vanity name). The namespace acts as the root container for all buckets across all compartments in that tenancy.
• Buckets: Logical containers created within a tenancy namespace to organize and store objects. While bucket names must be unique within a tenancy's namespace, multiple buckets with the same name can exist in different tenancies. Buckets serve as the policy boundary for access control, default storage tiering, versioning, retention rules, and encryption settings.
• Objects: An individual data item stored within a bucket. An object consists of the raw data payload (any binary or text format, ranging from 0 bytes up to 10 Terabytes per object) and associated metadata (system-generated metadata such as MD5 hash and creation time, plus user-defined key-value tags).

Access Interfaces

Object Storage is universally accessible from inside OCI and across the public internet:

• HTTPS REST APIs: Programmatic direct access over standard web protocols.
• OCI Console, CLI, and Software Development Kits (SDKs): Full management and data plane automation across Python, Java, Go, TypeScript, and .NET.
• Amazon S3 Compatibility API: OCI provides an S3-compatible API endpoint, allowing existing enterprise applications and backup utilities configured for AWS S3 to connect directly to OCI Object Storage by simply changing API credentials and endpoint URLs.

Object Storage Tiers: Standard, Infrequent Access & Archive

To balance access speed against storage expenditures, OCI provides three primary storage tiers:

+-------------------------------------------------------------------------+
|                     OCI Object Storage Tier Hierarchy                   |
|                                                                         |
|  +--------------------+  +--------------------+  +--------------------+ |
|  |   Standard Tier    |  | Infrequent Access  |  |    Archive Tier    |
|  |       (Hot)        |  |       (Cool)       |  |       (Cold)       |
|  +--------------------+  +--------------------+  +--------------------+ |
|  | - Frequent access  |  | - Infrequent access|  | - Long-term archive|
|  | - Instant retrieval|  | - Instant retrieval|  | - Up to 1h restore |
|  | - No retrieval fee |  | - Small ret. fee   |  | - Lowest cost/GB   |
|  | - No min retention |  | - 31-day min ret.  |  | - 90-day min ret.  |
|  +--------------------+  +--------------------+  +--------------------+ |
+-------------------------------------------------------------------------+

1. Standard Storage Tier (Hot Storage)

• Access Pattern: Designed for data that requires frequent, continuous access and immediate, low-latency retrieval.
• Operational Profile: Real-time read and write operations; no data retrieval fees and no minimum retention duration.
• Target Workloads: Active web application assets, customer-facing media streaming, big data analytics engines, and primary application database backups.

2. Infrequent Access Tier (Cool Storage)

• Access Pattern: Designed for data that is accessed rarely (e.g., once or twice a month) but requires instantaneous, immediate retrieval when requested.
• Cost Dynamics: Offers substantial storage cost savings (~40% to 50% lower monthly storage cost per gigabyte compared to Standard).
• Retention and Fees: Imposes a 31-day minimum storage retention requirement (deleting or replacing an object before 31 days incurs a pro-rated fee for the remaining days) and charges a small data retrieval fee per gigabyte read.
• Target Workloads: Secondary application backups, quarterly financial logs, historical user documents, and disaster recovery archives requiring immediate accessibility.

3. Archive Storage Tier (Cold Storage)

• Access Pattern: Designed for cold, rarely accessed data retained strictly for compliance, legal discovery, or multi-year business archives.
• Cost Dynamics: Provides the lowest storage price in OCI (up to 90% cheaper than the Standard tier).
• Asynchronous Retrieval (Restore Required): Objects stored in Archive cannot be downloaded immediately. You must first initiate an asynchronous restore request. Oracle states that from the time a restore request is made it takes at most one hour to read the data, measured as Time To First Byte (TTFB); how long the full object takes to land depends on its size. Once restored, the object enters a temporary download window (configurable from 1 to 240 hours, defaulting to 24 hours) during which it can be downloaded before reverting back to the cold archive state.
• Retention Rule: Imposes a 90-day minimum storage retention period.
• Target Workloads: Regulatory audit logs, multi-year medical imaging archives, historical tax records, and long-term disaster recovery snapshots.

Object Storage Tier Comparison Matrix

---

Auto-Tiering & Object Lifecycle Management

Managing storage costs across millions of objects manually is impractical. OCI provides two native automation mechanisms to govern storage lifecycles:

1. Auto-Tiering

• Automated Intelligence: Auto-Tiering is configured at the bucket level. It automatically monitors the access patterns of individual objects.
• Zero-Downtime Transition: If an object in a Standard bucket is not accessed for a specified threshold (e.g., 30 consecutive days), Auto-Tiering automatically shifts the object from the Standard tier to the Infrequent Access tier to reduce costs.
• Instant Rehydration: If an application subsequently reads the object, Auto-Tiering instantly serves the request without latency and transitions the object back to the Standard tier.
• Benefits: Completely automated; requires zero code modifications or scheduled cron jobs.

2. Object Lifecycle Management

• Rule-Based Automation: Enables administrators to define automated lifecycle policies at the bucket level based on object age, name prefixes, or tag criteria.
• Supported Actions:
  1. Tier Transition: Automatically move objects from Standard to Infrequent Access, or from Standard to Archive after a set number of days (e.g., move to Archive after 60 days).
  2. Expiration (Deletion): Automatically and permanently delete objects after a specified number of days (e.g., purge debug logs after 14 days).
  3. Multipart Upload Cleanup: Automatically abort and purge incomplete, uncommitted multipart uploads after a specified number of days to prevent unnecessary storage consumption.

---

Pre-Authenticated Requests (PARs)

In many enterprise scenarios, organizations need to share an object (such as a database export file or an architectural diagram) with an external third-party auditor, vendor, or client who does not possess an OCI user account or IAM credentials. Making the bucket public would violate security policies.

A Pre-Authenticated Request (PAR) is a secure, unique, time-delimited URL that grants specific access permissions to a bucket or object without requiring OCI IAM credentials:

+-------------------------------------------------------------------------+
|                     Pre-Authenticated Request (PAR)                     |
|                                                                         |
|   [ External Auditor / Client ]  (No OCI Account / No IAM Credentials)  |
|                 │                                                       |
|                 │ 1. HTTPS GET / PUT with Unique Secret PAR Token       |
|                 ▼                                                       |
|   https://objectstorage.us-ashburn-1.oraclecloud.com/p/V8x.../b/my-bkt/ |
|                 │                                                       |
|                 │ 2. Validates Expiration Date & Configured Permissions |
|                 ▼                                                       |
|   [ OCI Private Bucket / Object ]  (Bucket Remains 100% Private!)       |
+-------------------------------------------------------------------------+

Key Characteristics of PARs

• Granular Scopes: Can be created on an individual object or across an entire bucket.
• Access Permissions: Can be configured for Read-Only, Write-Only (allowing external partners to upload files directly into a private bucket without seeing existing files), or Read/Write.
• Mandatory Expiration: Every PAR must have an explicit expiration date and time. Once the expiration timestamp passes, the URL immediately becomes invalid.
• Instant Revocation: Administrators can manually delete or revoke a PAR at any time in the OCI Console, instantly terminating third-party access even before the scheduled expiration date.

---

Versioning, Retention Rules (WORM) & Multipart Uploads

• Object Versioning: Protects against accidental deletion or overwrites. When enabled on a bucket, updating an existing object creates a new version while retaining prior versions. Deleting an object creates a "delete marker," allowing prior versions to be restored effortlessly.
• Retention Rules (WORM - Write Once, Read Many): Satisfies strict regulatory and legal compliance mandates (e.g., SEC Rule 17a-4, FINRA, HIPAA):
  • Time-Bound Retention: Objects placed in the bucket cannot be deleted, overwritten, or modified until the specified retention duration elapses.
  • Indefinite Retention (Legal Hold): Locks objects indefinitely until an authorized compliance officer explicitly releases the hold.
  • Locked Retention Rules: Administrators can permanently lock a retention rule. Once locked, the rule cannot be removed or shortened—even by tenancy administrators—guaranteeing tamper-proof immutability.
• Multipart Uploads: Recommended for objects larger than 100 MiB, and required above 50 GiB because that is the largest object a single PutObject call accepts (the overall object ceiling is 10 TiB). Large files are split into smaller chunks and uploaded in parallel, dramatically accelerating upload speeds and allowing interrupted transfers to resume without restarting from scratch.