CloudFront origin failover lets a distribution use a secondary origin when the primary origin cannot serve an eligible request. The feature is configured through an origin group with a primary and secondary origin plus one or more failover criteria such as connection failure or selected HTTP status codes.<\/p>\n
Inside AWS Architecture and Operations<\/a>, origin failover is an edge resilience mechanism. It can keep read traffic available during an origin problem, but it does not make every request method or application state safe to fail over automatically.<\/p>\n The existing CloudFront and edge caching<\/a> article provides the caching and distribution context.<\/p>\n A CloudFront origin group contains at least two origins with an explicit priority order. CloudFront sends eligible requests to the primary origin first and uses the secondary only when the configured failure condition is met.<\/p>\n This is different from active-active routing. The secondary is a failover target rather than a peer that receives ordinary traffic by default.<\/p>\n The two origins should therefore be kept sufficiently synchronized to serve the same user-facing content when the primary fails.<\/p>\n CloudFront supports failover on configured status codes including 400, 403, 404, 416, 429, 500, 502, 503, and 504. The organization chooses which codes should cause CloudFront to try the secondary.<\/p>\n The choice should match the application. A 404 may mean \u201cobject genuinely does not exist,\u201d in which case failing over could hide a content problem. A 503 from the primary may be a clear availability signal that justifies using the secondary.<\/p>\n Failover criteria are application semantics, not merely a list of errors that look bad.<\/p>\n AWS documents an important limitation: CloudFront origin failover is attempted only for viewer requests using GET, HEAD, or OPTIONS. Methods such as POST, PUT, PATCH, and DELETE do not automatically fail over to the secondary origin.<\/p>\n This protects the application from blindly replaying non-idempotent write requests against another backend. It also means teams cannot assume a CloudFront origin group provides complete failover for a transactional API.<\/p>\n Write continuity requires an application-specific design outside this feature.<\/p>\n CloudFront attempts to connect to the primary origin before deciding it is unreachable. For custom origins, the connection timeout can be configured from 1 to 10 seconds and the connection-attempt count can be set up to three.<\/p>\n With defaults of three attempts at ten seconds, CloudFront can wait as long as roughly 30 seconds before trying the secondary when the connection itself cannot be established. AWS recommends lowering attempts, timeout, or both when faster failover is required.<\/p>\n Those values should be tested against normal origin latency so aggressive failover does not turn brief network jitter into unnecessary origin switching.<\/p>\n After a connection is established, CloudFront also waits for origin response data. If a GET or HEAD request stalls beyond the configured response timeout, CloudFront can retry according to the origin-attempt setting and then fail over if the origin group criteria are met.<\/p>\n Write methods behave differently and are not retried in the same way. This is another reason to test the exact methods and paths used by the application.<\/p>\n A slow origin can therefore look like an availability problem even when the TCP connection succeeds.<\/p>\n CloudFront can continue serving cached objects while the primary origin is unhealthy. That is good for users, but it can make an origin outage look smaller than it really is until an object misses cache or expires.<\/p>\n Operational tests should include uncached or deliberately expired objects so the failover path is actually exercised.<\/p>\n Monitoring should also include origin error metrics and synthetic checks that bypass a warm-cache-only view of health.<\/p>\n A passive secondary can be under-provisioned if it never sees normal traffic. When failover happens, it may suddenly receive the full miss traffic from CloudFront.<\/p>\n Capacity, database dependencies, secrets, certificates, IAM roles, and content synchronization should all be maintained in the secondary environment. A secondary that only exists on paper is not a recovery target.<\/p>\nOrigin groups make primary and secondary priority explicit<\/h3>\n
Failover can be triggered by selected HTTP response codes<\/h3>\n
Automatic failover is limited to GET, HEAD, and OPTIONS<\/h3>\n
Connection attempts and timeout control how quickly failover begins<\/h3>\n
Origin response timeout affects stalled requests<\/h3>\n
Cache hits can hide origin failure<\/h3>\n
The secondary origin needs its own capacity and dependency plan<\/h3>\n