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.
Bucket Tasks
You can perform the following Object Storage bucket tasks:
To use Oracle Cloud Infrastructure, an administrator must be a member of a group granted security access in a policy by a tenancy 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 the tenancy administrator what type of access you have and which compartment your access works in.
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 Object Storage Pre-Authenticated Requests 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 Storage Object Lifecycle Management.
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 Object Storage Data Retention Rules.
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 Object Storage Replication.
Tagging Resources 🔗
Apply tags to resources to help organize them according to 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.
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 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 don't 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.
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 Object Storage Pre-Authenticated Requests 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.