Laboratorio dimostrativo · Cloud Architecture
Laboratorio Cloud Architect. Le decisioni dietro un sito statico.
Questo laboratorio dimostrativo documenta le decisioni di un’architettura web statica: quali componenti usare, come regolare l’accesso all’origine e quali attività lasciare fuori dal modulo. È lo stesso esempio Terraform descritto nella pagina Cloud Engineer, esaminato dal punto di vista della progettazione.
Il contesto
Un requisito preciso
Il requisito è distribuire file pubblici attraverso una CDN, mantenendo il bucket di origine non pubblico. “Privato” riguarda l’accesso diretto a S3: i contenuti distribuiti ai visitatori restano pubblici. Il modello non comprende un’area riservata o un’applicazione dinamica.
Il flusso progettato
L’architettura del laboratorio.
Visitatore
Richiesta al dominio del sito; redirect da HTTP a HTTPS e certificato personalizzato.
CloudFront
Distribuzione pubblica, policy di cache dedicata e richieste all’origine firmate con OAC.
Origine S3 privata
Endpoint REST regionale, accesso pubblico bloccato e lettura consentita alla distribuzione indicata.
Il vincolo da rispettare
Decidere cosa includere
L’architettura deve rendere leggibili accesso, trasporto e cache. Il perimetro scelto comprende una sola origine S3 regionale e una distribuzione CloudFront. Dominio, certificato e pubblicazione dei file sono prerequisiti o attività esterne al modulo.
Il rilascio, per passaggi
Le decisioni architetturali
Separare CDN e origine
CloudFront usa l’endpoint REST regionale di S3, con Origin Access Control e richieste firmate. La policy concede alla distribuzione la lettura degli oggetti. Il bucket ha accesso pubblico bloccato e ACL disabilitate; non viene configurato come S3 website endpoint.
Richiedere un certificato personalizzato
Per impostare TLSv1.2_2021, la distribuzione richiede dominio e certificato ACM in us-east-1, con supporto SNI. Il certificato deve coprire il dominio. Il modulo non emette certificati, non ne completa la validazione e non crea record DNS.
Definire il comportamento della cache
La policy prevede TTL minimo zero, predefinito 60 secondi e massimo 300 secondi. Cookie e query string non differenziano la cache. È una scelta per file pubblici uguali per tutti; aggiornamento dei contenuti e invalidazioni richiedono una procedura dedicata.
Dichiarare i confini operativi
Il versioning conserva versioni degli oggetti, ma non costituisce un backup indipendente. Il modello non definisce failover tra origini, autenticazione dei visitatori o routing SPA. Logging, WAF e strategia di backup richiedono decisioni aggiuntive.
Il collaudo del progetto
Cosa rende esplicito il laboratorio
Gli esiti riguardano il modello e i suoi vincoli, non misure di un servizio cloud operativo.
- Accesso, HTTPS e cache
- Decisioni motivate
Il codice separa i permessi sull’origine dalla distribuzione pubblica e rende visibili le scelte sui protocolli e sulla cache.
- Dominio e certificato esterni
- Prerequisiti visibili
Gli input richiesti dichiarano ciò che deve esistere prima di un eventuale deployment e ciò che il modulo non crea.
- Una sola origine regionale
- Confini documentati
Il modello distingue la distribuzione dei contenuti dalle scelte ulteriori su recupero, continuità del servizio e protezioni applicative.
Materiali consultabili
Codice e verifiche
Il perimetro dei risultati
Cosa coprono le verifiche.
I test con mock e la validazione Terraform controllano il modello localmente. Non verificano proprietà del dominio, validità del certificato, autorizzazioni AWS o comportamento reale della distribuzione. L’esempio non comprende contenuti autenticati, elaborazione dinamica o collaudo end-to-end. Non ci sono misure di costi, latenza o disponibilità, né SLA dimostrati.
Oltre la pubblicazione
Il valore delle decisioni esplicite
Questo laboratorio mostra quali scelte devono accompagnare un modulo infrastrutturale: requisiti del contenuto, accesso all’origine, certificati, cache e recupero. Un impiego reale richiede di completare il perimetro in base al servizio e verificarlo nell’ambiente di destinazione.
L’autore
Eddy Boscolo.
Da oltre 17 anni lavoro con le infrastrutture IT. Mi occupo di architetture AWS e Azure, amministrazione Linux e automazione con Terraform, Ansible, Docker e Kubernetes, collaborando con team tecnici e responsabili di progetto.
Opero da Vicenza e offro consulenza da remoto per le aziende del Veneto.