Tuttavia, esistono casi in cui sfruttando l\u2019AWS Backbone<\/strong>, \u00e8 possibile ottenere prestazioni<\/strong> del tutto simili, a costi<\/strong> pi\u00f9 contenuti.\u00a0<\/p>\n\n\n\n L\u2019AWS backbone, o AWS Global Network, \u00e8 l\u2019infrastruttura in fibra ottica privata ad alte prestazioni di Amazon Web Services che collega tra loro AWS Regions, Availability Zones ed Edge Locations dislocate in tutto il mondo. Gestisce il routing e le performance di rete, garantendo costantemente bassa latenza<\/strong> e throughput elevato<\/strong> tra i servizi AWS.<\/p>\n\n\n\n In questo articolo, vediamo quando preferire questa rete ad alta velocit\u00e0 e bassa latenza rispetto alla replica dell\u2019infrastruttura su pi\u00f9 region e come sfruttarla in modo ottimale per migliorare l\u2019esperienza utente.<\/p>\n\n\n\n Gli AWS Edge Services sono funzionalit\u00e0 cloud progettate per portare elaborazione, storage e networking pi\u00f9 vicini all\u2019utente finale, invece di affidarsi esclusivamente a un\u2019infrastruttura centralizzata nelle AWS Regions. L\u2019obiettivo \u00e8 ridurre la latenza accorciando fisicamente la distanza che i dati devono percorrere.<\/p>\n\n\n\n Alcuni esempi di edge services sono:<\/p>\n\n\n\n Uno di questi servizi \u00e8 stato la chiave della nostra soluzione.<\/p>\n\n\n\n L\u2019obiettivo era creare una web application che consentisse agli operatori di distributori automatici di caff\u00e8 di accedere alle macchine e fornire supporto remoto in caso di problemi. In passato questo veniva fatto con TeamViewer, ma i nuovi modelli di macchine non lo supportavano pi\u00f9, perci\u00f2 \u00e8 stata necessaria una soluzione custom basata sul Remote Desktop Protocol (RDP).<\/p>\n\n\n\n Abbiamo deciso di utilizzare Apache Guacamole<\/strong>, un gateway clientless per il remote desktop che supporta RDP.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Quando un operatore installa una nuova macchina, la registra tramite la web app, che la inserisce nell\u2019OpenVPN server e invia il profilo VPN al servizio di telemetria.<\/p>\n\n\n\n Il servizio di telemetria \u00e8 una web app che utilizza IoT Core<\/strong> e gira nello stesso account AWS della soluzione per il remote desktop. Questo servizio gestisce e fornisce informazioni e funzionalit\u00e0 relative alle macchine da caff\u00e8.<\/p>\n\n\n\n Se un utente ha un problema con una macchina, pu\u00f2 premere un pulsante per inviare una richiesta di supporto, dando inizio al seguente flusso:<\/p>\n\n\n\n L\u2019intera applicazione era stata distribuita nella Region Irlanda (eu-west-1)<\/strong>, la stessa del servizio di telemetria.<\/p>\n\n\n\n Purtroppo la connessione RDP presentava problemi di latenza. Le macchine erano sparse in tutto il mondo e alcune aree disponevano di connessioni internet lente o instabili. In queste condizioni, la connessione RDP risultava quasi inutilizzabile.<\/p>\n\n\n\n Serviva quindi una soluzione per ridurre la latenza tra macchina, operatore e istanza Guacamole.<\/p>\n\n\n\n Un\u2019architettura multi-region consiste nel distribuire i carichi di lavoro in pi\u00f9 AWS Regions, in base alla distribuzione degli utenti. In questo modo, la maggior parte degli utenti si collega a una Region geograficamente vicina, minimizzando la latenza.<\/p>\n\n\n\n Tuttavia, questo approccio comporta alcuni compromessi:<\/p>\n\n\n\n Vediamo come questi aspetti impattano il nostro caso:<\/p>\n\n\n\n Sapevamo per\u00f2 come progettare una soluzione pi\u00f9 conveniente.<\/p>\n\n\n\n Nel nostro caso, il vero punto di svolta \u00e8 stato AWS Global Accelerator<\/strong>.<\/p>\n\n\n\n Grazie a Global Accelerator, abbiamo potuto distribuire l\u2019infrastruttura in una sola Region e, al tempo stesso, ridurre la latenza, rendendo la connessione RDP fluida, come se tutti gli utenti si trovassero nella stessa Region dell\u2019infrastruttura.<\/p>\n\n\n\n Questo \u00e8 possibile perch\u00e9 le connessioni degli utenti e delle macchine viaggiano su Internet solo fino alla AWS Edge Location<\/strong> pi\u00f9 vicina. Da l\u00ec in poi, il traffico viene instradato attraverso l\u2019AWS Backbone, che garantisce velocit\u00e0 elevata e bassa latenza per la connessione RDP.<\/p>\n\n\n\n Con Global Accelerator siamo riusciti a ottenere performance molto vicine a quelle di una soluzione multi-region, ma con costi poco superiori a quelli di una distribuzione single-region.<\/p>\n\n\n\n <\/p>\n\n\nAWS Edge Services<\/h2>\n\n\n\n
\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\nUse Case: Global Remote Desktop Service<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/08\/image2-1024x850.png\")
<\/figure><\/div>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\nIl limite del Single-Region<\/h2>\n\n\n\n
Multi-Region Deployment VS AWS Backbone<\/h2>\n\n\n\n
Multi-Region Deployment<\/h4>\n\n\n\n
\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
Anche se la maggior parte dell\u2019infrastruttura era serverless (con pagamento a consumo), DynamoDB Global Tables<\/strong> comportava costi moltiplicati per il numero di regioni (N): storage, operazioni di scrittura e aggiornamento replicate in ogni regione, pi\u00f9 il traffico inter-region per la sincronizzazione.
Nel nostro caso, il volume di dati non era enorme, quindi sostenibile.\u00a0 Il costo realmente problematico era invece la replica dell\u2019istanza EC2 con OpenVPN server. Ogni regione richiedeva una licenza separata di OpenVPN, con un costo complessivo ben superiore a quello accettabile.
<\/li>\n<\/ul>\n\n\n\nValorizzare al massimo l\u2019AWS Backbone tramite servizi Edge<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/08\/image1-1024x850.png\")
<\/figure><\/div>\n\n\n