Stop over-engineering your personal brand site; here is how to pivot from a fragile, expensive EC2 instance to a bulletproof architecture without breaking the bank.

Over-Engineering 101: Why Your Resume Site Doesn’t Need Kubernetes

I was scrolling through the subreddit this morning and caught your thread, “Thoughts on my new professional website?”. First off, the design is sleek. The dark mode toggle? Chef’s kiss. But then I looked at the comments. You mentioned you’re paying $45 a month to host this on a t3.medium because you “might need the RAM” for your Docker containers. I nearly spilled my coffee.

Let me tell you a quick war story. Back in my early days at a startup that no longer exists, we had a junior dev named Kevin. Kevin was brilliant but loved tools more than solutions. He deployed our company’s static “Coming Soon” landing page on a 3-node Kubernetes cluster. The first time marketing sent an email blast, the cluster didn’t scale fast enough, the load balancer choked, and our “Coming Soon” page turned into a 503 error. We were paying hundreds of dollars to host an error message. Don’t be Kevin.

The “Why”: You Are Solving the Wrong Problem

The root cause here isn’t that your code is bad; it’s that your architecture is mismatched to your workload. You are treating a Read-Heavy, Write-Never application (your portfolio) like a dynamic transactional database.

When you host a static React or Vue app on a raw Linux server (let’s call it prod-web-01), every time a recruiter clicks your link, your server has to wake up, accept the connection, read the file system, and serve the assets. If Reddit gives you the “Hug of Death” (a traffic spike), prod-web-01 runs out of worker threads and dies. You are paying for compute power you don’t need to serve files that never change.

Here are three ways to fix this, ranging from a band-aid to a total architectural shift.

Solution 1: The Quick Fix (Nginx Caching)

If you absolutely insist on keeping your current EC2 instance because you want the Linux practice (I respect the hustle), you need to stop your server from sweating over every request. We need to implement aggressive caching at the Nginx level.

Right now, your Nginx config probably looks like a default install. Let’s force the browser to cache your assets so they don’t hit your server repeatedly, and enable gzip to lower the bandwidth.

Edit your Nginx config:

server {
    listen 80;
    server_name your-portfolio.com;
    root /var/www/portfolio;

    # Gzip Compression: Reduce file size before sending
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;

    location / {
        try_files $uri $uri/ /index.html;
    }

    # The Magic: Cache static assets for 1 year
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 365d;
        add_header Cache-Control "public, no-transform";
    }
}

Pro Tip: Always run nginx -t before reloading. I once took down payment-gateway-02 because I missed a semicolon. Never again.

Solution 2: The Permanent Fix (S3 + CloudFront)

This is the industry standard approach. We kill the server entirely. No patching, no SSH, no downtime.

We move your build artifacts (the HTML/CSS/JS) into an AWS S3 bucket (storage) and put CloudFront (CDN) in front of it. CloudFront replicates your site to edge locations globally. If a recruiter in London views your site, they load it from a London server, not your US-East-1 bucket.

The “Hack” to make this work:

Since you are likely using a Single Page Application (SPA) like React, S3 gets confused when a user refreshes a sub-page (like /about) because that file doesn’t actually exist—it’s handled by client-side routing. You need to configure the error document to redirect back to index.html.

# AWS CLI command to configure the bucket website hosting
aws s3 website s3://your-portfolio-bucket/ --index-document index.html --error-document index.html

This costs pennies. Literally. Your $45/month bill drops to about $0.50.

Solution 3: The “Nuclear” Option (Vercel / Netlify)

If you want the job more than you want to manage infrastructure, stop managing infrastructure. This is what I tell every junior dev who is stuck in “DevOps hell” trying to configure SSL certificates manually.

Connect your GitHub repo to Vercel or Netlify. They handle the build pipeline, the CDN, the SSL, and the cache invalidation automatically. It feels like cheating, but in the professional world, shipping is the only metric that matters.

My advice? Take the Nuclear Option for your main site. Save the EC2 instances for your homelab or specific backend projects where you actually need to demonstrate Linux proficiency.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions