從瀏覽器上傳到 S3 儲存桶時使用 SSL/SNI
我的網站允許使用者上傳文件。我們使用典型的 Javascript+POST+Signature 將它們直接上傳到 S3。這很好用，但是一些本地網路反對 CORS 請求——使用者有一個他們可以連接的主機白名單。
我很樂意
uploads.baconserker.com為我的 S3 儲存桶提供 CNAME 別名來解決這個問題。但這與 SSL 相衝突（證書名稱與 s3 主機名不匹配）。我相信這種情況需要 SNI，而 Cloudfront 提供 SNI。但是，我的案例並不真正涉及 Cloudfront 或邊緣記憶體。是否可以直接為儲存桶 https 端點設置 SNI？或者通過我自己的主機名將上傳內容直接發送到 s3 的其他方法？
我相信這種情況需要 SNI，而 Cloudfront 提供 SNI。但是，我的案例並不真正涉及 Cloudfront 或邊緣記憶體。
很公平，但這是官方的解決方案。S3 不直接支持 SSL 和自定義域。
另外，考慮一下：
CloudFront 不僅僅是一個 CDN。它也是一個 SSL 解除安裝程序、主機：標頭重寫器、路徑前置器、地理定位器、地理限制器、安全內容網關、http 到 https 重定向器、錯誤頁面定制器、根頁面替代器、Web 應用程序防火牆、原始標頭注入器、動態內容 gzipper、基於路徑多源 http 請求路由器、查看器平台標識符、DDoS 緩解器、區域 apex 別名目標……所以不要太沉迷於“CDN”或您將一項服務堆疊在另一項服務之前的事實—— CloudFront 的設計在很大程度上是為了補充 S3。他們每個人都專注於儲存和傳遞的某些方面。
你可能會從那次小小的爆發中得到這樣的印象，即我是 AWS 的某種隱形佈道者，但我不是。無從屬關係。我只是一個有用工具的粉絲，而 CloudFront 就像一把瑞士軍刀，擁有與“CDN”基本無關的便捷功能。
所以 CloudFront 是一個可行的解決方案，在這裡。它允許您使用自己的域名和 SSL 證書（您購買的證書或從 ACM 獲得的免費證書），並且可以選擇將域名與儲存桶名稱分離，因此儲存桶名稱不再需要匹配領域。
此外，如果您的整個站點都在 CloudFront 上，則您不一定需要
uploads.主機名上的 —— 整個站點可以在一個主機名後面，因為 CloudFront 允許您通過路徑模式有選擇地路由到不同的後端。CloudFront 還將傾向於優化上傳速度，因為客戶端將連接到附近的邊緣，客戶端和儲存桶之間的其餘路徑將在 AWS 的託管網路上，而不是公共網際網路上。
**但是，**您提到了“主機白名單”問題。CloudFront 有幾萬個 IP 地址，所以這部分解決方案還是有點欠缺的。它們是公共資訊，但這是一個很大的列表。
儘管如此，它還是比 S3 更好的情況，因為 AWS 不像 CloudFront 那樣單獨發布 S3 的地址範圍。
但是，如果您真的不想走 CloudFront 路線，請在 EC2 中的一個小 t2.micro 實例上安裝 HAProxy，該實例具有彈性 IP，與儲存桶位於同一區域。將其配置為 S3 的反向代理，在那里安裝您的證書，並將您的主機名指向它，然後配置代理以將
Host:標頭重寫回儲存桶名稱。那麼，這意味著你有一個靜態 IP和你的虛域。只要實例與儲存桶位於同一區域，唯一的成本應該是實例的成本，因為您無需為同一區域內的 EC2 和 S3 之間的頻寬付費。
自從 CloudFront 提供 SNI 之前，我就一直在這樣做（儘管當時的實例是
m1），原因基本相同……儘管最近，我有另一個理由這樣做。可以利用 HAProxy 1.6 中的 Lua 解釋器通過注入對 XSL 樣式表的引用來操縱 S3 XML 錯誤響應，以便瀏覽器使它們…漂亮。