🌐 Traduzione italiana | Articolo originale: “Just use aws” is starting to sound like bad advice in 2026

Questa è una traduzione automatica realizzata con AI. I contenuti e i diritti appartengono all’autore originale.

Un tempo era la risposta più sicura nel tech. Ora sembra un pilota automatico e, a volte, una trappola.

C’è stato un tempo in cui “usa solo AWS” era il consiglio più responsabile che si potesse dare a uno sviluppatore.

Non figo.
Non intelligente.
Semplicemente sicuro.

Significava che la tua app non sarebbe crollata sotto il traffico reale. Significava che non stavi costruendo infrastrutture critiche su una VPS mantenuta a metà e sulle speranze. All’epoca, “usa solo AWS” era l’equivalente ingegneristico di indossare la cintura di sicurezza.

Da qualche parte lungo la strada, però, le cose sono cambiate silenziosamente.

Ora significa spesso accettare un modello di fatturazione che non capisci appieno, ereditare un labirinto di servizi che non hai richiesto e scambiare la velocità con un’opzionalità di cui potresti non aver mai bisogno. Amazon Web Services è ancora potente, ancora la scelta giusta in molti casi, ma il consiglio in sé non è invecchiato bene.

Se hai mai aperto il Cost Explorer con fiducia e l’hai chiuso con rimpianto, lo sai già.

Questo non è un attacco gratuito. Riguarda come l’industria è cambiata, perché gli sviluppatori si stanno adattando silenziosamente e perché i default che un tempo sembravano sicuri ora meritano un secondo pensiero.

E sì, probabilmente dovremmo parlarne.

Quando “usa solo AWS” aveva davvero senso

C’era una versione della realtà in cui “usa solo AWS” era un consiglio di livello élite.

Non alla moda. Non piccante. Semplicemente corretto.

Allora, Amazon Web Services sembrava un codice trucco che non avresti ancora dovuto avere. Potevi attivare server in pochi minuti. L’archiviazione smetteva di fare paura. I database non richiedevano un rituale da fine settimana e una preghiera per il backup.

Se eri un piccolo team o uno sviluppatore solitario, era ridicolo quanto vantaggio avessi improvvisamente.

EC2 significava che non dovevi supplicare le operations per le macchine.
S3 significava che smettevi di preoccuparti dei dischi pieni.
RDS significava che potevi smettere di fingere che ti piacesse gestire MySQL.

E il modello mentale era semplice. Dolorosamente semplice per gli standard odierni.

Avevi un server.
Eseguiva la tua app.
Se si rompeva, entravi via SSH e lo sistemavi.

Tutto qui.

Nessun grafico delle dipendenze con quindici servizi. Nessuna voce a sorpresa in fattura per “dati spostati tra due cose che pensavi fossero fondamentalmente la stessa cosa”. Nessuna archeologia delle policy IAM. Potevi spiegare la tua intera infrastruttura a un altro sviluppatore su una lavagna senza scusarti a metà strada.

Ricordo ancora il mio primo deploy su EC2. Non perché fosse perfetto, ma perché funzionava. Ho inviato il codice, aggiornato la pagina e il sito era semplicemente… lì. Nessun cerimoniale. Nessuna attesa. Sembrava di aver sbloccato un’abilità di fine gioco troppo presto.

In quel momento, “usa solo AWS” non era un consiglio pigro.
Era un consiglio compassionevole.

Significava: non pensarci troppo. Non costruirti problemi da solo. Pubblica qualcosa di reale.

La cosa fondamentale che dimentichiamo ora è questa: il consiglio corrispondeva all’epoca.

AWS era più semplice. I team erano più grandi. I margini erano più ampi. E il cloud non si era ancora trasformato in un libro-game dove ogni scelta aveva un’implicazione di fatturazione.

Il consiglio non era sbagliato.

Semplicemente non è stato aggiornato da quando il gioco è passato alla modalità difficile.

Cosa è cambiato (e perché importa ora)

A un certo punto, AWS ha smesso di sembrare una cassetta degli attrezzi e ha iniziato a sembrare un albero delle abilità che potresti accidentalmente rovinare.

Non è stato un singolo momento. Non c’è stato un grande annuncio. Nessun post sul blog intitolato “stiamo per rendere tutto questo emotivamente costoso”. Si è semplicemente… accumulato.

I servizi si sono accumulati. Le astrazioni si sono impilate sulle astrazioni. I modelli di prezzo sono stati affettati sempre più sottili finché non stavi più pagando per un server, stavi pagando per dei comportamenti.

Richieste.
Invocazioni.
Dati spostati di cinque centimetri a sinistra.

Sulla carta, Amazon Web Services è più potente che mai. In pratica, quella potenza ora arriva con un sovraccarico cognitivo che non esisteva quando il consiglio originale è stato coniato.

Il primo grande cambiamento è stato la proliferazione dei servizi. AWS non ha solo aggiunto funzionalità, ha aggiunto scelte. Molteplici modi per risolvere lo stesso problema, ognuno con compromessi, limiti e note a piè di pagina leggermente diversi. Vuoi capacità di calcolo? Bene. Scegli tra EC2, ECS, EKS, Lambda, Fargate, Batch, Lightsail… e questo prima ancora di parlare di come interagiscono.

Il secondo cambiamento è stato l’opacità dei prezzi. Non perché AWS nasconda i prezzi, la documentazione è lì, ma perché i prezzi moderni dipendono dal comportamento emergente. Non sai davvero quanto costa qualcosa finché non è in esecuzione sotto carico reale, facendo cose reali, nel mondo reale. A quel punto, congratulazioni, lo stai già pagando.

È qui che il tono del lavoro sull’infrastruttura è cambiato.

Il costo era qualcosa che ottimizzavi dopo il successo. Ora è qualcosa che temi prima del traffico. Le dashboard che una volta erano strumenti di osservabilità si sono trasformate silenziosamente in generatori di ansia. Gli avvisi sui costi sono diventati importanti quanto gli avvisi di uptime, a volte di più.

E poi sono arrivati i carichi di lavoro AI e dati.

Improvvisamente, spostare dati non era raro. Era costante. Improvvisamente, “serverless” non significava solo gestire webhook, significava macinare token, embedding, log, stream, tentativi. Pattern che erano economici su piccola scala hanno iniziato a diventare stranamente costosi in produzione, non perché avessi sbagliato, ma perché il modello era cambiato sotto i tuoi piedi.

Nulla di tutto ciò rende AWS cattivo.

Ma significa che il consiglio originale “usa solo AWS” presuppone una semplicità che non esiste più.

Presuppone che tu stia optando per una quantità nota.
In realtà, stai optando per un sistema che rivela la sua complessità nel tempo.

E questa è la parte su cui nessuno ti avverte.

Il costo nascosto: carico cognitivo e perdita di velocità

La parte su cui nessuno ti avverte non è il conto.

È la tassa cognitiva.

AWS non addebita solo denaro, addebita attenzione. Ogni nuovo servizio che tocchi aggiunge un po’ più di superficie che devi ricordare, su cui ragionare e spiegare al Te Futuro quando qualcosa si rompe per motivi che sembrano personali.

Sulla carta, Amazon Web Services ti dà flessibilità infinita. In pratica, quella flessibilità si manifesta come decisioni per le quali non sapevi di aver firmato. Modelli di rete. Confini dei permessi. Ruoli di esecuzione. Limiti di servizio. Quote che scopri solo colpendole.

Nessuna di queste cose è individualmente terribile. Il problema è l’accumulo.

Ho perso più tempo di quanto voglia ammettere a fare il debug di policy IAM che erano tecnicamente corrette ma emotivamente ostili. Inizi volendo dare a un servizio l’accesso a una cosa, e un’ora dopo sei sepolto sotto tre tab di documentazione, mormorando “perché questo è negato” come se fosse un tradimento personale.

E quel tempo si somma.

Le revisioni dell’infrastruttura iniziano a richiedere più tempo della pianificazione delle funzionalità. Le pull request vengono bloccate non sulla logica, ma sulla configurazione. Esiti a rilasciare piccole modifiche perché non sei del tutto sicuro di quale contatore invisibile potrebbero far girare.

È qui che la velocità fuoriesce silenziosamente.

Non perché AWS sia lento, ma perché pensare ad AWS è lento. Ti trascina fuori dalla modalità prodotto e dentro la modalità operatore di piattaforma, anche quando non hai mai voluto quel lavoro.

Ciò che brucia di più è che nulla di tutto ciò sembra un fallimento. Hai seguito le best practice. Hai scelto l’opzione “sicura”. Eppure, in qualche modo, rilasciare sembra più pesante di quanto dovrebbe.

Questo è il costo nascosto.

Non dollari.
Non tempi di inattività.
Solo la lenta realizzazione che la tua infrastruttura sta occupando più spazio mentale del tuo prodotto reale.

Cosa stanno facendo invece gli sviluppatori (silenziosamente)

Ciò che è interessante è che non c’è stato un esodo di massa.

Nessun post drammatico sui blog. Nessun giro d’onore del tipo “abbiamo cancellato il nostro account AWS e trovato la pace interiore”.

La maggior parte degli sviluppatori si è semplicemente… adattata.

Lo spostamento non è via da Amazon Web Services. È via dal trattarlo come una religione.

Invece di usare AWS come default per tutto, i team hanno iniziato a usarlo chirurgicamente. Un servizio qui. Uno là. Solo dove vale davvero la sua complessità. Tutto il resto? Libera scelta.

Lo vedi nelle decisioni piccole e pratiche. Calcolo in esecuzione da qualche parte più semplice perché è prevedibile. Database spostati su provider gestiti che fanno bene una cosa sola e non richiedono un dottorato in networking per operare. Roba statica spinta più vicino agli utenti senza una storia di origine che coinvolga sei servizi AWS e un diagramma che nessuno vuole mantenere.

Policloud ha smesso di essere una parola spaventosa e ha iniziato a essere… normale.

Non perché gli sviluppatori amino improvvisamente destreggiarsi tra fornitori, ma perché il compromesso ora ha senso. Usare lo strumento migliore per un lavoro specifico è spesso più economico, più veloce e più facile che forzare tutto attraverso una singola mega-piattaforma solo per sentirsi “pronti per l’enterprise”.

Ho visto team sostituire un servizio AWS e sentire immediatamente il sistema respirare di nuovo. Meno permessi su cui ragionare. Meno variabili di prezzo. Meno comportamenti a sorpresa. Niente di radicale, solo un’infrastruttura più silenziosa.

La parte divertente? La maggior parte di questi team usa ancora AWS.

Hanno solo smesso di presumere che fosse la risposta prima di fare la domanda.

Questo è il vero cambiamento. La fiducia di dire:
“Sì, AWS è fantastico… ma non qui.”

E una volta fatto questo spostamento mentale, la pressione si allenta. Le decisioni sull’infrastruttura smettono di sembrare permanenti. Smetti di ottimizzare per una scala ipotetica e inizi a ottimizzare per la realtà in cui ti trovi.

Che, per la maggior parte dei team, è più piccola, più veloce e più vincolata di quanto il vecchio consiglio abbia mai ipotizzato.

Un default migliore di “usa solo AWS”

La vera soluzione non è cambiare cloud.
È cambiare domande.

“Usa solo AWS” funzionava quando l’infrastruttura era il collo di bottiglia. Oggi, la qualità delle decisioni è il collo di bottiglia. Quindi un default migliore non è una piattaforma, è una pausa.

Prima di ricorrere ad Amazon Web Services, ho iniziato a fare alcune domande noiose ma mortalmente efficaci:

  • Quanto rimarrà piccolo tutto questo, realmente?

  • Qual è l’errore più costoso che possiamo fare qui?

  • Quale parte di questo ha bisogno di scalare, e quale parte ha solo bisogno di esistere?

  • Chi farà il debug di questo tra sei mesi?

Le risposte cambiano tutto.

A volte puntano direttamente a AWS. Grandi team, crescita imprevedibile, integrazioni complesse, reali esigenze di conformità? Sì. Lì AWS si guadagna da vivere.

Ma molte volte, le risposte puntano altrove, verso qualcosa di più tranquillo. Qualcosa di più opinionato. Qualcosa con meno manopole da girare accidentalmente. E questo non è “accontentarsi”, è abbinare lo strumento al momento.

Il più grande cambiamento mentale per me è stato realizzare che le scelte infrastrutturali non sono più matrimoni. Sono leasing. Puoi traslocare. Puoi rifattorizzare. Puoi superare le cose senza inquadrarlo come un fallimento.

Una volta internalizzato questo, la paura svanisce.

Smetti di sovra-ingegnerizzare per un futuro che potresti non raggiungere mai. Smetti di ereditare complessità “giusto in caso”. Rilasci più velocemente, dormi meglio e passi più tempo a pensare al prodotto invece che alla piattaforma.

Un default migliore non è “usa solo AWS”.

È: “quale problema stiamo effettivamente risolvendo in questo momento?”

Un default migliore di “usa solo AWS”

La soluzione non è trovare una nuova piattaforma magica.

È abbandonare l’idea che esista un default magico.

“Usa solo AWS” un tempo faceva risparmiare tempo perché le decisioni infrastrutturali riguardavano l’evitare errori ovvi. Oggi, gli errori sono più silenziosi, nascosti dietro default sensati, note sui prezzi e complessità opzionale che non hai richiesto.

Quindi, invece di usare Amazon Web Services come default, una mossa migliore è fermarsi e fare alcune domande noiose ma importanti:

  • Quanto diventerà grande tutto questo, realmente?

  • Qual è la peggiore sorpresa in bolletta a cui possiamo sopravvivere?

  • Cosa ha effettivamente bisogno di scalare qui?

  • Chi manterrà tutto questo quando il contesto sarà svanito?

A volte quelle risposte portano direttamente a AWS. Grandi team, vera conformità, crescita incerta, abbastanza giusto.

Ma spesso, non lo fanno.

Puntano a sistemi più semplici. Meno manopole. Meno complessità ereditata.

Il vero cambiamento di mentalità è questo: le scelte infrastrutturali non sono matrimoni. Sono leasing. Puoi spostarti. Puoi cambiare idea. Non hai bisogno di precaricare complessità solo per sentirti “responsabile”.

Un default migliore non è un provider.

È l’intenzionalità.

Una volta adottata questa, “usa solo AWS” smette di essere un consiglio e diventa un’opzione tra le tante.

AWS non è il cattivo, lo è il pilota automatico

È facile cercare un cattivo.

Attaccare Amazon Web Services.
Dire che il cloud è rotto.
Fingere che ci sia una risposta migliore a cui tutti dovrebbero passare domani.

Sarebbe facile. E sbagliato.

AWS non è diventato improvvisamente cattivo. L’industria è solo cresciuta. I team sono diventati più piccoli. I margini sono diventati più stretti. I carichi di lavoro sono diventati più strani. E il costo della complessità non necessaria ha smesso di essere teorico.

Il vero problema non è AWS.
È il pensiero da pilota automatico.

“Usa solo AWS” funzionava quando evitare errori infrastrutturali contava più di capire i compromessi. Ora, ereditare ciecamente la complessità può essere rischioso quanto creare tutto da soli.

La buona notizia? Ci è permesso mettere in discussione i default.

Puoi scegliere strumenti che corrispondono alla tua scala reale.
Puoi scambiare l’opzionalità per la chiarezza.
Puoi ottimizzare per la spedizione, non per futuri ipotetici.

Questa non è regressione. Questa è maturità.

Se AWS è giusto per il tuo problema, usalo con orgoglio.
Solo non farlo perché qualcuno ha detto che era la “scelta sicura”.

Risorse utili

📝 Nota sulla traduzione

Questo articolo è stato tradotto automaticamente dall’inglese all’italiano utilizzando intelligenza artificiale.
L’articolo originale è disponibile su: https://medium.com/ @dev_tips/just-use-aws-is-starting-to-sound-like-bad-advice-in-2026-f66e82a7f774

Tutti i diritti sui contenuti originali appartengono ai rispettivi proprietari. Questa traduzione è fornita a scopo informativo e non costituisce un’opera derivata con pretese di originalità.