Cloudwatch是否不從Cloudfront記錄Lambda函數？

Question

Cloudfront是否需要特殊設置才能觸發日志？

我有以下流程：

Devices -> Cloudfront -> API Gateway -> Lambda Function

可以，但是Cloudwatch似乎沒有為lambda函數（或API Gateway）創建日志。 但是，以下流程創建日志：

Web/Curl -> API Gateway -> Lambda Function

Answer 1

在上面的評論中，我們似乎已經得出一個結論，即意外的客戶端緩存（或客戶端和AWS基礎設施之間的某個地方的緩存）可能是觀察到的行為的更合適的解釋，因為尚無已知的機制可用於一個獨立的CloudFront發行版可以通過API網關訪問Lambda函數，並導致這些請求不會被Lambda記錄。

因此，我將以一種確認或否定這一假設的方式來回答這個問題。

CloudFront X-Amz-Cf-Id標頭注入請求和響應X-Amz-Cf-Id ，其中包含唯一標識請求和響應的不透明令牌。 文檔將它們稱為“加密的”，但就我們的目的而言，它們是不透明的值，具有很高的唯一性可能性。

盡管名稱相同，但請求標頭和響應標頭實際上是兩個不相關的值（在相同的請求/響應上它們彼此不匹配）。

在請求X-Amz-Cf-Id原始端X-Amz-Cf-Id發送到原始服務器僅對AWS工程師真正有用，用於進行故障排除。

但是CloudFront在響應中返回的查看者側X-Amz-Cf-Id對我們很有用，因為它不僅對每個響應都是唯一的（即使每次獲取同一對象時，即使來自CloudFront緩存的響應也具有不同的值）但它也以x-edge-request-id出現在CloudFront訪問日志中（盡管文檔似乎並未明確指出）。

因此，如果客戶端在多個響應中看到重復的X-Amz-Cf-Id值，則表明客戶端內部或客戶端與CloudFront（在客戶端網絡或ISP中）之間存在某種原因，導致看到了緩存的響應由客戶。

跨多個響應將來自客戶端的X-Amz-Cf-Id關聯可能是有用的（因為它們永遠不應該是相同的），並且與CloudFront日志也可能有用，因為這確認了CloudFront實際上生成該請求的請求的時間戳特別的回應。

tl; dr：在多個響應中觀察到相同的X-Amz-Cf-Id意味着緩存發生在AWS邊界之外。

---

請注意，即使CloudFront允許最小/最大/默認TTL來影響CloudFront緩存對象的時間，這些設置也不會影響任何下游或客戶端緩存行為。 源應返回正確的Cache-Control響應標頭（例如private, no-cache, no-store ），以確保整個鏈中的正確緩存行為。 如果原始行為無法更改，則可以使用Lambda @ Edge原始響應或查看器響應觸發器來注入適當的響應頭-請參閱“服務器故障”上的此示例 。

另請注意，默認情況下，CloudFront會將4xx / 5xx錯誤響應緩存5分鍾。 如果需要，請參閱Amazon CloudFront Latency以獲取解釋和禁用此行為的步驟。 此功能旨在使原始服務器休息一下，並且無論如何不要用假定繼續失敗的請求來轟炸它。 此行為可能會在測試和生產中引起各種問題，因此在某些情況下應禁用它。