各雲儲存空間為什麼都可以看到 AWS 的蹤影？

今天要來談談最近在網路上看到滿多人都有的一個疑問，好像在滿多雲儲存服務上面都會看到 AWS 的影子。

雲平台廠商

在台灣比較會用到的國外雲儲存空間有 AWS、GCP 與 Azure，國內的雲儲存空間有像是 Hicloud S3、捕夢網 S3、是方 S3 等 ……，其實應該還有滿多的，這邊就不一一介紹。

分析雲儲存 API

AWS

先介紹一下今天的主角 AWS S3 List 的 API 文件位置，如下圖可以看到標示的內容有一個 xml 的資料顯示著 S3 的 URL 位置 “http://s3.amazonaws.com/doc/2006-03-01/”，在下面幾個段落會一直看到他。

GCP

之後我們來看到 GCP Storage (GCS) List 的 API 文件位置，如下圖可以看到我們的 GCS xml 格式，又看到了帶有 “http://doc.s3.amazonaws.com/2006-03-01” 的格式了。

IBM Cloud

這邊就也來介紹一下比較少聽到不過應該也滿多企業用的廠商 IBM Cloud 吧！可以看到他們的 IBM Cloud Object Storage List 的 API 文件位置，也是依樣寫了一個 xml 的格式 “http://s3.amazonaws.com/doc/2006-03-01/”。

hicloud S3

台灣中華電信的 hicloud S3 List 的 API 文件位置，依然看到了此文件格式 “http://s3.amazonaws.com/doc/2006-03-01/”

Azure

Azure 的雲儲存服務 Blob API 文件位置，就沒有看到 http://s3.amazonaws.com/doc/2006-03-01/ 的蹤影了，是一個全新的 API 格式。

批發轉賣

滿常在網路上看到大家有一個疑問，大家是不是批發轉賣 S3 的資源呢？其實用幾個點就可以看出有沒有可能是批發轉賣的：

1. 成本：網路流量都是要錢的，如果今天使用者來拉檔案這個檔案要經過自己租的網路，還要經過 AWS 的網路，相信這個成本非常大，批發轉賣是不太划算的。
2. 回應時間：今天會提供如此服務給使用者就是為了讓使用者有更好的體驗，如果今天網路回應時間沒有比較優，那使用者自然會回去使用 AWS 的服務，要讓整個服務的回應時間可以得到優化就只有讓服務不要經過海纜才有辦法做到了。
3. 整合性：各個服務商都會想要把儲存服務跟自己的服務做到更緊密的整合，要如此就要自建服務，才有辦法達到最高的整合性。

相容性

說了這麼多不是要批發轉賣那為什麼會出現這個格式呢？這其實是為了讓工具可以通用，S3 在 2006 年的 3 月推出到今年 2019，已經超過 10 年了這之間有非常多的工具是使用 S3 的協定做出來的，如果雲平台廠商使用一樣的協定來製作 API，那這些工具就可以繼續沿用了，這是一種對使用者非常貼心的舉動。

自建 S3

竟然如此如果我也想要自己建立一個 S3 的服務有辦法嗎？這邊有個服務推薦給想要自建 S3 的讀者們：

• MINIO

此服務支援 AWS S3 的 API，所以如果是自建的 VM 掛上此服務就可以得到自己的 S3 了 ~ 不過除非是特殊需求不然直接用雲平台的服務是比較推薦的！

參考資料

• https://ithelp.ithome.com.tw/questions/10192679
• https://stackoverflow.com/questions/55801882/does-google-cloud-storage-bucket-use-amazon-s3