Quante volte ci \u00e8 capitato di dover risalire ad azioni fatte in un ambiente AWS cercando di ricostruire l\u2019accaduto e capire chi ha fatto cosa? <\/p>\n\n\n\n
E quante volte abbiamo abbandonato l\u2019investigazione senza cavare un ragno dal buco? <\/p>\n\n\n\n
Molti di voi si saranno gi\u00e0 visti in questa situazione, soprattutto coloro che lavorano su account AWS condivisi da team numerosi, o, addirittura, su account AWS dedicati a pi\u00f9 progetti e su cui lavorano pi\u00f9 consulenti esterni.<\/p>\n\n\n\n
In alcuni casi, quando la governance di un ambiente AWS non \u00e8 ben strutturata, bisogna ricorrere a dei metodi alternativi per poter risalire alla root cause di un problema. Per fare questo utilizzeremo uno dei miei servizi preferiti: AWS CloudTrail.<\/p>\n\n\n\n
In questo articolo andremo ad analizzare qual \u00e8 il setup tipico di AWS CloudTrail in un account\/organization AWS, quali sono alcuni problemi tipici che potremmo incontrare nell\u2019utilizzo quotidiano, e quali sono gli accorgimenti da prendere per poter facilitare il lavoro e superare i limiti di un setup standard.<\/p>\n\n\n\n
Il primo dei problemi pi\u00f9 comuni \u00e8 l\u2019assenza del Trail stesso. <\/p>\n\n\n\n
Capita spesso di dover risalire all\u2019ownership di una particolare risorsa AWS per poter chiedere pi\u00f9 informazioni a riguardo. Purtroppo per\u00f2 capita spesso di non avere alcuna evidenza nei log di AWS CloudTrail perch\u00e9 la risorsa \u00e8 stata creata tempo prima; il servizio, infatti, tiene di default solo lo storico degli ultimi 90 giorni.<\/p>\n\n\n\n
Lesson learned:<\/strong> all\u2019apertura di un account AWS, impostare sempre un Trail per tenere uno storico a lungo termine di tutte le attivit\u00e0 nell\u2019account.<\/em><\/p>\n\n\n\n
Secondo le best practice di AWS Cloudtrail, dovremmo attivare un Trail e predisporre un Bucket S3 per lo storage a lungo termine.<\/p>\n\n\n\n
D\u2019altro canto, secondo le best practice di Amazon S3 dovremmo anche prevedere delle lifecycle policy per variare le storage class gli oggetti memorizzati in base all\u2019utilizzo che ne facciamo.<\/p>\n\n\n\n
Per punti bonus possiamo anche creare una tabella Amazon Athena con lo schema di default suggerito da AWS per poter fare query pi\u00f9 comodamente.<\/p>\n\n\n\n
Capita di voler investigare su un\u2019azione accaduta in un particolare giorno; andiamo quindi a effettuare una query filtrando per quello specifico arco temporale e\u2026. scopriamo che la query non presenta nessun risultato.<\/p>\n\n\n\n
“Strano\u2026<\/em>”\u00a0 \u2013 average DevOps<\/p>\n\n\n\n
Un occhio poco attento pu\u00f2 trarre conclusioni affrettate riguardo all\u2019assenza del dato cercato. Ma se andassimo a controllare i log direttamente nel bucket S3, vedremmo invece che quel dato esiste: i file sono stati messi nel tier Glacier Flexible Retrieval.<\/p>\n\n\n\n
Lesson learned:<\/strong> una query su una tabella Athena di default ignora tutti gli oggetti in S3 Glacier Flexible Retrieval e in S3 Glacier Deep Archive. Athena \u00e8 in grado di effettuare query su questi file ma \u00e8 necessario prima abilitare questa opzione<\/a> per la specifica tabella che si vuole interrogare.<\/em><\/p>\n\n\n\n
Spesso cerchiamo delle azioni su particolari servizi di AWS (ad esempio IAM, Route53, ecc.), ma non troviamo niente. <\/p>\n\n\n\n
Perch\u00e8? <\/p>\n\n\n\n
Eppure abbiamo abilitato il Trail come da best practice. <\/p>\n\n\n\n
Alcune azioni vengono tracciate solo nella region North Virginia perch\u00e8 relative a servizi global;<\/em> \u00e8 il caso ad esempio di modifiche ai record Route53, creazione di IAM Roles, creazione di CloudFront Distributions, ecc…<\/p>\n\n\n\n
Lesson learned:<\/strong> creare il Trail con la feature multi-region abilitata e ricordarsi che i servizi AWS globali sono loggati in North Virginia.<\/em><\/p>\n\n\n\n
La risposta \u00e8 il partitioning. <\/p>\n\n\n\n
L\u2019alberatura usata da CloudTrail per memorizzare i log su S3 \u00e8:<\/p>\n\n\n\n
s3:\/\/<bucket-name>\/<optional-prefix>\/AWSLogs\/<account-id>\/CloudTrail\/<region>\/<year>\/<month>\/<day>\/<log-file>.json.gz<\/code><\/pre>\n\n\n\nquindi \u00e8 gi\u00e0 ben strutturata, ma questo non basta; per eseguire query in modo efficiente dobbiamo partizionare i dati anche su Athena e abbiamo due opzioni per farlo:<\/p>\n\n\n\n
1. Definire le partizioni in modo manuale<\/a> con `ALTER TABLE ADD PARTITION`<\/p>\n\n\n\n
2. Usare la partition projection<\/a><\/p>\n\n\n\n
Conlusione<\/h2>\n\n\n\n
Abbiamo visto alcune peculiarit\u00e0 e dettagli poco noti del servizio AWS CloudTrail e dei servizi annessi Amazon S3 e Amazon Athena. Abbiamo imparato che, in alcuni casi, le impostazioni delle lifecycle policy di S3 ci possono intralciare nell\u2019utilizzo quotidiano e che dobbiamo bilanciare i costi e la data availability. Abbiamo visto che, grazie all\u2019utilizzo delle partizioni, \u00e8 possibile ottimizzare le query su Athena per avere pi\u00f9 performance con poco effort di gestione.<\/p>\n\n\n\n
Eravate a conoscenza di questi aspetti? <\/p>\n\n\n\n
Vi siete scontrati con altri limiti o – speriamo – con ulteriori best practices?<\/p>\n\n\n\n
Fatecelo sapere! <\/p>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n
Proud2beCloud \u00e8 il blog di beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all’avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n","protected":false},"excerpt":{"rendered":"