{"id":1463,"date":"2020-06-26T00:14:36","date_gmt":"2020-06-25T22:14:36","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1463"},"modified":"2021-03-17T15:20:05","modified_gmt":"2021-03-17T14:20:05","slug":"hostare-un-sito-statico-su-aws-cloudfront-e-sempre-la-scelta-giusta","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/hostare-un-sito-statico-su-aws-cloudfront-e-sempre-la-scelta-giusta\/","title":{"rendered":"Hostare un sito statico su AWS: CloudFront \u00e8 sempre la scelta giusta?"},"content":{"rendered":"

Introduzione<\/span><\/h2>\n

Il binomio di servizi CloudFront<\/strong> – S3<\/strong> fa oramai parte delle pratiche consolidate di molte aziende che hanno la necessit\u00e0 di ospitare un sito statico (o parte di esso) a prezzi contenuti senza rinunciare per\u00f2 ai crismi di sicurezza<\/strong> (come ad esempio la terminazione SSL sul proprio dominio). Ma \u00e8 vero che \u00e8 l\u2019unica via percorribile? Esistono altri modi per conseguire il medesimo risultato che per\u00f2 rispondono ad esigenze differenti? In questo articolo si prova a dare una risposta!<\/span><\/p>\n

Problema<\/span><\/h2>\n

Immaginiamo di dover rispondere alla seguente esigenza: il team di frontend della propria azienda richiede di poter testare ci\u00f2 che ha appena sviluppato su un\u2019infrastruttura simile a quella finale per mostrare anche solo a livello visivo che il risultato sia quello aspettato. In particolare, avrebbe piacere nell\u2019avere a disposizione un nome di dominio differente per ogni feature in modo tale da non introdurre livelli di inconsistenza relativi ai path.<\/span><\/p>\n

Anche senza prendere la calcolatrice in mano per fare i conti tentando di prevedere il traffico gestito, \u00e8 subito chiaro che mantenere una differente distribuzione CloudFront per ogni feature e per ogni progetto frontend possa generare inutili complicazioni a livello di gestione dell\u2019account AWS stesso. Vale la pena far notare che non \u00e8 possibile creare due origin differenziate dalla path principale e collegarle a due domini differenti all\u2019interno della stessa distribuzione CloudFront senza incorrere in almeno un redirect che porterebbe ai problemi di path sopra citati).<\/span><\/p>\n

Soluzione<\/span><\/h2>\n

In prima istanza constatiamo la natura effimera di questi deploy. Ci\u00f2 richiede che vi siano dei tempi relativamente ristretti di creazione e rimozione di questi elementi infrastrutturali. Per raggiungere questo obiettivo \u00e8 utile quindi la condivisione delle medesime risorse da parte di pi\u00f9 interlocutori in modo tale da minimizzare l\u2019overhead introdotto.<\/span><\/p>\n

La soluzione proposta \u00e8 composta dai seguenti elementi infrastrutturali:<\/span><\/p>\n