GitHub Pages vs. AWS S3: Ein technischer Vergleich GitHub Pages vs. AWS S3: A Technical Comparison

Als ich meine Portfolio-Website gebaut habe, stand ich vor einer klassischen Entscheidung: Wie hoste ich eine leichte, statische Website (HTML, CSS und minimales JS), die schnell, sicher und professionell ist?

Da mein Portfolio hauptsächlich aus Text und Code besteht – keine schweren Videodateien oder riesigen Bildergalerien – brauchte ich keine komplexe serverseitige Verarbeitung. Ich brauchte einen Ort zum Speichern von Dateien und einen schnellen Weg, sie auszuliefern.

Um die Vor- und Nachteile wirklich zu verstehen, habe ich beschlossen, den exakt gleichen Codebasis gleichzeitig in zwei verschiedenen Umgebungen bereitzustellen:

1. GitHub Pages: Die "Kostenlose & Einfache" Option.
2. AWS S3 + CloudFront: Die "Professionelle & Skalierbare" Option.

Hier ist ein detaillierter technischer Vergleich, wie beide Systeme eine leichte statische Site verarbeiten.

Der Herausforderer 1: GitHub Pages (Der kostenlose Standard)

GitHub Pages ist die Standardlösung für Open-Source-Projekte und persönliche Portfolios. Es ist speziell für statische Sites konzipiert.

Wie es funktioniert

Man schiebt den Code in ein GitHub-Repository. GitHub sucht dann nach einer index.html-Datei (oder einem Jekyll-Build-Prozess) und stellt sie über ihre Server via HTTPS bereit.

Die Architektur

• Storage: Git Repository.
• Server: GitHub's interne HTTP-Server.
• DNS: username.github.io (Subdomain) oder Custom Domain Mapping.
• SSL: Automatisch (Let's Encrypt Integration, die von GitHub gehandhabt wird).

Vorteile für eine leichte Site

• Kosten: 0 €. Wirklich kostenlos.
• CI/CD: Integriert. Jeder git push an den main-Branch löst eine automatische Bereitstellung aus. Das ist der schnellste Workflow für Iterationen.
• Setup: Dauert weniger als 5 Minuten. "Pages" in den Repo-Einstellungen aktivieren, und schon ist es fertig.

Nachteile

• Cache-Control: Man hat begrenzte Kontrolle über HTTP-Cache-Header. GitHub setzt eigene Standardwerte, die möglicherweise nicht für bestimmte Asset-Versionierungsstrategien optimal sind.
• Jekyll Interference: Wenn man keine .nojekyll-Datei verwendet, versucht GitHub möglicherweise, die Site durch Jekyll (einen Ruby Static Site Generator) zu verarbeiten, was die Ordnerstruktur oder Dateinamen mit Unterstrichen stören kann.
• Branding: Auch wenn man eine Custom Domain verwenden kann, ist die zugrundeliegende Infrastruktur sichtbar "GitHub".

Der Herausforderer 2: AWS S3 + CloudFront (Der Enterprise Stack)

Für die Produktionsversion meiner Site verwende ich Amazon Web Services (AWS). Das ist nicht nur "Hosting"; es ist Infrastructure-as-Code. Für eine statische Site benötigen wir vier spezifische Dienste, die zusammenarbeiten.

1. AWS S3 (Simple Storage Service)

Funktion: Objekt-Speicher.
S3 ist kein herkömmliches Dateisystem; es ist ein Objektspeicher. Er speichert die eigentlichen Dateien (index.html, styles.css, scripts.js).

• Konfiguration: Ich habe einen "Public Bucket" erstellt und meine Dateien hochgeladen.
• Static Website Hosting: Ich habe die Eigenschaft "Static Website Hosting" auf dem Bucket aktiviert. Das weist S3 an, index.html bereitzustellen, wenn ein Benutzer das Stammverzeichnis anfordert.
• Haltbarkeit: S3 bietet 99,999999999% (11 9's) Haltbarkeit. Meine Portfolio-Dateien sind hier sicherer als auf der Festplatte meines Laptops.

2. AWS CloudFront (Content Delivery Network)

Funktion: Geschwindigkeit & Global Caching.
Wenn Benutzer direkt auf meinen S3-Bucket aus Deutschland zugreifen würden, kämen die Daten aus der AWS-Region Frankfurt. Das ist schnell, aber CloudFront macht es augenblicklich.

• Edge Locations: CloudFront kopiert meine statischen Dateien in Hunderte von Rechenzentren (Edge Locations) weltweit. Wenn ein Benutzer in Berlin die Site anfordert, erhält er sie vom Berlin-Edge, nicht vom Origin-Server.
• Komprimierung: CloudFront komprimiert Dateien (Gzip/Brotli) automatisch am Edge. Da mein CSS und JS textbasiert sind, schrumpfen sie erheblich, bevor sie den Browser des Benutzers erreichen.
• HTTPS: CloudFront fungiert als sicherer Endpunkt. Er übernimmt die SSL/TLS-Terminierung.

3. AWS ACM (AWS Certificate Manager)

Funktion: SSL/TLS Zertifikate.
Um das "Schloss"-Symbol (HTTPS) auf einer Custom Domain wie harisn.de zu haben, benötigt man ein Zertifikat.

• Prozess: Ich habe ein öffentliches Zertifikat in ACM für harisn.de und *.harisn.de angefordert.
• Validierung: Da ich mein DNS über Route 53 verwalte, konnte ich den Domain-Besitz automatisch durch Hinzufügen eines CNAME-Eintrags validieren. Keine manuelle E-Mail-Verifizierung war nötig.
• Integration: Sobald ausgestellt, habe ich dieses Zertifikat einfach an meine CloudFront-Distribution angehängt. ACM kümmert sich um die automatische Erneuerung.

4. Amazon Route 53 (DNS)

Funktion: Traffic Routing.
Route 53 ist das Telefonbuch des Internets. Es sagt Browsern, wohin sie gehen sollen, wenn jemand harisn.de tippt.

• Alias Records: Im Gegensatz zu standard CNAME-Records können Route 53 "Alias Records" eine Root-Domain (harisn.de) direkt einer CloudFront-Distribution oder einem S3-Bucket zuordnen.
• Latency-Based Routing: Wenn ich mehrere Server hätte, könnte Route 53 Benutzer zum physisch nächstgelegenen weiterleiten. Für meine einzelne Site sorgt es für hohe Verfügbarkeit.

Vorteile für eine leichte Site

• Performance: Die Kombination aus CloudFront-Caching und Brotli-Komprimierung macht die Site unglaublich schnell, sogar auf mobilen Netzen.
• Kontrolle: Ich kann granulare Cache-Regeln festlegen (z.B. "Dieses Bild ein Jahr cachen, aber das HTML stündlich prüfen").
• Sicherheit: Ich könnte AWS WAF (Web Application Firewall) konfigurieren, wenn ich jemals spezifische Traffic-Muster blockieren müsste.

Nachteile

• Kosten: Während der S3-Speicher Pfennige kostet, kostet Route 53 etwa 0,50 €/Monat für die Hosted Zone. Der Datentransfer ist bis zu einem Limit kostenlos, aber hoher Traffic könnte Kosten verursachen.
• Komplexität: Das Einrichten der S3-Bucket-Policy, CloudFront-Origin und ACM-Validierung dauert etwa eine Stunde im Vergleich zu den 5 Minuten von GitHub.

Der Vergleich

Fazit: Warum ich beide nutze

Für ein leichtes Portfolio wie dieses ist GitHub Pages technisch ausreichend. Es ist schnell, sicher und kostenlos.

Ich habe mich jedoch entschieden, die AWS S3 + CloudFront-Setup beizubehalten, aus drei Gründen:

1. Kompetenznachweis: Als Ingenieur, der "Cloud Hosting"-Dienste anbietet, beweist die Nutzung von AWS, dass ich die zugrundeliegende Infrastruktur verstehe. Ich kann AWS-Dienste nicht verkaufen, wenn ich sie nicht selbst nutze.
2. Lernkurve: Die Verwaltung von S3-Bucket-Policies und CloudFront-Distributionen zwingt mich dazu, zu verstehen, wie das Internet tatsächlich funktioniert (DNS-Propagation, SSL-Handshakes, Caching-Header).
3. Skalierbarkeit: Wenn diese Site plötzlich viral geht oder ich schwere Assets hinzufüge, wird die AWS-Architektur skalieren, ohne dass ich etwas anfassen muss. GitHub Pages hat Nutzungsgrenzen, die einen plötzlichen Traffic-Anstieg einschränken könnten.

When I built my portfolio website, I faced a common developer dilemma: How do I host a lightweight, static website (HTML, CSS, and minimal JS) that is fast, secure, and professional?

Since my portfolio consists mostly of text and code—no heavy video files or massive image galleries—I didn't need complex server-side processing. I needed a place to store files and serve them fast.

To truly understand the trade-offs, I decided to deploy the **exact same codebase** to two different environments simultaneously:

1. GitHub Pages: The "Free & Easy" option.
2. AWS S3 + CloudFront: The "Professional & Scalable" option.

Here is a detailed technical comparison of how both systems handle a lightweight static site.

The Contender 1: GitHub Pages (The Free Standard)

GitHub Pages is the go-to solution for open-source projects and personal portfolios. It is designed specifically for static sites.

How it works

You push your code to a GitHub repository. GitHub then looks for an `index.html` file (or a Jekyll build process) and serves it over HTTPS via their servers.

The Architecture

• Storage: Git Repository.
• Server: GitHub's internal HTTP servers.
• DNS: `username.github.io` (subdomain) or Custom Domain mapping.
• SSL: Automatic (Let's Encrypt integration handled by GitHub).

Pros for a Lightweight Site

• Cost: $0. Truly free.
• CI/CD: Built-in. Every `git push` to the `main` branch triggers an automatic deployment. It is the fastest workflow for iteration.
• Setup: Takes less than 5 minutes. Enable "Pages" in repo settings, and you are done.

Cons

• Caching Control: You have limited control over HTTP cache headers. GitHub sets its own defaults, which might not be optimal for specific asset versioning strategies.
• Jekyll Interference: If you don't use a `.nojekyll` file, GitHub might try to process your site through Jekyll (a Ruby static site generator), which can mess with folder structures or filenames starting with underscores.
• Branding: While you can use a custom domain, the underlying infrastructure is visibly "GitHub".

The Contender 2: AWS S3 + CloudFront (The Enterprise Stack)

For the production version of my site, I used Amazon Web Services (AWS). This is not just "hosting"; it is infrastructure-as-code. For a static site, we need four specific services working together.

1. AWS S3 (Simple Storage Service)

Function: Object Storage.
S3 is not a traditional file system; it is an object store. It stores the actual files (`index.html`, `styles.css`, `scripts.js`).

• Configuration: I created a "Public Bucket" and uploaded my files.
• Static Website Hosting: I enabled the "Static Website Hosting" property on the bucket. This tells S3 to serve `index.html` when a user requests the root directory.
• Durability: S3 offers 99.999999999% (11 9's) durability. My portfolio files are safer here than on my laptop's hard drive.

2. AWS CloudFront (Content Delivery Network)

Function: Speed & Global Caching.
If users accessed my S3 bucket directly from Germany, the data would travel from AWS's Frankfurt region. That's fast, but CloudFront makes it instant.

• Edge Locations: CloudFront copies my static files to hundreds of data centers (Edge Locations) around the world. When a user in Berlin requests the site, they get it from the Berlin edge, not the origin server.
• Compression: CloudFront automatically compresses files (Gzip/Brotli) at the edge. Since my CSS and JS are text-based, they shrink significantly before reaching the user's browser.
• HTTPS: CloudFront acts as the secure endpoint. It handles the SSL/TLS termination.

3. AWS ACM (AWS Certificate Manager)

Function: SSL/TLS Certificates.
To have the "lock" icon (HTTPS) on a custom domain like `harisn.de`, you need a certificate.

• Process: I requested a public certificate in ACM for `harisn.de` and `*.harisn.de`.
• Validation: Since I manage my DNS via Route 53, I could validate the domain ownership automatically by adding a CNAME record. No manual email verification was needed.
• Integration: Once issued, I simply attached this certificate to my CloudFront distribution. ACM handles the renewal automatically.

4. Amazon Route 53 (DNS)

Function: Traffic Routing.
Route 53 is the phonebook of the internet. It tells browsers where to go when they type `harisn.de`.

• Alias Records: Unlike standard CNAME records, Route 53 "Alias Records" can map a root domain (`harisn.de`) directly to a CloudFront distribution or S3 bucket.
• Latency-Based Routing: If I had multiple servers, Route 53 could route users to the physically closest one. For my single site, it ensures high availability.

Pros for a Lightweight Site

• Performance: The combination of CloudFront caching and Brotli compression makes the site load incredibly fast, even on mobile networks.
• Control: I can set granular cache rules (e.g., "Cache this image for a year, but check the HTML every hour").
• Security: I can configure AWS WAF (Web Application Firewall) if I ever need to block specific traffic patterns.

Cons

• Cost: While S3 storage is pennies, Route 53 costs about $0.50/month for the hosted zone. Data transfer out is free up to a limit, but high traffic could incur costs.
• Complexity: Setting up the S3 Bucket Policy, CloudFront Origin, and ACM validation takes about an hour compared to GitHub's 5 minutes.

The Comparison

The Verdict: Why I Use Both

For a lightweight portfolio like this, **GitHub Pages is technically sufficient**. It is fast, secure, and free.

However, I chose to maintain the **AWS S3 + CloudFront** setup for three reasons:

1. Demonstrating Skill: As an engineer offering "Cloud Hosting" services, using AWS proves I understand the underlying infrastructure. I can't sell AWS services if I don't use them myself.
2. Learning Curve: Managing S3 bucket policies and CloudFront distributions forces me to understand how the internet actually works (DNS propagation, SSL handshakes, caching headers).
3. Scalability: If this site suddenly goes viral or I add heavy assets, the AWS architecture will scale without me touching a thing. GitHub Pages has usage limits that might restrict a sudden spike in traffic.