Increased propagation times

We can confirm increased propagation times for invalidations to CloudFront configurations. End-user requests for content from our edge locations are not affected by this issue and are being served normally. We will provide another update within 30 minutes, or sooner if information becomes available.

We have identified the specific component causing the increased propagation times for invalidations to CloudFront configurations and are implementing necessary changes to restore normal service operations. Our engineers are actively working on a fix, but at this time, there are no temporary workarounds available. End-user requests for content from our edge locations are not affected by this issue and are being served normally. We will provide another update within 40 minutes, or sooner if information becomes available.

We continue work on mitigating the longer than usual invalidation times for Amazon CloudFront. The root cause is related to a recent configuration change. Our engineers are actively working on implementing and testing mitigation measures on one of the CloudFront edge pops to validate resolution before deploying broader. End-user requests for content from our edge locations are not affected by this issue and are being served normally. No customer action is required at this time. We will provide another update within 40 minutes, or sooner if information becomes available.

We have successfully tested our mitigation plan for the increased CloudFront invalidation propagation times and are now beginning to deploy the fix in our production environment. Our testing has validated that this solution will restore normal invalidation processing times. End-user requests for content from our edge locations continue to be unaffected by this issue and are being served normally. We are progressing down a definite path of recovery and will have an ETA on recovery in 30 minutes.

We are continuing to deploy our mitigation plan for the increased CloudFront invalidation propagation times across our production environment. Our initial testing and deployment has shown positive results in restoring normal invalidation processing times. We expect full recovery within the next 60 minutes as we carefully roll out the fix across our infrastructure. End-user requests for content from our edge locations continue to be unaffected by this issue and are being served normally. No customer action is required at this time. We will provide another update within 30 minutes, or sooner if information becomes available.

The deployment of our fix for the increased CloudFront invalidation propagation times continues to progress as expected. We remain on track to complete the full deployment within the next 30 minutes. End-user requests for content from our edge locations continue to be unaffected by this issue and are being served normally. No customer action is required at this time. We will provide another update within 30 minutes, or sooner if information becomes available.

Between 4:59 AM and 9:30 AM PDT, we experienced increased propagation times for invalidations to CloudFront configurations. During this time, customers observed longer than usual wait times for their CloudFront invalidations to propagate across our edge locations. End-user requests for content from our edge locations were not affected by this issue and continued to be served normally throughout the event. Our engineers identified that the root cause was related to a recent configuration change affecting the CloudFront invalidation system. After identifying the specific component causing the increased propagation times, we implemented and tested a fix on one edge location to validate the resolution before deploying it more broadly. By 9:30 AM PDT, we had successfully deployed the fix across our network, and invalidation propagation times have returned to normal levels. No customer action is required. Any invalidation requests that were delayed during this period have now been processed. The issue has been resolved and the service is operating normally.