Running a project on localhost is straightforward. But the moment you try to deploy something real : with a custom domain, HTTPS, and a scalable architecture ,you realize how many moving parts are actually involved.
For my project IPlusFlow (an EEG-based Alzheimer’s detection platform), I needed a setup that was secure, scalable, and mirrored real industry architecture. Most importantly, I wanted to run it entirely for free.
Project Links:
- 🌍 Live Site: eeg.iplusflow.com
- 💻 GitHub Repository: EEG-CNN-BiLSTM
This is a breakdown of how I wired AWS and Cloudflare together, the architectural decisions I made, and the debugging lessons I learned along the way.
The Architecture Strategy
The goal was to build a production-style design that strictly separated storage, compute, and traffic routing. Putting everything in one place is easier, but separating concerns scales better.
- Backend: FastAPI running on AWS Lambda via API Gateway
- Frontend: Static files hosted on Amazon S3
- CDN: AWS CloudFront
- DNS & Edge: Cloudflare
Bypassing Fixed Costs
The standard AWS approach for DNS management is Route 53. It works seamlessly, but it introduces a fixed monthly cost. To keep my infrastructure at exactly ₹0, I bypassed Route 53 entirely and handled DNS through Cloudflare.
I purchased the domain, pointed the nameservers to Cloudflare, and managed all routing for subdomains like eeg.iplusflow.com and api.iplusflow.com from there. It was a simple architectural decision, but it was the most impactful step in eliminating recurring overhead.
Challenges and Learnings
1. The AWS SSL Region Trap
Because my backend was deployed in the Mumbai region (ap-south-1), I generated a wildcard certificate (*.iplusflow.com) there. It attached to the API Gateway perfectly.
However, when I tried to attach the same certificate to CloudFront for the frontend, it simply didn't appear in the dropdown. After digging through the documentation, I learned that CloudFront strictly requires certificates to be generated in us-east-1 (N. Virginia), regardless of where your actual infrastructure lives. I had to provision a duplicate certificate in us-east-1 specifically for the CDN. It is a strict AWS requirement that isn't immediately obvious when you start.
2. The Cloudflare Proxy Conflict
When adding CNAME records in Cloudflare, I initially left the proxy setting enabled (the "orange cloud"). This immediately resulted in SSL handshake failures between Cloudflare and AWS.
In hindsight, the reason was clear: API Gateway and CloudFront were already terminating HTTPS using their own AWS ACM certificates. Cloudflare was attempting to sit in the middle and re-handle the SSL, creating a conflict. The fix was to switch those DNS records to "DNS Only" (the "grey cloud"). Once the proxy was disabled, the handshake issues were resolved.
3. Cross-Origin (CORS) Blocks on Subdomains
My frontend (eeg.iplusflow.com) was designed to fetch presigned URLs from the backend (api.iplusflow.com) to upload EEG files directly to S3. The API responded perfectly, but the browser blocked the actual file uploads.
The issue was CORS. Browsers treat different subdomains as entirely different origins. To fix this, I had to explicitly update the S3 bucket's CORS configuration to allow Origin: https://eeg.iplusflow.com and restrict the method to PUT. After applying that specific policy, the client-side uploads worked.
Why Use Both Cloudflare and CloudFront?
It might seem redundant to use CloudFront when Cloudflare already provides CDN capabilities. I considered dropping CloudFront, but keeping it solved two critical architectural problems:
- S3 Security: Without CloudFront, the S3 bucket would have to be public to serve the frontend files. By using CloudFront, I could keep the bucket entirely private, restricting access exclusively through the CDN via Origin Access Control (OAC).
- SSL Compatibility: CloudFront integrates flawlessly with AWS certificates. Trying to route Cloudflare directly to a private S3 bucket often introduces complex SSL and routing headaches.
The final flow cleanly separated responsibilities: Cloudflare handles DNS, CloudFront securely fetches from S3, and the S3 bucket remains locked down.
Final Thoughts
This setup achieved exactly what I needed: a zero-cost infrastructure, HTTPS across both frontend and backend, and a clean separation of layers.
More than just getting a project live, this process forced me to understand the lifecycle of a web request i.e. how DNS resolves, where SSL terminates, and how CDNs interact with private storage. If you are deploying your first serious project, I highly recommend skipping the one-click hosting platforms and trying a manual setup like this. It takes more effort, but the technical understanding you walk away with is invaluable.
If you are building something similar and hit a wall, feel free to reach out. I am still learning this myself, and documenting the process is part of that journey.
Top comments (0)