Amazon SES per il tuo MVP: email economica, setup grezzo

Ogni MVP che invia email transazionali finisce per affrontare lo stesso compromesso: pagare di più per un fornitore raffinato e pronto all’uso, o pagare meno e costruire da soli più impianti. Resend vs SendGrid tratta la prima scelta — due fornitori che vendono entrambi comodità sopra la consegna email. Amazon SES (Simple Email Service) si trova interamente dall’altra parte di quella linea. È l’infrastruttura grezza di invio email di AWS, con un prezzo vicino al costo effettivo dell’invio dell’email, senza la raffinatezza delle dashboard o gli strumenti di template integrati. Per gli MVP che monitorano ogni dollaro di spesa infrastrutturale, quella differenza vale la pena di essere compresa prima di scegliere un fornitore per default.

Cos’è realmente Amazon SES

SES fa parte di AWS, non è un’azienda email autonoma. Ti offre un’API (e un’interfaccia SMTP) per inviare email transazionali e di massa, insieme all’infrastruttura di invio sottostante — gestione della reputazione IP, gestione di bounce e reclami, e consegna tramite i server di posta di AWS. Non include un editor di template visivo, una dashboard di analisi integrata paragonabile a quella di SendGrid, o supporto di prim’ordine per un framework di templating come l’integrazione React Email di Resend. Quello che ottieni è più vicino a un’utility ben costruita che a un prodotto: un endpoint API, manopole di configurazione e metriche CloudWatch se le colleghi tu stesso.

Non è una critica — è il punto. SES è costruito per team che già vivono in AWS e vogliono l’email come un’altra primitiva infrastrutturale accanto al loro calcolo e archiviazione, non come una relazione con un fornitore gestita separatamente con una propria dashboard da controllare.

Perché SES è più economico

Il divario di costo tra SES e fornitori come Resend o SendGrid non è uno sconto o una promozione — riflette una posizione diversa nello stack. Resend e SendGrid acquistano infrastruttura di invio (in alcuni casi, da AWS o da un fornitore cloud simile) e poi aggiungono uno strato di prodotto sopra: dashboard, editor di template, webhook con payload amichevoli, flussi di onboarding e personale di supporto. I loro prezzi devono coprire quello strato di prodotto, non solo la meccanica dell’invio di un’email.

SES salta quello strato. Paghi ad AWS quasi il costo grezzo del trasporto di un’email attraverso la loro infrastruttura, allo stesso modo in cui Hetzner è più economico di un database gestito di un hyperscaler perché paghi per calcolo e archiviazione anziché per un servizio gestito che li avvolge (vedi Hosting cloud economico per MVP: quando Hetzner ha senso per la stessa logica di livello di costo applicata all’hosting). I risparmi sono reali, ma derivano dal fatto che AWS non spende denaro sulle parti del prodotto che rendono Resend o SendGrid piacevoli da usare — e quella differenza emerge nel momento in cui inizi a costruire su SES.

I veri compromessi

Un’API più grezza e meno protezioni

Inviare un’email tramite SES significa chiamare direttamente l’SDK AWS o l’API REST, gestire la propria logica di ripetizione tentativi e costruire tutta la visibilità che desideri sullo stato di consegna — bounce, reclami, aperture — di solito collegando tu stesso le notifiche SNS. Resend e SendGrid ti forniscono payload webhook leggibili e una dashboard pronti all’uso; con SES, li assembli da primitive AWS. È tutto documentato e collaudato, ma è decisamente più configurazione rispetto a “installa l’SDK, chiama send”.

Più configurazione AWS a monte

Prima di inviare una singola email, devi verificare il tuo dominio di invio in SES con record DNS (simile alla configurazione SPF/DKIM/DMARC per qualsiasi fornitore, ma fatta tramite la console AWS o la CLI anziché un flusso di onboarding guidato), configurare i permessi IAM per qualunque servizio chiami SES, e decidere se inviare tramite l’interfaccia API o SMTP. Niente di tutto ciò è esotico se il tuo team è già a suo agio con AWS — è un pomeriggio extra di configurazione, non un progetto di ricerca. Se il tuo team non ha mai toccato AWS prima, è una prima salita più ripida rispetto a iscriversi a Resend e incollare una chiave API.

La sandbox e il processo di approvazione del limite di invio

Questo è il compromesso più probabile a sorprendere un team che si muove velocemente. I nuovi account SES iniziano in una sandbox: puoi inviare solo a indirizzi email verificati, e il volume di invio giornaliero è limitato in basso. Per inviare a utenti reali non verificati in produzione, devi presentare una richiesta ad AWS che descriva il tuo caso d’uso, il volume previsto e come gestisci bounce e reclami — e AWS la esamina prima di concedere l’accesso in produzione. Non è istantaneo, e storicamente è stato più rigoroso di “iscriviti e vai”, il che conta se stai cercando di lanciare un’email di conferma iscrizione questa settimana anziché la prossima. Resend e SendGrid non hanno un cancello di approvazione equivalente per iniziare.

Amazon SES rispetto ai fornitori in stile Resend/SendGrid

Fattore	Amazon SES	Resend / SendGrid
Costo su larga scala	Il più basso — prezzi di infrastruttura AWS grezza	Più alto — include lo strato prodotto/supporto nel prezzo
Sforzo di configurazione	Più alto — configurazione console AWS/IAM/DNS, collegamento manuale dei webhook	Più basso — chiave API, verifica del dominio guidata, dashboard pronte
Esperienza sviluppatore	API/SMTP grezze, costruisci tu monitoraggio e templating	SDK raffinati, analisi integrate, strumenti di template (es. React Email su Resend)
Per iniziare	Limiti sandbox + processo di revisione AWS per l’invio in produzione	Nessun cancello di approvazione comparabile — invio rapido a indirizzi reali
Ideale per	Team già su AWS, invio ad alto volume, sensibili ai costi su larga scala	Team che vogliono configurazione rapida e meno manutenzione, volume basso/moderato

Quando i risparmi sui costi valgono la pena

SES tende ad avere senso quando almeno una di queste condizioni è vera: il tuo team gestisce già un’infrastruttura significativa su AWS e aggiungere un altro servizio è davvero a basso attrito; il tuo volume email previsto è abbastanza alto che la differenza di costo per email si somma a una vera voce di budget, non un arrotondamento; oppure hai il tempo di ingegneria per costruire il monitoraggio, i tentativi ripetuti e la gestione dei template che un fornitore raffinato ti dà gratis. In questi casi, il costo continuativo più basso si accumula ogni mese in cui gestisci il prodotto, e il costo di configurazione una tantum smette di contare una volta completato.

Quando un fornitore raffinato fa risparmiare più di quanto costi

Per la maggior parte degli MVP nei loro primi mesi, il calcolo va nella direzione opposta. Se il tuo team non ha mai lavorato con AWS, il tempo di configurazione — più l’attesa per l’approvazione del limite di invio di SES — è tempo non speso a costruire il prodotto stesso. Se il tuo volume email è ancora basso, i risparmi assoluti in dollari dalla scelta di SES sono piccoli nel primo anno, mentre le ore di ingegneria per costruire un monitoraggio e templating equivalenti non lo sono. In questa situazione, il confronto diretto di Resend o SendGrid è la lettura più utile: entrambi scambiano un costo per email più alto con una configurazione e manutenzione notevolmente inferiori, il che di solito è il compromesso giusto per un team la cui risorsa scarsa è il tempo di ingegneria, non il budget infrastrutturale.

Prendere la decisione

Amazon SES non è un trucco nascosto né una trappola — è la stessa decisione “infrastruttura grezza contro prodotto gestito” che i team MVP già prendono per l’hosting, applicata all’email. Il vantaggio di costo è reale e cresce con il volume, ma si paga con tempo di configurazione, un’API più grezza e un processo di approvazione che può aggiungere tempi di attesa prima di inviare vere email di produzione. Se il tuo team è nativo AWS o sta già scalando oltre il punto in cui il costo per email conta, quel compromesso vale la pena. Se stai ancora validando il prodotto e vuoi che l’email transazionale funzioni questa settimana senza dover gestire la configurazione AWS, un fornitore come Resend o SendGrid ti porterà lì più velocemente — e potrai sempre migrare a SES in seguito una volta che il volume giustifica il cambio, più o meno come i team migrano carichi di lavoro specifici da un host economico a un hyperscaler una volta che il calcolo cambia.

Domande frequenti

Amazon SES è più economico di Resend o SendGrid?

A volumi di invio significativi, sì — SES è generalmente l'opzione più economica perché ha un prezzo da infrastruttura AWS grezza anziché da prodotto raffinato con supporto, dashboard e templating inclusi nel prezzo. Controlla la pagina prezzi attuale di ciascun fornitore rispetto al tuo volume previsto invece di affidarti a un numero ricordato a memoria, poiché le fasce cambiano.

Amazon SES è difficile da configurare?

È più impegnativo di Resend o SendGrid. Configuri l'invio tramite la console AWS o la CLI, verifichi il tuo dominio di invio con record DNS e — per l'uso in produzione fuori dalla sandbox — richiedi un aumento del limite di invio che AWS esamina prima di approvarlo. Non è tanto difficile quanto manuale, con meno protezioni rispetto a un'API email dedicata.

Cos'è la sandbox SES e come influisce su un nuovo MVP?

I nuovi account SES iniziano in una sandbox che limita l'invio solo a indirizzi email verificati, con limiti di invio giornalieri bassi. Passare all'accesso in produzione richiede l'invio di una richiesta ad AWS che descriva il tuo caso d'uso, che loro esaminano prima di rimuovere la restrizione — pianifica questo tempo di attesa prima di aspettarti di inviare email a utenti reali.

Un MVP in fase iniziale dovrebbe usare Amazon SES invece di Resend o SendGrid?

Solo se il tempo di ingegneria è più disponibile del budget, o se sei già profondamente nell'infrastruttura AWS. Se vuoi lanciare rapidamente l'email transazionale con una configurazione minima e non ti dispiace pagare di più per email, Resend o SendGrid ti porteranno lì più velocemente. Se stai ottimizzando per il costo più basso possibile su larga scala e sei disposto a costruire di più da solo, SES vale la configurazione aggiuntiva.

Posso passare da Amazon SES a Resend o SendGrid in seguito, o viceversa?

Sì. Reindirizzi il codice di invio email della tua applicazione verso una nuova API e rifai l'autenticazione del dominio (SPF, DKIM, DMARC) per il nuovo fornitore — lavoro reale, ma non una ricostruzione. Molti team iniziano con un fornitore raffinato per velocità e passano a SES in seguito una volta che il volume giustifica il cambio, oppure fanno il contrario se il carico di configurazione di SES supera i risparmi.