在CloudFront中更改「Origin Path」需要非常長的時間

我們有一個靜態網站，位於S3中，並隨CloudFront一起提供。該網站的工作，但推出更新需要相當長的時間或更長的時間。具體而言，更改原點路徑不會在邊緣位置幾乎儘可能快地反映出來。在CloudFront中更改「Origin Path」需要非常長的時間

下面是我們正在努力實現...

我們的S3桶被配置爲擁有一個網站。它存儲同一站點的多個版本。每個git標籤都有一個子目錄。例如：

/git-v1 
/git-v2 
/git-v3 
..

目標是告訴CF根據Origin Path設置開始爲網站的新版本提供服務。我們不希望使舊對象無效，只需通過創建一個新目錄並指向CF來提高版本。 CloudFront分配下的狀態很長一段時間會顯示「已部署」，但邊緣位置會繼續忽略新的原始路徑。

任何想法如何使CF開始更快地服務新的子目錄將不勝感激。

來源

2017-08-27 Debriter

更改源路徑設置後，您是否清除CloudFront緩存？ –

這是我感到困惑的部分。我沒有更新現有的對象。根據CF手冊，「使對象無效可以將它們從CloudFront邊緣緩存中刪除，更快，更便宜的方法是使用版本化對象或目錄名稱。」因此，不應該更改所需的原始路徑？ – Debriter

他們正在討論的版本控制的類型涉及更改正在請求的實際URL，例如，如果您的網頁請求「style-v1.css」，然後您將其更改爲「style-v2.css」。但是，在您的方案中，請求URL永遠不會更改，因此我認爲CloudFront將繼續提供對象的舊版本，直到緩存過期。 –

的Origin Path設置應用於後緩存檢查......之前沒有請求。當URI中請求的對象不在緩存中時，將從Origin服務器請求該對象。此時，源路徑被添加到傳入的請求路徑，然後發送到原點。緩存是基於傳入的請求路徑。 ¹

設置本身快速生效，通常以秒爲單位，但不清除緩存。

如果這僅用於對根頁面進行版本控制，則可以將原始路徑留空，將默認根對象更改爲新的根對象，然後使/無效。或者，您可以繼續做你正在做的事情，並在更改後使/*無效。免費失效限制爲每月1000次，但無效/*（或任何通配符）僅計爲1次失效，無論通配符匹配多少個對象。

¹ 傳入請求路徑也指的路徑，因爲它代表一個lambda @ Edge查看請求觸發修改之後，如果適用。

來源

2017-08-27 12:59:39

在CloudFront中更改「Origin Path」需要非常長的時間

回答

相關問題