Cloudfront私人內容+簽名的網址架構

Question

讓我首先簡要介紹我正在考慮遷移到S3 + Cloudfront的系統架構。

我們有許多實體在樹中排序。樹的葉子有許多資源（具體的jpg圖像），通常爲20-5000的數量級，平均值爲200。每個資源都有一個唯一的URL，通過我們今天的colo設置提供。

我可以將所有這些資源轉移到S3，在上面設置Cloudfront並完成。如果只是我不必保護資源。

大多數實體都是公共的（即〜99％），其餘的以許多方式之一（登錄，IP，時間等）保護。一旦實體受到保護，所有資源也必須受到保護，並且只能在執行有效授權後才能訪問。

我可以通過創建兩個S3存儲桶來解決這個問題 - 一個私有存儲和一個公共存儲。對於私人內容，我會在用戶被授權後生成已簽名的Cloudfront URL。但是，一個實體的狀態可能會隨機地從公共狀態變爲私有狀態，反之亦然。系統的管理員可能會更改實體樹中任何級別的實體，從而導致整個樹中的級聯更改。一個變化可能導致約2萬個實體的變化，乘以200個資源，這將影響400萬個資源。

我可以在狀態更改的後臺監視中運行服務，但這會很麻煩，而更改400萬S3項目的ACL需要花費相當多的時間，並且發生這種情況時，我們要麼擁有未受保護的私人內容，或我們必須爲其生成簽名網址的公開內容。

另一種可能是默認情況下將所有資源設爲私有。在對實體發出的每個請求中，我們都會生成一個自定義策略，爲該特定用戶授予該實體中包含的所有資源的訪問權（通過在自定義策略中使用通配符url）。這需要爲每個實體的每個訪問者創建一個策略 - 但這不會成爲問題。但是，這意味着我們的用戶無法再緩存任何內容，因爲每個新會話的URL都會更改。雖然對於私人內容不是問題，但我們可以摒棄大約99％公開實體的所有緩存。

另一種選擇是保持所有內容的私密性，並將上述方法用於私人實體。對於公共實體，我們可以爲每個公共實體生成一個所有用戶都將共享的單個定製策略。如果我們設置6小時的生命週期並確保在5小時後生成新的策略，則將確保用戶至少一小時的策略生命週期。這樣做的好處是可以實現長達6小時的緩存，同時允許私人內容在狀態更改後最多可以公開6個小時。這是可以接受的，但我不確定這是否值得（嘗試計算當前緩存/命中率）。很明顯，我們可以調整5/6小時的邊界，以使更長/更短的緩存成本更高/更短時間接觸私人實體。

是否有人部署了類似的解決方案？我忽略了哪些AWS功能可能有用？一般的評論？

Answer 1

根據廣受歡迎的要求，我自己回答了這個問題。

在收集相關度量標準並進行一些計算之後，我們最終得出結論：我們可以用更少的緩存來生活，並被更快的CloudFront對象服務速度所抵消。實際執行情況詳見我的博客：How to Set Up and Serve Private Content Using S3 and Amazon CloudFront

Answer 2

同一個存儲桶中的資產可能有不同的隱私策略。 因此，您可以在同一個存儲桶中擁有公共和私有資產。

上傳時，只需設置隱私設置即可。

然後只需簽署URL即可訪問私有資產。