Conversations about the reliability of cloud computing services, particularly for mission critical applications, are almost as prevalent now as they were a couple of years ago. However, it isn’t until services are disrupted for a lengthy period that it becomes the top item in cloud chatter.

A fresh round of talk about reliability began today upon news that Amazon’s EC2 service is being affected by problems at a northern Virginia data center. The problem is rooted in the US-EAST-1 region—a zone that houses popular websites like FourSquare, HootSuite and a handful of others with household name prominence.

For websites that provide base services or networking tools, this is an inconvenience for them (and their users). However, some others are feeling the cascade effect of the outage, including Heroku, which relies on Amazon’s EC2 service to support its widely-used developer platform.

The outage trickle-down effect from EC2 to Heroku means that sites with applications connected to Heroku are affected—a fact that is causing some consternation for web businesses like Flightcaster, which is showing that its application is simply not available to users via a nondescript error screen.

With the possibility of even more cascade-effect problems, one has to wonder about redundancy.  In the wake of the outages today there are already some hefty questions about AWS backup and fail safes. As Larry Dignan noted this morning, AWS is architected so regions back each other up.  While the focus for now is on the immediate set of problems, this topic is bound to populate more than a few opinion pieces over the weekend.

The Roots of the Trouble….

The issues began at close to 2 a.m. EST when the EC2 team began investigating reports of connectivity and latency problems with RDS database instances and EBS volumes in the US-EAST-1 region. The problem persisted through the night as users reported other issues, including long waiting times on some multi-AZ failovers and connectivity errors impacting EC2 instances and increased latencies affecting EBS volumes in multiple availability zones in the US-EAST-1 region. Significant delays in launching EC2 instances and EBS API error rates were frequent.

Later in the morning some of the latency issues had been resolved in portions of the affected zone but IO latency for RDS database instances in other areas were not improving. In terms of the RDS problem, in the last update, which was posted at 8:12 a.m. today, the team stated that “despite the continued effort to resolve the issue we have not made any meaningful progress for the affected database instances since the last update…Create and Restore requests for RDS database instances are not succeeding in the US-EAST-1 region.”

The team noted just after that “A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in the region which created a shortage of capacity in one of the availability zones, which caused problems with new EBS volume creation and the pace that the team was able to re-mirror and recover the EBS volumes that had been affected. At the time of that update they were making some headway but nothing significant had been accomplished to resolve that problem.

According the AWS status page, which rarely shows anything but a list of green symbols indicating a go on services worldwide, only this region is begin affected but it is still some time before a resolution will be available.  

In the middle of the night last night the Elastic Beanstalk service was sending error messages that had an impact on the service’s APIs and console, which lasted for around four hours. As of this morning (Eastern) the company notes that both the APIs and console have recovered but there are some problems for users trying to create new instances in existing environments.

Outages Just Come With the Territory?

Although the problems are different this time technically, this is reminiscent of the outage a few months back. That problem  was caused by two back-to-back hardware failures which caused power supply failure in an availability zone data center followed immediately by the fizzling of a key element in the backup system. Following that event, a flurry of editorial ensued with some expressing concerns and others who simply suggested that this was just part of something we’ll need to learn to live with in the cloud era.  

As Stacey Higginbotham at GigaOM reported today, the large question and answer website Quora, which is hosted on Amazon’s EC2 service, had a sense of humor about the outage. The web giant posted a YouTube video that closed with the lines, “we’d point fingers, but we wouldn’t be where we are today without EC2.”

She went on to make a great point about how outages are something that we’re just going to have to live with, noting that “much like the trend in fun 404 pages, the habit of making light of a failure can endear your service…and providing quality information that indicates you know what’s wrong and are working on it is always a plus. However, what is refreshing about this latest outage is that so far the attitude is more resigned to cloud services going down for a bit as opposed to an all out condemnation of cloud services as unreliable.”

Her point is a good one—we’ve all grown used to error pages for sites when they experienced a failure of one kind or another—it’s nothing new.  However, when the problem is rooted in a service that is so pervasive as to cause a cascade effect or to bring down many popular sites in one swift round, it draws far more attention than an isolated server or hardware failure.

This isn’t going to do any favors to back the argument that the cloud is a good place for mission-critical applications. For the websites and services that were shut down today the whole of their business model relies exclusively on Amazon’s ability to stick to its SLAs.

While sure, problems happen with any infrastructure (not to mention such a vast network of data centers), Amazon will need to be careful about how it approaches this following restoration…they will need to the point to the fact of the rarity of such instances but far more importantly, be able to come up with a clear reason why backups and failsafes…well, weren’t.