Di recente, per esempio, \u00e8 stata necessaria la creazione all\u2019interno dei nostri account di un ambiente di test nel quale eseguire implementazioni di prova prima del rilascio all’interno dell\u2019organization AWS del cliente. Questa necessit\u00e0 era dovuta alle dimensioni dell’organizzazione: quasi 400 account AWS! Di conseguenza, anche un piccolo errore avrebbe avuto un impatto notevole. Per replicare il loro ambiente, all\u2019interno dei nostri account \u00e8 stata creata una AWS Organization ad hoc con una decina di account e risorse accuratamente selezionate.<\/p>\n\n\n\n
Al termine del lavoro, \u00e8 stato poi necessario chiudere i suddetti account, ma la chiusura di pi\u00f9 account AWS pieni di risorse pu\u00f2 richiedere molto tempo. <\/p>\n\n\n\n
Naturalmente, \u00e8 proprio quando un compito richiede molto tempo che bisogna automatizzare il pi\u00f9 possibile!<\/p>\n\n\n\n
Chiusura di un account AWS<\/h2>\n\n\n\n
Per la chiusura di un account AWS pu\u00f2 sembrare sufficiente premere il pulsante corretto, ma questa azione presenta una serie di accortezze da prendere. Alcune di esse dipendono dalla tipologia dell\u2019account (indipendente o account membro di un’organizzazione AWS); altre sono comuni a entrambi i tipi di account.<\/p>\n\n\n\n
Di seguito un piccolo riassunto dei punti pi\u00f9 importanti a cui prestare attenzione:<\/p>\n\n\n\n
- \n
- L’indirizzo email del root user non pu\u00f2 essere riutilizzato dopo la chiusura dell’account.<\/li>\n\n\n\n
- I domini registrati con Amazon Route 53 non vengono cancellati automaticamente; devono essere trasferiti a un altro registrar o account AWS, oppure si pu\u00f2 disattivare il rinnovo automatico e lasciarli scadere.<\/li>\n\n\n\n
- Se un account AWS viene riaperto durante il periodo di \u201cpost-closure\u201d, potrebbero essere addebitati i costi di tutti i servizi AWS che non sono stati interrotti o delle risorse che non sono state eliminate prima della chiusura.<\/li>\n\n\n\n
- Dopo la chiusura di un account AWS, qualsiasi richiesta di accesso ai servizi AWS dell’account chiuso da parte di altri account AWS fallisce.<\/li>\n\n\n\n
- AWS non elimina le peering connections di Amazon Virtual Private Cloud (Amazon VPC) quando un account che partecipa alla connessione viene chiuso.<\/li>\n<\/ul>\n\n\n\n
Se l’account \u00e8 membro di un’organizzazione AWS, ci sono ancora pi\u00f9 punti che richiedono attenzione:<\/p>\n\n\n\n
- \n
- L’account chiuso viene rimosso dall’organizzazione solo dopo il periodo di \u201cpost-closure\u201d.<\/li>\n\n\n\n
- Solo il 10% degli account membri pu\u00f2 essere chiuso in un periodo di 30 giorni.<\/li>\n\n\n\n
- Nel caso in cui si utilizzi AWS Control Tower, \u00e8 necessario che sia annullata la gestione degli account prima di tentare di chiuderli.<\/li>\n<\/ul>\n\n\n\n
Pertanto, automatizzare il processo di chiusura di un account AWS non \u00e8 un compito semplice. Se gli account sono autonomi, probabilmente significa che sono pochi, quindi la chiusura manuale \u00e8 la scelta migliore, non vale nemmeno la pena di provare ad automatizzarla. Se invece fanno parte di un’organizzazione la storia cambia, ma in questo caso non \u00e8 possibile chiuderne pi\u00f9 del 10% al mese, quindi non \u00e8 comunque molto efficiente.<\/p>\n\n\n\n
La soluzione pi\u00f9 efficiente a questo problema \u00e8 probabilmente quella di riutilizzare gli account per un altro scopo invece di chiuderli, magari cambiando il loro alias. Questi account possono essere ripuliti, inseriti in un’unit\u00e0 organizzativa (OU) specifica e utilizzati per lo sviluppo o i test.<\/p>\n\n\n\n
Eliminazione automatica delle risorse<\/h2>\n\n\n\n
Un’altra problematica comune a entrambi i tipi di account \u00e8: <\/p>\n\n\n\n
“When you close your AWS account, you must terminate all your resources, or you might continue to incur charges\u201d<\/p>\n\n\n\n
ovvero, \u201cquando chiudi il tuo account AWS, devi terminare tutte le tue risorse, altrimenti potresti continuare a subire addebiti”. Questa non \u00e8 certo una bella situazione!<\/p>\n\n\n\n
Spieghiamo meglio questa parte: quando un account AWS viene chiuso, non \u00e8 veramente<\/em> chiuso; si trova nel periodo di \u201cpost-closure\u201d, una finestra di 90 giorni in cui un utente pu\u00f2 ancora accedere all’account, visualizzare le fatture passate, pagare le fatture AWS e… incorrere in spese.<\/p>\n\n\n\n
Quando un account AWS viene chiuso, la fatturazione on-demand delle risorse si interrompe, ma alcune altre fonti di costo non vengono interrotte (ad esempio, gli abbonamenti ad AWS Marketplace). \u00c8 quindi consigliabile eliminare tutte le risorse prima di chiudere l’account.<\/p>\n\n\n\n
Cosa raccomanda AWS<\/h3>\n\n\n\n
AWS consiglia due modi per controllare le risorse attive:<\/p>\n\n\n\n
- \n
- Attraverso la Billing dashboard<\/strong>: controllare nella sezione Bills<\/strong>.<\/li>\n\n\n\n
- Utilizzare il Tag Editor<\/strong> all’interno della pagina Resource Groups <\/strong>nella console, selezionando “Tutte le regioni<\/em>” e “Tutti i tipi di risorse supportate<\/em>“.<\/li>\n<\/ul>\n\n\n\n
Queste sono entrambe soluzioni valide per trovare le risorse attive, ma non viene offerta alcuna soluzione per terminarle automaticamente.<\/p>\n\n\n\n
beSharp-nuke<\/h3>\n\n\n\n
Per risolvere questo problema, abbiamo deciso di implementare una soluzione il pi\u00f9 possibile minimale per cancellare tutte le risorse di uno o pi\u00f9 account AWS.<\/p>\n\n\n\n
Naturalmente, la maggior parte del lavoro \u00e8 gi\u00e0 stata svolta da aws-nuke<\/a>, sviluppato da rebuy; si tratta di un fantastico strumento open-source in grado di eseguire il nuke<\/em> (ovvero l’eliminazione di tutte le risorse) di un account AWS. Utilizzando un file di configurazione YAML \u00e8 possibile filtrare alcune risorse da mantenere e creare una blocklist di account di produzione che non devono mai essere toccati. Purtroppo, per\u00f2, questo software \u00e8 stato progettato per essere eseguito su un singolo account AWS, ma a noi serviva una soluzione per pi\u00f9 account!<\/p>\n\n\n\n
La soluzione finale, riassunta nel diagramma sottostante, \u00e8 piuttosto minimale: un modello CDK contenente solo un Amazon S3 Bucket per memorizzare la configurazione e AWS CodeBuild per l\u2019esecuzione. Durante la fase di “build”, viene analizzata la configurazione alla ricerca degli account di destinazione e viene eseguito aws-nuke, in sequenza, su ogni account.<\/p>\n\n\n\n
<\/p>\n\n\n
\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/08\/image1-1-1024x461.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
Ora, perch\u00e9 scegliere AWS CodeBuild per la parte di \u201ccompute\u201d? Non \u00e8 stata una scelta semplice, ma \u00e8 stato preferito per le sue esigenze minime in termini di risorse e per la sua natura gestita<\/em>. <\/p>\n\n\n\n
Ecco un riepilogo delle opzioni scartate:<\/p>\n\n\n\n
- \n
- AWS Lambda: il timeout di 15 minuti non \u00e8 adatto alla cancellazione di grandi account.<\/li>\n\n\n\n
- Amazon EC2: richiede tempo per l’avvio\/risveglio, inoltre ha bisogno di un VPC; la soluzione deve funzionare con requisiti minimi e non deve dipendere da risorse gi\u00e0 esistenti.<\/li>\n\n\n\n
- Amazon ECS: richiede anch’esso un VPC.<\/li>\n\n\n\n
- AWS Step Function: non risolve il timeout di 15 minuti se usato insieme a Lambda in quanto l’esecuzione di aws-nuke non pu\u00f2 essere suddivisa in pi\u00f9 funzioni. Se usato solo come orchestratore \u00e8 probabilmente eccessivo.<\/li>\n\n\n\n
- AWS Batch: sembra la scelta migliore per attivit\u00e0 lunghe come il nuking di un’intera organizzazione, ma richiede una VPC.<\/li>\n<\/ul>\n\n\n\n
Utilizzo<\/h4>\n\n\n\n
- Utilizzare il Tag Editor<\/strong> all’interno della pagina Resource Groups <\/strong>nella console, selezionando “Tutte le regioni<\/em>” e “Tutti i tipi di risorse supportate<\/em>“.<\/li>\n<\/ul>\n\n\n\n
- Attraverso la Billing dashboard<\/strong>: controllare nella sezione Bills<\/strong>.<\/li>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/08\/image2-1.png\")
<\/figure><\/div>\n\n\n