Torna al blog Managed Cloud

Come scegliere una regione cloud per un'applicazione aziendale self-hosted

Scegli la regione di hosting mappando dove viaggiano i dati dell'applicazione, chi deve accedervi e cosa serve per il ripristino: non limitarti a scegliere una posizione sulla mappa.

Diagramma dei flussi tra utenti, regione del server, backup, log e servizi collegati di un'applicazione aziendale

Parti dai requisiti, non dalla mappa delle località dei provider

Una regione vicina può essere comoda, ma la sola vicinanza non basta a stabilire se sia il posto giusto per eseguire un'applicazione aziendale. Per prima cosa, chiarisci quali dati l'applicazione archivia ed elabora, chi la usa, da quali servizi dipende e quali requisiti di accesso e ripristino ha la tua organizzazione.

Metti per iscritto i requisiti prima di confrontare le località disponibili. Distingui quelli obbligatori, come una policy interna o un impegno documentato verso un cliente, dalle preferenze, come un percorso di rete più breve per gli utenti. Se un requisito dipende da una legge o da un contratto, chiedi una consulenza legale o di conformità adeguata, anziché considerare la selezione di una regione come una valutazione di conformità.

  • Quali persone e processi aziendali dipendono dall'applicazione?
  • Quali tipi di informazioni conterrà o invierà ad altri servizi?
  • Ci sono requisiti legali, contrattuali o organizzativi relativi alla localizzazione da valutare?
  • Quali esigenze di esperienza d'uso e ripristino deve supportare la soluzione di hosting?
  • Quali dettagli sono ancora sconosciuti e richiedono una conferma scritta?
Parti dai requisiti, non dalla mappa delle località dei provider

Mappa i flussi di dati dell'applicazione

Elenca le informazioni gestite dall'applicazione e segui il percorso che compiono. Parti dai dati principali, poi includi file caricati, esportazioni generate, dati di autenticazione, log dell'applicazione e degli accessi, dati di monitoraggio, backup e informazioni inviate ai servizi collegati. Considera sia le persone che possono accedere a tali informazioni o gestirle, sia i sistemi che le archiviano o elaborano.

Registra la categoria dei dati, il sistema o la persona che li riceve, lo scopo e tutte le informazioni sulla localizzazione che hai verificato. Segnala esplicitamente ciò che non sai. Il server dell'applicazione è solo una parte della mappa: verifica la localizzazione degli altri servizi e percorsi dei dati, anziché presumere che si trovino nello stesso luogo.

Mantieni la mappa proporzionata alle tue esigenze. Un piccolo team può iniziare con una tabella e aggiornarla quando cambiano le integrazioni o i flussi di lavoro. L'obiettivo è rendere visibili i percorsi dei dati a sufficienza per porre le domande pertinenti.

  • Record del database principale e file caricati
  • Esportazioni, file temporanei e contenuti generati dall'applicazione
  • Log dell'applicazione, degli accessi e degli errori, e dati di monitoraggio
  • Backup, snapshot e copie utilizzate per il ripristino
  • Accessi per assistenza, amministrazione e altre attività operative
  • Dati inviati a servizi di identità, email, pagamento, analisi, AI o altri servizi collegati
Mappa i flussi di dati dell'applicazione

Valuta separatamente le esigenze degli utenti e gli obblighi di localizzazione

L'esperienza d'uso e i requisiti di localizzazione dei dati sono aspetti diversi. Per valutare le esigenze degli utenti, individua dove lavorano le persone e quali flussi di lavoro dell'applicazione sono più importanti per loro. Quando è pratico, prova l'applicazione con utenti in località rappresentative e con i relativi percorsi di accesso, invece di basarti solo su una mappa.

Per quanto riguarda gli obblighi di localizzazione, individua i dati e i trattamenti specifici coperti da ciascun requisito e verifica i dettagli relativi al provider e al servizio interessato. Tieni questi obblighi distinti dalle preferenze legate all'esperienza d'uso e chiedi una consulenza adeguata per interpretare i requisiti legali o contrattuali.

La [documentazione di Google Compute Engine](https://docs.cloud.google.com/compute/docs/regions-zones) indica che gli utenti scelgono la regione o la zona che ospita le risorse e che tale scelta determina dove vengono archiviati e utilizzati i dati relativi a quelle risorse. Questa descrizione riguarda Google Compute Engine: non estenderla automaticamente a tutti i servizi cloud o a ogni flusso di dati dell'applicazione.

  • Registra le principali località degli utenti e i flussi di lavoro per loro più importanti.
  • Quando è pratico, verifica l'esperienza d'uso con l'applicazione e con percorsi di accesso rappresentativi.
  • Elenca separatamente gli obblighi relativi alla localizzazione e le preferenze legate all'esperienza d'uso.
  • Verifica quali servizi e categorie di dati sono coperti dalle dichiarazioni del provider sulla localizzazione.

Verifica ogni servizio collegato

Un'applicazione self-hosted può scambiare informazioni con servizi esterni al server principale. A seconda della configurazione, possono essere inclusi servizi di identità e single sign-on, invio di email, elaborazione dei pagamenti, analisi, endpoint AI, archiviazione di file o monitoraggio. Ogni servizio ha condizioni, impostazioni e modalità di trattamento dei dati proprie.

Per ogni dipendenza, registra quali informazioni vengono inviate e per quale motivo. Consulta la documentazione del servizio o chiedi al provider informazioni sulla localizzazione, l'archiviazione, la conservazione e l'accesso operativo pertinenti alla tua configurazione. Le domande da porre dipendono dal servizio e dai tuoi requisiti.

Per esempio, [Langfuse dichiara che i clienti possono scegliere una regione](https://langfuse.com/security/data-regions) per allinearsi alle esigenze della propria organizzazione in materia di residenza dei dati. Questa dichiarazione riguarda il servizio Langfuse: verifica i dettagli pertinenti alla tua configurazione, anziché considerarla valida per tutte le categorie di dati o per ogni forma di accesso operativo.

  • Fai l'inventario delle integrazioni, inclusi plugin facoltativi e processi in background.
  • Individua i campi o i file sensibili inviati a ciascun servizio.
  • Verifica le impostazioni regionali e la documentazione del servizio per i dati interessati.
  • Chiedi se sono necessarie modifiche alla configurazione per soddisfare i requisiti che intendi rispettare.
  • Registra i servizi per cui la localizzazione o le condizioni di trattamento non sono ancora chiare.

Chiedi ai provider cosa comprende ogni scelta di localizzazione

Poni domande precise e specifiche sul servizio per sapere cosa controlla la selezione di una regione e quali servizi sono inclusi. Quando sono pertinenti ai tuoi requisiti, chiedi informazioni su backup, monitoraggio, log e assistenza operativa. Conserva le risposte dei provider insieme alla documentazione della decisione.

Se usi un servizio di hosting gestito, chiedi chi può accedere all'ambiente per fornire assistenza operativa e in quali circostanze. L'infrastruttura gestita può ridurre le attività di amministrazione cloud svolte dal tuo team, ma non elimina la tua responsabilità di decidere quali dati inserire nell'applicazione né come gestire gli accessi di utenti e amministratori.

Per un'applicazione gestita da Airbip, le istanze vengono eseguite come workload Docker sui server cloud di Airbip. Airbip fornisce la gestione del ciclo di vita del servizio e backup giornalieri, settimanali e mensili configurabili. Queste funzionalità non determinano una specifica localizzazione dei server o dei backup. Prima di farvi affidamento, consulta il sito Airbip aggiornato e chiedi direttamente ad Airbip i dettagli sulla localizzazione pertinenti ai tuoi requisiti.

  • Quale località si applica al server dell'applicazione e allo spazio di archiviazione collegato?
  • Dove vengono archiviati i backup e quali opzioni o condizioni di localizzazione si applicano?
  • Dove vengono gestiti i log e i dati di monitoraggio?
  • Chi può accedere all'ambiente per fornire assistenza operativa?
  • Quali servizi collegati o sub-responsabili non rientrano in questa soluzione di hosting?
  • Come vengono gestiti i cambi di localizzazione, la conservazione dei backup e il ripristino?

Pianifica il ripristino e un eventuale trasferimento

Prima di scegliere una località, documenta come ripristineresti l'applicazione e quali modifiche servirebbero per trasferirla. Individua cosa deve essere ripristinato, quali copie sono disponibili, chi può avviare il ripristino e quali informazioni ti servono dal provider di hosting. Verifica le condizioni pertinenti anziché presumere una specifica localizzazione dei backup o la disponibilità di un'opzione di ripristino tra regioni.

Chiedi se un backup include i dati e la configurazione dell'applicazione di cui hai bisogno, come potresti ottenerlo e se hai già provato a ripristinarlo. Airbip offre backup giornalieri, settimanali e mensili configurabili: verifica la configurazione applicabile e i dettagli del ripristino per la tua istanza, senza dedurli dalle opzioni di pianificazione.

Se prevedi un possibile trasferimento, chiarisci come esportare i dati dell'applicazione, quali configurazioni o integrazioni potrebbero dover essere modificate e come convalideresti il nuovo ambiente prima di trasferirvi gli utenti. Il piano dipenderà dall'applicazione e dalla soluzione di hosting.

  • Elenca i dati e la configurazione necessari per ripristinare il servizio.
  • Verifica con il provider la localizzazione, la conservazione e l'accesso ai backup, oltre alla procedura di ripristino.
  • Stabilisci chi è responsabile delle attività di ripristino e chi è autorizzato a svolgerle.
  • Controlla le opzioni di esportazione e individua le integrazioni che potrebbero richiedere una nuova configurazione dopo il trasferimento.
  • Quando è opportuno in base all'impatto sull'attività, valuta una prova di ripristino o migrazione.

Documenta la decisione e le questioni ancora aperte

Una breve scheda di valutazione facilita la revisione della decisione da parte di un altro amministratore. Confronta le località candidate con i requisiti essenziali e distingui i fatti verificati dalle supposizioni. Se un provider non può rispondere a una domanda rilevante, registra l'incertezza anziché considerarla risolta.

Il risultato non deve necessariamente ridursi a un unico punteggio: una località può soddisfare le esigenze degli utenti lasciando però aperta una questione sul trattamento dei dati. Prima di considerare definitiva la decisione, sottoponi agli interlocutori competenti le questioni legali, contrattuali o di governance ancora irrisolte.

  • Regione candidata o località di hosting
  • Utenti e flussi di lavoro che la località dovrebbe servire
  • Categorie di dati e servizi coperti dalla scelta
  • Servizi collegati e relativi dettagli verificati in modo indipendente
  • Risposte del provider su monitoraggio, accesso per l'assistenza e ripristino
  • Requisiti soddisfatti, compromessi accettati e documentazione raccolta
  • Questioni aperte, responsabile e data della prossima revisione

Rivedi la decisione quando il sistema cambia

Rivedi la decisione quando l'applicazione acquisisce utenti in nuove località, inizia ad archiviare nuove categorie di informazioni, aggiunge un'integrazione, modifica le modalità di backup o è soggetta a un nuovo requisito contrattuale o normativo.

La revisione può aggiornare la mappa dei flussi di dati, verificare la documentazione del provider e stabilire se le ipotesi iniziali sono ancora valide. Registra i cambiamenti e chi ha approvato eventuali modifiche all'hosting o alla configurazione.

  • Rivedi la decisione dopo aver aggiunto o sostituito un servizio collegato.
  • Rivalutala quando cambiano le località degli utenti, i flussi di lavoro o i tipi di dati.
  • Verifica eventuali cambiamenti del provider che possano influire su localizzazione, backup, log o accesso per l'assistenza.
  • Aggiorna la documentazione della decisione e assegna le attività di approfondimento relative alle questioni ancora aperte.

Domande frequenti

Scegliere una regione per il server cloud garantisce la residenza dei dati?

La scelta di una regione si applica alle risorse coperte dall'impostazione del provider. Controlla la mappa dei flussi di dati e verifica i dettagli pertinenti con i provider coinvolti. Stabilire se la soluzione soddisfa un requisito legale o contrattuale dipende dal requisito e dai servizi utilizzati; se necessario, chiedi una consulenza adeguata.

Dovrei scegliere la regione più vicina ai miei utenti?

La località degli utenti può orientare la decisione, ma è opportuno considerare anche i flussi di lavoro da cui dipendono, i requisiti di localizzazione, i servizi collegati e le modalità di ripristino. Quando è pratico, verifica l'esperienza d'uso con utenti o percorsi di accesso rappresentativi.

I backup dell'applicazione rimangono necessariamente nella stessa regione del server?

Non presumere che la località del backup coincida con quella del server dell'applicazione. Chiedi al provider di hosting dove vengono archiviati i backup e come funziona il ripristino.

Cosa dovrebbe fare un piccolo team se un provider non può confermare un dettaglio sulla localizzazione?

Registra la questione come irrisolta, individua i dati o i requisiti interessati e chiedi chiarimenti al provider. Se il dettaglio è rilevante per un obbligo legale, contrattuale o di governance, chiedi una consulenza adeguata prima di fare affidamento sulla soluzione di hosting.

L'hosting gestito elimina la responsabilità del cliente per le decisioni sui dati e sugli accessi?

No. Il tuo team deve comunque decidere quali informazioni contiene l'applicazione, quali integrazioni ricevono dati, chi può accedervi e quali requisiti deve soddisfare la soluzione.

Fonti e approfondimenti

  1. Regions and zones — Google Cloud
  2. Data Regions & Availability — Langfuse