Chapter 14. High availability: working with AWS networking tools

 

Back in chapter 12, you doubled the ability of your application to meet growing demand by replicating the instance, running it as an AMI, and then launching it as a new instance. But there’s a far more important reason to replicate your resources: to protect against failure. All hardware (and most software) will eventually stop working; it’s just a matter of time. This means the storage drive containing your OS will one day drop dead, the network connection will fail, and the application software will bug out. That’s life.

But why let disaster become catastrophe? Consider high availability—the sysadmin way to provide backup resources that can be automatically deployed to replace or supplement public-facing servers showing distress. In this chapter, you’ll learn about the structure and benefits of AWS VPCs and how the subnets in VPCs use sound networking principles to significantly improve the reliability of resources.

Because I’m pretty sure you want your share of all those reliability improvements, you’ll finish the chapter by learning how you can deploy identical (read: redundant) application instances into two separate availability zones. That way, even if an entire complete zone fails (and don’t think it’s never happened), you’ll be covered by the instance you have running in the other one.

14.1. Organizing AWS resources in VPCs

14.2. Availability zones and network subnets

14.3. Deploying a website across two availability zones

14.4. Lab