Stage Three
In Stage Two we built our infrastructure in AWS using Terraform, Ansible, and Packer. Now it's time to take that infrastructure an make it highly available. This means it can survive an outage, such as a server failing, power failing, networking being saturated, and more. Essentially, if a single component fails, the solution keeps going and serving traffic. This is what a real world solution looks like.
We're also going to explore networked filesystems via AWS Elastic File System, so that we can make WordPress scale as new servers are introduced and old ones are decommissioned. Without a shared, network based file system, this wouldn't possible as WordPress stoes uploaded files on the disk of the server that handled the request, and they're not automatically replicated to the other servers. This must be resolved.
Our attention is then drawn to cyber security ("CyberSec", or Information Security; "InfoSec") and the need to keep our solutions secure. This includes introducing encryption to our solution to ensure it's protected against common attack vectors and more. Security is an increasingly growing threat in our field, and everyone involved, regardless of their place in the process, must do what they can to see data, software and networks secure.
We're also going to explore some other advanced AWS features that are commonly found in the wild: Organisations, advanced networking setups, and AWS Backups. You're going to find a lot of multi-account setups out there, as well as advanced networking setups like having a single VPC that all other VPCs route Internet bound data through. And finally we'll look at AWS Backups, because data is, ultimately, what this whole game is about.
Architect
This is the target architecture we will implement by the time we reach the end of this stage:
Topics
Next
Let's get started on making Tightly a Highly Available, redundant solution.