Deploying Node.js to AWS EC2: Lessons Learned

🚀 Just built and deployed my own AWS EC2-like cloud platform — NimbusCloud! Over the past few weeks, I worked on understanding how cloud services actually work under the hood — and ended up building a mini version of EC2 from scratch. 💡 What it does: Launch compute instances (powered by Docker containers) Start, Stop, and Delete instances (full lifecycle management) Connect to instances via a browser-based Linux terminal Execute real Linux commands using xterm.js + WebSockets Fully deployed on AWS EC2 and accessible publicly 🌐 Live Demo: 👉 http://3.17.204.2:5000 (Anyone can try launching and connecting to instances) ⚙️ Tech Stack: Flask (Backend / API layer) Docker (Compute layer – simulating EC2 instances) xterm.js + WebSockets (Real-time terminal) HTML, CSS, JS (Frontend) AWS EC2 (Deployment) 🔥 What I learned: How EC2-like services manage compute resources How to connect frontend ↔ backend ↔ infrastructure Real-time communication using WebSockets Debugging real-world issues (routing, Docker behavior, deployment) Importance of proper backend serving instead of static file handling 📌 Key Highlight: Building a web-based terminal where users can run commands directly inside their instances — similar to AWS EC2 Instance Connect — was the most exciting part. 🚧 Next Improvements: Add authentication & security layers Instance monitoring dashboard Persistent shell sessions This project helped me move beyond tutorials and think like a DevOps + Backend engineer. Would love your feedback 🙌 #DevOps #CloudComputing #AWS #Docker #Flask #WebSockets #FullStack #Projects #LearningInPublic

🚀 I deployed the same project using EC2, Amplify, and S3 — here’s what I learned Instead of just learning deployment in theory, I tried something different: I hosted the same website using three different AWS services to understand the real differences. Here’s a simple breakdown: ⚙️ Amazon EC2 — Full Control Complete server access (Linux machine) Can host both frontend + backend (MERN) Requires manual setup (Nginx, PM2, reverse proxy) Best for: Real-world production apps Downside: More setup and maintenance ⚡ AWS Amplify — Effortless CI/CD Connect GitHub → automatic build & deploy Great for modern frontend apps (React, Next.js) Built-in CI/CD pipeline Best for: Fast deployment and clean workflows Limitation: No direct support for full Express backend 📦 Amazon S3 — Static Hosting Hosts static files (HTML, CSS, JS) Very fast and cost-effective No server-side logic Best for: Portfolios and landing pages Limitation: No backend support Key Takeaway There is no “one best” hosting solution. The right choice depends on your project: Full-stack app → EC2 Frontend app → Amplify Static site → S3 What I realized Deployment is not just about making your app live. It is about understanding: control vs simplicity flexibility vs speed choosing the right tool for the right job If you’re learning cloud or MERN, try this exercise once. It gives you clarity you won’t get from tutorials. #AWS #CloudComputing #WebDevelopment #MERN #DevOps #LearningInPublic

🚀 Day 23 of 100 Days of DevOps 🚨 I was managing… 50 EC2 configs Nginx setup Auto Scaling Load Balancer Every deploy felt like a nightmare. 💀 One mistake = downtime. Then I discovered something surprising… 👉 You don’t always need to “manage infrastructure” ⚡ Enter: AWS Elastic Beanstalk ⚡ What changed instantly: • Deployment → git push → live app • Scaling → automatic (ASG built-in) • Load balancing → handled for you • Monitoring → CloudWatch integrated 🧠 The shift that changed everything: Stop managing servers Start deploying applications ⚙️ What Beanstalk actually does: Upload code → 👉 Provisions: • EC2 • Load Balancer • Auto Scaling • Monitoring Automatically. 🔥 The part most people miss: Elastic Beanstalk is PaaS → You control the app → AWS controls the infrastructure 💡 Best for: Web apps, APIs, quick deployments ⚔️ But here’s the REAL decision: When should you NOT use Beanstalk? → Need full control? → EC2 → Need containers at scale? → ECS/EKS → Event-driven apps? → Lambda 💡 Choosing the wrong tool = bad architecture 💣 Reality check: Most beginners try to learn EVERYTHING at once. Top engineers ask: 👉 What is the simplest tool that solves this problem? 📌 My takeaway (Day 23): If you're over-engineering your deployment… 👉 you’re slowing yourself down 📚 I turned this into a visual comic (super easy to understand) Comment "BEANSTALK" and checkout bellow 🔥 Let’s grow together 🚀 #Day23 #100DaysOfDevOps #AWS #ElasticBeanstalk #DevOps #CloudComputing #SystemDesign #LearnInPublic

Deploying an application is where a lot of engineering assumptions get tested. Working with .NET Core applications in Azure App Service taught me that writing the code is only one part of the job. The other part is making sure the application can run reliably in the real world. A few lessons that stuck with me: - Environment configuration needs just as much care as application code. - Release confidence goes up when deployment steps are predictable. - Cloud and on-prem workflows often need more coordination than people expect. - Reliability and scalability are easier to talk about than to actually design for. I like that cloud work pushes you to think beyond the happy path. It makes you think about hosting, production behaviour, release safety, and how systems behave after they leave your machine. What is one deployment lesson you learned the hard way? #Azure #AzureAppService #DotNet #CloudEngineering #DevOps #FullStack

Day-2 Hands-on with Azure Web Apps + Docker (My Learning Experience) Today I explored deploying a web application using containers on Microsoft Azure — and honestly, it made me rethink how applications are hosted. * First, I worked with a Virtual Machine (IaaS model) I created a VM, installed a web server manually, configured everything step by step. It gave me full control, but it also took time and effort. Every small setup had to be done by me. * Then I moved to Web App with Docker (PaaS model) Here things felt completely different. Instead of installing a server, I just selected a container image (NGINX), and Azure handled everything internally using Docker. Within minutes, I got a live URL showing the default page from Nginx. * What I understood: In IaaS (VM): * I manage OS, software, updates * Full control, but more responsibility 👉 In PaaS (Web App + Docker): * Azure manages infrastructure. * I only focus on the application. 🔄 Why Docker here? Docker packages the application with all dependencies into an image. Azure simply pulls that image and runs it as a container. No setup. No compatibility issues. Just run. * Why this is better than VM (in many cases): * Faster deployment (minutes vs hours) * No manual installation * Consistent environment everywhere * Easier scaling My realization: Using VM is like building everything from scratch. Using Web App with Docker is like running a ready-made, packaged application. Both are useful — but choosing the right one depends on the requirement. This hands-on really helped me understand the shift from traditional infrastructure to modern cloud-native deployment. #Azure #Docker #CloudComputing #WebApp #PaaS #IaaS #LearningByDoing

🆚 Amplify vs CDK feels like a tooling choice… until you actually have to decide. Both build on AWS. But they solve very different problems. 📰 I recently wrote an article breaking down: • When Amplify helps you move faster with app development • When CDK gives you the control you actually need • Why “app-first vs infrastructure-first” matters more than features • And how this decision impacts your project long-term Not just surface-level differences, but what it really means when you pick one over the other. If you're working with AWS, this can help you avoid overcomplicating things early. 👉 Read the full article here: https://lnkd.in/gpXcifDx Would love to know, how are you approaching this in your projects? #AWS #Amplify #AWSCDK #Cloud #DevOps #Serverless

Microsoft Shows. AWS Actually Does: I deployed the exact same .NET 8 app on both free tiers. Same code. Same Dockerfile. Completely different results. AWS EC2 (t2.micro): x86 architecture (Intel) Standard Docker build: 2-3 minutes Deploys smoothly. Just works. ✅ Azure Free Tier (B2pts v2): ARM64 architecture (Ampere) Standard Docker build: 10+ minutes → TIMEOUT My x64 container ran under emulation. 5-10x slower. ❌ Here's the kicker: This is Microsoft's own tech stack. .NET 8. ASP.NET Core. Their own cloud free tier can't run their own framework's default deployment without choking. Meanwhile, AWS EC2—boring, predictable, x86—handles it without breaking a sweat. Why does this matter? Because beginners will hit this and blame themselves. They'll think their code is broken. They'll waste hours debugging architecture mismatches they didn't even know existed. I've been doing cloud deployments for months across both platforms, and even I was frustrated. A newcomer? Demoralized. My Experience I've deployed production workloads on both AWS and Azure. AWS free tier is what a free tier should be: honest about what you get, compatible with standard tooling, and actually usable for learning. Azure's free tier is cost-cutting dressed up as "better specs." ARM VMs have their place, but shoving them as the default free option—especially for .NET developers—is a trap. If you're starting your cloud journey or building side projects: AWS EC2 free tier is the clear winner. Don't let Azure's spec sheet fool you. #AWS #Azure #DotNet #DevOps #CloudComputing #Developer #FreeTier

One of those days where I just had the urge to build something personal. Had an idea for an app, started building it, and once it was done I thought — why not use this as a real AWS deployment project? So that’s what I did. 🔧 Infrastructure: • VPC with public & private subnets + custom route tables • Internet Gateway for public access, NAT routing for private resources ⚙️ Stack: • Frontend → AWS Amplify (with built-in CI/CD) • Backend → Node.js on EC2 (public subnet, PM2 for process management) • Database → RDS on private subnet (zero direct internet exposure) • Auth → Amazon Cognito • File storage → S3 (public assets) Keeping the DB isolated in a private subnet while giving it controlled internet access via route table config was a key focus — security without sacrificing functionality. PM2 keeps the backend resilient, and Cognito removes the overhead of building auth from scratch. 📌 What's next: • Move backend behind an Application Load Balancer + private subnet • Add CloudFront CDN in front of S3 and Amplify • Introduce auto-scaling for the EC2 layer • Set up CloudWatch monitoring & alerts • Migrate toward containerization with ECS or explore serverless with Lambda • Terraform to automate and codify the entire infrastructure Every project teaches you something new about trade-offs. This one was about balancing simplicity with production-readiness. You can check it out here https://lnkd.in/epsw3xH7 PS: deleting link soon once i destroy resources because of cost #AWS #CloudArchitecture #FullStack #DevOps #NodeJS #RDS #Amplify #Cognito

Let me explain AWS EKS like you've never heard of it before. 🧵 Imagine you want to run 100 copies of your app across multiple servers. Without Kubernetes: → You manually start each copy → One crashes? You manually restart it → Traffic spikes? You manually add more → This doesn't scale ❌ With Kubernetes: → You say "I want 100 copies running" → One crashes? K8s restarts it automatically → Traffic spikes? K8s adds more automatically → This scales ✅ But Kubernetes is complex to set up. You need master nodes, worker nodes, networking... That's where AWS EKS comes in. 𝗘𝗞𝗦 = Kubernetes but AWS manages the hard part. AWS runs the brain (control plane) for you. You just run the workers and deploy your apps. Think of it like this: 🏢 Self-managed K8s = You buy the building, hire staff, fix the plumbing 🏨 AWS EKS = You rent a hotel room - AWS manages everything else Here's how simple it is to get started: Step 1 — Create the cluster exksctl create cluster --name my-app --region us-east-1 → AWS builds VPC, subnets, IAM roles, worker nodes → All automated. Takes ~15 minutes. Step 2 — Deploy your app kubectl apply -f deployment.yaml → Your app is now running on AWS → Kubernetes manages it automatically Step 3 — Check everything is running kubectl get pods → Shows all your running app instances Step 4 — Delete when done learning exksctl delete cluster --name my-app → IMPORTANT — EKS costs $0.10/hr even when idle → Always delete after labs! 💸 𝗞𝗲𝘆 𝘁𝗲𝗿𝗺𝘀 𝘁𝗼 𝗸𝗻𝗼𝘄: • Pod = smallest unit - wraps your container • Node = server that runs your pods • eksctl = tool that builds the cluster • kubectl = tool that manages what runs inside • Fargate = serverless nodes - no EC2 to manage #AWS #EKS #Kubernetes #CloudEngineering #DevOps #LearningInPublic #TechEducation