Introduction:

In today’s cloud-first world, migrating legacy or on-premise applications to the cloud is no longer optional—it’s essential. Our team recently completed a cloud migration project for an e-commerce web application, where we designed and deployed a robust, secure, and scalable infrastructure using Amazon Web Services (AWS).

In this post, I’ll walk through the architecture, services used, and best practices we followed for this migration.

🎯 Project Objective:

The main goal was to migrate an existing e-commerce web application from an on-prem environment to AWS, while:

  1. Implementing network and data security

  2. Improving scalability and performance

  3. Ensuring high availability and monitoring

  4. Optimizing for cost-efficiency

☁️ Cloud Architecture Overview:

Following AWS best practices and implemented a multi-tier architecture split across public, private, and database subnets, within a custom VPC.

🔹 VPC & Subnets

1. CIDR block: 10.0.0.0/16

2. Public Subnets (ALB): 10.0.1.0/24, 10.0.6.0/24

3. Private Subnets (EC2): 10.0.60.0/24, 10.0.120.0/24

4. DB Subnets (RDS): 10.0.180.0/24, 10.0.240.0/24

5. Availability Zones: us-east-1a, us-east-1b

6. A NAT Gateway was set up to allow internet access for private instances without exposing them publicly.

🔐 Security Implementation:

Security was a core part of this project. Here’s what needs to be done:

✅ Security Groups:

  1. Load Balancer (sg_loadbalancer): Allow HTTP/HTTPS ingress and egress from internet.

  2. Web Servers (sg_private): Allow traffic to port 80 and 443 from internet only the instances within the private subnet use NAT for abstracting themselves from internet and allow ingress and egress to port 3306 from sg_rds.

  3. Database (sg_rds): Only allow MySQL traffic from EC2 in private subnet over port 3306.

✅ Web Application Firewall (WAF):

  1. Attached to ALB with both:

  2. AWS-managed rule sets (Linux, PHP, SQLi)

  3. Custom rule sets (e.g., BlockBadBots)

✅ IAM & KMS:

  1. Created fine-grained IAM roles and policies for EC2, ALB, CloudFront, WAF, and CloudWatch.

  2. Used AWS KMS to encrypt:

    i. RDS storage

    ii. EC2 volumes

  3. Secrets in Secrets Manager

  4. CloudWatch logs and S3 buckets

📦 Content Delivery & DNS:

  1. Manually setup CloudFront CDN linked to an S3 bucket for static content (JS, CSS, images), ensuring low latency and high availability.

  2. Route 53 used to manage DNS routing.

  3. ALB configured with SSL certs from AWS Certificate Manager for HTTPS support and redirecting HTTP to HTTPS.

🧠 Application & Database Setup:

  1. EC2 (Web Tier):

    i. Instance Type: t4g.small (cost-efficient + ARM support)

    ii. Hosted the app on Ubuntu 24.02 LTS

    iii. Configured for scaling and metrics collection via SSM & CWAgent

  2. RDS (Database Tier):

    i. Engine: MySQL

    ii. Instance Type: db.t4g.medium (I/O optimized)

    iii. Multi-AZ enabled for high availability

    iv. Private access only (secured by sg_rds)

  3. Secrets Manager used to store DB credentials and endpoint

📊 Monitoring & Cost Control:

  1. Implement observability and budget tracking using:

    i. CloudWatch Dashboards & Alarms for EC2, RDS, and CloudFront

    ii. CloudTrail for auditing API actions and security events

    iii. SSM Agent for EC2 log/metric extraction

    iv. AWS Budgets for real-time cost monitoring and alerts

🚀 Auto Scaling & Resilience:

  1. To handle traffic spikes:

    i. Created a Launch Template with baked-in user data and configuration

    ii. Attached it to an Auto Scaling Group triggered by CPU > 60%

    iii. This ensured our application could scale dynamically while maintaining performance.

💡 Key Takeaways:

This project gave me hands-on experience with:

  1. Designing secure and scalable cloud architectures

  2. Implementing network isolation and encryption

  3. Leveraging IAM, WAF, and KMS for cloud security

  4. Using CloudWatch and CloudTrail for full-stack monitoring

  5. Enabling cost-effective scaling strategies

This help successfully transition the application from a static, monolithic setup to a highly available and secure cloud-native infrastructure.

🔎 What’s Next?

We’re looking to explore:

  1. CI/CD pipelines for automated deployments

  2. Containerizing the app with ECS or EKS

  3. Using IAM authentication for connecting with RDS

  4. Dynamic caching using cloudfront

👉 Interested in chatting about cloud, DevOps, or security engineering?

Feel free to connect or drop me a message!

Github repo:

  1. https://github.com/arbaaz29/e-commerce-tf.git

  2. https://github.com/arbaaz29/e-commerce-app.git

  3. https://github.com/arbaaz29/e-commerce-db.git