Mettetevi comodi e tenete un account break-glass a portata di mano: si comincia!<\/p>\n\n\n\n
Non c\u2019\u00e8 via d\u2019uscita<\/h2>\n\n\n\n![\"\u201cNon](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2026\/10\/infra_incubo-5-1024x576.jpg\")
\u201cNon si pu\u00f2 uscire da qui!”
Worth, Cube (1997)<\/figcaption><\/figure>\n<\/div>\n\n\nIn Cube<\/em>, alcune persone si risvegliano in un labirinto di stanze, dove ogni porta sembra un’uscita (ma non lo \u00e8). La nostra storia inizia in modo analogo: un’AWS Organization bloccata, senza possibilit\u00e0 di accedervi da nessuna porta.<\/p>\n\n\n\nIn questo caso, tutte le scelte erano corrette: IAM Identity Center federato con Microsoft Entra ID, per consentire alle persone di accedere con la propria identit\u00e0 aziendale e ottenere i permission set corretti. <\/p>\n\n\n\n
N\u00e9 il root user n\u00e9 il management account erano in uso, ed \u00e8 stato creato anche un utente breaking-glass con un hardware MFA token, nel caso in cui un giorno fosse necessario.<\/p>\n\n\n\n
Un giorno \u00e8 scaduto il certificato della federation perch\u00e9 nessuno controllava la mailbox con gli avvisi della health dashboard, e nessuno aveva impostato un allarme sulla scadenza, quindi una mattina la federation ha semplicemente smesso di funzionare e nessun poteva accedere, rendendo quindi necessario mettere in pratica la teoria. La porta di accesso normale non esisteva pi\u00f9.<\/p>\n\n\n\n
La prima scelta \u00e8 stata utilizzare il root user del management account, scoprendo che porta era bloccata, a causa della two factor legata a un numero di telefono gestito centralino VoIP, dismesso all’inizio di quello stesso anno. I codici che sarebbero dovuti arrivare da qualche parte non sarebbero mai potuti arrivare.<\/p>\n\n\n\n
Restava l’opzione dell’utente breaking-glass: le credenziali erano salvate nel password manager aziendale. L’unico problema era che la persona che aveva l\u2019unico token fisico per il secondo fattore era in vacanza, ed il token era rimasto a casa, separato da un costoso volo di 10 ore per rientrare, con nessun altra persona che potesse accedervi. <\/p>\n\n\n\n
Risultato: circa una settimana senza accessi fuori. Business e servizi hanno continuato a funzionare normalmente e, per fortuna, in quel periodo non ci sono stati incidenti n\u00e9 downtime.<\/p>\n\n\n\n
Per favore, non pensate che “la federation \u00e8 sbagliata”: occorre tenere presente che il percorso di recovery fa parte del design di una landing zone. Inoltre, una email non \u00e8 un sistema valido di monitoring per i certificati in scadenza, e non occorre dipendere da una sola persona o da sistemi esterni per l’MFA. <\/p>\n\n\n\n
E, per favore, testate il percorso di recovery,, come dovreste fare con i backup (lo state facendo, giusto?), perch\u00e9 un restore riuscito \u00e8 l’unica prova che tutto andr\u00e0 bene quando ne avrete bisogno.<\/p>\n\n\n\n
Nel film, Worth aveva ragione su una cosa: se non progettate una via d’uscita, da qui non si esce.<\/p>\n\n\n\n
Non si ferma<\/h2>\n\n\n\n![\"\u201cMi](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2026\/10\/infra_incubo-1024x576.jpg\")
\u201cMi dispiace\u2026 non si fermer\u00e0”
Samara, The Ring (2002)<\/figcaption><\/figure>\n<\/div>\n\n\nLa storia la ricordate: la videocassetta deve continuare a circolare, e se la guardate, l’unico modo per sopravvivere \u00e8 farne una copia e passarla a qualcun altro.<\/p>\n\n\n\n
Ci siamo trovati ad analizzare un’integrazione tra una software house e un sistema di terze parti; sulla carta era un pattern classico: i sistemi si scambiavano messaggi su un bus, con dei webhook a chiudere il cerchio a elaborazione terminata; insomma un caso da manuale di comunicazione asincrona, di cui tutti erano contenti.<\/p>\n\n\n\n
Dopo qualche tempo, si \u00e8 scoperto che il lavoro svolto dal sistema di terze parti era questo: <\/p>\n\n\n\n
\n- ricevere un messaggio<\/li>\n\n\n\n
- rimandare lo stesso messaggio all’endpoint del webhook<\/li>\n\n\n\n
- riscrivere lo stesso payload sullo stesso bus.<\/li>\n<\/ul>\n\n\n\n
Non c\u2019era essuna trasformazione utile e nessuna modifica che significasse “fatto”, ma solo un’altra copia.<\/p>\n\n\n\n
Come per la videocassetta, ricevere il messaggio voleva dire pubblicarlo di nuovo. L’integrazione sembrava lavorare a pieno regime, ma in realt\u00e0 si stava solo tenendo in vita da sola.<\/p>\n\n\n\n
Abbiamo scoperto il loop durante una sessione di debug, perch\u00e9 a causa sua alcuni messaggi venivano persi.<\/p>\n\n\n\n
Attenti ai loop (come diceva la canzone di Lucio Dalla): per evitarli potete usare una chiave per tracciare i messaggi, impostare un TTL o applicare qualsiasi altra tecnica utile a identificare i messaggi duplicati e prevenire i loop. <\/p>\n\n\n\n
Pu\u00f2 sembrare ovvio, ma tenete anche una dead-letter queue monitorata (le vostre DLQ le monitorate, vero?).<\/p>\n\n\n\n
In The Ring<\/em> la maledizione continua ogni volta che qualcuno copia la VHS; la versione cloud \u00e8 pi\u00f9 silenziosa, ma si traduce in costi da paura!<\/p>\n\n\n\nCento Tabelle<\/h2>\n\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2026\/10\/infra_incubo-3-1024x576.jpg\")
<\/figure>\n\n\n\nQuesta storia non ha bisogno di una citazione d’apertura: il billing fa gi\u00e0 abbastanza paura da solo!<\/p>\n\n\n\n
Un\u2019azienda voleva modernizzare la sua applicazione CRUD legacy con l\u2019’obiettivo di passare a serverless per ridurre al minimo il lavoro dovuto alle operations, per cui hanno iniziato a guardare a DynamoDB con fiducia e speranza, per il fatto che \u00e8 gestito, scalabile e con un modello pay-as-you-go, senza un costo fisso per il database. <\/p>\n\n\n\n
Il team di sviluppo, per\u00f2, ha mantenuto il vecchio modello relazionale quasi invariato, forse condizionato da anni di conoscenza del dominio applicativo e dalla conoscenza del prodotto sviluppato. In men che non si dica sono comparse cento tabelle DynamoDB: una per entit\u00e0, regolate dalle stesse join gi\u00e0 presenti.<\/p>\n\n\n\n
Anche i pattern di accesso pattern sono rimasti simili a SQL, comportando quindi tante operazioni di Scan e filtrando i dati solo dopo averli gi\u00e0 letti.<\/p>\n\n\n\n
Nell’ambiente di staging andava tutto bene, ma sappiamo che in produzione i dati crescono, e con loro problemi e costi. Dato che ogni richiesta leggeva pi\u00f9 dati del necessario, a fine mese DynamoDB ha avuto un impatto sul billing di circa 13.000$.<\/strong><\/p>\n\n\n\nTendiamo sempre a usare la nuova tecnologia che ci piace per qualsiasi cosa, siamo esseri umani e spesso e volentieri quando scopriamo qualcosa di nuovo lo vogliamo usare da subito. <\/p>\n\n\n\n
\u00c8 successa la stessa cosa al team con DynamoDB: hanno iniziato a usarlo ovunque, senza accorgersi di usare un key-value store come un motore relazionale, con tutti gli svantaggi che questo approccio comporta.<\/p>\n\n\n\n
Visto che \u00e8 Halloween, una storia simile la troviamo in Gremlins<\/em>: in questo caso c\u2019erano delle regole per i Mogwai, come tenerli lontani dalla luce, non bagnarli e non dargli mai da mangiare dopo mezzanotte. <\/p>\n\n\n\nDynamoDB ha regole diverse, ma se le infrangete vi ritroverete un gremlin nel billing: \u00e8 la scelta migliore se progettate le tabelle in base alle query che vi servono, senza adattarlo al diagramma ER che avete gi\u00e0. Se dovete eseguire query relazionali, meglio usare RDS o Aurora (e ricordate che esiste anche Aurora Serverless). Se per leggere i dati vi affidate agli scan, il vostro tenero animaletto serverless crescer\u00e0 fino a diventare una fattura con i denti affilati per cibarsi del budget annuale.<\/p>\n\n\n\n
Indossate gli occhiali<\/h2>\n\n\n\n![\"\n\u201cMetti](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2026\/10\/infra_incubo4-1024x576.jpg\")
\u201cMetti gli occhiali!”
Nada, Essi vivono (1988)
<\/figcaption><\/figure>\n<\/div>\n\n\nNel film di john Carpenter basta indossare un paio di occhiali per scoprire che le etichette ufficiali mentivano ed avevano un significato nascosto. Nel nostro caso, non erano scritte, ma dati.<\/p>\n\n\n\n
Un team sales aveva bisogno di codici di classificazione settoriale per le aziende presenti nel loro CRM. I codici erano utilizzati per decidere quali proposte mandare ai lead, e per il progetto era stato quindi utilizzato un noto servizio di terze parti per ottenere i codici di classificazione. Sulla carta \u00e8 una mossa ragionevole: il vendor promette di avere conoscenza completa del mercato, cos\u00ec il feed \u00e8 diventato la fonte di verit\u00e0 per la classificazione: nessuno metteva in discussione una classificazione precisa e a pagamento.<\/p>\n\n\n\n
Ogni tanto, per\u00f2, dei controlli a campione non erano corretti: una software house risultava un fornitore di cucine industriali, un’altra sembrava a posto finch\u00e9 qualcuno non leggeva la pagina “Chi siamo”.La lista di aziende lunga, e la maggior parte delle righe non era ovviamente mai stata verificata, portando a dubbi e incertezze, e un controllo manuale avrebbe richiesto tempi troppo lunghi. <\/p>\n\n\n\n
Per risolvere il problema abbiamo pensato di usare l’AI, costruendo un sistema RAG che consultasse la tassonomia ufficiale e i dati pubblici di ogni azienda (nome, sito, breve descrizione) per proporre un codice basato sui dati dell’azienda, da confrontare poi con quello del vendor.<\/p>\n\n\n\n
Abbiamo scoperto che per pi\u00f9 dell’80% delle aziende in lista il codice del vendor era sbagliato, e quello basato sulla presenza pubblica dell’azienda era migliore. <\/p>\n\n\n\n
La parte spaventosa non \u00e8 che l’AI abbia risolto il problema, ma per quanto tempo le risposte sbagliate siano state usate come se corrette.<\/p>\n\n\n\n
Cosa abbiamo imparato? La qualit\u00e0 dei dati conta, ma conta di pi\u00f9 avere un modo per verificarla. Nel nostro caso il feed del vendor sembrava essere una verit\u00e0 assoluta, finch\u00e9 non l’abbiamo confrontato con la realt\u00e0.<\/p>\n\n\n\n
Conclusione<\/h2>\n\n\n\n
Worth, Cube (1997)<\/figcaption><\/figure>\n<\/div>\n\n\n
In Cube<\/em>, alcune persone si risvegliano in un labirinto di stanze, dove ogni porta sembra un’uscita (ma non lo \u00e8). La nostra storia inizia in modo analogo: un’AWS Organization bloccata, senza possibilit\u00e0 di accedervi da nessuna porta.<\/p>\n\n\n\n In questo caso, tutte le scelte erano corrette: IAM Identity Center federato con Microsoft Entra ID, per consentire alle persone di accedere con la propria identit\u00e0 aziendale e ottenere i permission set corretti. <\/p>\n\n\n\n N\u00e9 il root user n\u00e9 il management account erano in uso, ed \u00e8 stato creato anche un utente breaking-glass con un hardware MFA token, nel caso in cui un giorno fosse necessario.<\/p>\n\n\n\n Un giorno \u00e8 scaduto il certificato della federation perch\u00e9 nessuno controllava la mailbox con gli avvisi della health dashboard, e nessuno aveva impostato un allarme sulla scadenza, quindi una mattina la federation ha semplicemente smesso di funzionare e nessun poteva accedere, rendendo quindi necessario mettere in pratica la teoria. La porta di accesso normale non esisteva pi\u00f9.<\/p>\n\n\n\n La prima scelta \u00e8 stata utilizzare il root user del management account, scoprendo che porta era bloccata, a causa della two factor legata a un numero di telefono gestito centralino VoIP, dismesso all’inizio di quello stesso anno. I codici che sarebbero dovuti arrivare da qualche parte non sarebbero mai potuti arrivare.<\/p>\n\n\n\n Restava l’opzione dell’utente breaking-glass: le credenziali erano salvate nel password manager aziendale. L’unico problema era che la persona che aveva l\u2019unico token fisico per il secondo fattore era in vacanza, ed il token era rimasto a casa, separato da un costoso volo di 10 ore per rientrare, con nessun altra persona che potesse accedervi. <\/p>\n\n\n\n Risultato: circa una settimana senza accessi fuori. Business e servizi hanno continuato a funzionare normalmente e, per fortuna, in quel periodo non ci sono stati incidenti n\u00e9 downtime.<\/p>\n\n\n\n Per favore, non pensate che “la federation \u00e8 sbagliata”: occorre tenere presente che il percorso di recovery fa parte del design di una landing zone. Inoltre, una email non \u00e8 un sistema valido di monitoring per i certificati in scadenza, e non occorre dipendere da una sola persona o da sistemi esterni per l’MFA. <\/p>\n\n\n\n E, per favore, testate il percorso di recovery,, come dovreste fare con i backup (lo state facendo, giusto?), perch\u00e9 un restore riuscito \u00e8 l’unica prova che tutto andr\u00e0 bene quando ne avrete bisogno.<\/p>\n\n\n\n Nel film, Worth aveva ragione su una cosa: se non progettate una via d’uscita, da qui non si esce.<\/p>\n\n\n\n La storia la ricordate: la videocassetta deve continuare a circolare, e se la guardate, l’unico modo per sopravvivere \u00e8 farne una copia e passarla a qualcun altro.<\/p>\n\n\n\n Ci siamo trovati ad analizzare un’integrazione tra una software house e un sistema di terze parti; sulla carta era un pattern classico: i sistemi si scambiavano messaggi su un bus, con dei webhook a chiudere il cerchio a elaborazione terminata; insomma un caso da manuale di comunicazione asincrona, di cui tutti erano contenti.<\/p>\n\n\n\n Dopo qualche tempo, si \u00e8 scoperto che il lavoro svolto dal sistema di terze parti era questo: <\/p>\n\n\n\n Non c\u2019era essuna trasformazione utile e nessuna modifica che significasse “fatto”, ma solo un’altra copia.<\/p>\n\n\n\n Come per la videocassetta, ricevere il messaggio voleva dire pubblicarlo di nuovo. L’integrazione sembrava lavorare a pieno regime, ma in realt\u00e0 si stava solo tenendo in vita da sola.<\/p>\n\n\n\n Abbiamo scoperto il loop durante una sessione di debug, perch\u00e9 a causa sua alcuni messaggi venivano persi.<\/p>\n\n\n\n Attenti ai loop (come diceva la canzone di Lucio Dalla): per evitarli potete usare una chiave per tracciare i messaggi, impostare un TTL o applicare qualsiasi altra tecnica utile a identificare i messaggi duplicati e prevenire i loop. <\/p>\n\n\n\n Pu\u00f2 sembrare ovvio, ma tenete anche una dead-letter queue monitorata (le vostre DLQ le monitorate, vero?).<\/p>\n\n\n\n In The Ring<\/em> la maledizione continua ogni volta che qualcuno copia la VHS; la versione cloud \u00e8 pi\u00f9 silenziosa, ma si traduce in costi da paura!<\/p>\n\n\n\n Questa storia non ha bisogno di una citazione d’apertura: il billing fa gi\u00e0 abbastanza paura da solo!<\/p>\n\n\n\n Un\u2019azienda voleva modernizzare la sua applicazione CRUD legacy con l\u2019’obiettivo di passare a serverless per ridurre al minimo il lavoro dovuto alle operations, per cui hanno iniziato a guardare a DynamoDB con fiducia e speranza, per il fatto che \u00e8 gestito, scalabile e con un modello pay-as-you-go, senza un costo fisso per il database. <\/p>\n\n\n\n Il team di sviluppo, per\u00f2, ha mantenuto il vecchio modello relazionale quasi invariato, forse condizionato da anni di conoscenza del dominio applicativo e dalla conoscenza del prodotto sviluppato. In men che non si dica sono comparse cento tabelle DynamoDB: una per entit\u00e0, regolate dalle stesse join gi\u00e0 presenti.<\/p>\n\n\n\n Anche i pattern di accesso pattern sono rimasti simili a SQL, comportando quindi tante operazioni di Scan e filtrando i dati solo dopo averli gi\u00e0 letti.<\/p>\n\n\n\n Nell’ambiente di staging andava tutto bene, ma sappiamo che in produzione i dati crescono, e con loro problemi e costi. Dato che ogni richiesta leggeva pi\u00f9 dati del necessario, a fine mese DynamoDB ha avuto un impatto sul billing di circa 13.000$.<\/strong><\/p>\n\n\n\n Tendiamo sempre a usare la nuova tecnologia che ci piace per qualsiasi cosa, siamo esseri umani e spesso e volentieri quando scopriamo qualcosa di nuovo lo vogliamo usare da subito. <\/p>\n\n\n\n \u00c8 successa la stessa cosa al team con DynamoDB: hanno iniziato a usarlo ovunque, senza accorgersi di usare un key-value store come un motore relazionale, con tutti gli svantaggi che questo approccio comporta.<\/p>\n\n\n\n Visto che \u00e8 Halloween, una storia simile la troviamo in Gremlins<\/em>: in questo caso c\u2019erano delle regole per i Mogwai, come tenerli lontani dalla luce, non bagnarli e non dargli mai da mangiare dopo mezzanotte. <\/p>\n\n\n\n DynamoDB ha regole diverse, ma se le infrangete vi ritroverete un gremlin nel billing: \u00e8 la scelta migliore se progettate le tabelle in base alle query che vi servono, senza adattarlo al diagramma ER che avete gi\u00e0. Se dovete eseguire query relazionali, meglio usare RDS o Aurora (e ricordate che esiste anche Aurora Serverless). Se per leggere i dati vi affidate agli scan, il vostro tenero animaletto serverless crescer\u00e0 fino a diventare una fattura con i denti affilati per cibarsi del budget annuale.<\/p>\n\n\n\n Nel film di john Carpenter basta indossare un paio di occhiali per scoprire che le etichette ufficiali mentivano ed avevano un significato nascosto. Nel nostro caso, non erano scritte, ma dati.<\/p>\n\n\n\n Un team sales aveva bisogno di codici di classificazione settoriale per le aziende presenti nel loro CRM. I codici erano utilizzati per decidere quali proposte mandare ai lead, e per il progetto era stato quindi utilizzato un noto servizio di terze parti per ottenere i codici di classificazione. Sulla carta \u00e8 una mossa ragionevole: il vendor promette di avere conoscenza completa del mercato, cos\u00ec il feed \u00e8 diventato la fonte di verit\u00e0 per la classificazione: nessuno metteva in discussione una classificazione precisa e a pagamento.<\/p>\n\n\n\n Ogni tanto, per\u00f2, dei controlli a campione non erano corretti: una software house risultava un fornitore di cucine industriali, un’altra sembrava a posto finch\u00e9 qualcuno non leggeva la pagina “Chi siamo”.La lista di aziende lunga, e la maggior parte delle righe non era ovviamente mai stata verificata, portando a dubbi e incertezze, e un controllo manuale avrebbe richiesto tempi troppo lunghi. <\/p>\n\n\n\n Per risolvere il problema abbiamo pensato di usare l’AI, costruendo un sistema RAG che consultasse la tassonomia ufficiale e i dati pubblici di ogni azienda (nome, sito, breve descrizione) per proporre un codice basato sui dati dell’azienda, da confrontare poi con quello del vendor.<\/p>\n\n\n\n Abbiamo scoperto che per pi\u00f9 dell’80% delle aziende in lista il codice del vendor era sbagliato, e quello basato sulla presenza pubblica dell’azienda era migliore. <\/p>\n\n\n\n La parte spaventosa non \u00e8 che l’AI abbia risolto il problema, ma per quanto tempo le risposte sbagliate siano state usate come se corrette.<\/p>\n\n\n\n Cosa abbiamo imparato? La qualit\u00e0 dei dati conta, ma conta di pi\u00f9 avere un modo per verificarla. Nel nostro caso il feed del vendor sembrava essere una verit\u00e0 assoluta, finch\u00e9 non l’abbiamo confrontato con la realt\u00e0.<\/p>\n\n\n\nNon si ferma<\/h2>\n\n\n
Samara, The Ring (2002)<\/figcaption><\/figure>\n<\/div>\n\n\n\n
Cento Tabelle<\/h2>\n\n\n\n
<\/figure>\n\n\n\nIndossate gli occhiali<\/h2>\n\n\n
\u201cMetti gli occhiali!”
Nada, Essi vivono (1988)
<\/figcaption><\/figure>\n<\/div>\n\n\nConclusione<\/h2>\n\n\n\n