← schwarz.cc --:--:--
01 / BLOG POST

EC2 t4g.micro als Webserver

TL;DR Onpremise ist geil. Hyperscaler sind meistens Geldverschwendung. Aber eine Firmenwebsite gehört nicht ins eigene Netz – und erst recht nicht auf Wordpress. Statisches HTML auf einem $4-EC2. Fertig. Weiterlesen wenn du wissen willst warum.

ich bin eigentlich onpremise-typ

Zur Klarstellung: Ich halte nichts von der Hyperscaler-Romantik. AWS, Azure, GCP – meistens überteuert, meistens overengineered, und meistens kauft man Komplexität die man nicht braucht. Wer seine Infrastruktur kennt und weiss was er tut, fährt mit eigener Hardware in den meisten Fällen günstiger, schneller und mit mehr Kontrolle.

Aber es gibt zwei Dinge die mir noch mehr auf die Eier gehen als Hyperscaler. Und für genau diese zwei Fälle ist AWS die richtige Antwort.

was mich mehr nervt als aws: registrare mit webbaukästen

Du registrierst eine Domain und wirst sofort mit einem Upsell bombardiert: „Erstellen Sie jetzt Ihre Website! Ab CHF 12.90/Monat!" Drag-and-Drop-Editor. 47 Themes. Integrierter Onlineshop. SEO-Optimierung inklusive. Alles was ein Unternehmen braucht um eine Website zu bauen die genauso aussieht wie jede andere.

Die Zielgruppe: der Marketing-Beauftragte, der sich um das Bescheuertste im Unternehmen kümmert. Die Homepage. Das Ding das niemand liest. Das Ding das existiert weil es existieren muss. Das Ding bei dem man jährlich CHF 150 an einen Registrar zahlt damit ein Webbaukasten-Template mit dem Firmenlogo drauf im Netz hängt.

MARKETING-HOMEPAGE BINGO „Wir sind ein innovatives Unternehmen mit langjähriger Erfahrung und setzen auf nachhaltige Lösungen für Ihre individuellen Bedürfnisse." — steht auf 80% aller Unternehmenswebsites. Niemand liest das. Nicht mal die eigenen Mitarbeiter. Trotzdem zahlt man dafür jeden Monat.

warum die homepage nicht ins eigene netz gehört

Nehmen wir an jemand hackt die Firmenwebsite. Was passiert? Im schlimmsten Fall steht da „H4CK3D BY ANONYMOUS" drauf. Imageschaden, unangenehmes Meeting mit der Geschäftsleitung, Website wird restored, fertig. Die Kundendaten sind nicht dort. Die internen Systeme sind nicht dort. Es ist eine HTML-Seite.

Jetzt stell dir vor das Teil läuft im eigenen Netz. Auf demselben Segment wie die Server, die NAS, die Buchhaltungssoftware. Aus einem Imageschaden wird ein potenzieller Einstiegspunkt ins Unternehmensnetz. Wegen einer Homepage die niemand liest.

Gleiches gilt für Hostingprovider: auch dort will man die eigene Firmenwebsite nicht haben. Shared Hosting, geteilte Ressourcen, Nachbarschaft mit tausend anderen Sites – kein Mensch weiss was auf demselben Server sonst noch läuft.

Die Website gehört irgendwo hin wo es scheissegal ist wenn ein Meteorit einschlägt – oder ein Script-Kiddie. Irgendwo wo kein Mensch nachts aufwacht und sich fragt ob die Kiste noch läuft. AWS ist dafür nicht weil es toll ist, sondern weil es egal ist. Maximale Isolation, minimale Konsequenzen im Worst Case.

und bitte kein wordpress

Wordpress ist die meistgehackte Software im Web. Nicht weil der Code per se so schlimm ist, sondern weil es überall läuft und die meisten Instanzen seit Jahren nicht mehr geupdated wurden. Plugins mit bekannten CVEs. Themes von 2016. PHP das läuft obwohl niemand mehr weiss warum. Eine MySQL-Datenbank die mitschleppt obwohl die Seite komplett statisch sein könnte.

Für eine Unternehmenswebsite mit 5 Seiten, einem Kontaktformular und dem obligatorischen Team-Foto braucht es kein CMS, keine Datenbank, kein PHP. Es braucht HTML. Und einen Webserver der das ausliefert. Das war's. Kein Angriffspotenzial, keine Dependencies, keine Updates die man vergisst. Eine Datei. nginx. Done.

✓ Diese Website ist statisches HTML. Kein Wordpress. Kein PHP. Keine Datenbank. Die schlimmste Sache die passieren kann: jemand klaut die index.html. Viel Spass damit.

also: EC2. aber warum nicht S3?

S3 Static Hosting kostet fast nichts und wäre theoretisch noch simpler. Aber: kein SSH, kein nginx, kein direkter Zugriff. Sobald du HTTPS willst brauchst du CloudFront davor, dann ACM für Zertifikate, dann Route 53 für DNS – und plötzlich hast du drei AWS-Services für eine HTML-Seite. Für Leute die Linux kennen: nimm EC2, eine Kiste, nginx drauf, fertig. Mehr Kontrolle, weniger AWS-Voodoo.

die specs: t4g.micro

CPU
2x AWS Graviton2 (ARM) ARMv8 Neoverse-N1, 2.5 GHz. Nicht x86. Das ist wichtig beim AMI-Auswählen – du willst das ARM-Image, sonst zahlst du für Graviton und kriegst die Performance nicht.
RAM
1 GB Klingt wenig, ist für nginx + certbot + statisches HTML aber absolut overkill. nginx frisst im Idle ~5 MB. Du hast 995 MB Luft.
NET
bis zu 5 Gbit/s Ja, wirklich. Deine Leitung zuhause ist langsamer als dein $4-Server.
HDD
EBS only (kein lokaler Storage) Du hängst ein EBS-Volume dran. 8 GB reicht locker, kostet ~$0.80/Monat extra.
$$$
~$4/Monat Weniger als ein Kaffee. Weniger als der Webbaukasten vom Registrar. Weniger als die monatliche Lizenz für das Wordpress-Plugin das eh niemand benutzt.

instanz starten – schritt für schritt

⚠ WICHTIG: Zuerst Region wählen! Oben rechts in der AWS Console. Nimm eu-central-1 (Frankfurt) oder eu-central-2 (Zürich). Sonst startest du aus Versehen was in Virginia und wunderst dich über Latenz.
01
EC2 → Launch Instance Name eingeben, z.B. webserver
02
AMI: Ubuntu 24.04 LTS → 64-bit (Arm) auswählen Nicht vergessen auf ARM umschalten! Der Default ist oft x86.
03
Instance Type: t4g.micro ~$4/Monat, 2 vCPUs, 1 GB RAM
04
Key Pair erstellen RSA oder ED25519, .pem runterladen. Nicht verlieren. Kein Backup. Kein Support. Weg = weg.
05
Security Group: Port 22, 80, 443 auf SSH, HTTP, HTTPS. Alles andere zu.
06
Storage: 8 GB Reicht für nginx + alle HTML-Files die du jemals schreiben wirst.
07
Launch Instance Warten bis Status "running" ist.

elastic ip – pflicht, kein optional

Ohne Elastic IP bekommt die Instanz bei jedem Neustart eine neue Public IP. Dein DNS-Record stimmt dann nicht mehr. Elastic IP ist fix und kostet nix solange die Instanz läuft.

01
EC2 → Elastic IPs → Allocate Elastic IP address
02
Actions → Associate Elastic IP address → deine Instanz auswählen
✓ Ab jetzt hast du eine feste Public IP. Die schmeisst du als A-Record bei deinem Registrar rein – fertig.

per ssh verbinden

ssh -i deinkey.pem ubuntu@DEINE-ELASTIC-IP

# Windows mit PuTTY: .pem → .ppk via PuTTYgen konvertieren
# Host: ubuntu@IP | Port: 22 | Auth: .ppk file

Username ist immer ubuntu bei Ubuntu AMIs. Nicht root, nicht admin, nicht dein Name.

nginx installieren und loslegen

sudo apt update && sudo apt install -y nginx
sudo systemctl status nginx
# → active (running)
# Deine index.html nach /var/www/html/ schmeissen, fertig.

SSL via certbot kommt im nächsten Post. Dauert 2 Minuten und ist gratis. Kein Grund mehr für „wir haben noch kein HTTPS weil das zu teuer ist".