01
VISITOR2 components
AWS / TERRAFORM / CLOUD
dzhaner.com Infrastructure
The infrastructure behind this portfolio, built as a real AWS architecture rather than treating the website as an isolated frontend.
CASE STUDY / ARCHITECTURE
dzhaner.com / Secure Static AWS Edge
Public CDN edge with a private S3 origin, managed DNS/TLS and infrastructure defined as code.
01
dzhaner.com / Secure Static AWS EdgeAWS · TERRAFORM · SECUREPublic CDN edge with a private S3 origin, managed DNS/TLS and infrastructure defined as code.
02
PUBLIC EDGE3 components
03
ORIGIN2 components
04
SOURCE OF TRUTH2 components
01THE PROBLEM
Build a website without making the infrastructure an afterthought.
A static portfolio does not require a complicated application stack. The challenge was therefore not compute — it was designing a small architecture with sensible security boundaries, HTTPS, DNS, global delivery and infrastructure that could be reproduced.
The website is treated as an infrastructure project as much as a frontend project. Every major AWS resource is defined through Terraform rather than configured manually.
02ARCHITECTURE
Public edge, private origin.
CloudFront is the public entry point. S3 stores the website content but is not exposed as a public website endpoint.
03SECURITY
The S3 bucket is not the public interface.
This creates a clear security boundary: users interact with the CDN, while the storage layer remains an internal origin.
- S3 Block Public Access enabled.
- Bucket remains private.
- CloudFront uses Origin Access Control.
- Bucket policy is scoped to the CloudFront distribution.
- HTTPS is enforced at the CloudFront edge.
04DNS & TLS
Route 53 and ACM handle the public endpoint.
Route 53 hosts the public DNS zone and points the apex domain and www hostname to CloudFront.
The TLS certificate is provisioned through AWS Certificate Manager in the region required by CloudFront. DNS validation is handled through Route 53.
05INFRASTRUCTURE AS CODE
Terraform is the source of truth.
This keeps infrastructure reviewable, repeatable and easy to change. The same approach can later be extended to automated deployment through GitHub Actions and AWS OIDC.
- main.tf — Route 53 resources.
- s3.tf — private website bucket and policy.
- cloudfront.tf — distribution and origin access.
- acm.tf — TLS certificate and validation.
- providers.tf — AWS providers and tagging.
- variables.tf / outputs.tf — reusable configuration.
06ENGINEERING DECISIONS
Small system, deliberate choices.
Why S3?
The website is static, so object storage is sufficient. There is no reason to introduce a server or container just to serve HTML.
Why CloudFront?
It provides the public edge, HTTPS termination and CDN delivery while keeping the S3 origin private.
Why Terraform?
The infrastructure itself is part of the portfolio. Terraform makes the architecture explicit instead of hiding it in console configuration.
Why not expose S3 directly?
There is no benefit in making the storage layer publicly reachable when CloudFront can act as the controlled public edge.
07RESULT
A simple website with real infrastructure behind it.
The final system keeps the application layer deliberately lightweight while demonstrating several core cloud engineering concerns: DNS, certificates, CDN architecture, private object storage, identity-based origin access and infrastructure as code.
The architecture is also intentionally extensible. Deployment automation, security hardening, monitoring and additional AWS services can be added without replacing the foundation.