This article walks through the architectural decisions behind oriehulan.com, my professional website.

The site was intentionally designed to be simple, lightweight, and inexpensive to operate, while still reflecting how I approach system design and the use of cloud services in real-world scenarios. Rather than focusing on tools for their own sake, this write-up explains the reasoning behind key decisions and how a static, serverless approach fit the problem.

What follows is a breakdown of how the site was built, the services involved, and the considerations that guided those choices.

Why I Built This

I wanted a personal website that was clean, maintainable, and inexpensive to operate - something that reflected how I think about systems, rather than how many tools I could stack together.

The goal was not to over-engineer a portfolio. It was to design something intentional: simple where it could be, and thoughtfully designed where it mattered. I wanted a site that was easy to reason about, easy to evolve, and did not carry unnecessary operational weight.

Core Website Architecture

The site is built using HTML, CSS, and JavaScript. I intentionally avoided heavy frameworks and complex build pipelines to keep the structure straightforward and easy to maintain over time.

It is hosted as a static website on Amazon S3, which keeps the hosting layer extremely simple while still being reliable and performant. There is no always-on backend infrastructure, no servers to manage, and very little that can break unexpectedly. For this type of project, that simplicity is a feature.

Dynamic Content Without a CMS

Even though the site is static, the blog and project sections are not hardcoded page by page.

Content is stored as JSON, and JavaScript loops through that data at runtime to generate the cards and links dynamically. This keeps content structured and consistent without introducing a CMS, database, or administrative interface.

For a personal site maintained by a developer, this strikes a good balance. Adding new content is quick and predictable, while the hosting model stays fully static. The focus here is on maintainability and clarity, not on building editor-driven workflows.

Serverless Contact Form Architecture

The contact form is where the architecture leans into serverless AWS services.

Rather than running a traditional backend server, the form follows a simple event-driven flow:

A client-side form handles user input

Cloudflare Turnstile is used for bot protection

Submissions go through Amazon API Gateway

API Gateway invokes a Lambda function

The Lambda function sends email using Amazon SES

Sensitive configuration is handled securely and never exposed client-side. There are no long-running services and nothing sitting idle. The workflow only runs when the form is used, which keeps both cost and operational complexity low while still being robust.

DNS, SSL, and Real-World Constraints

The domain is registered with an external provider, while DNS is handled through Route 53. This setup provides better control and integrates cleanly with other AWS services.

The site is fronted by CloudFront, which serves content from edge locations and sits in front of the S3 bucket. SSL is managed using AWS Certificate Manager, which is a particularly useful detail in this setup: when used with CloudFront, ACM certificates are provided at no additional cost and are fully managed, removing both certificate fees and renewal work.

One practical challenge came up around SSL support for the root (apex) domain. While subdomains like www are usually straightforward, root domains can introduce limitations depending on how DNS and certificates are handled. Using Route 53 alias records in combination with CloudFront resolved this cleanly.

It was a good reminder that real-world systems do not always behave exactly like diagrams suggest - and that understanding those details matters.

Cost and Operational Considerations

Keeping ongoing costs low and predictable was an explicit design goal.

This setup achieves that by:

Using static hosting wherever possible

Relying on managed AWS services

Avoiding always-on compute

Paying only for actual usage

The result is a site that is inexpensive to operate, requires very little maintenance, and remains easy to reason about.

Closing Thoughts

This site is intentionally simple. It is not meant to be a platform or a product - it is a clear, lightweight way to showcase who I am and how I approach building systems.

The focus throughout was on making deliberate choices, keeping complexity in check, and using cloud services thoughtfully rather than excessively. Even for something small, those decisions matter.