Thorsten von Eicken – a former academic colleague of Amazon CTO Werner Vogels and the brains behind RightScale, one of the organizations best positioned to comment on the Amazon "cloud" – has heavily criticized Vogels and company for providing so little information about the massive outage that hit their service last week and continues to affect at least some Amazon customers.

"Amazon’s communication, while better than during previous outages, still earns an F. This is probably the #1 threat to AWS’s business," von Eicken said in a blog post on Monday.

"The biggest failure in this event was Amazon’s communication, or rather lack thereof. The status updates were far too vague to be of much use and there was no background information whatsoever. Neither the official AWS blog nor Werner Vogels’ blog had any post whatsoever 4 days after the outage!"

Eicken called the outage the worst in Amazon's history, but he believes that – at least on one level – the company proved that it was prepared for such an outage. "The Amazon cloud proved itself in that sufficient resources were available worldwide such that many well-prepared users could continue operating with relatively little downtime," he said.

"But because Amazon’s reliability has been incredible, many users were not well-prepared leading to widespread outages. Additionally, some users got caught by unforseen failure modes rendering their failure plans ineffective."

Amazon's lack of communication aside, Eicken said that the "biggest problem" was that the outage affected more than one "availability zone".

Amazon divides its so-called infrastructure cloud into multiple geographic regions, and some regions are divided into availability zones that are ostensibly "insulated" from each other's failures. But the outage that began in the early morning hours Pacific time on Thursday originated in one zone inside the service's East region and spread to other zones.

'Not supposed to happen'

RightScale runs a service for managing the use of Amazon's Elastic Compute Cloud and similar "infrastructure clouds," services that provide on-demand access to readily scalable processing power. RightScale did not see failures outside the zone where the problem originated, with an breakdown in Amazon's Elastic Block Store service, but it was nevertheless unable to launch new server instances outside that zone.

"We didn't see servers or volumes fail in other zones but we were unable to create fresh volumes elsewhere, which of course makes it difficult to move services," von Eicken says. "This is 'not supposed to happen' and is an indication that the EBS control plane has dependencies across zones."

However, von Eicken points out, Amazon did contain the problem to one zone approximately three hours after it started.

Amazon first reported the problem at 1:41am Pacific on Thursday, and von Eicken says RightScale started noticing problems about 40 minutes before. "They finally posted a status message at 1:41am containing no useful details, sadly this is a typical sequence of events," he says.

In one of its brief status messages, Amazon said the problem began with a "network event" that caused the service to re-mirror a large number of EBS volumes in the East region. "It appears that a major network failure was the initial cause of problems but that the real damage happened when EBS (Elastic Block Store) volume replication was disrupted," von Eicken says.

"It appears that a significant fraction of the volumes concluded that the replication mirroring was out-of-sync and started re-replicating causing further havoc, including an overload of the EBS control plane. It is also possible that the EBS replication problem was the root cause and that the network issues were a consequence, hopefully Amazon’s root cause analysis will shed light on this."

'500,000' volumes affected

According to RightScale's extrapolations, about 500,000 EBS volumes were affected.

"After Amazon managed to contain the problems to one zone, it took a very long time to get the EBS machinery under control and to recover all the volumes. Given the extrapolated number of volumes it would not be surprising that an event of this scale exceeded the design parameters and was never tested (or able to be tested). I’m not sure there is any system of comparable scale in operation anywhere," von Eicken says.

"I do want to state that while 'something large' clearly failed, namely the EBS system as a whole, the real big failure is that multiple availability zones were affected for ~3 hours."

In addition, von Eicken says he's "uncomfortable" with the performance of Amazon RDS (Relational Database Service), which serves up MySQL and at least one other database via EC2. RDS also experienced problems during the outage. "Some databases that were replicated across multiple availability zones did not fail-over properly," he says. "It evidently took more than 12 hours to recover a number of the multi-[availability zone] databases."

According to von Eicken, Amazon has "made it difficult" to backup their database outside of RDS, and this leaves them "no choice but to wait for someone at Amazon to work on their database. This lock-in is one reason many of our customers prefer to use our MySQL master-slave setup or to architect their own."

Even RightScale, he says, was confused by Amazon's terse status messages. "In hindsight we should have intentionally failed-over our master database which was operating in the 'impacted availability zone' early on at a time where we could minimize downtime." he says. "We were lucky that it didn’t get affected until about 12 hours after the start of the outage, but we didn’t connect one and one. A clear message from Amazon that more and more volumes were continuing to fail in the zone would have been really helpful."

von Eicken has called on Amazon to make a long list of improvements to its communication policies. These include giving actual percentages of volumes affected by an outage, listing the names of each availability zone affected, and sending individual status updates to particular users.

"Use email (or other means) to tell us what the status of our instances and volumes is," he says. "I don’t mean things I can get myself like cpu load or such, but information like 'the following volumes (by id) are currently recovering and should be available within the next hour, the following volumes will require manual intervention at a later time, …' That allows users to plan and choose where to put their efforts."

But he also wants a blog post from the company. Which is still yet to be seen. As of 1pm Pacific time on Monday, Amazon says that a "vast majority" of volumes have been recovered and that EBS is now operating normally for all APIs on these volumes, but some volumes have not been recovered, and the company says it is working to contact the customers involved.

Thorsten von Eicken was a professor in Cornell's computer science department when Werner Vogels did research there, and the two have coauthored distributed-computing research. RightScale began as a web front-end for Amazon Web Services when the service was only accessible from a command line, but it has sense morphed into a management service for several other infrastructure clouds as well. ®