React-based e-commerce frontend deployed on AWS with a complete DevSecOps CI/CD pipeline, Helm, Docker containerization, and multi-environment deployment (Development & Production).
Table of Contents
- ShopNow Frontend: React E-Commerce with AWS Infrastructure & DevSecOps Pipeline
The frontend architecture is designed with strict separation of concerns, high availability, and network isolation using Terraform IaC.
AWS Architecture Modeling
- Compute Layer: Containerized React SPA deployed on AWS EKS (Kubernetes) for Production (multi-pod auto-scaling) and AWS EC2 ASG for Development.
- Traffic Routing: Internal and external traffic managed via AWS Load Balancer Controller (ALB) terminating HTTPS via AWS Certificate Manager (ACM).
- Network Isolation (Private/Public Subnets):
- Public Subnets: Only the Bastion Host (SSH Jump Server) is exposed to the internet.
- Private Subnets: EKS Cluster, Worker Nodes, and self-hosted GitHub Actions Runners communicate entirely inside private subnets, routing outbound traffic via NAT Gateways.
- EKS Control Plane: Ingress HTTPS (443) allowed only from Worker Nodes and Bastion Host.
- EKS Worker Nodes: Ingress HTTP/HTTPS (80/443) allowed from ALB; Node-to-Node communication unrestricted.
- Bastion EC2: Ingress SSH (22) restricted to corporate VPC CIDR (
10.0.0.0/16). - Frontend Dev Runner: Ingress SSH (22) from Bastion only. Outbound allowed to ECR, GitHub API, and Backend Runner (Port 5214).
All infrastructure is provisioned via Terraform as Code in Bel7phegor/shopnow-infa.
| Technical Aspect | Development Environment (develop) |
Production Environment (v* Tags / release) |
|---|---|---|
| Target Infrastructure | AWS EC2 + Auto Scaling Group | AWS EKS (Kubernetes Cluster) |
| Application Domain URL | https://shopnow-dev.anphuc.site |
https://shopnow.anphuc.site |
| Backend API Endpoint | https://api-dev.anphuc.site |
https://api-shopnow.anphuc.site |
| Trigger Mechanism | Automatic on every push |
Manual approval triggered via Git tags |
| Docker Image Tagging | dev_${COMMIT_SHA} |
${VERSION}_${COMMIT_SHA} + latest |
| NAT Gateway Strategy | Single NAT (Cost-Optimized) | Multi-AZ NAT Gateways (High-Availability) |
| Deployment Strategy | Container replacement on EC2 | Zero-Downtime Rolling Update (K8s Ingress) |
| Log Management | CloudWatch Group: /ec2/shopnow-frontend |
CloudWatch Group: /prod/shopnow-frontend |
| Security Gates | Lightweight (Snyk + Trivy FS) | Comprehensive (SAST + Container + DAST) |
A multi-stage Dockerfile is utilized to optimize image size, ensuring that development dependencies are excluded from the final lightweight production image (~20MB).
# Stage 1: Build Environment
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
ARG REACT_APP_BASE_API_URL
ENV REACT_APP_BASE_API_URL=$REACT_APP_BASE_API_URL
RUN npm run build
# Stage 2: Optimized Nginx Production Runtime
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]- Image Registry: Private AWS Elastic Container Registry (ECR), integrated with secure OpenID Connect (OIDC) IAM Roles (no static AWS hardcoded credentials).
The pipelines utilize a Shift-Left Security approach, embedding automated vulnerability assessment gates before and after code changes hit production.
End-to-End DevSecOps Workflow Architecture Modeling
A. Development Pipeline (ci-dev.yml)
- Trigger: Code push to
developbranch. - Execution: Self-hosted EC2 runner pulls code → Builds Docker Image with Dev API configuration → Pushes to ECR → Deploys directly to EC2 via
docker runwith CloudWatch logs logging driver enabled.
B. Production Pipeline (ci-prod.yml)
- Trigger: Git version tag creation (
v*). - Build Stage: Builds production-optimized Docker image.
- Security Gate (Parallel Execution):
- Snyk Code Scan: Analyzes
package.jsonfor flawed third-party npm libraries. - Trivy FS Scan: Scans repository filesystem for hardcoded secrets/API keys.
- Trivy Image Scan: Deep scans OS layers within the Docker container for known CVEs.
- Snyk Code Scan: Analyzes
- Orchestrated Deploy: Requires successful scan results. Executes Helm upgrade /
kubectl applyon EKS cluster with atomic rollbacks. - Post-Deploy DAST (Parallel Execution):
- OWASP ZAP Scan: Validates OWASP Top 10 compliance on the live URL.
- Arachni Penetration Testing: Executes dynamic security testing across subdomains.
The pipeline integrates Telegram as a real-time channel for security visibility and deployment gating:
- Pre-Deploy Alert: After the SAST/SCA/Filesystem scans complete, a summary message is sent to Telegram. Scan jobs are intentionally allowed to pass (non-blocking) even when
HIGH/CRITICALfindings exist, so the pipeline keeps moving while still surfacing issues — visibility into the GitHub Actions::errorannotations and the Telegram alert, rather than a hard pipeline stop. - Selective Report Delivery: Only the HTML report from the specific scanner that found a vulnerability is attached and sent — avoiding noise from clean reports.
- Approval Request: The same notification includes a direct link to approve the
buildjob, combining the security summary and the deployment gate into a single message. - Post-Build Image Scan Alert: A second, separate notification reports the Trivy container image scan result once the image has been built and pushed to ECR.
The Kubernetes manifests for this service are defined as a Helm chart in the helm/ directory of this repo. During deployment, the CI pipeline runs:
helm upgrade --install shopnow-frontend ./helm \
--namespace shopnow \
--create-namespace \
--set fullnameOverride=shopnow-frontend \
--set image.repository=<ECR_REGISTRY>/shopnow-frontend \
--set image.tag=<TAG>_<SHA> \
--set ingress.host=<FRONTEND_DOMAIN> \
--set ingress.acmArn=<ACM_CERT_ARN> \
--atomic --wait-
Rather than maintaining separate
values-dev.yaml/values-prod.yamlfiles, environment-specific configuration (image tag, ingress host, ACM certificate ARN) is injected at deploy time directly from GitHub Actions secrets via--setflags. This keeps the chart itself environment-agnostic while the CI workflow decides what gets deployed where. -
--atomic --waitensures that if the rollout fails health checks within the timeout, Helm automatically rolls back to the previous release — avoiding a broken deployment staying live in production.
The chart structure follows the reusable template defined in Bel7phegor/templates-helm-k8s (Deployment, Service, Ingress, HPA), adapted here for the frontend service's specific needs (Nginx-served static build, single container port 80).
A few key infrastructure choices and the reasoning behind them:
-
EC2 (Dev) vs. EKS (Prod): Development uses a single EC2 instance with direct
docker rundeployment — fast and cheap to iterate on. Production runs on EKS to get rolling updates, self-healing pods, and horizontal autoscaling under real traffic. Running EKS for dev as well would add unnecessary cost for an environment that doesn't need HA. -
Single NAT (Dev) vs. Multi-AZ NAT (Prod): A single NAT Gateway in dev keeps cost down since downtime there only affects testing. Production uses NAT Gateways across multiple AZs so an AZ failure doesn't cut off outbound connectivity for the cluster.
-
OIDC over static AWS credentials: GitHub Actions assumes short-lived IAM roles via OIDC instead of storing long-lived AWS access keys as secrets — removes a major credential-leak risk in the pipeline.
-
Manual tag-based promotion to Production: Dev deploys automatically on every push to
developfor fast feedback. Production only deploys on an explicit version tag (v*), giving a manual gate before changes reach the live environment. -
Security gates split into pre-deploy (SAST/FS/image scan) and post-deploy (DAST): Static/dependency scans run before the image is built/pushed to catch issues early (shift-left), while ZAP/Arachni run against the live URL after deployment to catch runtime/configuration issues that static scans can't see.
| Layer | Technologies & Tools |
|---|---|
| Frontend Engine | React 18.2 |
| Cloud Infrastructure | AWS (EKS, EC2, VPC, Route 53, CloudWatch, ACM, IAM OIDC), Terraform IaC |
| Deployment & Orchestration | Docker (Multi-stage Build), Helm Charts, GitHub Actions Pipelines |
| DevSecOps Scanners | Snyk (SAST & SCA), Aqua Trivy (FS & Container Scan), OWASP ZAP (DAST), Arachni Framework |
The screenshots and links below show the pipeline, infrastructure, and security scans actually running for this project.
Live Workflow Runs Release v1.2.8: GitHub Actions Production Workflow
End-to-end Build, Scan, and Deploy workflow completing successfully on Production
The pipeline runs the build, parallel security scans, and deployment stages in sequence, with the deploy step only proceeding once all security gates pass.
Live Workflow Runs test/dev: GitHub Actions Production Workflow
End-to-end Build, Scan, and Deploy workflow completing successfully on test/development
Target group routing and health status on the AWS Application Load Balancer
Inbound traffic is routed through the AWS ALB, which applies host- and path-based routing rules to direct requests to the appropriate pods/targets.
Separate CloudWatch log groups for Development and Production
Application logs are split by environment (
/ec2/shopnow-frontendfor Dev,/prod/shopnow-frontendvia FluentBit for the EKS workload), keeping dev and prod logs isolated for easier debugging.
Docker images stored in a private AWS ECR repository
Images are pushed to a private ECR repository using short-lived OIDC credentials — no static AWS keys are stored in CI.
Application running on its custom domain with a valid SSL certificate
The app runs on its custom domain over HTTPS, with the certificate provisioned and auto-renewed via AWS Certificate Manager.
Each pipeline run produces scan reports used as gates before deployment:
| Scan Type | Tool | Report |
|---|---|---|
| Dependency Vulnerabilities | Snyk (SCA + SAST) | Snyk SCA Report / Snyk SAST Report |
| Repo Secret Leakage | Trivy FS | Trivy Filesystem Report |
| Container Image CVEs | Trivy Image | Trivy Image Report |
| Web App Security (DAST) | OWASP ZAP | ZAP Baseline Report |
| Penetration Test | Arachni | Arachni Scan Archive |
Real-time Telegram alert showing scan status and the report attached for the job that found a vulnerability
When a scan job detects
HIGH/CRITICALfindings, the pipeline sends a Telegram message summarizing the result alongside the deployment approval link, then attaches only the HTML report from the scanner(s) that flagged an issue.
Author: Nguyễn An Phúc (Bel7phegor)
- Profiles: LinkedIn: nguyen-an-phuc | GitHub: Bel7phegor | Portfolio: anphuc.site
- Email: nguyenanphuc12032002@gmail.com
E-Commerce Project Subsystems:
- Frontend React: Bel7phegor/shopnow-frontend
- Backend Java microsevices: Bel7phegor/shopnow-backend
- Terraform Cloud Automation Infrastructure: Bel7phegor/shopnow-infa
- Kubernetes Helm Templates: Bel7phegor/shopnow-helm