S3基礎

S3（簡單存儲服務）是AWS的標準雲存儲服務，提供從0到5TB的幾乎任意大小的任意數量文件的文件（不透明「blob」）存儲。（在2011年之前，最大尺寸為5 GB;現在較大的尺寸通過多部分支持得到很好的支持。）
項目或對象被放置在存儲名稱通常被稱為鍵的命名桶中。主要內容是價值。
對象被創建，刪除或更新。大對象可以流式傳輸，但是不能訪問或修改一部分值; 你需要更新整個對象。
每個對象也有元數據，其中包括任意鍵值對，並以類似於HTTP標頭的方式使用。有些元數據是系統定義的，有些元數據在從桶或CloudFront提供HTTP內容時很重要，您還可以定義任意元數據供您自己使用。
S3 URI：雖然通常在API中分別提供了存儲區和密鑰名稱，但通常還是以「s3：// bucket-name / path / to / key」格式編寫一個S3位置（這裡的關鍵字是path /到/鍵）。（您還會在Hadoop系統中看到s3n：//和s3a：//前綴。）
S3與冰河，EBS和EFS： AWS提供了許多存儲服務，除S3之外的一些提供文件類型抽象。冰川是更便宜和不常訪問的檔案存儲。與S3不同，EBS允許通過傳統文件系統隨機訪問文件內容，但一次只能附加到一個EC2實例。EFS是許多實例可以連接的網路文件系統，但成本較高。看比較表。

S3提示

對於大多數實際用途，您可以考慮S3容量無限制，無論是在文件的總大小和對象的數量。桶中的對象數量本質上也是無限的。客戶通常擁有數百萬個對象。
? 許可權：

?如果您在Amazon S3上存儲業務數據，則合理管理許可權很重要。在2017年，像道瓊斯和Verizon這樣的公司看到了數據泄露的原因是由於對敏感數據的S3配置選擇不當。如果您擁有大量資產和內部用戶，那麼稍後解決這個問題可能是一項艱巨的任務。
?有三種不同的方式來授予訪問存儲桶中Amazon S3內容的許可權。

IAM策略使用熟悉的身份和身份驗證管理許可權方案來控制對特定操作的訪問。
存儲桶策略授予或拒絕整個存儲桶的許可權。在S3中託管一個網站時，您可能會使用此方法，以使該存儲桶公開可讀，或通過IP地址限制對存儲桶的訪問。亞馬遜的樣本存儲桶策略顯示了許多這些策略派上用場的用例。
訪問控制列表（ACL）也可以應用於存儲在S3中的每個存儲桶和對象。ACL授予超出IAM或存儲桶策略中指定的額外許可權。可以使用ACL來授予對另一個AWS用戶的訪問許可權，也可以授予像普通公眾一樣的預定義組。這是強大的，但可能是危險的，因為你需要檢查每個對象，看看誰有權訪問。

?AWS的預定義訪問控制組使用可能不符合允許訪問的名稱，這可能不符合您期望的名稱：

「所有用戶」向公眾授予許可權，不僅限於在您自己的AWS賬戶中定義的用戶。如果一個對象對所有用戶都可用，那麼可以通過表單的一個簡單的HTTP請求來檢索它http://s3.amazonaws.com/bucket-name/filename。訪問這個類別的數據不需要授權或簽名。
「經過身份驗證的用戶」授予使用AWS賬戶的任何人的許可權，同樣不限於您自己的用戶。因為任何人都可以註冊AWS，所有的意圖和目的也向公眾開放。

這個ACL的典型用例與S3 的請求者支付功能一起使用。

?2017年8月，AWS添加了AWS Config規則，以確保您的S3存儲桶安全。

?這些AWS Config規則僅檢查您的存儲桶策略和存儲區級ACL的安全性。您仍然可以創建對象ACL，授予其他許可權，包括向全世界打開文件。

?如果您有不同類型的數據具有不同的敏感級別，請創建新的存儲桶。這比複雜的許可權規則更不容易出錯。例如，如果數據僅供管理員使用，如日誌數據，則將其放入只有管理員可以訪問的新存儲區。
有關更多指導，請參閱：

如何保護Amazon S3存儲桶
深入了解S3訪問控制。
S3許可權如何工作？。

存儲區命名：從全局命名空間中選擇存儲區（跨所有區域，儘管S3本身將數據存儲在您選擇的任何S3區域中），所以您會發現許多存儲區名稱已被佔用。創建一個存儲桶意味著取得該名稱的所有權，直到刪除它。存儲桶名稱對它們有一些限制。

在訪問存儲桶或其內容時，存儲桶名稱可以用作主機名的一部分<bucket_name>.s3-us-east-1.amazonaws.com，只要名稱符合DNS。
通常的做法是使用公司名稱的首字母縮寫詞或縮寫詞作為前綴（或後綴，如果您更喜歡DNS風格的層次結構）所有存儲桶的名稱（但請不要使用這個檢查作為安全措施 - 這是非常不安全的並容易規避！）。
?包含「。」的存儲桶名稱（句點）在使用SSL時可能導致證書不匹配。使用 - 代替，因為這符合SSL的期望，並符合DNS。

版本控制： S3具有可選的版本控制支持，所有對象版本都保存在一個存儲桶中。如果您想要更改存檔或退出錯誤（注意：它缺少像Git這樣的完整版本控制系統的功能集），這個功能最為有用。
耐用性： S3的耐用性非常高，因為它在內部保留了幾個副本。如果不意外刪除它，可以指望S3不會丟失您的數據。（AWS提供99.999999999％的似乎不可能的持久率，但這是一個基於獨立失效率和複製水平的數學計算 - 不是一個真正的概率估計，無論哪種方式，S3都有很好的耐久性記錄。是多比EBS耐久性更高！
??S3定價取決於存儲，請求和傳輸。

對於傳輸，將數據放入AWS是免費的，但是您將付費。從S3轉移到EC2在同一地區是免費的。轉移到其他地區或一般的互聯網並不是免費的。
刪除是免費的。

S3減少冗餘和不經常訪問：大多數人使用S3中的標準存儲類，但是其他存儲類的成本更低：

??減少冗餘存儲（RRS）已被有效地棄用，並且具有比標準S3更低的耐久性（99.99％，所以只有四個九）。請注意，它不再參與S3的降價，所以它提供比標準S3更多的資金。因此，沒有理由使用它。
不經常訪問（IA）可讓您獲得更便宜的存儲，以換取更昂貴的訪問許可權。這對於已經處理的日誌等檔案很有用，但是可能要稍後再看。要了解在使用不頻繁訪問（IA）時節約成本的想法，可以使用此S3不頻繁訪問計算器。
冰川是作為獨立產品討論的第三種選擇。
看比較表。

?性能：最大化S3性能意味著在帶寬和每秒操作數方面提高整體吞吐量。

S3具有高度的可擴展性，因此原則上可以獲得任意高的吞吐量。（一個很好的例子是S3DistCp。）
但是通常你被源和S3之間的管道和/或操作的並發級別所約束。
吞吐量當然是從AWS到S3，同一區域的EC2實例和S3存儲桶之間最高的。
來自EC2的帶寬取決於實例類型。請參閱ec2instances.info上的「網路性能」列。
從許多EC2實例分散式訪問數據時，許多對象的吞吐量非常高。一次可以從數百或數千個實例讀取或寫入來自S3的對象。
但是，從單個實例順序訪問對象時吞吐量非常有限。單獨的操作需要很多毫秒，而實例的帶寬是有限的。
因此，為了執行大量的操作，有必要在各個實例上使用多個工作者線程和連接，對於較大的作業，也需要多個EC2實例。
多部分上傳：對於大型對象，您希望利用多部分上傳功能（從最小塊大小為5 MB開始）。
大量下載：您也可以通過利用HTTP GET範圍標頭功能並行下載單個大型對象的塊。
??列表分頁：列表內容發生在每個請求1000個響應，所以對於具有數百萬個對象列表的分區將需要時間。
? 關鍵字前綴：另外，操作上的延遲高度依賴於鍵名之間的前綴相似性。如果您需要大量的操作，為了避免「熱點」，在密鑰名稱的前面（前6或8個字元）儘早考慮更多隨機性的命名方案是非常重要的。

我們列舉這是一個主要的問題，因為做大規模的重命名往往是痛苦的。
?請注意，不幸的是，關於隨機密鑰名稱的建議與使用通用前綴進行一致布局來自動管理數據生命周期不一致。

對於AWS以外的數據，DirectConnect和S3 Transfer Acceleration可以提供幫助。對於S3傳輸加速，為了使用較近的端點，您需要支付大約相當於1-2個月的傳輸存儲空間。

命令行應用程序：從命令行使用S3有幾種方法：

最初，s3cmd是這項工作的最佳工具。它仍然被許多人使用。
常規的aws命令行界面現在支持S3，並且在大多數情況下非常有用。
s4cmd是一個替代品，通過多線程更加強調性能，這對於大文件和大型文件集是有幫助的，並且還提供類似於Unix的通配符支持。

GUI應用程序：您可能更喜歡GUI，或者希望為技術較差的用戶支持GUI訪問。一些選項：

在AWS控制台確實提供了使用S3圖形化的方式。請謹慎告知非技術人員使用它，但是，由於沒有嚴格的許可權，因此可以訪問許多其他AWS功能。
在大多數情況下，傳輸是macOS上的一個很好的選擇。
在MacOS和Windows上，Cyberduck是一個很好的選擇，支持分段上傳，ACL，版本控制，生命周期配置，存儲類和伺服器端加密（SSE-S3和SSE-KMS）。

S3和CloudFront： S3與CloudFront CDN緊密集成。有關更多信息以及S3傳輸加速，請參閱CloudFront部分。
靜態網站託管：

S3有一個靜態的網站託管選項是簡單地使配置HTTP指數和錯誤頁面，並設置HTTP重定向的支持，以公共內容的S3。這是一個簡單的方法來託管靜態資產或一個完全靜態的網站。
考慮在大部分或全部資產之前使用CloudFront：

像任何CDN一樣，CloudFront顯著提高了性能。
?SSL僅在S3的內置http://amazonaws.com域中受支持。S3支持通過自定義域來提供這些網站，但不支持自定義域上的SSL。但是，CloudFront允許您通過https提供自定義域名。Amazon通過Amazon Certificate Manager提供免費的SNI SSL / TLS證書。SNI不適用於非常過時的瀏覽器/操作系統。或者，您可以提供您自己的證書，以便在CloudFront上使用，以支付所有瀏覽器/操作系統的費用。
?如果跨域的資源包括CSS文件中的字體，則可能需要為服務這些資源的存儲桶配置CORS。
由於現在幾乎所有東西都轉移到了SSL上，而且您可能想要控制域，所以您可能希望在S3之前使用自己的證書來設置CloudFront（並忽略AWS上的示例，因為它只是非SSL ）。
也就是說，如果您這樣做，則需要考慮CloudFront上的失效或更新。您可能希望在文件名中包含版本或散列，因此無效是不必要的。

數據生命周期：

在管理數據時，理解數據的生命周期與理解數據本身同樣重要。當把數據放到一個桶里時，想想它的生命周期 - 它的生命結束，而不僅僅是它的開始。
?通常，具有不同過期策略的數據應該存儲在頂層的不同前綴下。例如，一些大量的日誌可能需要每月自動刪除，而其他數據是關鍵的，不應該刪除。將前者放在單獨的存儲桶中或至少一個單獨的文件夾是明智的。
?想想這個前面會省下你的痛苦。清理由許多工程師創建的大量文件是非常困難的，這些工程師具有不同的生命周期和不一致的組織。
或者，您可以設置生命周期策略以將舊數據歸檔到Glacier。小心將大量的小物體歸檔到冰川，因為它實際上可能花費更多。
還有一個稱為「 不頻繁訪問」的存儲類別，它具有與標準S3相同的耐用性，但是按GB標準打折。它適用於不常訪問的對象。

數據一致性：對於有多個數據生產者和消費者的S3的任何使用來說，了解數據一致性至關重要。

在S3中創建和更新單個對象是原子的，因為你永遠不會上傳一個新的對象或改變一個對象，而讓另一個客戶端只看到部分改變的一半。
不確定性在於當你的客戶和其他客戶看到更新。
新對象：如果你創建一個新的對象，你將能夠立即讀取它，這就是所謂的寫後讀一致性。

好吧，另外需要注意的是，如果在對象存在之前先讀取一個對象，然後創建它，那麼您將得到最終的一致性（不是寫後讀）。
這不適用於任何列表操作; 新創建的對象不保證立即出現在列表操作中

對對象的更新：如果你覆蓋或者刪除了一個對象，你只能保證最終的一致性，即改變會發生，但你不能保證什麼時候。
?對於很多用例來說，將S3對象視為不可變的（即按照慣例來決定它們將被創建或刪除，但不會被更新）可以大大簡化使用它們的代碼，避免複雜的狀態管理。
?請注意，到2015年之前，「美國標準」地區的最終一致性模型較弱，而其他（較新的）地區則是後寫。這個問題終於得到糾正 - 但是請注意許多老博客提到這個！
慢速更新：在實踐中，「最終一致性」通常意味著在幾秒鐘內，但預計幾分鐘或幾小時的罕見情況。

S3作為文件系統：

一般來說，S3的API有固有的限制，使得S3很難直接作為POSIX風格的文件系統使用，同時仍然保留S3自己的對象格式。例如，追加到文件需要重寫，這削弱了性能，並且對目錄進行原子重命名，在打開文件時互斥，以及硬鏈接是不可能的。
s3fs是一個FUSE文件系統，可以繼續嘗試，但是由於這些原因，它具有性能限制和意外。
Riofs（C）和Goofys（Go）是最近嘗試採用不同的數據存儲格式來解決這些問題的努力，s3fs也可能有所改進。
S3QL（討論）是一個Python實現，提供重複數據刪除，快照和加密，但一次只能有一個客戶端。
ObjectiveFS（討論）是一個支持文件系統功能和並發客戶端的商業解決方案。

如果您主要使用VPC，請考慮設置適用於S3 的VPC Endpoint，以便讓VPC託管的資源輕鬆訪問，無需額外的網路配置或跳躍。
跨區域複製： S3具有在一個區域與另一個區域之間複製存儲區的功能。請注意，S3在一個區域內已被高度複製，因此通常這不是持久性所必需的，但對於遵從性（地理上分散的數據存儲），較低的延遲或作為減少區域間帶寬的策略通過在第二個地區鏡像大量使用的數據來降低成本。
IPv4 vs IPv6：很長一段時間，S3僅在默認端點支持IPv4 https://BUCKET.s3.amazonaws.com。但是，截至2016年8月11日，它現在支持IPv4和IPv6！要同時使用，您必須在您首選的API客戶端中啟用dualstack，或直接使用此url方案https://BUCKET.s3.dualstack.REGION.amazonaws.com。這也延伸到S3傳輸加速。
S3事件通知：可以將S3配置為在存儲桶事件上發送SNS通知，SQS消息或AWS Lambda函數。
?將您的個人用戶（或IAM角色）限制在最低要求的S3位置，並對「已批准」位置進行編目。否則，S3往往成為垃圾場，人們把數據放在隨機的地方，這些地方多年來沒有清理乾淨，花了你大筆的錢。

S3陷阱和局限性

?多年來，每個賬戶有一個臭名昭著的100桶限制，不能提高，造成許多公司的痛苦。截至2015年，您可以要求增加。你可以要求增加限制，但是它仍然會被限制（通常在每個賬戶?1000以下）。
?注意不要對事務或對對象更新的排序作出隱含的假設。永遠不要假設，如果你修改一個對象序列，客戶端將會以相同的順序看到相同的修改，或者如果你上傳了一大堆文件，它們將全部出現在所有的客戶端。
?S3具有一個SLA與99.9％的正常運行時間。如果您大量使用S3，那麼隨著磁碟或其他基礎架構的失敗，您將不可避免地看到偶然的錯誤訪問或存儲數據。可用性通常在幾秒或幾分鐘內恢復。雖然可用性不是非常高，但如上所述，耐用性非常好。
?上傳之後，對對象所做的任何更改都會導致完全重寫對象，因此請避免使用常規文件進行附加操作。
?如上所述，最終的數據一致性有時會令人驚訝。如果S3受到內部複製問題的困擾，則可能會從一部分機器中看到一個對象，具體取決於它們所在的S3端點。那些通常在幾秒鐘內解決; 然而，當問題持續20-30小時時，我們看到了孤立的案例。
??MD5和多部分上傳：在S3中，S3中的ETag頭是對象的散列。在很多情況下，這是MD5散列。但是，當您使用多部分上傳時，通常情況並非如此。一種解決方法是自己計算MD5，並將其放入自定義標題（例如由s4cmd完成）。
??不完整的多部分上傳成本：即使上傳失敗並且沒有創建S3對象，不完整的多部分上傳也會產生存儲費用。亞馬遜（和其他）建議使用生命周期策略來清理不完整的上傳並節省存儲成本。請注意，如果你有很多這樣的情況，那麼可能有必要調查一下定期失敗的事情。
??美國標準地區：以前，美國東部地區（也稱為美國標準地區）在海岸線上被複制，導致等待時間變化更大。從2015年6月19日起，這不再是這種情況。所有Amazon S3區域現在都支持寫後讀一致性。亞馬遜S3還將美國標準地區更名為美國東部（弗吉尼亞北部）地區，以符合AWS地區性命名慣例。
??S3認證版本和區域：在較新的地區，S3 只支持最新的認證。如果使用CLI或SDK的S3文件操作在一個區域中不起作用，但在另一個區域中正常工作，請確保使用最新的身份驗證簽名。