Cloud ibrido per PMI: il ruolo della connettività

Il cloud ibrido — server locali che convivono con risorse su cloud pubblico — è oggi la norma per molte PMI: ERP gestionale in sede, backup e disaster recovery nel cloud, magari qualche applicazione SaaS. Il punto critico, spesso sottovalutato, è che un'architettura ibrida vale quanto la connettività che la tiene insieme. Se il collegamento tra sede e cloud è fragile, l'intera infrastruttura lo è.

Perché la connettività è il vero collo di bottiglia

In un modello ibrido, dati e applicazioni attraversano costantemente il confine tra LAN aziendale e cloud:

• Sincronizzazione di backup e repliche verso il cloud.
• Accesso degli utenti ad applicazioni che girano in parte in sede, in parte remote.
• Traffico di sistemi che dialogano via API tra on-premise e provider.

Quando la linea cade o degrada, non si perde "solo Internet": si perde l'accesso a pezzi del proprio sistema gestionale. Per questo la connettività di un'architettura ibrida va trattata come infrastruttura critica, non come un contratto consumer.

Banda: simmetria più che velocità di punta

Le PMI guardano spesso solo al download, ma in un contesto ibrido conta soprattutto l'upload:

• I backup e le repliche verso il cloud sono traffico in uscita: una linea asimmetrica (es. molto download, poco upload) diventa un collo di bottiglia nelle finestre di sincronizzazione.
• La fibra FTTH simmetrica è il riferimento ideale, perché garantisce upload pari al download.

Va dimensionata la banda di picco considerando backup notturni, utenti attivi e margine di crescita, non la media giornaliera.

Latenza e jitter: il fattore nascosto

Per le applicazioni interattive (desktop remoto, gestionali in cloud, VoIP integrato) la latenza pesa più della banda:

• Una latenza alta rende lente le applicazioni anche con banda abbondante, perché ogni interazione attende il round-trip.
• Il jitter (variazione della latenza) degrada voce e video.

Avvicinarsi a data center e nodi cloud raggiungibili con pochi hop — possibile quando l'ISP ha buon peering — riduce la latenza in modo strutturale, non con espedienti lato client.

Ridondanza: la linea singola non basta

Un'infrastruttura ibrida critica non può dipendere da un solo collegamento:

• Dual WAN / failover: una seconda linea (idealmente su tecnologia diversa, es. fibra + FWA 5G) che subentra automaticamente se la primaria cade.
• IP statico: spesso necessario per VPN site-to-site stabili, regole firewall e raggiungibilità dei servizi pubblicati.
• VPN site-to-site tra sede e cloud (IPsec o WireGuard) per un canale cifrato e permanente, invece di esporre servizi direttamente su Internet.

Sicurezza del collegamento

Il traffico ibrido che attraversa Internet va protetto a prescindere:

• Tunnel cifrati (IPsec/WireGuard) per ogni comunicazione sede-cloud.
• Segmentazione tra il traffico di gestione, quello applicativo e quello degli ospiti.
• Filtri sul perimetro che espongono solo ciò che serve, idealmente nulla in modo diretto.

Errori tipici di progettazione

• Dimensionare sul download ignorando l'upload necessario ai backup.
• Affidarsi a una linea sola per servizi che l'azienda considera indispensabili.
• Trascurare la latenza scegliendo l'offerta solo in base ai Mbps.
• VPN improvvisate su connessioni dinamiche, che si rompono a ogni cambio di IP (qui un DDNS o, meglio, un IP statico risolvono).

In sintesi

Il cloud ibrido sposta il baricentro dell'affidabilità sulla rete: serve banda simmetrica dimensionata sull'upload reale, bassa latenza verso i nodi cloud, e ridondanza con dual WAN e IP statico per i servizi critici. Il collegamento tra sede e cloud va progettato e protetto come parte dell'infrastruttura, perché è esattamente lì che un'architettura ibrida si rompe per prima.