For Week 3 of the AWS Power Hour: AWS Solutions Architect Associate, they covered Domain 2 of the exam, which is Designing Resilient Architectures. They did a quick overview (it's not possible to deep dive in 90 minutes) and then presented us with the architecture below for our 'HomeFun' project. We were assigned to review and make recommendations for a more robust, resilient architecture, using the AWS Well-Architected Framework as a guide. This framework is integral to the Solutions Architect (and indeed, any) role, as it provides 'Best Practices' to follow. As with any Architecture, Client RTO and RPO will dictate how much or how little resiliency we build in--the changes to this model architecture is designed for High-Availability and Fault-tolerance.
At first glance, the diagram is definitely not resilient. There is no fault tolerance, it exists in a single Availability Zone, exposed to the internet. But, if you look deeper, it is trying to be resilient, by having two Web
Servers running on Amazon EC2 instances, to serve up content. However, if I put on my network administrator hat, I see that the Web Servers are not load balanced (so no 'fault tolerance) and are connected to a Database Server, which leads me to believe this is some type of Content Management System (CMS). That same hat sees that the Database Server, a MySQL database running on an Amazon EC2 instance, is sitting exposed to the public internet--which is not only a failure in Security Best Practices, it also makes this not resilient.
If we make the assumption that this is some type of CMS, then a three-tier Architecture immediately comes to mind. We can use Elastic Load Balancer and Auto Scaling Groups to scale the application. We can split out the content of the CMS using Elastic File System, and finally, place our database into a MySQL RDS or Amazon Aurora DB instance, and configure at least one Standby Replica.
How do we do this, you might ask? Let's take a high-level look at the steps involved. We are making the assumption that the EC2 instances were originally configured with a User Data script that installs and does the initial configuration of your CMS.
Create the environment required--VPC, Subnets (for a 3-Tier Architecture, we need three in each AZ we will use, one each for Web, App, and DB) with appropriate routing table and Network ACLs. You will need an Internet Gateway (IGW), and a security group for each tier plus the Load Balancer with appropriately designed inbound and outbound rules (for example, the Database should only allow inbound connections from the Web tier Security Group on port 3306, and the Web tier should only allow access from the Load Balancer).
Next, Create a Launch Template using one of the running EC2 instances as a template. This way, we will capture all current configurations, and we can modify this launch template later.
Next, we will need to create Subnet Group in the RDS Console and assign it to our VPC for our client and the Database Subnets in each Availability Zone. Then, we will create a Database and extract the data from the current database to run in the new. If you use RDS, there is a multi-AZ deployment model with automated failover, and you can set up Automated Backups for point-in time recovery. Once created, migrate the data from the current MySQl database using the backup-restore method. Fore more details, review the documentation
Next, we need to create an EFS File System, which will be mounted on our App Tier. We will need to use our EFS Security Group and from the Command Line of our EC2 instance, we will migrate the existing files from the CMS content folder(s) to the EFS. Reboot the EC2 instance and confirm you can still access the content. Next, Update the Launch Template to add the EFS File system changes.
As our final step, we will create the ELB and Auto Scaling Group and integrate them togehter. We will set up our scaling policy, based on the business rules of the company we are doing the work for.
Our Architecture has evolved to provide Resilience and greater security to the company. We have locked the database down to only being accessed by our Web Servers, and both are designed to scale with demand, based on business rules. This environment could easily be duplicated over other Availability Zones as need arises.
Top comments (0)