Part 2: (AZ Series) Why we should leverage AWS Availability Zones?

Why we should leverage AWS Availability Zones?

Just moving a system into the cloud doesn’t make it fault-tolerant or highly available; we need to understand the features provided by the cloud provider for availability in depth and then architect our application leveraging the same. 
In AWS infrastructure it is usually recommended to architect applications using multiple availability zones inside a region as best practice. When you design such a system, it is suggested to have a good prior understanding of zone dependencies.
Availability zones (AZs) are distinct geographical locations that are engineered to be insulated from failures in other AZs. Certain services that provide basic infrastructure, such as Amazon Elastic Compute Cloud (EC2) and Amazon Elastic Block Store (EBS) need to be properly architected using this Amazon Multi-AZ’s concept. By placing Amazon EC2 instances in multiple AZs, an application can be protected from failure at a Single EC2, Single location or Single Data center level. It is important to run independent application stacks in more than one AZ, so that if one zone fails, the application in the other zone can continue to run without disruption.
Usually applications which are properly architected for multi-tiered distribution and statelessness in mind can easily leverage AWS High availability features without any code change. Applications which are Statefull can still leverage Amazon Multi-AZ deployment, but it will not be completely fault tolerant because of it is design. Some of the techniques followed in AWS Multi-AZ deployments to avoid Single point of Failure (SPOF) in web/app layer are:

• Since AWS infrastructure does not support Multicast protocol currently, the application layer software should synchronize data using Unicast TCP mechanism. Example: Java based servers can use JGroups or Terracotta NAM to synchronize the cluster information in AWS.
• In case the Web/App servers are written on PHP, .Net, Python etc then all the user and session data can be stored on centralized systems like MemCached EC2 instance or ElastiCache nodes or Amazon DynamoDB. Note: Deploy redundant ElastiCache Clusters in different Availability Zones for HA (or) build cache warming in your design for ElastiCache/MemCached Layers.
• Uploaded User files and documents should be centrally stored on NFS Pool or RedHat Gluster Storage Pool or Amazon S3

The above mentioned points are some of the simple steps that needs to be remembered during the Architecture or Migration phase in AWS.


Other Related Articles :
(Full Article) Exploring Amazon Availability Zones 
Part 8: (AZ Series) Availability Zones : Simple Latency Test
Part 7: (AZ Series) AWS Availability Zones Usage charges
Part 6: (AZ Series) Guidelines for architecting applications across AWS Availability Zones
Part 5:(AZ Series) Availability Zone Names are logical names
Part 4: (AZ Series) How Amazon VPC uses Availability zones
Part 3: (AZ Series) How AWS Building blocks inherently leverage Availability Zones?
Part 2: (AZ Series) Why we should leverage AWS Availability Zones?
Part 1: (AZ Series) What is AWS Availability Zone ?