Two controlled paths serve and update the static website.

Visitor delivery

  1. BrowserRequests HTTPS content
  2. CloudFrontApplies TLS, headers, and caching
  3. Private S3Allows the approved distribution

Deployment

  1. GitHub ActionsRequests short-lived identity
  2. AWS OIDC roleEvaluates trusted claims
  3. CDK and S3Update infrastructure and content

Keep the storage origin private

Amazon S3 is durable object storage, but the bucket does not need to become a public website endpoint. CloudFront can retrieve approved objects through origin access control while S3 public-access blocking remains enabled. Visitors interact with the distribution rather than the bucket.[1][2]

Put delivery behavior at the edge

CloudFront provides the public delivery layer for TLS, compression, caching, and response policy. That separation makes browser-facing behavior explicit while keeping the origin narrowly accessible.[4]

  • ACM supplies the certificate used by CloudFront.
  • Security headers are applied consistently through a response-headers policy.
  • HTML and long-lived assets receive different cache controls.
  • Invalidations are reserved for paths that cannot wait for normal expiry.

Treat DNS authority as a separate decision

Hosting a website on AWS does not require moving every DNS record to Route 53. Dagitali currently retains GoDaddy as authoritative DNS to reduce risk to existing email and service records, while the infrastructure supports an optional Route 53 mode for a deliberate future migration.

Design principle: Infrastructure as code should not force a broader operational migration than the system actually needs.

Replace stored deployment keys with short-lived identity

GitHub Actions can request short-lived AWS credentials through OpenID Connect. AWS evaluates repository, branch, environment, and workflow claims against the role’s trust policy before issuing a session. The workflow does not need a long-lived AWS access key stored as a GitHub secret.[3]

Separate infrastructure deployment from content delivery

The deployment workflow can optionally deploy CDK-defined resources, read stack outputs, upload static content with file-specific cache controls, and invalidate selected CloudFront paths. Keeping these operations explicit makes routine content changes understandable without hiding infrastructure changes.

Build cost safeguards into the design

A low-traffic static site should avoid always-on compute and unbounded optional services. Useful safeguards include AWS Budgets notifications, retained S3 versions with lifecycle rules, bounded logging retention, explicit cache behavior, and an optional contact-form runtime that is deployed only when configured.

A compact architecture review checklist

  • Is the S3 origin private with public access blocked?
  • Can only the intended CloudFront distribution retrieve objects?
  • Are TLS, security headers, compression, and caching explicit?
  • Does deployment use short-lived identity with a narrow trust policy?
  • Are HTML and versionable assets cached differently?
  • Are DNS and email dependencies understood before authority changes?
  • Are budgets, retention, and optional runtime costs bounded?
  • Can maintainers verify the deployment and recover from failure?

Sources and further reading

  1. AWS CloudFront documentation: Restrict access to an Amazon S3 origin .
  2. Amazon S3 documentation: Block Public Access .
  3. GitHub documentation: Configure OpenID Connect in Amazon Web Services .
  4. AWS CloudFront documentation: Manage how long content stays in the cache .

Related Dagitali evidence: The dagitali.com technical profile describes the production architecture and its current boundaries. The source repository remains private, so the profile does not present inaccessible GitHub links as public proof.

Continue exploring

Related serviceReview cloud and delivery services

Related insightReview operability beyond deployment

Apply the guidanceExplore the Engineering Clarity Review