Part 3: (AZ Series) How AWS Building blocks inherently leverage Availability Zones?

How AWS Building blocks inherently leverage Availability Zones?


Most of the higher-level AWS, such as Amazon Simple Storage Service (S3), Amazon DynamoDB, Amazon CloudWatch, Amazon Simple Queue Service (SQS), and Amazon Elastic Load Balancing (ELB), have been built with inherent fault tolerance and high availability in mind. They already work across multiple availability zones inside an Amazon Region. Let us see how each of them uses the Availability zone concept;


Amazon ELB:  Amazon ELB can direct and load balance requests to multiple EC2 instances launched across multiple availability zones inside a Region. Load Balancer Instances are spawned in Multiple Availability Zones in the ELB tier as well internally when the traffic increases. 
Amazon RDS MySQL:  Amazon RDS for MySQL and Oracle currently supports Multi-AZ Hot Standby architecture, where the Primary Master will run on one Availability zone and Hot Standby (Secondary) will run on another Availability zone. In event of Primary AZ failure, the Hot Standby will start serving the requests from the alternative AZ. We can also create and launch multiple RDS Read Replica’s in Multiple Availability Zones for Read scaling and HA.
Amazon S3: Any data that is stored on S3 (Standard Storage option) is synchronized at multiple locations/facilities inside an Amazon Region. Amazon S3 Objects are redundantly stored on multiple devices across multiple facilities (AZ’s) in an Amazon S3 Region. To help ensure durability, Amazon S3 PUT and COPY operations synchronously store our data across multiple facilities before returning a successful response.
Amazon DynamoDB: Amazon DynamoDB service replicates data across three facilities/Availability zones in an AWS Region to provide fault tolerance in the event of a server failure or Availability Zone outage. Also to achieve high uptime and durability, Amazon DynamoDB does synchronous replication of data across these (multiple) facilities.
Amazon SQS: Amazon SQS stores all queue and messages redundantly on multiple servers and in multiple data centers/availability zones, which means that no single computer or network failure will render SQS messages inaccessible.
Amazon ElastiCache: Currently Amazon ElastiCache Cluster cannot span multiple Availability Zones inside an AWS Region. Deploy redundant ElastiCache Clusters in different Availability Zones for HA in AWS or alternatively use efficient cache warming techniques in your architecture for fault tolerance in this layer.
Amazon CloudWatch: Amazon CloudWatch can monitor EC2 instances which are deployed at multiple availability zones inside an Amazon Region. Amazon CloudWatch is an AWS building block and it is a Highly Available service by design. 
Amazon AutoScaling: Amazon AutoScaling can scale out/down EC2 instances across multiple Availability zones inside an Amazon Region. Amazon AutoScaling cannot span EC2 scale out across Amazon Regions.

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 ?