Demonstration lab · Cloud Architecture
Cloud Architecture lab. The decisions behind a static site.
This demonstration lab documents the decisions behind a static web architecture: which components to use, how to control origin access and which tasks to leave outside the module. It is the same Terraform example described in the Cloud Engineering article, examined from a design perspective.
The context
A specific requirement
The requirement is to distribute public files through a CDN while keeping the origin bucket non-public. 'Private' refers to direct S3 access: content delivered to visitors remains public. The model does not include a members-only area or a dynamic application.
Illustrative diagram
A proposed flow, not an operational service.
An illustration of the Cloud Architecture model, the same Terraform lab as the Cloud Engineering article. Content delivered to visitors is public; direct access to the S3 origin is blocked. The domain, certificate and file publication remain outside the module. Local mock checks only: no AWS deployment.
Open the full-resolution diagramThe proposed flow
The lab architecture.
Visitor
Request to the site's domain; HTTP-to-HTTPS redirect and a custom certificate.
CloudFront
Public distribution, a dedicated cache policy and origin requests signed with OAC.
Private S3 origin
Regional REST endpoint, public access blocked and read access granted to the specified distribution.
The constraint
Decide what to include
The architecture needs to make access, transport and caching clear. The chosen scope includes a single regional S3 origin and one CloudFront distribution. The domain, certificate and file publication are prerequisites or tasks outside the module.
Design, step by step
Architecture decisions
Separate the CDN from the origin
CloudFront uses S3's regional REST endpoint, with Origin Access Control and signed requests. The policy grants the distribution permission to read objects. The bucket blocks public access and has ACLs disabled; it is not configured as an S3 website endpoint.
Require a custom certificate
To configure TLSv1.2_2021, the distribution requires a domain and an ACM certificate in us-east-1, with SNI support. The certificate must cover the domain. The module does not issue certificates, complete certificate validation or create DNS records.
Define cache behaviour
The policy sets a minimum TTL of zero, a default of 60 seconds and a maximum of 300 seconds. Cookies and query strings do not vary the cache. This suits public files that are the same for everyone; content updates and invalidations require a dedicated procedure.
State the operational boundaries
Versioning retains object versions but is not an independent backup. The model does not define origin failover, visitor authentication or SPA routing. Logging, WAF and a backup strategy require additional decisions.
The documented model
What the lab makes explicit
The outcomes concern the model and its constraints, not measurements from an operational cloud service.
- Access, HTTPS and caching
- Reasoned decisions
The code separates origin permissions from public delivery and makes protocol and cache choices visible.
- External domain and certificate
- Visible prerequisites
Required inputs state what must exist before any deployment and what the module does not create.
- A single regional origin
- Documented boundaries
The model distinguishes content delivery from additional decisions about recovery, service continuity and application protections.
Available materials
Code and verification
Scope of the results
What the checks cover.
Mock tests and Terraform validation check the model locally. They do not verify domain ownership, certificate validity, AWS permissions or the distribution's real behaviour. The example does not include authenticated content, dynamic processing or end-to-end acceptance testing. There are no cost, latency or availability measurements, nor demonstrated SLAs.
Before any deployment
The value of explicit decisions
This lab shows which decisions need to accompany an infrastructure module: content requirements, origin access, certificates, caching and recovery. Real use requires completing the scope to suit the service and verifying it in the target environment.
The author
Eddy Boscolo.
For over 17 years, I have worked with IT infrastructure. My work covers AWS and Azure architecture, Linux administration and automation with Terraform, Ansible, Docker and Kubernetes, alongside technical teams and project managers.
Based in Vicenza, I work with businesses across Veneto and remotely throughout Italy.