Last month, the SNIA Cloud Storage Technologies Community hosted a live webinar, “Community Driven S3 Compatibility Testing,” where engineers from multiple technology leaders shared their interoperability testing experiences among various S3 implementations at the SNIA Cloud Object Storage Plugfest in April 2025. The session was highly rated by the audience and generated several intriguing questions, which Frank Borich from IBM and Jeff Terrace from Google have answered here.
Q: How does the community feel about the virtual host addressing versus path based addressing options for the API? Especially for on-prem customers/products this requires more complex DNS setups, and TLS certificates.
A: Virtual host addressing (e.g. bucketname.service.com) and path-style addressing (e.g. service.com/bucketname) both have tradeoffs.
As you allude to, virtual-host addressing makes DNS and SSL certificates more difficult. SSL also isn't possible for bucket names with dots in the name, since SSL certificate wildcards only support a single subdomain. But virtual-host style does allow for powerful DNS-based routing and load balancing, and it also segments web-based requests into different origins, which can be important for security.
Path-style addressing is simpler, but it doesn't allow for DNS-based features, and is currently on the deprecation path by AWS.
As a community, the reality is that both styles typically have to be supported by service implementers. Many tools and libraries make assumptions about one or the other being available.
Q: In what areas of the S3 API do you see the most varied implementations/behaviors? Suspended mode versioning?
A: We typically don't see any one area being different from others. The S3 API is composed of many different features, so what we've found is it's difficult to talk about a service being "S3 Compatible" or "S3 Interoperable" without breaking it down further. We've started brainstorming ideas about classifying the S3 API into concrete feature sets.
Q: From the IBM perspective chart: What is with the Noobaa implementation? This is an important development for us here and have a good feature list?
A: We are not able to rate the compliance level of any particular product at this point.
Q: Do you have any recommendation or best practice for developers of applications that require interoperability with object storage of different vendors? Are known differences documented somewhere?
A: We'd recommend you reach out to each object storage provider for documentation on their interoperability. There's no central repository of providers and compatibility. As we mentioned, as part of the test tools effort, we are exploring the idea of categorizing interoperability into concrete feature sets that would make it easier to classify levels of compatibility between providers.
Q: Is there any abstraction layer for configuration that you could recommend? Is it preferable to try to adapt to the proprietary APIs or better to use S3 http interface for e.g. bucket policy configuration, which does not seem to be the promoted way of working for most vendors?
A: We would recommend differentiating your control plane and data plane usage of cloud storage providers. Data plane usage (i.e. reading and writing of objects) typically doesn't need to interact with bucket-level policies and configuration. We have seen many customers take advantage of generic configuration libraries such as Terraform, for managing control plane resources.
Q: Will the AWS S3 team participate in this effort?
A: While we cannot speak for Amazon, we are hoping that AWS S3 will join our community.
Q: How do you anticipate AWS S3 may benefit from this activity?
A: We believe the SNIA Cloud Object Storage (COS) Plugfest community shares exactly the same “end customer excellence" goals as AWS S3. The SNIA COS Plugfest community is specifically designed to help improve overall industry interoperability, and make it easier to help application developers introduce and maintain capabilities.
Q: Please say more about object storage interoperability; why is it important?
A: We want to be very clear. There is no issue for clients working directly with AWS services. AWS S3 is a popular proprietary API, fully controlled and well managed by AWS. The area we are addressing is heterogeneous COS interoperability. We are doing this because, before third-party storage providers worked independently, repeating the same investment in test, but worked in silos, so no shared test results. Now that we can pool our resources among the Plugfest community, we can share test results under NDA, between participating companies. We believe this is important to address COS interoperability for configurations, including a number of third-party storage providers integrated across a number of ISV services, like backup, archive, disaster recovery and dynamic applications such as AI analytics, micro-services and container environments.
Q: Who else should participate in this Plugfest effort?
A: Again, we are focused on heterogeneous interoperability (including proprietary and open source projects); areas like on-prem, hybrid-cloud and multi-cloud solutions that are deployed at banks, health care, enterprise, government, retail, scientific / AI computing, etc. We are eager to expand COS Plugfest testing with multiple cloud service providers (CSPs), client and server providers, multi-protocol gateway providers, database vendors, and ISVs (including backup, archive and disaster recovery services), as well as tape archive solution vendors.
Q: Will SNIA consider offering more remote COS Plugfest testing?
A: Yes. We had a very good set of remote test sessions during the April ’25 COS Plugfest, and we are putting together plans now to enable more remote COS testing. We believe that face-to-face COS Plugfest engagement result in the very best collaboration, because we have immediate interaction to first identify where to test and analyze findings. This cuts weeks of delay from typical multi-company interactions and helps natively build the developer-to-developer network to expedite issues, as well as helps build the tribal community knowledge pool. However, we also see the need to extend the face-to-face network with an even broader set of remote contributors. This is to rapidly respond to new use cases as needed, expand the community, and accommodate the realities that not everyone can gain travel approval for every event. We see this especially in the area of over-seas travel. Please contact us at askcloudplugfest@snia.org if you have questions and to join the Plugfest community to stay in touch with these important developments.
Our next Cloud Object Storage Plugfest will be in Santa Clara, CA co-located with the SNIA Developer Conference (SDC’25), September 15-17, 2025. Learn how you and your company can be part of this Plugfest here.
Leave a Reply