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.