Conceptele cloud și delimitarea responsabilității

Cloud computing este un model de utilizare în care resursele IT nu sunt deținute, ci împrumutate doar atunci când sunt necesare, în cantitatea necesară, plătindu-se doar pentru ceea ce se folosește. Timpul de la solicitare până la începerea utilizării este scurt, iar dacă resursele sunt returnate, facturarea se oprește în acel moment. Stabilirea cantității necesare înainte de implementare și achiziționarea echipamentelor, precum și gestionarea proprie a alimentării și climatizării, sunt ambele metode specifice on-premises, iar pentru că trebuie decisă cantitatea în avans, apar supra-provizionarea sau lipsa de capacitate. Descrierea conform căreia cantitatea nu poate fi modificată pe durata contractului este opusă premisei cloud-ului, conform căreia aceasta poate fi crescută sau redusă ulterior.

Pay-as-you-go este principiul conform căruia se plătește doar pentru ceea ce se folosește efectiv, fără plăți în avans și fără angajament pe termen lung. Deoarece scalarea se face în funcție de cererea reală, nu de o previziune, se reduce riscul de supra-provizionare. Reducerea prețului unitar în schimbul angajării la un nivel de utilizare pe o perioadă fixă este Save when you commit; scăderea prețului unitar pe măsură ce utilizarea crește este Pay less by using more; iar gruparea într-o sumă lunară fixă fără costuri suplimentare este Flat rate — toate acestea se referă la principii diferite.

Pay less by using more este principiul conform căruia, pentru servicii precum S3 sau transferul de date, se aplică o structură de tarifare graduală în care prețul pe GB scade pe măsură ce utilizarea crește. Reducerea prețului unitar în schimbul angajării la un nivel de utilizare pe o perioadă fixă este Save when you commit, iar Savings Plans corespunde acestui principiu. Plata, de fiecare dată, doar pentru ceea ce s-a folosit efectiv este Pay-as-you-go, iar gruparea într-o sumă lunară fixă fără costuri suplimentare este Flat rate. Cele patru principii au scopuri diferite, deci nu se exclud reciproc, ci se folosesc combinate.

Save when you commit este principiul conform căruia, ca în cazul Savings Plans, în schimbul angajării la un anumit nivel de utilizare pentru o perioadă de 1 sau 3 ani, prețul serviciilor de calcul sau de învățare automată este redus. Fixarea sumei lunare fără costuri suplimentare este Flat rate și nu implică un mecanism de report. Structura graduală în care prețul unitar scade pe măsură ce utilizarea crește corespunde principiului Pay less by using more. Posibilitatea de a opri utilizarea oricând, fără angajament, este o caracteristică a Pay-as-you-go, ale cărui premise sunt opuse acestui principiu, care presupune angajament.

Conform listei oficiale a ghidurilor de examen, valabilă din august 2026, la nivelul Foundational se află doar AWS Certified Cloud Practitioner (CLF-C02) și AWS Certified AI Practitioner (AIF-C01). Developer - Associate (DVA-C02) și Data Engineer - Associate (DEA-C01) se află ambele la nivelul Associate, iar Advanced Networking - Specialty (ANS-C01) se află la nivelul Specialty. Certificările care au denumirea nivelului în nume oferă un indiciu, dar Cloud Practitioner și AI Practitioner nu au un nume de nivel atașat, așa că merită reținut că tocmai acestea două sunt Foundational.

CLF-C02 este codul de examen pentru AWS Certified Cloud Practitioner. CLF indică Cloud Practitioner, iar C02 de la final indică generația de revizuire. Codul pentru AWS Certified AI Practitioner este AIF-C01, pentru AWS Certified Developer - Associate este DVA-C02, iar pentru AWS Certified Data Engineer - Associate este DEA-C01. Denumirea unei certificări se poate schimba, dar codul de examen rămâne neschimbat până la o nouă revizuire, astfel încât verificarea codului este modul sigur de a confirma dacă un material este actual.

Codul de examen pentru AWS Certified Solutions Architect - Professional este SAP-C02. SAA-C03 este codul pentru nivelul Associate al aceleiași certificări Solutions Architect, SOA-C03 este codul pentru CloudOps Engineer - Associate, iar SCS-C03 este codul pentru Security - Specialty. Primele trei litere sunt asemănătoare și pot crea confuzie, dar merită reținut că SAA corespunde nivelului Associate, iar SAP nivelului Professional.

Exam Guide pentru CLF-C02 stabilește următoarele proporții: Cloud Concepts 24%, Security and Compliance 30%, Cloud Technology and Services 34%, Billing, Pricing, and Support 12%. Prin urmare, cea mai mare proporție revine domeniului Cloud Technology and Services, iar cea mai mică domeniului Billing, Pricing, and Support. Fiind o certificare de nivel introductiv, se tinde să se creadă că domeniul conceptual are ponderea cea mai mare, dar în realitate domeniul care testează cunoștințele despre servicii are cea mai mare pondere, urmat de securitate. Alocarea timpului de studiu ar trebui să urmeze exact aceste proporții.

Exam Guide pentru SAA-C03 stabilește următoarele proporții: Design Secure Architectures 30%, Design Resilient Architectures 26%, Design High-Performing Architectures 24%, Design Cost-Optimized Architectures 20%. Cea mai mare proporție revine proiectării unor arhitecturi securizate. Cele patru domenii sunt mai ușor de reținut dacă sunt asociate cu pilonii Well-Architected, iar ordinea corespunde securității, rezilienței, eficienței performanței și optimizării costurilor.

Certificarea de nivel Associate pentru operațiuni și-a schimbat numele din SysOps Administrator în CloudOps Engineer, iar codul de examen s-a schimbat din SOA-C02 în SOA-C03. Ultima zi de susținere a vechiului cod a fost 29 septembrie 2025, iar noul cod a intrat în vigoare la 30 septembrie 2025. Data Engineer - Associate și Machine Learning Engineer - Associate nu sunt succesoare ale certificării de operațiuni, ci certificări noi, distincte, create pentru domeniile datelor și, respectiv, al învățării automate. DevOps Engineer - Professional este o certificare de nivel Professional care exista deja anterior, aflată de altfel la un nivel diferit.

AWS numește oficial propria responsabilitate „Security of the Cloud” și o definește drept protejarea infrastructurii care rulează toate serviciile oferite în cloud-ul AWS, adică hardware-ul, software-ul, rețeaua și facilitățile. Remedierea vulnerabilităților unei aplicații instalate pe o instanță revine clientului, atunci când acesta alege EC2. Alegerea opțiunilor de criptare a datelor și acordarea permisiunilor prin IAM rămân sarcini ale clientului indiferent de serviciul ales, și ambele aparțin părții „Security in the Cloud”.

AWS precizează explicit că „responsabilitatea clientului este determinată de serviciul cloud AWS pe care îl alege clientul”. Aceasta înseamnă că, în funcție de serviciul ales, variază volumul de configurări pe care trebuie să le realizeze utilizatorul ca parte a responsabilității sale de securitate. Planul de asistență determină modul de a primi suport tehnic și nu deplasează linia de demarcație a responsabilității. Regiunea și zona de disponibilitate țin de plasarea resurselor, iar perioada de utilizare și suma cheltuită țin de facturare — niciunul dintre acestea nu determină amploarea sferei de responsabilitate.

AWS precizează că, pentru servicii precum EC2, care necesită configurare, utilizatorul își asumă „gestionarea guest OS-ului (inclusiv actualizări și patch-uri de securitate), software-ul de aplicație și utilitarele instalate pe instanță, precum și configurarea grupurilor de securitate”. Prin urmare, aplicarea patch-urilor pe sistemul de operare este responsabilitatea utilizatorului. Pentru EC2, AWS operează doar infrastructura fizică și stratul de virtualizare, sistemul de operare din interiorul instanței nefiind inclus. Planul de asistență este un contract pentru primirea de suport tehnic și nu mută locul responsabilității.

Pentru serviciile abstractizate sau gestionate (managed), AWS precizează că „AWS operează stratul de infrastructură, sistemul de operare și platforma, iar clientul accesează punctul final (endpoint) pentru a stoca și prelua date”. Ceea ce îi rămâne utilizatorului este gestionarea propriilor date (inclusiv opțiunile de criptare), clasificarea activelor și aplicarea permisiunilor corespunzătoare prin instrumentele IAM. Nici actualizarea sistemului de operare, nici operarea platformei nu revin utilizatorului, dar clasificarea datelor și configurarea permisiunilor rămân în sarcina utilizatorului indiferent de serviciu.

Linia de demarcație a modelului de responsabilitate partajată nu este fixă, ci se deplasează în funcție de serviciul ales. Pentru servicii precum EC2, unde utilizatorul gestionează guest OS-ul, aplicarea patch-urilor revine utilizatorului, dar pentru servicii precum S3 sau DynamoDB, unde AWS operează chiar și sistemul de operare și platforma, responsabilitatea revine AWS. Prin urmare, atât „întotdeauna AWS”, cât și „întotdeauna utilizatorul” sunt greșite. Regiunea este doar o alegere de amplasare și nu modifică repartizarea responsabilității. Reținând acest singur punct, se poate estima linia de demarcație pentru un serviciu nou întâlnit gândindu-ne dacă seamănă mai mult cu EC2 sau cu S3.

Facilitățile sunt menționate explicit ca parte a infrastructurii care rulează serviciile cloud AWS, în cadrul „Security of the Cloud”, și revin întotdeauna responsabilității AWS, indiferent de serviciul folosit. Utilizatorul nu poate audia singur această zonă și nici nu poate intra fizic pentru inspecție, ci se bazează pe certificările de la terți și rapoartele de audit publicate de AWS. Aceasta corespunde categoriei de controale moștenite (Inherited Controls) dintre cele trei categorii de controale, adică partea pe care utilizatorul o preia integral de la AWS. Ceea ce se deplasează în funcție de serviciul ales este stratul sistemului de operare sau al middleware-ului, nu stratul fizic.

AWS precizează explicit că gestionarea propriilor date (inclusiv opțiunile de criptare), clasificarea activelor și aplicarea permisiunilor corespunzătoare prin instrumentele IAM rămân în sarcina utilizatorului chiar și atunci când se folosesc servicii abstractizate. Deoarece acestea nu se schimbă indiferent de serviciul ales, ele reprezintă un punct fix atunci când se stabilește linia de demarcație. Înlocuirea serverelor fizice și protejarea rețelei backbone țin de facilități și de hardware, deci revin întotdeauna AWS. Sistemul de operare care stă la baza serviciilor gestionate este operat de AWS, deci aplicarea patch-urilor pe acesta nu este o sarcină a utilizatorului.

Controalele moștenite sunt definite oficial ca fiind controale pe care utilizatorul le moștenește integral de la AWS, iar controalele fizice și de mediu se încadrează aici. Controalele aplicate separat atât la stratul de infrastructură, cât și la stratul utilizatorului sunt controalele partajate (Shared Controls), iar cele care sunt integral responsabilitatea utilizatorului, incluzând securitatea serviciilor și a zonelor, sunt controalele specifice clientului (Customer Specific Controls). Direcția moștenirii este unidirecțională, de la AWS către utilizator, și nu este vorba despre o relație în care AWS preia configurările utilizatorului.

Exemplele oficiale de controale partajate sunt gestionarea patch-urilor, gestionarea configurațiilor, precum și sensibilizarea și formarea. Caracteristica lor este că aceeași activitate se desfășoară în paralel atât la stratul de infrastructură, cât și la stratul utilizatorului; de exemplu, în cazul gestionării patch-urilor, AWS o aplică propriei infrastructuri, iar utilizatorul o aplică separat guest OS-ului și aplicațiilor. Controlul accesului, redundanța sursei de alimentare, achiziția și casarea hardware-ului sunt controale fizice și de mediu, aparținând categoriei pe care utilizatorul o moștenește de la AWS. Securitatea serviciilor și a zonelor este un exemplu de control specific clientului.

DynamoDB este un serviciu abstractizat, astfel încât AWS operează stratul de infrastructură, sistemul de operare și platforma. Aplicarea patch-urilor pe guest OS, care în EC2 revenea utilizatorului, devine, prin migrare, o sarcină de partea AWS. Pe de altă parte, clasificarea datelor, alegerea opțiunilor de criptare și acordarea permisiunilor prin IAM rămân în sarcina utilizatorului, indiferent de serviciul ales. Protejarea facilităților fizice este oricum întotdeauna responsabilitatea AWS, deci nu trece la utilizator prin migrare. Reținând că „ceea ce se schimbă este stratul sistemului de operare sau al platformei, iar ceea ce nu se schimbă sunt datele și permisiunile”, nu ar trebui să apară confuzii.

Pilonii actuali sunt cei șase: Excelență operațională, Securitate, Fiabilitate, Eficiența performanței, Optimizarea costurilor și Sustenabilitate. Sustenabilitatea a fost adăugată ca al șaselea pilon în 2021, așa că o listă de doar cinci piloni, fără aceasta, reflectă informații mai vechi, dinainte de adăugare. Interoperabilitatea și Portabilitatea nu sunt menționate ca piloni ai cadrului; niciuna dintre ele nu apare în lista oficială. Un material care are un număr învechit de piloni are probabil și denumiri de servicii sau coduri de examen învechite, așa că acest lucru poate servi drept indiciu al gradului de actualitate al unui material.

Excelența operațională este pilonul care se concentrează pe rularea și monitorizarea sistemelor, precum și pe îmbunătățirea continuă a proceselor și procedurilor. Aici se încadrează automatizarea implementărilor, actualizarea procedurilor pe baza analizelor post-incident și efectuarea unor schimbări mici și frecvente. Protejarea informațiilor și a sistemelor ține de Securitate, optimizarea alocării resurselor și alegerea tipului de resursă țin de Eficiența performanței, iar eliminarea cheltuielilor inutile și dimensionarea corectă a resurselor țin de Optimizarea costurilor — toate se referă la alți piloni.

Pilonul de securitate se concentrează pe protejarea informațiilor și a sistemelor, iar în centrul său se află integritatea datelor și controlul accesului. Criptarea și controlul accesului bazat pe principiul privilegiului minim se încadrează direct aici. Oprirea resurselor neutilizate și dimensionarea corectă țin de Optimizarea costurilor, automatizarea implementărilor și actualizarea procedurilor pe baza analizelor post-incident țin de Excelența operațională, iar măsurarea și reducerea impactului asupra mediului țin de Sustenabilitate. Cea mai mare parte din ceea ce rămâne în sarcina utilizatorului, conform modelului de responsabilitate partajată, este tratată în cadrul acestui pilon de securitate.

Fiabilitatea este pilonul care se concentrează pe îndeplinirea de către sarcina de lucru a funcției intenționate și pe rapiditatea recuperării în urma unui incident. Aici se încadrează distribuirea pe mai multe zone de disponibilitate, recuperarea automată și verificarea procedurilor de backup și restaurare. Caracteristica sa este că nu se limitează la a preveni defecțiunile, ci include și restabilirea rapidă atunci când acestea apar. Optimizarea alocării resurselor ține de Eficiența performanței, rularea, monitorizarea și îmbunătățirea procedurilor țin de Excelența operațională, iar minimizarea impactului asupra mediului ține de Sustenabilitate.

Eficiența performanței este pilonul care se concentrează pe optimizarea alocării resurselor IT și pe alegerea tipului de resursă potrivit nevoilor sarcinii de lucru. Reconsiderarea tipului de resursă pentru a îndeplini cerințele se încadrează direct aici. Optimizarea costurilor poate părea o activitate asemănătoare, dar scopul ei este eliminarea cheltuielilor inutile, iar în acest caz motivația este îndeplinirea cerinței de latență, deci accentul este diferit. Fiabilitatea privește rezistența la incidente, iar Excelența operațională privește îmbunătățirea procedurilor — niciuna dintre acestea nu este preocuparea principală aici.

Optimizarea costurilor este pilonul care se concentrează pe eliminarea cheltuielilor inutile și pe dimensionarea corectă a resurselor în raport cu cerințele afacerii. Aici se încadrează decizii precum oprirea resurselor neutilizate, corectarea dimensiunii instanțelor supradimensionate sau alegerea combinată a diferitelor modele de tarifare. Scopul nu este simpla reducere a costurilor, ci verificarea dacă valoarea obținută corespunde sumei plătite. Protejarea informațiilor și a sistemelor ține de Securitate, îndeplinirea funcției intenționate și recuperarea țin de Fiabilitate, iar minimizarea impactului asupra mediului ține de Sustenabilitate.

Sustenabilitatea este pilonul care se concentrează pe minimizarea impactului asupra mediului generat de rularea sarcinilor de lucru în cloud. Este cel mai nou pilon, adăugat ca al șaselea în 2021, iar prezența sau absența acestui pilon reprezintă linia de demarcație față de materialele mai vechi. Optimizarea alocării resurselor și alegerea tipului acestora țin de Eficiența performanței, rularea, monitorizarea și îmbunătățirea continuă a procedurilor țin de Excelența operațională, iar îndeplinirea funcției intenționate și recuperarea în urma incidentelor țin de Fiabilitate — toate se referă la alți piloni.

Ceea ce lipsește este Sustenabilitatea (Sustainability), pilonul care se ocupă de minimizarea impactului asupra mediului generat de rularea sarcinilor de lucru în cloud. Deoarece a fost adăugată ca al șaselea pilon în 2021, articolele scrise anterior au rămas la cinci piloni. Excelența operațională, Eficiența performanței și Fiabilitatea existau deja înainte de adăugare, deci apar și în articolele care menționează cinci piloni. Un articol care greșește un aspect atât de fundamental precum numărul pilonilor are șanse mari să conțină și alte informații învechite.

Pilonii actuali sunt cei șase: Excelență operațională, Securitate, Fiabilitate, Eficiența performanței, Optimizarea costurilor și Sustenabilitate, iar Interoperabilitatea nu se numără printre ei. Deși capacitatea diferitelor sisteme de a comunica între ele este o preocupare importantă de proiectare, cadrul Well-Architected nu îi dedică un pilon separat. Optimizarea costurilor, Excelența operațională și Eficiența performanței sunt toate piloni oficiali, dintre cei șase. Reținerea unui termen care nu există în cadru drept pilon poate crea confuzie la eliminarea variantelor greșite.

Eliminarea cheltuielilor inutile și dimensionarea corectă a resurselor în raport cu cerințele afacerii este focusul pilonului Optimizarea costurilor, nu al Fiabilității. Fiabilitatea este pilonul care se concentrează pe îndeplinirea de către sarcina de lucru a funcției intenționate și pe rapiditatea recuperării în urma incidentelor. Celelalte trei combinații corespund exact descrierii oficiale. Deoarece numele pilonilor sunt apropiate de limbajul comun, asocierea lor doar după impresia superficială poate duce la confuzii. Reținerea împreună cu o frază care exprimă focusul evită astfel de greșeli.

O regiune este o locație fizică din lume în care AWS deține mai multe zone de disponibilitate. Are un nume precum us-east-1 sau ap-northeast-1 și se alege în funcție de locația datelor și reglementările aplicabile, de distanța față de utilizatori și de tarife. Unitatea de izolare a incidentelor, formată din una sau mai multe centre de date independente, corespunde descrierii unei zone de disponibilitate. Punctele din care CloudFront memorează în cache și distribuie conținutul sunt locațiile edge (edge locations), iar zonele amplasate în rețeaua unui operator de telecomunicații sunt Wavelength Zones.

O zonă de disponibilitate este definită ca fiind formată din una sau mai multe centre de date independente, fiecare dotat cu surse de alimentare, rețea și conectivitate redundante, și amplasate în facilități separate. Nu este echivalentă cu o singură clădire de centru de date, ci reprezintă o grupare, iar faptul că se află într-o clădire diferită de celelalte zone este esențial. Stratul dintre locația edge și origine este cache-ul regional edge (Regional Edge Cache), iar posibilitatea de a rula aplicații într-un oraș apropiat de utilizatori corespunde descrierii Local Zones — ambele se referă la mecanisme diferite.

AWS afirmă că fiecare regiune este formată din „cel puțin trei zone de disponibilitate separate fizic și independente”. Numărul total de regiuni și de zone continuă să crească, așa că memorarea acestor cifre are o valoare redusă, dar regula privind numărul minim de zone dintr-o regiune este stabilă și poate fi folosită direct ca premisă de proiectare. Descrierea „amplasate în aceeași facilitate” contrazice definiția conform căreia zonele sunt amplasate în facilități separate. Zonele nu sunt nici adăugate la cererea utilizatorului, nici limitate la una singură pe regiune.

Locațiile edge formează rețeaua globală de centre de date prin care CloudFront distribuie conținut. Cererile sunt rutate către locația edge cu cea mai mică latență, iar de acolo se face distribuirea. Nu reprezintă o unitate de redundanță pentru creșterea disponibilității, ci un punct de cache pentru a redistribui conținutul cât mai aproape de utilizator — acesta este aspectul esențial. Izolarea incidentelor este rolul zonelor de disponibilitate, împărțirea intervalelor de adrese IP este rolul subrețelelor (subnets), iar rularea în facilitățile unui operator de telecomunicații este rolul Wavelength Zones.

Cererea este rutată către locația edge cu cea mai mică latență, iar dacă conținutul se află acolo, este distribuit imediat. Dacă nu, este preluat de la origine — de exemplu un bucket S3 sau un server HTTP —, distribuit, și în același timp păstrat în cache. Astfel, cererile ulterioare sunt returnate direct din locația apropiată. Lipsa unui element din cache nu devine o eroare și nici nu lasă utilizatorul în așteptare nedefinită. Redirecționarea către o zonă de disponibilitate este un mecanism de izolare a incidentelor, diferit de fluxul de distribuire a conținutului.

Cache-ul regional edge este un strat de cache plasat între locația edge și origine. Rolul său este să reducă numărul de accesări la origine atunci când conținutul nu este găsit la nivel edge. Unitatea de gestiune care grupează zonele de disponibilitate este regiunea, iar zonele amplasate în rețeaua unui operator de telecomunicații sunt Wavelength Zones — ambele fiind concepte diferite. Cache-ul de pe dispozitivul utilizatorului nu este un mecanism AWS, ci o funcție proprie a browserului sau a sistemului de operare.

O zonă de disponibilitate este o unitate de izolare a incidentelor, amplasată în facilități separate și dotată cu sursă de alimentare și rețea redundante. Dacă resurse cu același rol sunt distribuite în mai multe zone, procesarea poate continua cu resursele rămase chiar dacă una dintre zone se oprește complet. Aceasta este configurația multi-AZ, punctul de plecare al proiectării pentru disponibilitate. Distribuirea din punctul cel mai apropiat este rolul locațiilor edge, locația datelor este un criteriu pentru alegerea regiunii, iar reducerea prețului unitar prin angajament este o chestiune de model de tarifare — niciuna dintre acestea nu este motivul pentru care se separă zonele.

Local Zones este un mecanism care permite rularea aplicațiilor pe infrastructură AWS mai aproape de utilizatorii finali sau de sarcinile de lucru, fiind amplasat în orașe aflate la distanță de regiune. Seamănă cu locațiile edge prin faptul că se ocupă de „apropierea”, dar diferența este că aici se rulează efectiv aplicația, nu doar un cache pentru distribuirea conținutului. Izolarea incidentelor în interiorul unei regiuni este rolul zonelor de disponibilitate, punctele dedicate distribuirii sunt locațiile edge, iar cache-ul intermediar de dinaintea originii este cache-ul regional edge.

Wavelength Zones sunt zone amplasate în interiorul rețelei unui operator de telecomunicații. La fel ca Local Zones, sunt un mecanism pentru rularea efectivă a aplicațiilor aproape de utilizatori, cu un scop diferit de locațiile edge, care sunt puncte de cache pentru distribuirea conținutului. Ceea ce este amplasat între locația edge și origine este cache-ul regional edge, unitatea de izolare a incidentelor dintr-o regiune este zona de disponibilitate, iar împărțirea intervalelor de adrese IP dintr-un VPC este subrețeaua (subnet).

Deoarece o zonă de disponibilitate este o unitate de izolare a incidentelor amplasată în facilități separate, pentru a face față unui incident care afectează întreaga zonă este necesar să se dispună resursele pe mai multe zone. Fiecare regiune este formată din cel puțin trei zone independente, deci distribuirea în mai multe zone din aceeași regiune este posibilă. Adăugarea mai multor servere în aceeași zonă nu îndeplinește cerința, deoarece toate ar cădea odată cu zona respectivă. CloudFront este un mecanism care accelerează distribuirea, dar dacă originea se oprește, procesarea dinamică nu poate continua. Schimbarea planului de tarifare ține de costuri și nu are legătură cu disponibilitatea.