Come costruire un'architettura cloud AWS sicura e affidabile senza perdere la testa?

Introduzione

Se avete mai provato a progettare da zero un'architettura cloud in AWS, probabilmente lo sapete già: si tratta di una libertà e di un caos in parti uguali. Ci sono mille modi per costruire qualcosa e altrettanti per sbagliare.

Una breve occhiata alla documentazione di AWS potrebbe farvi pensare: "Bene, ci limiteremo a osservare le pratiche di prima qualità". Ma negli ambienti reali, le pratiche di prima qualità non sono spesso a contatto con le reali esigenze delle imprese commerciali, con i limiti di prezzo o con l'errore umano. Ecco perché affidarsi a professionisti come perfsys fin dall'inizio può evitare di giocare a briscola con le falle di protezione e le complicazioni di scalabilità in un secondo momento.

L'obiettivo non è solo ottenere qualcosa che funzioni. Si tratta di costruire un sistema che non crolli quando il traffico aumenta o una regione si spegne, e che non lasci la porta d'ingresso spalancata a Internet.

Partiamo dall'ovvio: AWS è una bestia

Con AWS si può costruire praticamente tutto. Dalle startup di due persone alle grandi piattaforme aziendali, gli elementi costitutivi sono tutti lì: EC2, Lambda, RDS, S3, IAM, VPC, l'elenco continua. Il problema? Più opzioni si hanno a disposizione, più è facile creare un groviglio.

Non è che AWS sia progettato male. È solo che bisogna progettarlo correttamente. Altrimenti, ci si ritrova con quelli che alcuni team chiamano "spaghetti del cloud": servizi interdipendenti, segreti codificati, nessun tagging, nessun logging e assolutamente nessuna idea di cosa costi quanto.

L'affidabilità e la sicurezza non sono un optional

Si è tentati di trattare la sicurezza e l'affidabilità come problemi del futuro. "Lo metteremo in sicurezza dopo la messa in funzione". "Aggiungeremo il monitoraggio nel prossimo sprint". Ma chiedete a chiunque abbia avuto a che fare con una violazione dei dati o con un'interruzione di servizio di molte ore: saltando questi passaggi si finisce per fare le notti in bianco.

Cosa significa veramente affidabilità

Non si tratta di garanzie di uptime su una slide. Si tratta di progettare il fallimento. I servizi si guastano. I dischi si guastano. Le API vanno in tilt. L'importante è che il sistema continui a funzionare anche quando le cose si rompono.

Avete una ridondanza tra le zone di disponibilità? Il vostro sistema è in grado di tollerare un nodo di database guasto senza perdere dati o generare errori? I carichi di lavoro critici vengono eseguiti in un'unica regione perché "era più facile da distribuire"? Queste sono le domande che separano i sistemi funzionanti da quelli resilienti.

E la sicurezza? Non è solo IAM

Sì, la gestione dell'identità e degli accessi (IAM) è il primo muro. Ma la sicurezza va ben oltre. Secchi S3 accessibili pubblicamente. Ruoli con permessi eccessivi. Segreti codificati nelle funzioni Lambda. Registrazione disattivata "per risparmiare sui costi". Tutte queste cose sono bombe a orologeria.

L'utilizzo del framework aws well architected può aiutare a identificare questi problemi prima che esplodano. Il framework suddivide l'architettura in cinque aree chiave - sicurezza, affidabilità, eccellenza operativa, efficienza delle prestazioni e ottimizzazione dei costi - e costringe i team a valutarle onestamente. Non è una pallottola d'argento, ma spinge a porsi domande difficili.

Gli elementi costitutivi che contano davvero

Bene, entriamo nel vivo della questione. Ecco cosa conta quando si costruisce un'architettura sicura e affidabile su AWS e dove i team sbagliano più spesso.

Usare i ruoli IAM nel modo giusto (sì, davvero)

I ruoli IAM sono potenti. Troppo potenti, a volte. È fin troppo facile mettere "AdministratorAccess" perché qualcosa non funziona, promettere di risolverlo più tardi... e poi non risolverlo mai.

È necessario bloccarlo in anticipo. Il principio del minimo privilegio non è solo una buona pratica, è l'unico modo sano di operare. Questo significa che:

• Ruoli definiti per ogni servizio

• Evitare i caratteri jolly nei permessi

• Credenziali di breve durata

• MFA obbligatorio per gli utenti umani

Sembra una seccatura? Lo è. Ma lo è anche spiegare al vostro capo perché qualcuno ha esfiltrato i dati dei clienti da un Lambda mal configurato.

Separare la rete come se fosse una cosa seria

Questa è un'altra area in cui le scorciatoie si ritorcono contro. Non è necessaria una configurazione di rete super complessa, ma alcuni elementi di base sono molto utili:

• Sottoreti pubbliche solo per le cose che devono affacciarsi su Internet (ad esempio, gli ALB).

• Subnet private per tutto il resto

• Gateway NAT per l'accesso controllato in uscita

• Endpoint VPC per il traffico dei servizi AWS senza raggiungere la rete Internet pubblica.

Un VPC piatto con tutto sulla stessa subnet può sembrare facile. Finché qualcosa non si rompe e si porta via tutto.

Registrazione e monitoraggio: Non si può riparare ciò che non si vede

Questo punto non dovrebbe più essere oggetto di discussione. La registrazione non è facoltativa. Se non state acquisendo CloudTrail, le metriche di CloudWatch e i log dei flussi VPC, state volando alla cieca.

Ma c'è un problema: la sola registrazione non è sufficiente. È necessario esaminare effettivamente i registri. Creare avvisi per le cose che contano. Filtrare il rumore. E assicurarsi che i registri siano centralizzati tra gli account e le regioni. Una visibilità frammentata non è visibilità.

Crittografate tutto (senza eccezioni)

Utilizzate KMS per i dati a riposo. Usate TLS per i dati in transito. Ruotare le chiavi. Monitorare l'accesso. Questa è una di quelle aree in cui essere pigri ora diventa molto costoso in seguito.

E non dimenticate cose come la crittografia RDS, le impostazioni dei volumi EBS e l'applicazione del TLS al gateway API. Questi piccoli dettagli si accumulano.

Infrastruttura come codice o fallimento

State ancora facendo il deploy cliccando sulla console di AWS? Va bene per il dev, ma è pericoloso per il prod.

Utilizzate Terraform, CloudFormation o CDK. Qualsiasi cosa il vostro team preferisca, sceglietene una e seguitela. Controllate la versione dei vostri modelli. Usare CI/CD per la distribuzione. Automatizzate i rollback. Le distribuzioni manuali sono un invito aperto agli errori.

Inoltre, etichettate tutto. Le risorse senza tag sono come i cavi senza etichette: nessuno sa a cosa servono e tutti hanno paura di toccarli.

Scalare senza affondare

Parliamoci chiaro: AWS adora l'over-provisioning. Voi ottenete le "prestazioni", loro i soldi. Scalare in modo efficiente significa conoscere i propri modelli e pianificarli.

Utilizzate gruppi di autoscaling, istanze spot (con attenzione) e livelli di caching. Ma soprattutto: testate sotto carico. L'ultima cosa che volete è scoprire che la vostra istanza RDS si scioglie sotto il traffico reale due giorni dopo il lancio.

Inoltre, riservate la capacità quando ha senso. Si risparmia denaro e si evitano errori di provisioning a sorpresa.

I piani di disaster recovery non sono facoltativi

Cosa succede se una regione va in tilt? E se il database principale si danneggia? Se la risposta è "ehm... saremmo nei guai", allora è il momento di rivedere la strategia di DR.

Questo non significa costruire una copia identica della vostra infrastruttura in un'altra regione. Significa saperlo:

• Cosa ripristinare

• Quanto tempo ci vorrebbe

• Quali dati andrebbero persi (se ce ne sono)

• Chi è responsabile di cosa durante un failover?

E sì, dovete testare il vostro piano di ripristino. Altrimenti è solo finzione.

Antipattern comuni da evitare

Vediamo rapidamente alcuni no che si presentano troppo spesso:

• Un unico grande account per tutto: utilizzare le Organizzazioni AWS. Separare prod, dev, staging, ecc.

• Lasciare intatti i VPC e i gruppi di sicurezza predefiniti: bloccarli.

• Fare eccessivo affidamento sulle istanze t2.micro "per i test": alla fine finiranno in prod.

• Non prevedere i costi di CloudWatch: sì, il logging costa. Non registrare costa di più.

• Dare accesso al "risolvi subito il problema": correggete invece il vostro processo.

Le ultime parole? Rimanere flessibili, rimanere sani di mente

L'architettura cloud non consiste nel trovare la configurazione perfetta. Si tratta di costruire qualcosa che sia flessibile, robusto e comprensibile da più di una persona che l'ha scritto.

Non si è mai veramente "finito", e va bene così. L'importante è essere intenzionali. Porre domande difficili in anticipo. Fare frequenti verifiche. Automatizzare dove serve. E sapere quando chiedere aiuto.

Perché siamo onesti: AWS è potente, ma è anche facile perdersi. Lavorare con ingegneri esperti che vivono e respirano l'architettura cloud può fare la differenza tra "funziona, per lo più" e "dormiamo la notte".

E per questo vale la pena costruire.