Presentation

Simple Object Storage (or SOS) is a storage service over the HTTP(s) protocol by Exoscale.

Features

Simple Object Storage service has the main features of an S3 compatible storage:

  • Available in multiple locations
  • High data durability
  • Supported in a large number of tools, libraries, languages

S3 Unsupported Features

While we strive to maintain full compatibility with the S3 API, we do not support all S3 features. Currently, the following functionality cannot be used on Exoscale:

Limits

The following table shows which limits are applied to SOS compared to AWS.

Usage Limit AWS S3 equivalent
Maximum number of buckets 20 (service limit upgradeable) 100
Maximum object size 4TiB 5TiB
Maximum number of parts in a multipart upload 10000 10000
Minimum part size 5MiB (does not apply to last part) 5MiB (does not apply to last part)
Maximum part size 5GiB 5GiB
Maximum number of objects in a bucket unlimited unlimited
Maximum number of versions per object 1000 unlimited
Minimum billed size 128kb 128kb
Maximum metadata size 2kb 2kb
Maximum tags per object 10 10
Maximum tag key size 128 char 128 char
Maximum tag value size 256 char 256 char
Maximum bucket name size 64 char (DNS compatible) 64 char (DNS compatible)
Maximum key name size 1024 byte UTF-8 string 1024 byte UTF-8 string
Maximum number of objects per delete-objects operation 1000 1000

Advanced Options

Buckets and objects support advanced options:

Those options are available through the API. ACL, CORS and Metadata can also be configured through the Portal.

IAM

It is possible to limit programmatic access to a specific bucket by creating dedicated IAM API Keys and limit them to a single bucket.

ACL

With Access Control Lists (ACLs), you can define specific permissions at the bucket level and single object level for a granular access policy. ACLs are not inherited from parent objects.

ACLs let you manage access to buckets and objects with read, write, read ACP, write ACP, and full control (read + write) rights. You can make your objects accessible by their public URL, your buckets writable by your team, and so on.

For in-depth details about ACLs, you can look at the SOS ACL documentation.

CORS

With CORS (Cross-Origin Resource Sharing) your browser-based applications can perform actions on buckets and objects contained in a bucket. CORS is available only at the bucket level, and CORS configuration is applied to all the objects contained in a bucket.

The SOS CORS documentation has a breakdown and examples.

Metadata

Each object contained in a bucket can be tagged with key-value pairs. This metadata is presented through HTTP headers on SOS requests and responses.

You can read the SOS Metadata documentation for more information and examples.

Encryption

Both client side encryption and SSE-C are supported encryption options with SOS. To learn more about client side encryption, refer to the client library documentation.

For server side encryption details you can read the SSE-C documentation for more information and examples.

Conditional Writes

Mechanisms like object locking or other synchronization methods are often used to avoid race conditions, which can lead to data inconsistency and corruption. However, these approaches usually rely on external code and introduce an additional orchestration layer. By default, the Object Store does not prevent race conditions when several clients try to create the same object concurrently. Conditional writes offer a straightforward solution. They act as a verification step, preventing accidental overwrites in concurrent write scenarios. This simplifies the process and ensures data integrity.

Conditional Writes in SOS