This week’s Gestalt IT Weekly Rundown podcast talked about the major AWS outage which happened just days back that literally brought the world crashing down on businesses that were impacted by it. The problem occurred in Amazon’s us-east-1 data center located in Virginia. The US-East-1 data center aside from being the cloud computing engine to many businesses of both small and large scale in the region also happen to be the oldest data center Amazon has. This was not the first time an outage of this severity happened at this particular data center.
The outage this time was historic and continued for hours on end leading to a cascade of unfortunate events. Websites and applications went down for long hours while Amazon’s own as well as retail operations of many other businesses came to a stop. Disney Plus, Alexa, Ring, Facebook messenger, Snapchat were among the names that faced significant downtime. Although it took Amazon only a day to resolve the issue, the effects it left behind on business operations were huge. Some are still recovering from it.
Aggravating as SPoFs often are, this event engendered clamor and chaos among the users. As a business you can choose to treat them as isolated incidents and put up with the encumbrances they cause, or if you are no good at the grin-and-bear game, you take matters in your own hand and change things for yourself. But the question is how?
The incidents of recurring outages indicate businesses’ growing reliance on public cloud and the now-clear shortcomings of it. Although viable in all other ways, public cloud clearly has some downsides that lead to expensive messes. The alternate is to build high availability applications and go multi-cloud so that your world does not stop every time a cloud service goes down for a few hours.
Chris Evans, a Field Day Delegate, offers an interesting range of insights into businesses’ growing reliance on public cloud with respect to the AWS outage in his blog post.
The problem of us-east-1 highlights several issues for AWS and customers. First, there are clear dependencies on the use of that location for a range of services that should otherwise be fault-tolerant. Customers have unknown dependencies on us-east-1 around which they cannot design services, because AWS owns and manages those components with no transparency.
Read the rest of his blog AWS Outage – There’s always a dependency somewhere at architectingit to gain insights on the subject of multi-cloud.