Overcoming Outages in AWS : High Availability Architectures

“Design for Failure“, we hear this Slogan and importance of this philosophy in many cloud forums and conferences.  Yet, every day many applications are Deployed/Architected on AWS without this point in mind. The reasons could be ranging from technical awareness of designing High availability(HA) Architectures to Cost of Operating a complex global HA setup in AWS. In this article, i have shared some of my prior experience on architecting High Availability systems on AWS avoiding and overcoming outages. I feel this small gesture will create HA awareness and help the strong AWS user community to build better solutions.

A typical Web App stack consists of DNS, Load Balancer, Web, App, Cache and Database layer. Now let us take this stack and see what are the major points that needs to be considered while building High Availability Architectures in AWS:

• Architecting High Availability in AWS
  • High Availability @ Web/App tier
  • High Availability @ Load balancing tier
  • High Availability @ DNS tier
  • High Availability @ Caching tier
  • High Availability @ Database tier
  • High Availability @ Search tier (in progress)
  • High Availability @ NoSQL tier (in progress)
  • High Availability @ Monitoring tier (in progress)
  • High Availability @ Storage tier (in progress)
  • Architecting High Availability across Amazon AZ’s
  • Architecting High Availability across AWS Regions
  • Architecting High Availability across Cloud and Hosting Providers/DC

High Availability @ Web/App tier

To avoid Single Point of Failure in the Web/App layer it is a common practice to launch the Web/App layer in minimum two or more EC2 instances. This is fault tolerant than the single EC2 instance design and offers better application stability. Usually the Web/App Servers are designed either with Stateless or State full models.  Following are some of the common architecture patterns for HA in Web/App Layer in AWS Infra: