CASE 153 · BISTRO · 2023
A primary origin that can fail, with a secondary already ready.
A restaurant booking platform served static fallback content for their app when the dynamic API was down — a "we’re experiencing issues, check back soon" page. Until the API actually went down, when it turned out the fallback wasn’t wired to anything. We added CloudFront Origin Failover.
Restaurant booking
RELIABILITY
2023
RESULTS
What changed, by the numbers.
OUTAGE EXPERIENCE
GRACEFUL
CUSTOMER PERCEPTION
IMPROVED
FAILOVER LATENCY
< 5s
NO-OUTAGE COST
NEGLIGIBLE
HOW IT WENT
The fallback page existed in S3. The wiring did not. During the actual outage, customers got 503 errors from CloudFront because the primary ALB origin was returning 503s and the secondary "origin" was a hopeful idea, not a configuration.
CloudFront Origin Failover with an Origin Group containing the ALB (primary) and the S3 bucket (secondary, with a 502/503/504 failover criteria) made the wiring real. When the primary returned consecutive 5xx, CloudFront automatically served from S3.
The next outage — six months later, lasted 14 minutes — served the fallback page instead of a 503. App rating in the post-outage week was unchanged from before, instead of dropping by the usual 0.3 a noticeable outage costs.
RELATED · SAME DOMAIN
Other engagements in this space.
READY WHEN YOU ARE
Let's get your AWS bill (and architecture) in order.
The discovery call is free. You walk away with at least one concrete idea — even if we never work together.