Cloud // Software as a Service
Commentary
12/2/2010
11:48 PM
Charles Babcock
Charles Babcock
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Why Did Amazon Web Services Shut Down WikiLeaks?

If the real reason is the impact denial of service attacks had on other customers' EC2 service, what does that mean for less controversial cloud users hit by hackers?

What prompted Amazon Web Services to give WikiLeaks the boot off its EC2 servers?

Surely the theft of and airing of thousands of secret diplomatic cables gave someone in the U.S. State Department or Department of Homeland Security the initiative to call AWS and advise a shutdown. I wouldn't be surprised to learn such a thing happened.

But there was another reason for doing so, people responsible for the CloudSleuth monitoring system tell me. WikiLeaks was running on servers in Amazon's data center in Dublin, Ireland. CloudSleuth maintains monitoring stations around the world, constantly checking the response times of web services running in 30 different cloud centers, including EC2’s Dublin data center.

As the revelations became more damaging, someone attempted to slow or halt the outflow of WikiLeaks information through denial of service (DoS) attacks, where the host servers are subjected to so many automated requests that they can't deal with legitimate traffic. Cloud performance can vary due to network vagaries around the world, but CloudSleuth operators figured they should be able to detect the impact of the attacks from their London station, which was close enough to Dublin for the network issue to become negligible. And were they affecting EC2's performance out of Dublin?

Amazon Web Services spokesmen have not responded to requests for comment on the situation. But CloudSleuth practitioners were less reticent. "To quote the star of Sarah Palin's Alaska, 'You betcha!'" wrote John J. Krcmarik, a member of the CloudSleuth development team at Compuware, wrote in a blog Dec. 2.

Prior to the onset of the denial of service attacks, CloudSleuth found its own application in Dublin issuing a consistent response time of 1.3 to 1.4 seconds through November. On Nov. 29th, it spiked to 2.4 seconds, a 58% increase. There was a corresponding performance spike around the world at the 29 other monitoring stations, which appeared to bump up response times by 50%, Krcmarik wrote in his blog. That means the denial of service attacks directed at one customer were absorbing EC2's resources at the expense of some other customers and hurting their application performance.

On a business basis, Amazon Web Services was justified in making an executive decision and telling its WikiLeaks customer to go elsewhere, or simply curtailing its operation singlehandedly, which WikiLeaks posts indicate is what happened.

But this still raises awkward questions for advocates of cloud computing and AWS itself. Under what circumstances does AWS feel justified in shutting down a customer? Did it take a call from the State Department, and if so, what rank of public official gets to make that call? Surely not the administrative assistant to the under secretary.

On the other hand, it may have decided on its own that enough was enough and it wasn't in business to satisfy the demands of denial of service attacks. If so, what happens if someone formulates such an attack against your public-facing application in the cloud? AWS would likely treat a valued customer differently from how it treated WikiLeaks, and an application's owner and the cloud service provider would together find a way to shut out the attacks or shift operations to a dedicated and protected server.

It may be that the WikiLeaks incident illustrates something I thought was highly unlikely in the cloud: the service provider finds the traffic too debilitating to allow the customer to continue operations. Amazon Web Services can clarify what decisions it made -- and what decisions were made for it -- in this case, but right now, it's working on how to handle the fallout from this brouhaha and put an acceptable public face on it.

Comment  | 
Print  | 
More Insights
8 Steps to Modern Service Management
8 Steps to Modern Service Management
ITSM as we know it is dead. SaaS helped kill it, and CIOs should be thankful. Hereís what comes next.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - September 10, 2014
A high-scale relational database? NoSQL database? Hadoop? Event-processing technology? When it comes to big data, one size doesn't fit all. Here's how to decide.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A look at the top stories from InformationWeek.com for the week of September 7, 2014.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.