Object Storage Buckets

Learn about Object Storage buckets, in which you can store objects in a compartment.

In the Object Storage service, a bucket is a container for storing objects in a compartment  within an Object Storage namespace. A bucket is associated with a single compartment. The compartment has policies  that indicate what actions you can perform on a bucket and all the objects in the bucket.

You can't nest buckets—a bucket can't contain other buckets.

You can perform the following Object Storage bucket tasks:

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

If you're new to policies, see Getting Started with Policies and Common Policies.

For administrators:

Security Zones

Security Zones ensure that your cloud resources comply with Oracle security principles. If any operation on a resource in a security zone compartment violates a policy for that security zone, then the operation is denied.

The following security zone policies affect your ability to manage buckets:

  • You can't move a bucket from a security zone to a compartment that isn't in the same security zone, because it might be less secure. For details, see Restrict Resource Movement.
  • Buckets in a security zone must be private.
  • Buckets in a security zone must use customer-managed master encryption keys in the Vault service.

Pre-Authenticated Requests

Pre-authenticated requests provide a way to let you access a bucket or an object without having your own credentials. For example, you can create a request that lets you upload backups to a bucket without owning API keys. See Pre-Authenticated Requests for Object Storage for details.

Object Versioning

You can enable object versioning to retain previous versions of objects. Object versioning lets you view, retrieve, and recover previous versions of objects and provides protection against accidental or malicious object overwrite or deletion. For information about this feature, see Object Storage Versioning.

Object Lifecycle Policies

Using object lifecycle policies applied at the bucket level, you can automatically manage the archiving and deletion of objects according to a pre-defined schedule. For information about this feature, see Object Lifecycle Management for Object Storage.

Retention Rules

You can apply retention rules at the bucket level to provide immutable object storage options for data written to Object Storage for governance, regulatory compliance, and legal requirements. For information about this feature, see Data Retention Rules for Object Storage.

Replication Policy

Using a replication policy for a bucket, you can automatically replicate the objects in one Object Storage bucket to another bucket in the same region or a different region. For information about this feature, see Replication.

Tagging Resources

Apply tags to your resources to help organize them according to your business needs. Apply tags at the time you create a resource, or update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.

Object Storage supports adding tags to buckets.

Monitoring Resources

You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.

For information about monitoring buckets, see Object Storage Metrics.

Usage Reports

A usage report is a comma-separated value (CSV) file that can be used to get a detailed breakdown of resources in Oracle Cloud Infrastructure for audit or invoice reconciliation. A usage report is generated daily and stored in an Object Storage bucket. For more information, see Cost and Usage Reports Overview and Accessing Cost and Usage Reports.

Creating Automation Using Events

You can create automation based on state changes for your Oracle Cloud Infrastructure resources by using event types, rules, and actions. For more information, see Overview of Events.

Buckets emit events for bucket state changes by default. Events for objects are handled differently than other resources. Objects do not emit events by default. Use the Console, CLI, or API to enable a bucket to emit events for object state changes. You can enable events for object state changes during or after bucket creation. See Enabling or Disabling Emitting Events for Object State Changes for more information.

Bucket Names

Bucket names are system generated by default, but you can overwrite the default with a name you specify.

System-Generated Bucket Names

When a bucket is created, the system generates a default name for that bucket, for example bucket-20190306-1359. This bucket name identifies the current year, month, and day that the bucket was created. You can use that system-generated name for your new bucket or you can specify a different name.

User-Specified Bucket Names

If you change this default bucket name or the name of any bucket, observe the following:

  • Make the name unique within your tenancy's Object Storage namespace.
  • Use from 1 to 256 characters.
  • Valid characters are letters (upper or lowercase), numbers, hyphens, underscores, and periods.
    Important

    Bucket names and object names are case-sensitive. Object Storage handles accounts-payable and Accounts-Payable as separate buckets.
  • Avoid entering confidential information.

Default Storage Tiers

When you create a bucket, you decide which default storage tier is appropriate for storing the objects:

  • Use the Standard tier for data to which you need fast, immediate, and frequent access.
  • Use the Archive tier for data to which you seldom or rarely access, but that must be retained and preserved for long periods of time.

The storage tier property is then assigned to each object that you upload to a bucket.

For more information, see Understanding Storage Tiers. To automate the movement of data to the most cost effective tier, see Auto-Tiering.

Important

You can't change the default storage tier of a bucket after creation.

Public Buckets

When you create a bucket, the bucket is considered a private bucket and the access to the bucket and bucket contents requires authentication and authorization. However, Object Storage supports anonymous, unauthenticated access to a bucket that is not in a security zone. You make a bucket public by enabling read access to the bucket.

Important

Carefully assess the business requirement for public access to a bucket. When you enable anonymous access to a bucket, any user can obtain object metadata, download bucket objects, and optionally list bucket contents. We recommend using pre-authenticated requests instead of public buckets. Pre-authenticated requests support more authorization, expiry, and scoping capabilities not possible with public buckets. See Pre-Authenticated Requests for Object Storage for details.

Required Permissions

The following permissions are required to configure a public bucket:

  • To enable public access when creating a bucket, use permission BUCKET_CREATE.

  • To enable public access for an existing bucket, use permission BUCKET_UPDATE.

Options

When creating a public bucket, you have the following options:

  • You can configure the access to allow listing and downloading objects. List and download access is the default.

  • You can configure the access to allow downloading objects only. A user couldn't list bucket contents.

Scope and Constraints

Understand the following scope and constraints regarding public access:

  • Buckets in a security zone can't be public.
  • Changing the type of access is bi-directional. You can change a bucket's access from public to private or from private to public.
  • Changing the type of access doesn't affect existing pre-authenticated requests. Existing pre-authenticated requests still work.

You can enable anonymous public access for new or existing buckets using the Console, CLI, or an SDK to access the API.