CIO Brief: What the Dyn Outage Taught Us About Single Points of Failure in the Cloud
Retrospective: this article looks back at events from October 2016, written in 2026 with the benefit of hindsight.
The short version: In October 2016, an attack on one DNS company, Dyn, made major websites unreachable for hours. The websites were fine. A supplier they all depended on was not.
Why this still matters to a CIO
Your company depends on outside services that never appear on an asset list: DNS, content delivery, email filtering, identity, payment processing. Any one of them can take you offline without anyone touching your systems. The Dyn outage was the first time many boards saw that clearly.
The business impact
- Revenue: if customers cannot reach your site or portal, sales and service stop.
- Reputation: customers blame you, not your supplier.
- Contracts: your service-level commitments rarely exclude your vendors' failures.
Questions to ask your team
- Which external providers could take our customer-facing services down on their own?
- For each one, do we have a second provider or a tested fallback?
- How long would it take to switch, and who has the access to do it?
- When did we last rehearse a supplier outage?
What good looks like
Critical dependencies are documented, the most important ones have redundancy, and the team has practiced the switch. That is cheaper than most people expect — redundant DNS, for example, costs little compared with a day of lost revenue.
The decision
Ask for a one-page dependency map of your top three revenue-generating services, with a recommendation for each single point of failure. It is a small piece of work with an outsized payoff.
- Dyn and the Mirai Botnet (Oct 2016): When DNS Took Down Half the Internet Incident Teardowns
- How to Design Multi-Provider DNS and DDoS Protection for Azure and AWS Workloads How-To & Hardening
- Detecting DNS DDoS Attacks: Sentinel and GuardDuty Detections Detection & Response