Down shouldn’t mean out

Amazon Web Services (AWS) experienced its worst outage in history last week, going down for four hours, and crippling nearly 150,000 websites. The cause – human error – or to be more specific, a typo during a routine billing system debug that caused more servers to be removed than needed. AWS is on pace to…
by Andrew Humber | March 5, 2017

Amazon Web Services (AWS) experienced its worst outage in history last week, going down for four hours, and crippling nearly 150,000 websites. The cause – human error – or to be more specific, a typo during a routine billing system debug that caused more servers to be removed than needed.

AWS is on pace to become a $14 billion business over the next year. It provides Amazon with much of its operating income, and they are far and away the largest provider of cloud infrastructure in the world. But despite all that, last week’s outage proved that mistakes can still happen, and more importantly, they will happen again.

The question Webscale has been getting, since this happened, is what can be done to mitigate this kind of disaster? As a company that’s focused on taking e-commerce businesses into the cloud, we know that four hours of downtime, or just performance so slow that users abandon your site altogether, can be catastrophic for one’s brand reputation and revenue.

The answer is actually simple, and you only need look at Amazon themselves for the answer. As Business Insider noted in their story, Amazon didn’t experience any issues during the outage, because its infrastructure is spread across multiple geographic zones, so if any one region has a problem, it fails over to the backup zone with minimal disruption. Many large AWS customers do the same thing – Apple, Walmart, Costco – but contrary to popular belief, you don’t have to be their size, or have their IT teams to do the same.

Webscale’s Cloud Rescue (or Cloud Mirror if you’re already deployed on a Webscale platform) maintains a near real-time replica of your web application backend systems in an alternate cloud region, enabling smooth failover with minimal downtime in the event of a service or cloud provider outage. We’ll get you back up and running in 60 minutes or less – much less painful than the four hours you may have endured on Tuesday – and our proactive 24x7x365 support team will manage everything, including the ongoing monitoring and management of your web application infrastructure.

With shoppers abandoning websites that take more than a few seconds to load, even a one second delay in page load time could cost an e-commerce business making $100,000 a day, more than $2.5 Million a year. When even AWS has proved itself susceptible to downtime, businesses need to really understand their options when it comes to disaster recovery and

Like to learn more? Drop us a note at info@webscalenetworks.com and one of our specialists can talk you through your options.

Popular posts

How To Identify Good vs. Bad Web Traffic
by Adrian Luna | February 4, 2026

How to Identify Good vs. Bad Web Traffic

What is a Carding Attack 800x430
by Adrian Luna | January 27, 2026

What Are Carding Attacks?

Stay up to date with Webscale
by signing up for our blog subscription

Recent Posts

Featured agentic commerce os engineers
by Adrian Luna | May 19, 2026

Agentic Commerce OS for Engineers: What Changes,...

For engineering teams evaluating Agentic Commerce OS: your application architecture doesn't change. What changes is the delivery layer in front of it. Here's exactly what to expect.
Featured live data plane walkthrough
by Adrian Luna | May 19, 2026

Live Walkthrough: How the Data Plane Works

A live walkthrough of how the Webscale data plane processes session signals, AI classifications, and recommendations inline — across four real request flows and a failure mode test.
Featured adobe commerce real time cdp
by Adrian Luna | May 18, 2026

What Changes When Adobe Commerce Gets a...

Adobe Commerce + Real-Time CDP works on data that was current a minute ago. See what changes when the CDP moves inline with the request path instead of parallel to...