Your Availability Zones Are Just a Single Failure Domain but with Better Marketing

a cloud provider in japan just told 495 customers, including a prefecture and its police force, that it may not be able to give their data back. ransomware hit idc frontier’s idcf cloud in the early hours of october 7. by the company’s third update, the advice to customers was blunt. restore from the backups you kept yourself.

idc frontier is a softbank subsidiary, and idcf cloud is its business infrastructure service. companies rent virtual servers, storage, and other infrastructure there instead of running everything themselves.

at around 3:40 in the morning, the attack hit east japan region 1. four zones named tesla, henry, pascal, and joule stopped operating and could not be restarted. idc frontier isolated the affected region from the network and suspended management consoles in its other regions while it investigated whether the damage had spread.

in its october 8 update, idc frontier said data in those four zones would be difficult to extract or restore, and that recovery was possible only from backups customers held themselves. an infrastructure provider was effectively telling the businesses that trusted it with production to go find another copy, and to find it somewhere else.

the four-zone part is more important than it looks. idc frontier separates infrastructure by zone, not too dissimilar in theory to aws and its availability zones, and multi-zone deployment is supposed to reduce the chance that one physical failure takes everything with it.

this ransomware attack crossed all four of those zones at once.

that does not mean the zones were fake or physical redundancy failed at its own job. it means physical separation and cyber independence are not the same thing. systems can sit on different racks, storage, and power while still sharing enough management infrastructure or administrative fate to disappear during one cyber event. this attack demonstrates it.

idc frontier has not yet disclosed the intrusion path in enough detail to say exactly what shared layer failed. an attacker statement claims access to hundreds of hypervisors, but the company has not confirmed that. what is confirmed is enough: four physically separated zones became unavailable together.

that is the architectural lesson hiding inside the outage. a cloud diagram can show several availability zones and still conceal one cyber failure domain spanning all of them.

this is also where the notion of a shared-responsibility model gets uncomfortable, because both halves can be true at once. the provider can suffer the infrastructure failure, and the customer can still own the consequences of not having an independent recovery copy. idc frontier’s own terms put responsibility for customer backups on the customer, which does not absolve the provider of whatever failed inside its environment.

this was not 495 organizations independently getting ransomware at the same time. although one could argue it certainly felt that way. it was just a one provider-side incident creating the same availability and recovery problem for hundreds of tenants at once.

that is correlated risk, the property insurers and regulators fear most. failures that were supposed to be independent turn out to be a single event wearing hundreds of names.

those tenants were not hobby projects. the website of ibaraki prefecture went dark, and so did the site of its prefectural police. public services were unreachable because a private vendor the public never chose made resilience decisions the public never saw.

concentration creates efficiency in normal times, but it also hands a deep provider compromise economies of scale. that is exactly why threat actors increasingly aim at providers instead of their customers. hit the right shared dependency and hundreds inherit the incident together. japan has felt a run of it lately, with osaka metropolitan university knocked offline by ransomware barely a week earlier.

the most useful part of the story is what happened next. soliton systems had its production environment and backup server on the same affected platform. when the platform became unavailable, so did the recovery path. there is no confirmation the backup data itself was destroyed. it simply could not be used when it was needed the most.

six apart gives us almost the perfect counterexample. thirty-one of its servers on idcf cloud became unavailable, but it kept seven generations of daily backups on google cloud, a separate platform. it restored from the october 7 1am backup and began rebuilding on sakura cloud, migrating the servers in stages.

same provider failure. completely different recovery outcome.

the difference was not whether production disappeared. it did in both cases. the difference was whether recovery depended on the very thing that had just failed.

this does not make six apart’s outcome free. restoring from the 1am backup means losing whatever was written after it, and standing the servers back up elsewhere still costs human hours. independent recovery is not zero impact. it is survivable impact, which is the most anyone gets.

six apart also exposes what a backup checklist tends to miss. preserving the data is only half the problem. you have to be able to turn that data back into a running service somewhere the failed environment does not control, and a backup that cannot be restored outside the platform that just failed is far weaker than it looks.

availability zones, snapshots, backup servers, and redundant copies all sound like resilience until you ask the question that actually matters. what single event can make all of them unavailable together?

a backup does not become independent merely because somebody calls it a backup. another region may help, another storage platform may help, and immutable storage may help. even the same provider can create meaningful separation if the architecture establishes a genuinely different failure domain. but if the same credentials, management layer, storage dependency, or administrative plane can remove production and recovery at once, the second copy bought duplication without independence.

there is also a discipline worth holding onto while this unfolds. a statement attributed to the attacker is circulating on social media with very large numbers attached to it: 225 databases encrypted, 3.6 petabytes affected, 239 hypervisors reached, roughly 16,000 virtual disks sealed, and more than half a million snapshots wiped, with the environment supposedly falling in seven minutes. none of those figures is confirmed.

idc frontier says it is aware of the statement and is investigating whether it is genuine. until that happens, those numbers belong to the alleged attacker, not to the incident record. an extortionist writing its own after-action report is not an independent forensic witness.

the confirmed picture is narrower and still serious enough. four zones are down, 495 customers are affected, provider-side restoration is considered difficult, and customers have been told to rely on backups they control themselves. no group has been publicly named, no ransom amount has been disclosed, and idc frontier has not yet confirmed whether customer data was encrypted, stolen, destroyed, or some combination of those things.

the honest version is smaller than the one trending on social media, and it is the more useful one, because the confirmed facts already expose the architectural problem without the attacker’s numbers.

this is not really a story about whether cloud is safe, and concentration cuts both ways. a softbank subsidiary almost certainly defends its infrastructure better than most of its 495 customers could defend their own, so moving onto it raised their baseline security. the same concentration that raised the floor also raised the ceiling of catastrophe, which is how hundreds of organizations come to share one bad morning.

the real question is what cloud does and does not remove from the customer’s problem set. it can outsource hardware, facilities, power, physical redundancy, and enormous operational complexity. it does not remove the need to decide what survives if the provider becomes unavailable, and that decision has to be made before the outage.

the real lesson is not to distrust cloud infrastructure. it is to stop confusing redundancy with independence. four physically separated zones still went down together because physical separation did not prevent them from sharing the same cyber event.

resilience begins where shared fate ends. if one failure can take production and recovery away from you at the same time, you do not have two independent copies.

you have one failure domain with better marketing.