Lessons Learned from Code Spaces: What to Do with AWS Now

By Flux7 Labs
July 3, 2014

Code Spaces. Its story is sending shivers up and down the spines of businesses and developers alike, and for good reason. But that doesn’t mean it should stop the progress of cloud migration or significantly change your strategy. In fact, the story brightly shines a light on an issue that is avoidable, and serves as a warning of what can happen in the complex world of cloud architecture.

In one of our previous posts, we discussed the six reasons why large enterprises should consider moving to the cloud. One of them highlights the security features offered by AWS. Amazon supports several security certifications, including, but not limited to HIPAA, PCI and ISO. However, as we mentioned in that post, security of the cloud compared to on-premise security is still in question.

Recently, Network World reported in an article entitled “A Wakeup Call for the Cloud”:

“Code Spaces is a company that hosted application development work in Amazon Web Service’s cloud on behalf of its customers. On June 17, the company experienced a DDoS attack, whereby traffic floods the company’s servers. Multiple media outlets have reported that when company officials contacted the perpetrator, a ransom was demanded. When the money was not paid, the bad guys hacked into the administrative console for Code Space’s AWS account and deleted what appears to be the entirety of the company’s files. Code Spaces has since been shut down.”

The problem here is that Code Spaces put all its eggs in one basket. Perhaps this was not obvious to them or perhaps they thought they had measures in place to protect themselves. Clearly, they did not have their house in order.

This kind of event is something we have heard of in the past. And it’s not restricted to just cloud users.

Some noteworthy ones include the DDoS attack recently at the Meetup site. During the past year, storage vendor Nirvanix ended up shutting down the entire company within a few weeks. Not to be forgotten is the outage of mighty Amazon three years ago, when, typically, measures to avoid the same outcome was given more serious thought.

This one hits closer to home. We recently learned about a local startup’s troubling experience with the complete shutdown of its application dedicated to a community college event. The application allowed for Facebook logins and was on a VPC host. The website was used for a specific event by college, honing in on a crowd of more than 10,000 targeted as the hub of the event. When all was said and done, a security breach right before the night of the event ended up bringing down the entire website costing a total loss of more than $10,000.


Now and then, outages occur at various severities serving as reminders that there are certain things cloud users can’t and shouldn’t take for granted. Topping the list is the need for putting in place disaster readiness. Irrespective of the size and type of your business, it is mandatory to foresee the future, predict possible appropriate failures, and have contingency plans on hand.

So, the question to ask now is: Is a security breach the only possible reason for such outages? Surprise yourself! The answer: A big NO!

A few other reasons that could cause outages or failures are:

  • External Dependencies
  • Human Elements (Yes, it’s true!)
  • Process Improvements

Solutions to Ponder

Disaster readiness plans are not a one-time thing. It is a process by itself and needs constant rework, analysis, testing and applied solutions. Repeating the old mantra of software development to disaster readiness, a cloud user needs to understand loud and clear that an untested disaster readiness plan is one that’s definitely broken. Read more here to learn in detail why a continuous testing of disaster plans is a necessity rather than an opt-in.

First things first, though. Let’s break down a disaster readiness plan into two sub-steps:

  • Understand your business needs.
  • Validate architecture based on your business needs.

You can learn about a checklist for validating a DevOps architecture by reading these two blog posts: Part 1 and Part 2.

Of course, solutions come in various flavors. We explored this problem and a similar scenario in a talk given by our Flux7 CEO last month at the Bleeding Edge Web Meetup in Austin, Texas. You can watch his presentation “A Crash Course on AWS for App Developers” here.

AWS offers multi-factor authentication that keeps a strict check on who has access to the root account.

Are such disasters only a “success problem,” or a problem that can eliminate any chance of success? Said another way: Should startups wait to fix their cloud infrastructure, or do they need to do it today? If you have to think about your answer, you could be the next Code Spaces.

Currently, there’s a popular quote making the rounds on social media:

The bitterness of poor quality remains long after the sweetness of low price is forgotten.

Don’t cut corners on your AWS set up or you could be tasting that bitterness for a long time.

If you’re confidence is wavering about your architecture, get the assurance you need from our assessment. We’ll run a 60-point review that gives you an actionable plan. It will justify your own project or help you gain approval for specialist help.

Don’t wait to get your house in order. Take proactive steps today to ensure your cloud infrastructure is protected.