Ai o aplicație web care rulează pe un VPS — React pe frontend, Node.js pe backend, PostgreSQL ca bază de date și Redis pentru cache. Totul merge bine pe un server de €15-30/lună la Hetzner sau DigitalOcean. Dar vine momentul în care traficul crește, clienții vor SLA-uri, iar tu ai nevoie de scalabilitate reală. E momentul să te uiți serios la AWS.
În acest articol trecem prin arhitectura AWS potrivită pentru o astfel de aplicație, comparăm costurile concret, și explicăm cum funcționează autoscaling-ul pe EC2 — cu numere reale.
Punctul de plecare: VPS-ul clasic
Scenariul tipic arată așa: un singur server (Hetzner CPX31 — 4 vCPU, 8GB RAM, 160GB SSD) la ~€15/lună care rulează totul — Node.js, PostgreSQL, Redis, eventual și Nginx ca reverse proxy. Adaugi poate un al doilea server pentru redundanță, ajungi la €30-40/lună total.
Funcționează. Dar ai câteva probleme fundamentale: nu ai autoscaling (traficul de Black Friday doboară serverul), nu ai failover automat (dacă pică serverul, pică totul), backup-urile sunt manuale sau semi-automatizate, iar scalarea înseamnă „cumpăr un server mai mare și migrez manual."
Arhitectura AWS propusă
Pe AWS, aceeași aplicație se descompune în servicii specializate:
Frontend (React) — S3 + CloudFront. Fișierele statice (HTML, CSS, JS) se servesc din S3 prin CDN-ul CloudFront. Zero servere de administrat, latență mică global, cost neglijabil pentru trafic moderat.
Load Balancer — Application Load Balancer (ALB). Distribuie traficul HTTP/HTTPS către instanțele de backend. Costă ~$0.0252/oră fix plus un cost variabil bazat pe LCU (Load Balancer Capacity Units) în funcție de trafic.
Backend (Node.js) — EC2 Auto Scaling Group. Minim 2 instanțe t3.medium (2 vCPU, 4GB RAM) în Availability Zone-uri diferite. Auto Scaling Group-ul adaugă sau elimină instanțe automat pe baza traficului.
Baza de date (PostgreSQL) — RDS PostgreSQL. Instanță db.t3.medium cu Multi-AZ pentru failover automat. Backup-uri automate, patch-uri gestionate de AWS, restaurare point-in-time.
Cache (Redis) — ElastiCache. Nod cache.t3.medium gestionat complet. Nu mai trebuie să administrezi procesul Redis, actualizările sau monitorizarea.
Comparație de costuri: VPS vs. AWS
Hai să punem numerele față în față. Prețurile sunt pentru regiunea eu-central-1 (Frankfurt), On-Demand, fără discounturi.
Scenariul VPS (Hetzner)
Un setup tipic de producție cu două servere pentru redundanță costă cam așa: două servere CPX31 la €15/lună fiecare, plus managed backup la ~€3/lună, totalizând aproximativ €33/lună.
Scenariul AWS (On-Demand)
Pe AWS, costurile se distribuie pe fiecare serviciu. Două instanțe EC2 t3.medium (backend) vin la circa $67/lună ($0.046/oră × 730h × 2). ALB-ul costă în jur de $25/lună (taxa fixă plus LCU-uri pentru trafic moderat). RDS PostgreSQL db.t3.medium Single-AZ ajunge la ~$53/lună ($0.072/oră × 730h), iar cu Multi-AZ se dublează la aproximativ $106/lună. ElastiCache Redis cache.t3.medium vine la circa $50/lună. S3 și CloudFront pentru frontend-ul static costă sub $5/lună la trafic moderat. În total, AWS On-Demand ajunge la aproximativ $200-306/lună, în funcție de opțiunea Single-AZ sau Multi-AZ pentru baza de date.
Scenariul AWS optimizat
Cu Reserved Instances (1 an, fără plată în avans) economisești circa 30-40%. Adică totalul scade la aproximativ $130-200/lună. Cu Savings Plans pe 1 an, poți ajunge și mai jos. Iar dacă folosești instanțe Graviton (t4g în loc de t3), câștigi încă 10-20% pe preț cu performanță similară sau mai bună.
Verdictul pe costuri
VPS-ul e de 5-8 ori mai ieftin ca preț brut. Dar nu compari mere cu mere. AWS îți oferă: failover automat, backup-uri gestionate, scalabilitate elastică, monitorizare integrată (CloudWatch), certificare și compliance (SOC 2, ISO 27001, GDPR), și un SLA de 99.99% pe ALB. Când calculezi costul real — inclusiv timpul tău pentru administrare, risc de downtime, și pierderi potențiale — diferența se micșorează semnificativ.
Autoscaling pe EC2: Cum funcționează
Autoscaling-ul este motivul principal pentru care migrezi pe AWS. În loc să plătești pentru capacitate maximă 24/7, plătești doar pentru ce folosești.
Auto Scaling Group (ASG) definește: câte instanțe EC2 minim (ex: 2), maxim (ex: 8) și dorit (desired capacity). ASG-ul menține automat numărul dorit și înlocuiește instanțele care pică health check-urile.
Scaling Policies definesc când și cum se scalează. Ai două abordări principale.
Target Tracking Scaling — cea mai simplă și recomandată. Setezi o țintă (ex: „vreau ca CPU-ul mediu să fie la 60%") și AWS ajustează automat numărul de instanțe pentru a menține acea valoare. Funcționează similar cu un termostat: dacă traficul crește și CPU-ul trece peste 60%, se adaugă instanțe; dacă scade, se retrag.
Step Scaling — pentru control mai fin. Definești pași: dacă CPU trece de 70%, adaugă 1 instanță; dacă trece de 90%, adaugă 3. Util când ai pattern-uri de trafic previzibile și vrei reacții diferențiate.
Metrici pe care să scalezi. CPU-ul e cel mai comun, dar nu întotdeauna cel mai bun. Pentru o aplicație Node.js, poți scala pe: ALB Request Count per Target (câte cereri primește fiecare instanță — ideal pentru web apps), CPU Utilization (bun pentru sarcini compute-intensive), sau metrici custom prin CloudWatch (ex: lungimea cozii de job-uri, latența răspunsurilor).
Cooldown period — după ce ASG adaugă o instanță, așteaptă un interval (default 300 secunde) înainte să ia altă decizie de scalare. Previne oscilațiile: nu vrei să adaugi 10 instanțe în 10 secunde pentru un spike momentan.
Exemplu practic: aplicația ta servește în medie 500 req/s ziua și 50 req/s noaptea, cu spike-uri de 2000 req/s la lansări de campanii. Configurezi ASG-ul cu minim 2 instanțe, maxim 8, și Target Tracking pe ALBRequestCountPerTarget la 1000 cereri/instanță. Noaptea rulezi pe 2 instanțe (~$2/zi). Ziua, sistemul menține 2-3 instanțe. La spike, scalează automat la 4-5 instanțe, apoi revine. Plătești doar pentru orele efectiv utilizate.
Ce nu scalezi: baza de date și Redis
Un detaliu important — RDS PostgreSQL și ElastiCache nu se scalează orizontal la fel de ușor ca EC2. Baza de date poate folosi Read Replicas pentru a distribui citirile, dar scrierile rămân pe instanța primară. Redis în ElastiCache suportă cluster mode cu sharding, dar asta adaugă complexitate.
Recomandarea practică: dimensionează baza de date și Redis pentru vârf de la început (sau ușor peste), și scalează doar layer-ul de backend (EC2). E mai simplu, mai previzibil și acoperă 90% din scenarii.
Pași concreți pentru migrare
Procesul de migrare implică mai multe etape. Mai întâi, deploy-ul frontend-ului React pe S3 cu CloudFront. Apoi configurarea RDS PostgreSQL și migrarea datelor cu pg_dump și pg_restore. Urmează setup-ul ElastiCache Redis. Apoi crearea AMI-ului (Amazon Machine Image) cu aplicația Node.js și configurarea Launch Template + Auto Scaling Group. Se adaugă ALB-ul în fața ASG-ului. Și nu în ultimul rând, setup-ul Route 53 pentru DNS, cu un cutover planificat de la VPS la AWS.
Timpul realist pentru o migrare completă: 2-4 săptămâni, incluzând testare și perioadă de rulare în paralel.
Când merită și când nu
Migrează pe AWS când: ai nevoie de scalabilitate elastică, clienții cer SLA-uri și compliance, vrei high availability fără efort manual, sau aplicația crește și un VPS nu mai face față.
Rămâi pe VPS când: traficul e previzibil și modest, bugetul e prioritatea #1, echipa e mică și nu are experiență AWS, sau aplicația e un MVP în fază de validare.
Nu există răspuns universal. Dar dacă aplicația ta generează venituri și orice oră de downtime înseamnă bani pierduți, AWS nu e un cost — e o investiție în stabilitate.
Publicat pe teninvent.ro — TEN INVENT S.R.L. oferă servicii de consultanță și implementare infrastructură AWS. Contactează-ne pentru o evaluare gratuită a arhitecturii tale cloud.