將CloudFront主機頭轉發到API網關

我們有一個指向CloudFront分配的通配符（*）子域。起源是API網關。將CloudFront主機頭轉發到API網關

我們需要知道API網關中的原始Host標頭，以便我們可以路由這些請求。

只需白名單中的CloudFront的頭Host訪問通過HTTP CloudFront的分佈時返回錯誤 - 大概是因爲API網關需要Host頭知道調用哪個API。

如果是這種情況，是否可以通過X-Forwarded-Host將Host標題從CloudFront轉發到API網關？或者...是否有另一種方法將通配符子域與API網關一起使用？

2016-08-30 Lawrence Wagerfield

如果您將主機標頭列入白名單，則應將主機標頭作爲「主機」（即不是「X-Forwarded-Host」）傳遞到原始標頭。你能發佈你收到的實際錯誤嗎？它只是一個沒有內容的500人，或者是否有身體或錯誤信息？也可能需要查看API網關的Cloudwatch日誌以獲取更詳細的錯誤消息。 –

@ChrisSimon將原始請求的主機標頭作爲「Host：」傳遞，將導致請求永遠不會到達API網關，該API網關需要在Host中指定一個值，因此在那裏不會生成日誌。這裏的問題是如何通過將一個目標的多個請求主機值（通配符）彙集到一個目標，而不會丟失原始主機名的跟蹤，通過將其作爲備用*標頭髮送，如由CloudFront自動創建的「X-Forwarded-Host」。 –

@ Michael-sqlbot正是我想要的（你知道是否有可能？！）。另外，我可以確認我從CloudFront獲得了一個403（ERROR。請求無法滿足。錯誤的請求。）以及該API網關永遠不會被擊中（並且不會在CloudWatch中生成任何日誌...但是，如果您直接點擊API，而不是通過CloudFront進行操作）。 –

這不是您的原始問題的答案，但它可能是實現您的目標的替代方法。首先，在所有環境（包括prod）之間共享一個CF分配會帶來風險 - 當您需要測試對CF配置的更改時，您必然會修改產品CF dist併產生未經測試的更改，這可能會產生重大後果。其次，如果您可以在CI/CD管道的所有階段測試整個環境，這真是太好了，但並不總是可能的（並且CF對它特別不利） - 所以它需要在短的反饋週期和徹底的測試。

解決方案通常是爲管道引入額外的階段，其中早期階段對最常見問題提供快速反饋，而後期對較不常見問題的反饋較慢。

在你的情況，我建議：

分公司部署不部署CF - 測試目標API網關直接
主/默認部署DO部署CF - 到 '分期' 環境 - 測試目標分期CF分佈
試驗成功發佈到「暫存」環境提升到生產

通過引入分級環境，你會得到RA對分支構建的pid反饋，但在進入產品之前，您仍然有機會測試緩存背後的內容。

如果您正在對CF配置進行更改，可以讓您的部署腳本動態地決定將CF包含在某個觸發器的分支部署中（可能在分支名稱中包含「cloudfront」一詞） - 儘管可以對某些人來說有點'神奇'！），並且你可以在合併到master以便在分期中進行測試之前在分支上測試這些更改。

來源

2016-09-02 23:27:13

將CloudFront主機頭轉發到API網關

回答

相關問題