zachull.com Static Cloud Migration

Overview

Replacing a Lightsail WordPress site with a static Astro portfolio served from S3, CloudFront, Route 53, and ACM.

Problem This Project Solves

My existing WordPress site had become stale, carried more maintenance overhead than I needed, and exposed features I no longer wanted to support. The comment system in particular had attracted suspicious activity, which pushed me to reduce the attack surface immediately and rethink the site more deliberately.

Goals

In the short term, I wanted to reduce unnecessary exposure on the existing WordPress site while preparing a better replacement. Disabling comments addressed the immediate concern, but it did not solve the larger problem: the site was outdated, harder to maintain than it needed to be, and lacked a clean path for ongoing improvement.

The long-term goal is to turn zachull.com into an automated portfolio platform that can display ongoing and completed projects, what I am currently learning, and up-to-date professional contact information.

Planned Architecture

The target architecture for zachull.com is a low-cost static hosting path built around managed AWS edge services:

• Astro builds the static website from version-controlled project files.
• GitHub remains the source of truth for site code and public-safe content.
• Amazon S3 stores the compiled static build output.
• CloudFront serves the site at the edge and becomes the public delivery layer.
• Route 53 manages DNS for the domain and directs public traffic to CloudFront.
• AWS Certificate Manager provides TLS coverage for the custom domain.
• GitHub Actions is planned as the deployment mechanism for future build-and-publish automation.
• Terraform is planned later, after the manual architecture is proven and documented.

Design Decisions

The previous WordPress deployment gave me a functional public site, but it also introduced maintenance overhead I did not need for a portfolio that is primarily static content. A static architecture reduces the amount of running application infrastructure I have to patch, monitor, and pay for while still giving me room to learn meaningful cloud engineering concepts.

This migration is intentionally designed around a few priorities:

• Lower recurring cloud cost than an always-on WordPress host
• Less operational burden for a mostly static website
• Cleaner version control through GitHub
• A stronger deployment story than manual website edits
• A public project that connects front-end code, cloud infrastructure, DNS, TLS, and automation

This keeps the site aligned with the kind of infrastructure work I want to become better at: clear boundaries, lower overhead, repeatable deployment, and well-documented tradeoffs.

Implementation Path

The project is being developed in stages so that each part of the system is understandable before I automate it.

1. Build the portfolio site locally in Astro.
2. Track the project in GitHub and establish clean commit history.
3. Create the AWS hosting path using S3, CloudFront, Route 53, and ACM.
4. Test the new site through a preview or temporary endpoint before changing public DNS.
5. Cut over zachull.com from the existing WordPress host to the new static architecture.
6. Add GitHub Actions deployment automation using AWS OIDC rather than long-lived AWS credentials.
7. Convert the proven hosting design into Terraform-managed infrastructure.

What I’m Learning

This project is giving me a practical path through several cloud and operations concepts that are easier to understand when they are tied to a real deliverable:

• How static site builds differ from server-rendered or CMS-backed websites
• How S3, CloudFront, Route 53, and ACM fit together in a public hosting path
• How to think about DNS migration and cutover planning without creating avoidable disruption
• Why deployment automation should use scoped, temporary credentials instead of long-lived secrets
• How content structure, code structure, and infrastructure decisions affect long-term maintainability
• When to prove an architecture manually before codifying it in Terraform

Current Status

The Astro portfolio site is under active development and tracked in GitHub. The content model, homepage, About page, and initial project documentation are in place.

The next implementation phase is the AWS hosting path: S3, CloudFront, Route 53, and ACM, followed by public DNS cutover from the existing WordPress site. GitHub Actions deployment automation and Terraform-managed infrastructure are planned after the manual architecture is proven.

Planned Improvements

• Complete the AWS hosting path with S3, CloudFront, Route 53, and ACM.
• Add a deployment workflow in GitHub Actions using an AWS OIDC role.
• Migrate any WordPress content worth retaining into Markdown pages or managed static assets.
• Add diagrams showing the request path from Route 53 through CloudFront to S3.
• Document the DNS cutover and rollback plan.
• Convert the proven AWS hosting resources into Terraform-managed infrastructure.