The arithmetic on the window is worth doing before the argument. The failure ran three hours and thirty-three minutes [2], which is 213 minutes [1], so a 3:45 a.m. ET onset puts the end near 7:18 a.m. ET [2]. For that entire stretch the data plane was fine. Edge processors kept running; what they lacked was valid instructions for where to send VPC Origins traffic, because the component that distributes routing configuration to the global edge had stopped updating [4][5].
That distinction is the mechanism, and it is the part a security review would not have surfaced. Turning the feature on does something specific: the origin gives up the public IP and public-facing posture it previously needed [9], and CloudFront's private connection into your VPC becomes the only route to the backend, singular by design [10]. The dev.to writeup states the consequence plainly, that the reroute a public-origin setup retained, a public address an operator could point traffic at mid-incident, is gone rather than degraded [8]. When the config distributor stalls, there is no second door to open. The ceiling that stalled it sat in one availability zone, euc1-az2 [3], and it reached customers who had never knowingly depended on Frankfurt, including Hugging Face across most regions [6]. A control plane's region is not your region.
None of this makes the feature bad engineering. The pitch is real: fewer exposed endpoints means less to patch, fewer ways to misconfigure it, and less for a port scan to find [15], which is why the writeup says nothing about July 16 makes adopting VPC Origins a mistake [11]. AWS points the feature at financial institutions, healthcare platforms and SaaS providers [12], and for those buyers the security case stands on its own terms.
The failure is in the sign-off, and the writeup's sharpest observation is about what those customers believed: asked in June, every one of them would have said they had not concentrated risk in CloudFront, because what they had made was a security decision [14]. That is a single-source characterisation of intent, not a survey, and it should be read that way. But it matches the shape of the incident. The failover was removed as a side effect of a control that was working exactly as specified, not because anyone skipped a test.
So treat the incident report the way you would treat someone else's benchmark table. For your July 16 to have looked different, one thing has to be true: your origin retains a second ingress path that stays routable without the VPC Origins control plane. If it does not, your blast radius is not what your architecture diagram says, it is whatever the worst zone in that control plane can do. The cheap version of the fix is documentary. Whatever removes a fallback path should name it in the same ticket that claims the security win.
