Replicate Settings from Existing Bucket |
Optional. To use this function, click Select Bucket and select a bucket from the list as the replication source. After the replication source is selected, the following settings are replicated to the bucket you are creating: region, data redundancy policy, storage class, bucket policy, server-side encryption, direct reading, enterprise project, and tags.
You can still change some or all of the replicated settings as needed. |
Region |
Region where the bucket is located. For low latency and faster access, select the region nearest to you. Once the bucket is created, its region cannot be changed.
Most OBS features are available in all regions, but some are only available for certain regions. Consider the feature availability in each region when you select a region for a bucket. For details, see Function Overview.
If your ECS needs to access an OBS bucket over the intranet, ensure that the bucket and the ECS are in the same region. For details, see Accessing OBS over an Intranet. |
Bucket Name |
Name of the bucket. A bucket name must be unique across all accounts and regions. Once a bucket is created, its name cannot be changed.
According to the globally applied DNS naming rules, an OBS bucket name:
- Must be unique across all accounts and regions. The name of a deleted bucket can be reused for another bucket or a parallel file system at least 30 minutes after the deletion.
- Must be 3 to 63 characters long. Only lowercase letters, digits, hyphens (-), and periods (.) are allowed.
- Cannot start or end with a period (.) or hyphen (-), and cannot contain two consecutive periods (..) or contain a period (.) and a hyphen (-) adjacent to each other.
- Cannot be formatted as an IP address.
NOTE:
When you access OBS through HTTPS using virtual hosted-style URLs, if the bucket name contains a period (.), the certificate verification will fail. To work around this issue, you are advised not to use periods (.) in bucket names.
|
Data Redundancy Policy |
- Multi-AZ storage: Data is stored in multiple AZs to achieve higher reliability.
- Single-AZ storage: Data is stored in a single AZ, with lower costs.
For details about the performance comparison between multi-AZ and single-AZ storage, see Comparison of Storage Classes.
Once a bucket is created, the data redundancy policy cannot be changed, so choose the policy that can meet your needs.
- Multi-AZ storage is not available for buckets in the Archive storage class.
|
Storage Class |
Storage classes of a bucket. These storage classes can meet different needs for storage performance and costs.
- The Standard storage class is for storing a large number of hot files or small files that are frequently accessed (multiple times per month on average) and require quick retrieval.
- The storage class is for storing data that is less frequently accessed (less than 12 times per year on average) and requires quick retrieval.
- The Archive storage class is for archiving data that is rarely accessed (once a year on average) and has no requirements for quick retrieval.
For details, see Storage Classes. |
Block All Public Access |
Used to centrally set certain levels of public access to buckets.
Enabling all the settings will prevent the creation of an ACL or a bucket policy to allow public access. When APIs are used for authentication, such ACLs or bucket policies will be ignored. However, existing bucket policies that allow public access remain unaffected.
The following four settings are supported:
- Enabling the setting will prevent creating or modifying an ACL to allow public read/write or grant anonymous users read/write permissions. Enabling this setting does not affect existing ACLs that allow public read/write or grant anonymous users read/write permissions.
- Enabling the setting will prevent creating or modifying a bucket policy to allow public access (read/write permissions for non-bucket owners). Enabling this setting does not affect existing bucket policies that allow public access.
- Enabling the setting will ignore ACLs that allow public read/write or grant anonymous users read/write permissions when OBS APIs are used for authentication.
- Enabling the setting will ignore bucket policies that allow public access (read/write permissions for non-bucket owners) when OBS APIs are used for authentication.
NOTE:
To block all public access, your account must have the PutBucketPublicAccessBlock permission.
For details, see Block Public Access. |
Bucket Policy |
Controls read and write permissions for buckets.
- Private: No access beyond the bucket ACL settings is granted.
- Public Read: Anyone can read objects in the bucket.
- Public Read and Write: Anyone can read, write, or delete objects in the bucket.
|
Enterprise Project |
You can add a bucket to an enterprise project for unified management.
Create an enterprise project by referring to Creating an Enterprise Project. The default enterprise project is named default.
On the Enterprise Project Management Service page, create an enterprise project, and add a user group to the enterprise project. By doing so, users in this user group obtain the operation permissions for the buckets and objects in the enterprise project.
NOTE:
Only an enterprise account can configure enterprise projects.
OBS ReadOnlyAccess and OBS OperateAccess are the fine-grained authorizations of the enterprise project user group in OBS.
|
Direct Reading |
Direct reading allows you to directly download objects from the Archive storage class without restoring them first. Direct reading is a billable function. For details, see Product Pricing Details.
No matter which default storage class you select, you can enable direct reading for your bucket. For example, if you select the Standard storage class and enable direct reading for your bucket, you can directly download objects stored in the Archive storage class from your bucket. |
Server-Side Encryption |
Choose SSE-KMS. DEW APIs have traffic control limits. For details, see DEW API Overview. After SSE-KMS is enabled, your service access may be affected by traffic control.
- You can choose Default to use the default key in the current region to encrypt the objects you upload to the bucket. If you do not have a default key, OBS automatically creates one the first time you upload an object.
- You can also choose Custom to use a custom key for encryption. If there is no custom key available, click View KMS Keys to create one.
- You can also select Shared to enter a shared key ID. The key shared by other users will be used to encrypt your objects. For details about how to obtain a shared key ID, see Viewing a CMK.
NOTE:
A shared key from a project or a subproject can be configured here. However, if a shared key from a subproject is specified, the owner of the shared key cannot access objects encrypted with that key, but the bucket owner can.
Selecting SSE-OBS for Encryption Method will use the keys created and managed by OBS for encryption.
When Server-Side Encryption is enabled for a bucket, you can configure the object you upload to inherit encryption from the bucket or choose SSE-KMS or SSE-OBS. |
WORM |
When you enable write-once-read-many (WORM), you can configure a retention policy for the current bucket. The object version which the retention policy is applied to cannot be deleted within a specified period. You can only enable WORM when you create a bucket. Once enabled for a bucket, WORM cannot be disabled. When you enable WORM, OBS automatically enables versioning for the bucket, and versioning cannot be suspended later for that bucket. |
Tags |
Optional. Tags are used to identify and classify buckets in OBS. Each tag is represented by a key-value pair.
For more information, see Adding Tags to a Bucket. |