Production-style edge routing with CloudFront, Lambda@Edge, Application Load Balancers, and EC2
This project deploys a geo-routed multi-origin web architecture on AWS using Terraform.
A user hits a single CloudFront distribution, and Lambda@Edge decides which backend origin to use based on viewer location metadata. The request is then forwarded to one of two Application Load Balancers, which send traffic to separate EC2 web servers.
This demonstrates:
- CDN and edge routing concepts
- Lambda@Edge origin selection
- Multi-origin CloudFront design
- Load balancing with ALB target groups
- Public VPC networking on AWS
- Infrastructure as Code with Terraform
Rec1.AWS.1.mp4
Rec2.BR.1.mp4
✅ A custom VPC
✅ 2 public subnets across different Availability Zones
✅ An Internet Gateway and route table for public access
✅ Security groups for ALB and EC2
✅ 2 EC2 instances serving different web pages
✅ 2 Application Load Balancers
✅ 2 target groups with health checks
✅ A Lambda@Edge function for geo-based origin routing
✅ A CloudFront distribution with custom cache/origin request policies
✅ A default .cloudfront.net endpoint for global access
| Service | Role in Architecture |
|---|---|
| Amazon CloudFront | Global CDN and primary entry point. |
| AWS Lambda@Edge | Executes routing logic at edge locations based on viewer geography. |
| Application Load Balancer (ALB) | Distributes traffic to the designated regional EC2 targets. |
| Amazon EC2 | Hosts the web servers/applications for the specific regions. |
| Amazon VPC | Provides the isolated network infrastructure, subnets, and routing. |
.
├── build/
│ └── geo_router.zip
├── lambda/
│ └── geo_router.js.tftpl
├── scripts/
│ ├── ec2-webpage.sh
│ └── ec2-webpage2.sh
│ └── quick-run.sh
├── .gitignore
├── README.md
├── main.tf
├── output.tf
├── terraform.lock.hcl
└── var.tf
-
Clone the repository
-
git clone https://github.com7twoduo/Geo-Routed-Multi-Origin-Web-Infrastructure-on-AWS.git
-
cd Geo-Routed-Multi-Origin-Web-Infrastructure-on-AWS
-
Review the backend config
Update the backend bucket if needed:
terraform {
backend "s3" {
bucket = "YOUR_BACKEND_BUCKET"
key = "terraform.tfstate"
region = "us-east-1"
}
}
- cd Geo-Routed-Multi-Origin-Web-Infrastructure-on-AWS/scripts
In the terminal, run ./quick-run.sh
After deployment, grab the CloudFront domain from Terraform output and open it in a browser.
It should look like:
https://xxxxxxxxxxxx.cloudfront.net
To verify that the Lambda@Edge routing logic is correctly identifying viewer location and dynamically shifting origins, follow these steps:
Access the CloudFront distribution link directly from your browser. Since the default routing points to the North American region, you will be directed to the US Server.
To test the geo-routing logic, you need to simulate a request originating from South America:
- Action: Enable a VPN (such as UrbanVPN) and set your exit node to Brazil.
- Result: This changes your request metadata to reflect a Brazilian IP address.
Refresh the CloudFront URL. The Lambda@Edge function intercepts the request, identifies the CloudFront-Viewer-Country header as BR, and dynamically rewrites the origin request to the Brazil ALB.
✅ Success Criteria: You should now see the unique web content served from the Brazil-based EC2 instance, proving the global traffic management and edge logic are fully functional.
- Global Entry Point: Users hit a single CloudFront distribution endpoint.
- Edge Logic: A Lambda@Edge function intercepts the request and evaluates the viewer's location.
- Dynamic Routing: Traffic is intelligently forwarded to the appropriate regional backend:
- 🇧🇷 Brazil Origin: Routed to the Brazil Application Load Balancer (ALB).
- 🇺🇸 US / Default Origin: Routed to the US Application Load Balancer (ALB).
- Processing: Each ALB forwards traffic to its dedicated EC2 instance, serving a region-specific response.
To decommission the infrastructure and avoid unnecessary AWS costs, navigate to the root directory containing main.tf and run:
terraform destroy- Edge Defense: CloudFront serves as the hardened public entry point.
- Identity & Access: Granular IAM Roles power the Lambda@Edge execution.
- Network Isolation: Tiered Security Groups protect both the ALBs and the EC2 instances.
- Path Separation: Logic-based routing ensures backend origins remain isolated.
This project is built as a portfolio-ready proof of concept. To transition to a full-scale production environment, the following enhancements are recommended:
- Enhanced Lockdown: Restrict EC2 HTTP traffic strictly to ALB Security Group IDs.
- Access Control: Replace open SSH with AWS Systems Manager (SSM) or a Bastion host.
- Encryption: Implement HTTPS on ALBs and attach a custom domain via AWS Certificate Manager (ACM).
- Edge Security: Deploy AWS WAF in front of CloudFront to mitigate Layer 7 attacks.
- High Availability: Replace single-instance EC2s with Auto Scaling Groups (ASG).
- Observability: Integrate structured logging (CloudWatch) and real-time alerting.
| Problem | Technical Resolution |
|---|---|
| Lambda@Edge Packaging | Automated the build process to render and ZIP JavaScript templates into deployable artifacts during the Terraform apply. |
| Origin Rewriting | Configured CloudFront Origin Request events to handle custom routing logic that native CloudFront behaviors don't support out-of-the-box. |
| Geo-Location Precision | Optimized Cache & Origin Request Policies to ensure CloudFront viewer headers (like CloudFront-Viewer-Country) are correctly forwarded. |
| State Management | Implemented an S3 Backend for Terraform with considerations for local lockfile synchronization across different workflows. |
This project highlights production-inspired AWS edge architecture and demonstrates how modern cloud services can be combined to build intelligent, scalable, and globally distributed routing systems.
Instead of stopping at a basic deployment, this repository focuses on real infrastructure patterns used in performance-sensitive and traffic-aware environments.
- 🌐 AWS networking and traffic flow design
- ⚡ Edge computing with Lambda@Edge
- 📦 CDN behavior and request routing with CloudFront
- 🧠 Origin selection and request manipulation at the edge
- 🔀 Load balancing across backend services
- 🏗️ Terraform-based infrastructure provisioning
- 📈 Production-inspired architecture thinking
- Terraform
- Amazon CloudFront
- Lambda@Edge
- Application Load Balancers
- Amazon EC2
The goal of this repository is to demonstrate practical cloud engineering skills through a production-inspired AWS edge routing solution.
It is designed to showcase more than just deployment — it emphasizes:
- intelligent request routing
- edge-side logic
- scalable backend delivery
- repeatable Infrastructure as Code
- real-world architectural decision-making
I build hands-on cloud projects designed to reflect practical engineering work rather than simple demos. My focus is on AWS infrastructure, Infrastructure as Code, automation, security-minded design, and real implementation patterns that translate into production environments.
Through projects like this, I aim to demonstrate the ability to design, provision, and integrate modern cloud services in ways that are scalable, structured, and operationally relevant.
