In the world of e-commerce, visibility is everything. But what happens when search engines index the wrong version of our site? Imagine a potential customer clicking a Google link, only to land on an unstable sandbox with test-mode payment gateways and an incomplete product catalog. Not only does this create a poor user experience, but it can also destroy trust and cost you real revenue.
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.
Data loss remains one of the most critical risks for IT professionals, developers, and home-lab enthusiasts alike. While cloud solutions exist, nothing beats the control, speed, and privacy of backing up directly to your own Network Attached Storage (NAS).