今天我們將來了解 S3 與 EBS 這兩種儲存方案的各自特點，並為大家介紹 AWS S3 在整體架構中的基本定位。

AWS S3 及 EBS 的儲存類別比較 (Storage)

AWS 服務中的 S3 及 EBS 的類別，分別對應 Object-Level Storage (下圖#1)及 Block-Level Storage (下圖#2)。

AWS S3 及 EBS 的功能比較 (Operation)

S3 與 EBS 能做的事情不同，S3 能做到創造(Create)與刪除(Delete)(下圖#1)；而 EBS 除了創造(Create)與刪除(Delete)，甚至能做到修改(Edit)(下圖#2)。

S3 的功能 (Operation)

S3 只能做到創造(Create)與刪除(Delete)(下圖#1)，也就是我們只能把一個完整的檔案上傳上去，或者把上面已存在的完整檔案給直接刪掉，我們不能開啟一個檔案，對裡面的某一行進行修改，這是 Object-Level Storage 類別的一個小缺點(下圖#2)。

EBS 的功能 (Operation)

為什麼 EBS 能夠比 S3 多出一個修改(Edit)功能呢？(下圖#1)
這是因為 EBS 是 Block-Level Storage 類別(下圖#2)，所以當我們想要掛載到任何一台 EC2 Instance 的時候，都需要先進行硬碟格式化(Dist Formatting)(下圖#3)，並且這個硬碟格式化還要根據不同的作業系統來做(下圖#4)。

透過這個方式，作業系統才會知道如何去使用這個硬碟空間，正因為更了解這個硬碟空間的格式，才能針對一個檔案，打開並對其進行新增或修改。

AWS S3 及 EBS 的最大的儲存空間 (Max Storage)

我們可以從下圖看到指標最大的儲存空間，S3 最大是無限(下圖#1)，EBS 最大則只能存到 16TB (下圖#2)，也就是與 EBS 相較下，S3 遠遠能夠無上限並不停的存放。

AWS S3 及 EBS 的 Scaling 比較

在面對更大需求的時候，S3 在 Scaling 的方面相較於 EBS 是非常厲害的(下圖#1)，而 EBS 則非常的不好(下圖#2)，下面我們將細部說明原因。

S3 的 Scaling

背後原由是 S3 其實是一個分散式系統，AWS 會一次啟動多台的 Server 來應付所有的 S3 請求，所以 S3 的 Scaling 是非常的強大的。

譬如下圖以 1 個 ● 代表 1 個 Server，並且 S3 有可能一次啟動 8 台 Server 來應付請求，但這樣強大的 Scaling 也帶來了一點小副作用。

假設我們上傳一個新的檔案，它有可能不會瞬間的直接同步到 8 台的 Server 上面，只同步到 6 台 Server (下圖#1)。而如果這麼恰好的，後面的請求剛好撞到這兩台還沒跟前面同步的 Server (下圖#2)，我們是有可能會拿到不同步的檔案的。

如果等得夠久，最後 8 台 Server 都會同步擁有最新檔案的版本(下圖#1)，而這樣的特點有一個特別的詞叫做 Eventual Consistency (下圖#2)，即最後會同步的意思。

在 Eventual Consistency 這個概念下所做的(下圖#2)，即是為取得更高的 Availability (下圖#3)，就算是犧牲一點資料的一致性也在所不惜(下圖#4)。此處的 Availability，指的是整體系統對外持續運作的穩健程度(下圖#5)。

舉例來說，假設有 8 台 Server，我們不那麼在意資料是否永遠一致(下圖#4)，我們更在意的，是客戶端有請求來的時候，是否能夠去回應它(下圖#3)，這個就是我們所說的 Availability (下圖#5)。

小結

下圖為本單元推導出的架構圖，從中可以看到 S3 的優點，就在於最大的儲存空間無限(下圖#1)、Scaling 很強(下圖#2)，但帶來一個小副作用叫做 Eventual Consistency (下圖#3)，並且還有一個小缺點，那就是 S3 不能對檔案進行內部的修改(下圖#4)。

What's Next?

那麼明天，我們將接著介紹「儲存寶石：S3 架構 & 版本控管 (Versioning)」！