Cum să construiți de fapt o arhitectură cloud AWS sigură și fiabilă fără să vă pierdeți mințile

Introducere

Dacă ați încercat vreodată să concepeți de la zero o arhitectură cloud în AWS, probabil că știți deja: este vorba în egală măsură de libertate și haos. Există o mie de moduri de a construi ceva și la fel de multe moduri de a o da în bară.

O scurtă privire asupra documentației AWS vă poate face să vă gândiți: "Super, vom respecta pur și simplu practicile de primă clasă". Dar în medii reale-internaționale, practicile de primă mână nu trăiesc adesea la primul contact cu nevoile reale ale întreprinderii comerciale, limitele gamei de prețuri sau eroarea umană. De aceea, colaborarea timpurie cu profesioniști precum perfsys poate preveni riscul de a se confrunta ulterior cu lacune de protecție și complicații de scalare.

Scopul nu este doar de a obține ceva care rulează. Este vorba de a construi un sistem care să nu se prăbușească atunci când traficul crește brusc sau când o regiune nu mai funcționează - și care să nu lase ușa din față larg deschisă internetului.

Să începem cu ceea ce este evident: AWS este o bestie

Puteți construi practic orice cu AWS. De la startup-uri cu două persoane la platforme de întreprindere, toate elementele de bază sunt disponibile - EC2, Lambda, RDS, S3, IAM, VPC-uri, lista continuă. Șmecheria? Cu cât aveți mai multe opțiuni, cu atât este mai ușor să creați o încurcătură.

Nu este vorba că AWS este prost conceput. Doar că trebuie să îl proiectați corespunzător. În caz contrar, veți ajunge la ceea ce unele echipe numesc "spaghete în cloud": servicii interdependente, secrete codificate, fără etichetare, fără logare și absolut nicio idee despre ce costă și cât costă.

Fiabilitatea și securitatea nu sunt lucruri de preț

Este tentant să tratăm securitatea și fiabilitatea ca pe o problemă a viitorului. "Îl vom securiza după ce intrăm în funcțiune". "Vom adăuga monitorizarea în următorul sprint". Dar întrebați pe oricine care a avut de-a face cu o încălcare a securității datelor sau cu o întrerupere de mai multe ore - dacă săriți peste acești pași, veți ajunge să vă petreceți nopțile.

Ce înseamnă cu adevărat fiabilitatea

Nu este vorba despre garanțiile de timp de funcționare pe un pachet de diapozitive. Este vorba despre inginerie pentru eșec. Serviciile nu funcționează. Discurile cedează. API-urile expiră. Ceea ce contează este dacă sistemul dvs. continuă să funcționeze atunci când lucrurile se defectează.

Aveți redundanță între zonele de disponibilitate? Sistemul dvs. poate tolera un nod de bază de date defect fără să piardă date sau să producă erori? Executați sarcini de lucru critice într-o singură regiune pentru că "așa a fost cel mai ușor de implementat"? Acestea sunt întrebările care separă sistemele funcționale de cele reziliente.

Și securitatea? Nu este vorba doar de IAM

Da, gestionarea identității și a accesului (IAM) este primul zid. Dar securitatea se extinde mult dincolo de acesta. Bucket-uri S3 accesibile publicului. Roluri suprapermise. Secretele codate în funcții Lambda. Înregistrarea dezactivată "pentru a reduce costurile". Toate acestea sunt bombe cu ceas.

Utilizarea cadrului aws well architected poate ajuta la identificarea acestor probleme înainte ca ele să explodeze. Acesta împarte arhitectura în cinci domenii cheie - securitate, fiabilitate, excelență operațională, eficiență a performanței și optimizarea costurilor - și obligă echipele să le evalueze pe fiecare, în mod onest. Nu este un glonț de argint, dar vă împinge să puneți întrebări dificile.

Elementele de bază care contează cu adevărat

În regulă, să trecem la subiect. Iată ce contează atunci când construiți o arhitectură sigură și fiabilă pe AWS - și unde greșesc cel mai adesea echipele.

Utilizați rolurile IAM în mod corect (da, într-adevăr)

Rolurile IAM sunt puternice. Prea puternice, uneori. Este mult prea ușor să aplicați "AdministratorAccess" pentru că ceva nu funcționează, să promiteți că veți rezolva problema mai târziu... și apoi să nu o rezolvați niciodată.

Trebuie să blocați acest lucru din timp. Principiul privilegiului minim nu este doar o bună practică - este singura modalitate sănătoasă de operare. Asta înseamnă:

• Roluri delimitate pe serviciu

• Evitarea caracterelor wildcard în permisiuni

• Acreditări de scurtă durată

• MFA obligatoriu pentru utilizatorii umani

Sună ca o durere? Este. Dar la fel este și să îi explici șefului tău de ce cineva a exfiltrat date despre clienți de la un Lambda configurat greșit.

Separă-ți rețeaua ca și cum ai fi serios

Acesta este un alt domeniu în care scurtăturile se întorc împotriva ta. Nu aveți nevoie de o configurație de rețea foarte complexă, dar câteva elemente de bază sunt foarte utile:

• Subrețele publice numai pentru lucrurile care trebuie să aibă acces la internet (de exemplu, ALB)

• subrețele private pentru toate celelalte

• gateway-uri NAT pentru accesul controlat la ieșire

• puncte finale VPC pentru traficul de servicii AWS fără a atinge internetul public

Un VPC plat cu totul pe aceeași subrețea poate părea ușor. Până când ceva se strică și ia totul cu el.

Înregistrare și monitorizare: Nu puteți repara ceea ce nu puteți vedea

Acest lucru nici nu ar trebui să mai fie supus dezbaterii. Înregistrarea nu este opțională. Dacă nu capturați CloudTrail, metrici CloudWatch și jurnale de flux VPC, sunteți orbi.

Dar iată care este șmecheria - logarea singură nu este suficientă. Trebuie să vă uitați efectiv la jurnale. Creați alerte pentru lucrurile care contează. Filtrați zgomotul. Și asigurați-vă că jurnalele sunt centralizate în toate conturile și regiunile. Vizibilitatea fragmentată nu înseamnă vizibilitate.

Criptați totul (fără excepții)

Utilizați KMS pentru datele aflate în repaus. Utilizați TLS pentru datele în tranzit. Rotiți cheile. Monitorizați accesul. Acesta este unul dintre acele domenii în care a fi leneș acum devine foarte costisitor mai târziu.

Și nu uitați de lucruri precum criptarea RDS, setările volumelor EBS și aplicarea TLS pentru API Gateway. Aceste mici detalii se adună.

Infrastructură ca cod sau eșec

Încă mai implementați făcând clic pe consola AWS? Este bine pentru dezvoltare, dar periculos pentru producție.

Utilizați Terraform, CloudFormation sau CDK. Indiferent ce preferă echipa ta - alege una și rămâi la ea. Controlează-ți versiunea șabloanelor. Utilizați CI/CD pentru implementare. Automatizați rollback-urile. Implementările manuale sunt o invitație deschisă la greșeli.

De asemenea: etichetați totul. Resursele fără etichete sunt precum cablurile fără etichete - nimeni nu știe la ce folosesc și tuturor le este teamă să le atingă.

Scalare fără scufundare

Să fim clari: AWS adoră când vă supraaprovizionați. Tu obții "performanță", ei îți primesc banii. Scalarea eficientă înseamnă să vă cunoașteți tiparele - și să le planificați.

Utilizați grupuri de scalare automată, instanțe punctuale (cu atenție) și straturi de caching. Dar cel mai important: testați sub sarcină. Ultimul lucru pe care îl doriți este să descoperiți că instanța dvs. RDS se topește sub traficul real la două zile după lansare.

De asemenea, rezervați capacitate atunci când are sens. Aceasta economisește bani și previne eșecurile surpriză ale provizionării.

Planurile de recuperare în caz de dezastru nu sunt opționale

Ce se întâmplă dacă o regiune nu funcționează? Ce se întâmplă dacă baza de date principală este coruptă? Dacă răspunsul este "uh... am avea probleme", atunci este timpul să vă refaceți strategia de DR.

Aceasta nu înseamnă să construiți o copie identică a infrastructurii dvs. în altă regiune. Înseamnă să știți:

• Ce ați restaura

• Cât timp ar dura

• Ce date ar fi pierdute (dacă este cazul)

• Cine este responsabil pentru ce în timpul unui failover

Și da - trebuie să vă testați planul de recuperare. Altfel, este doar ficțiune.

Anti-patforme comune de evitat

Haideți să expunem rapid câteva "nu-nu" care apar mult prea des:

• Un singur cont mare pentru toate: utilizați AWS Organizations. Separați prod, dev, staging etc.

• Lăsarea neatinsă a VPC-urilor implicite și a grupurilor de securitate: blocați-le.

• Bazarea excesivă pe instanțele t2.micro "pentru testare" - acestea vor ajunge în cele din urmă în prod.

• Nebugetarea costurilor CloudWatch: da, logarea costă bani. Lipsa logării costă mai mult.

• Acordarea accesului la "reparații rapide": reparați-vă mai degrabă procesul.

Ultimele cuvinte? Rămâneți flexibili, rămâneți sănătoși

Arhitectura cloud nu înseamnă să găsești configurația perfectă. Este vorba despre a construi ceva care să fie flexibil, robust și ușor de înțeles de mai mulți decât persoana care l-a scris.

Niciodată nu sunteți cu adevărat "gata" - și asta este în regulă. Ceea ce contează este să fii intenționat. Să puneți întrebări dificile din timp. Auditarea frecventă. Automatizarea acolo unde contează. Și să știți când să apelați la ajutor.

Pentru că, să fim sinceri - AWS este puternic, dar este și ușor să te pierzi în el. Colaborarea cu ingineri experimentați care trăiesc și respiră arhitectura cloud poate face diferența între "funcționează, în mare parte" și "dormim noaptea".

Și pentru asta merită să construiți.