Both AWS and Azure sell the idea of inherent high-availability and scalability within their cloud services. Many companies bought into that idea and dove head-first thinking that, once in the cloud, the provider will provide the redundancy natively. With the recent AWS S3 outage many customers learned the hard way that this is not the case. There is still a need for customers to design redundancy into their applications when moving to the cloud. Companies like Amazon AWS and Microsoft Azure provide the platform to use, but it is still up to the customer to design their systems to utilize that platform.
For many AWS customers, their workloads are located in one region, and in many cases their applications are utilizing only one availability zone within a region. To use the S3 outage as an example, the Simple Storage Service (S3) outage was localized to only the US East Region. Had customers replicated their S3 data to an additional region and utilized Amazons failover platform the outage would have gone unnoticed to all but the operators at AWS.
Beyond providing disaster recovery and failover during a service outage, a multi-region design provides lower latency for users of the applications that are hosted in the cloud. Does your company do business on both coasts of the United States? AWS Regions run in Active/Active mode allowing for fast local content delivery. Having your applications in both the US East and US West regions provides failover, but also puts your application closer to the end user, increasing satisfaction in the customer experience. AWS has datacenters all over the world so this type of scalability works not just here in the US, but globally.
So now you realize your applications are vulnerable and want to set up a multi-region design, how do you go about it? As with anything, a more complex design means more moving parts and possibly new services. To start, the application should be redundant within the region, spread across multiple availability zones. For your web/application tier, multiple web/application servers should reside in each availability zone (AZ). Then using the Elastic Load Balancer service, provide load balancing between those nodes. On the Database Tier, using Amazon’s Relation Database Service (RDS) to host your SQL database, or Amazon’s DynamoDB for your No-SQL database will give you the option to replicate your database between multiple availability zones.
Now that you have redundancy built within your region the same process should be applied to another region. In our example above we use the US-East and Singapore regions and set up identical services in each. Once completed using Amazons Route 53 DNS service we can load balance traffic to each region based on availability of services at that region as well as location of the end user. This design ensures that not only are your applications redundant, but your services are distributed so that your customers have the best low latency experience.
So now your applications are redundant and scalable. The process of scaling to new regions is identical and allows your business to meet market demands in uptime and content delivery effectively. The best part? The next time S3 has an outage, you will be happily unaware.