Our highly available and fault-tolerant web application infrastructure so far needs some final validation to ensure it works as expected. Now we’ll simulate failure cases, check recover behavior, and confirm if DNS has failed.

Most production application has a storage layer to be shared with multiple EC2 instances. This layer can store logs, static content, or file uploaded by users that persists across instance replacements and always be available in all AZs. In this part, we’ll use Amazon Elastic File System (EFS) where we can mount a shared and persistent file system to all EC2 instances. This means we shall replace our dependency on the GitHub clone files which unreliable whenever any EC2 instance is terminated and replaced by Auto-scaling.

Apart from the multi-AZ infrastructure, we also need a way to intelligently route user traffic according to the system health. This means by configuring Route 53 DNS with health check ability to route traffic to our application via ALB and automatically failover once the ALB becomes unhealthy. This way, we can protect the user from seeing downtime during outages by routing them to a backup error page, too.

As an integral part of most application, database is such a crucial part where it also need a resilience design and implementation. In this part, we will setup a secure multi-AZ enabled Amazon RDS for the Flash Sale app where it can only be accessed from the EC2 instances. The scope of RDS in this project is to simulate the usage of database since the Flash Sale application is a front-end app only.

Reliability pillar is an architecture guideline that focuses on the ability of a workload to perform its intended function correctly and consistently when it is expected to. In this project we will re-architect a traditional application deployment where it lacks of fault-tolerance and high-availability. We will start by deploying a flash-sale application for an e-commerce flash campaign without fault-tolerance where if any of EC2 or RDS instance is down there will be a loss of access to customer transaction data.

In this final part of this project, we’ll strengthen the application-layer security, we’ll integrate AWS Web Application Firewall (WAF) with our existing Application Load Balancer (ALB). WAF helps detect and block malicious HTTP requests before they reach your app, such as SQL injection, cross-site scripting (XSS), and bot traffic.

After deploying the EC2 (application-tier) behind the Application Load Balancer (ALB), we’ll privately deploy RDS (database-tier) and S3 (storage-tier) by following the principle of least privilege. The RDS is only accessible from private EC2 while S3 assets are not publicly accessible.

In order to run the application backend in a secure way, we’ll deploy the EC2 instance inside a private subnet of the secured VPC. There will be a Bastion Host deployed in the public subnet for administrative access only. Last but not least, we’ll securely route the inbound traffic via Application Load Balancer (ALB) hosted on the public subnet.

After intentionally deploy the insecure ShoppingCart application in the part 1, in the 2nd part, we will start to rebuild the proper architecture for with AWS security best practices. In essence, the goal of security pillar is to minimise risk by default through a layered security model such as: network isolation using private subnets, controlled access as the principle of least access through security groups, and AWS WAF to block common threats (i.e. SQL injection, XSS, malware, and IP bots)

As part of the Well-Architected Framework from AWS, security pillar is one of the main fundamental aspects in designing and delivering any AWS project. In this project we’ll demonstrate how to transform a vulnerable cloud environment into a secure and production grade architecture. After deploying the insecure baseline, the step-by-step re-design will follow the security-first design principles by involving the AWS services such as custom VPC, secured EC2, and ALB (Application Load Balancer) with WAF protection-enabled.