If it was Feb. 28, 2017, everything. AWS’ S3 service decided to have “technical difficulties”. The problems were so bad that the service’s dashboard couldn’t tell users if their sites were up or down. (Coincidentally, Adrian Cockcroft, AWS’ VP of cloud architecture strategy, was on stage talking it up while it happened. Oops.)
A post-mortem of the outage conducted by thousandeyes.com found the outage was from 9:40 am PST 12:40 PST on Feb. 28, 2017, affecting the the US-East-1 region of Amazon Web Services S3. Thousandeyes’ cloud agents detected “0% availability and 100% packet loss through the entire duration of the outage.” They noted that the packets were lost within the AWS US-East-1 infrastructure in Ashburn, Va. and the cause of the outage was most likely a network issue. Amazon’s official word is the outage was due to a typo.
Websites that depended on AWS found themselves out of commission — including IsItDownRightNow.com, which tells users if the website is down, or if it’s something’s wrong on their end. Awkward, right?
Static sites that were hosted on S3 were down. Sites and services with objects that were hosted (including sub-services like media files) on S3 and Amazon’s other affected services suffered from prolonged load times or files that did not load at all. Studies from Akamai and Gomez.com have users will leave sites that take longer than two seconds to load. About 80 percent of consumers who are shopping won’t come back, and many of them (44 percent) will tell their friends about the bad experience.
Sites and services that did not have a failover in place will suffer from real negative financial and long-term consequences from the AWS outage.
So what’s the solution? If you’re a company’s that’s migrated from owning your own data centers or hardware to AWS, do you move back to your own equipment? Probably not. The situation is even worse if you’ve only worked with AWS. We’re talking about a toothpaste and tube sort of scenario. And, despite the outage, you might have some very compelling reasons why you want to continue using AWS. Maybe you just like AWS or you have a mandate from above — to be fair, between its integrated load balancing, CDN and other services, there’s a lot to like.
For your consideration: AWS integration with BGP Anycast. We know what you’re thinking. This can’t be done. AWS doesn’t play well with Anycast. Amazon is a walled garden, guarded by a massive nasty NAT, making routing policies for your service impossible.
Well, NetActuate has made them play well together. And leveraging the advantages of Anycast, the next AWS outage won’t leave you scrambling to get back up and you will notice a significant increase in end-user performance.
How does it work? We offer interconnection to any AWS region in the world. Our CloudTransit service was to mix and match any type of port, on both the a or z side of your endpoints, while end users reach your service using our global Anycast PoPs for the nearest last mile delivery.
CloudTransit utilizes direct Internet, IX, peering, or DirectConnect AWS ports in each region. BGP Anycast is enabled using a unique /24 (and IPv6 /48) for the customer using NetActuate-provided IPv4 space and stub ASN, or the customer’s own IPv4 space and ASN.
BGP peering sessions are enabled into AWS allowing for seamless failover if an Amazon region goes down. You can control BGP announcements from your applications or our NetActuate portal and NetActuate’s managed NOC service that monitors and optimizes performance on a 24/7/365 basis.
Your end users connect to a single, optimized Anycast IP address globally. The Anycast IP address allows for advanced routing policies by directing traffic to each AWS region. In the event of failure, traffic flows seamlessly to another region.
Your customers will read about other sites and services using AWS — but they’ll be none the wiser.
But don’t take our word for it. Talk to us. Try it out for yourself. Contact NetActuate and you’ll get a one-on-one consultation about integrating AWS with Anycast, connected directly to AWS regions through our worldwide data centers. Contact our sales team to discuss a 30 day proof of concept for your application at email@example.com.