Object storage
What is S3-compatible object storage?
S3-compatible object storage stores data as named objects inside buckets and exposes those objects through an HTTP API. The familiar S3 request model makes many tools portable between providers, but compatibility should be treated as a tested protocol surface. It does not promise that every AWS service exists elsewhere.
Start with buckets, objects and keys
A bucket is a top-level namespace. An object combines bytes with a key and metadata. The key can contain slash characters, so software often presents keys as folders even though the backend is not maintaining a traditional directory tree.
That difference matters when an application expects file locking, random in-place writes or POSIX permissions. Object storage normally replaces an object with a new version of its bytes. It does not behave like a mounted disk.
The endpoint is part of the configuration
An S3 client needs an HTTPS endpoint, a region or signing scope, and credentials. A non-AWS provider usually requires the endpoint to be entered explicitly; leaving the AWS default in place can send requests to the wrong service.
Path-style and virtual-hosted-style requests also affect DNS and TLS. A compatibility test should cover the addressing style the intended client actually uses. One command-line example is not enough proof.
Authentication usually means Signature Version 4
Modern S3 clients sign requests with an access key and secret key. The signature covers request details and prevents a client from simply sending the secret across the network as a password.
The secret still needs the same care as any production credential. Put it in a secret store or protected application configuration, scope its permissions narrowly, and make rotation part of the operating plan.
Compatibility has boundaries
Core bucket and object operations, multipart uploads and presigned URLs are common compatibility targets. AWS-specific services around S3—such as unrelated IAM products, event integrations or proprietary management features—should not be assumed to exist just because basic object operations work.
Before production use, test the exact SDK, backup application or workflow that will depend on the service. Record unsupported operations so later users do not turn an untested assumption into a recovery problem.
Choose object storage for object-shaped workloads
Backups, immutable-style archives, media, application uploads, generated artifacts and static assets often map naturally to objects. A database data directory or a workload that needs block-level updates usually does not.
The protocol can be extremely useful without being universal. Start by describing how the application reads, writes, lists and deletes data, then choose the storage model that matches those operations.