One of the key characteristic of Amazon Web Services (AWS) platform is its high availability. Standard availability figure is five 9’s, that is five and half minutes in a year. However, AWS outages occurred in the past clearly indicates that outages can happen and only those apps or services that are designed for failure can withstand outages with less impact to business continuity. This emphasizes “design for failure” as one of the key design attributes to be considered while architecting for AWS platform.
AWS public cloud infrastructure is built in such a way that the control of application availability is in the hands of the designers or developers, so if designed and implemented well, it is possible to make applications running on AWS withstand infrastructure outages. This article looks at few best practices that are key to “design for failure” on AWS platform:
1. Failover gracefully using Elastic IPs
Elastic IP Addresses are public IP addresses that can be routed to any EC2 instance within a region. During an outage, an elastic IP address can be detached from a failed instance and then mapped to a replacement instance programmatically within a very short time frame. This helps in failing over to another instance quickly.
2. Utilize multiple Availability Zones:
In AWS infrastructure, Availability Zones (AZ) are considered as independent logical datacentres. Application architecture can be deployed to multiple availability zones to ensure high availability. Type of AZ configuration determines the level of Recovery Point Objective (RPO) & Recovery Time Objective (RTO) for disaster recovery (DR) and business continuity (BC). Databases can also be replicated across multiple availability zones by utilizing Amazon RDS Multi-AZ deployment functionality. AWS allows different DR strategies like Pilot Light, Warm Standby, Multi-site etc., choice of the strategy to be made based on the cost considerations. If one availability zone fails, another can be made active to keep the applications active, however, application downtime during AZ switching should be minimized by configuring read-only mode using read replicas and disabling the less important functionalities.
3. Maintain an Amazon Machine Image
Amazon Machine Images (AMI) help to launch instances in a new availability zone whenever there is an outage of one availability zone detected by a healthcheck. AMIs can be created from regular backups of EBS volumes and saved configuration templates are used for launching future instances. This ensures that we can restore and clone environments very easily in a different Availability Zone. Databases are maintained as multiple database slaves across Availability Zones with hot replication.
4. Utilize Amazon CloudWatch
Amazon CloudWatch is a monitoring service for AWS resources and the applications on AWS. CloudWatch can collect and track metrics, monitor log files, set alarms, and automatically trigger actions to changes in AWS resources. CloudWatch alerts are utilized to get more visibility and take appropriate actions in case of hardware failure or performance degradation. Auto scaling groups should be configured to maintain a fixed fleet size so that unhealthy Amazon EC2 instances can be replaced by new ones, whenever there is an outage.
5. Design components with Loose coupling
One of the most important rules of cloud application design is to make system components loosely coupled. Such systems are easily scalable and highly reliable. For decoupling components and enabling asynchronous communication, AWS provided services like SQS, SNS or SWF can be utilized. It is always a good practice to expose components as a service interface and make them responsible for its own scalability in all appropriate dimensions while interacting with other components asynchronously.
Above all, try Chaos Monkey. The Netflix Chaos Monkey tool allows you to proactively launch attack code against your infrastructure to cause failures and give you the chance to fix potential problems before they occur on their own.