Inizia dal carico di lavoro, non da un piano di hosting
Elenca i percorsi che generano valore o rischio: prima visita, ricerca, accesso, dettaglio prodotto, invio moduli, checkout, aggiornamento dell'editor o chiamata API. Per ciascuno registra richieste di picco o utenti concorrenti, payload, personalizzazione, dipendenze e regioni dei visitatori. Includi lavori schedulati e amministrativi perché consumano le stesse risorse.
Trasforma la lista in misure di accettazione. Largest Contentful Paint, o LCP, misura il caricamento del contenuto principale; Interaction to Next Paint, o INP, la reattività; e Cumulative Layout Shift, o CLS, i movimenti inaspettati. Google descrive come buoni target LCP entro 2,5 secondi, INP sotto 200 millisecondi e CLS sotto 0,1. Aggiungi obiettivi di completamento di percorso, tempo di risposta del server e tasso di errore.
Non lasciare che una pagina cacheata e veloce sostituisca una transazione autenticata o basata su database.
Definisci il periodo di picco, la crescita prevista, i picchi di campagna e i lavori batch sovrapposti.
Segna se l'host, il tuo team o una terza parte controllano ciascun possibile collo di bottiglia.
Confronta capacità, limiti e comportamento di scaling
Chiedi i limiti sotto l'offerta: compute e memoria, performance di storage, connessioni al database, limiti worker, controlli di rete, addebiti di rete, controlli di request e vincoli dovuti a vicini condivisi. “Larghezza di banda illimitata” non mostra se l'app può eseguire abbastanza lavoro non cacheato in un picco. Chiedi quali metriche sono visibili e per quanto tempo rimangono disponibili.
Lo scaling conta solo quando sono noti trigger, ritardi, tetti e prezzo. Conferma se è automatico, se sessioni e job restano integri e cosa succede al raggiungimento del tetto. Preferisci un test al picco previsto e oltre anziché una dichiarazione teorica di capacità. Il margine operativo (headroom) è una decisione di business, non una percentuale universale.
Confronta tempi di risposta p95 o p99, non solo una media.
Raccogli i tempi di database, queue e API upstream durante il test.
Stima costi di scala, delivery, backup e di una seconda regione prima di impegnarti.
Posiziona l'origine con criterio e valida la consegna
Scegli una regione di origine usando la localizzazione del pubblico, le dipendenze dell'applicazione, i requisiti di ubicazione dei dati e l'accesso operativo. Testa da geografie e condizioni di rete rappresentative. Una content delivery network, o CDN, è una cache distribuita che può servire asset idonei più vicino ai visitatori e ridurre il lavoro sull'origine; non sostituisce un'origine, un database o un'applicazione sani.
Ispeziona header e comportamento, non solo un'impostazione di dashboard. Gli asset statici versionati possono generalmente avere durate più lunghe perché un aggiornamento ha una nuova URL. Risposte dinamiche e personalizzate richiedono regole esplicite. HTTP distingue cache condivise da private; i dettagli dell'account non devono diventare riutilizzabili da altri clienti. Prova un purge della cache e un rollback.
Cattura una prima visita e una visita di ritorno perché gli stati della cache differiscono.
Controlla Cache-Control e le chiavi della cache per pagine, asset, cookie, parametri e locale.
Documenta come il personale autorizzato disabilita una regola dannosa senza esporre contenuti sensibili.
Considera le prove di ripristino come requisito di prestazione
Chiedi cosa viene fatto il backup, dove vivono le copie, la retention, l'autorità di restore e se i backup coprono database, upload, codice, configurazione e infrastruttura. Definisci il recovery point objective, o RPO, come perdita di dati accettabile in termini temporali, e il recovery time objective, o RTO, come tempo di ripristino accettabile. Imposta entrambi in base alle conseguenze di business, non a un default del pacchetto.
Un backup riuscito non è prova di ripristino. CISA raccomanda test di recupero schedulati, e AWS dice che il disaster recovery va valutato e testato. Ripristina una copia recente in isolamento, verifica record e media importanti, usa la sequenza documentata e registra il tempo trascorso. Una regione alternativa può ridurre alcuni rischi ma aggiunge costi e complessità.
Recupera un singolo file o record senza sovrascrivere i dati correnti.
Limita l'accesso al restore e mantieni credenziali e runbook di ripristino disponibili ai responder autorizzati.
Uno snapshot del database potrebbe non ricreare impostazioni, versioni dell'applicazione o regole di delivery.
Valuta supporto e responsabilità condivisa prima che servano
Confronta ambito del supporto, orari, canali, escalation e la differenza tra incidenti di piattaforma e troubleshooting applicativo. Ottieni responsabilità scritta per patch, database gestiti, TLS, regole firewall, backup e ripristino. Una promessa di supporto è utile quando nomina il proprietario e la prossima azione in uno scenario realistico.
Rivedi ruoli di accesso, autenticazione a più fattori, log di audit, gestione dei segreti e isolamento degli account. Per carte di pagamento o dati regolamentati sensibili, le funzionalità di hosting da sole non stabiliscono la conformità. Usa questo confronto come input tecnico e ottieni una revisione qualificata di sicurezza, legale o compliance dell'architettura di pagamento e degli obblighi applicabili.
Chiedi come il provider gestisce un ripristino fallito, un database saturo o una regola di cache dannosa.
Verifica chi può modificare la produzione, leggere i backup, vedere i log e creare credenziali.
I crediti di servizio e la copertura gestita possono avere condizioni materiali.
Esegui test comparativi realistici e sicuri e conserva la scheda di valutazione
Usa la stessa release, intento di configurazione e script di test per ogni candidato. Esegui un baseline, il picco previsto, uno spike breve, un periodo sostenuto e un esercizio di recupero o deployment sicuro. AWS raccomanda ambienti simili alla produzione, scenari definiti, monitoraggio a livello architetturale, dati sanificati o sintetici e retesting regolare. Ottieni l'approvazione del provider e segui la sua policy di test.
Combina test di laboratorio controllati con dati di campo dopo il lancio. I test di laboratorio sono ripetibili per il debug; i dati di campo riflettono dispositivi reali, reti, geografia, stato della cache e comportamento. Riesamina la scheda di valutazione dopo release importanti o cambi di dipendenza. SIU può trasformare le evidenze in indurimenti pre-lancio, rimedi assegnati ai proprietari e miglioramenti pronti al rollback.
Mantieni costanti località, concorrenza, stato della cache e payload.
Salva tempi di percorso, errori, metriche delle risorse, versioni, costi e osservazioni.
Seleziona l'opzione che soddisfa i bisogni documentati a un costo operativo sostenibile.