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.
After setup and integrate Slack with Amazon Q (Chatbot) configuration successfully, we’ll setup the CloudWatch alarm which detects high CPU usage on an EC2 instance. Thus, the key part of this phase it to ensure AWS send real-time alerts to our Slack channel.
Operational excellence focuses on running and monitoring systems to deliver business value. This pillar is about how we operate our systems day-to-day, which makes it the foundation upon which everything else builds. In this project, we will integrate the AWS dashboard capabilities into Slack in real-time. This will help the efficiency of support teams just to work using Slack channels in fixing the issues instead of switching around the AWS console, CloudWatch, and various dashboard that can lead to error-prone human-error steps in handling the incident tickets.
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.