BERND KUHLENAlle Notizen ↗Eine statische Website ist wunderbar ereignislos. Es gibt keinen Anwendungsserver, der darauf wartet, gepatcht zu werden, keinen Datenbankverbindungspool zum Ausschöpfen und keine öffentliche API, die rund um die Uhr aktiv sein muss. Ein Browser fragt nach Dateien; ein Content Delivery Network gibt sie zurück.
Diese Einfachheit warf eine interessante Frage für dieses Portfolio auf: Könnte ich zeigen, wo die Website gelesen wird und wie sich der Anfragetraffic im Laufe der Zeit verändert, ohne die Website in eine dynamische Anwendung umzuwandeln — oder Informationen zu veröffentlichen, die privat bleiben sollten?
Die Antwort war eine kleine Datenpipeline, die aus CloudFront-Zugriffsprotokollen, CloudWatch, Lambda, EventBridge und einem einzigen JSON-Objekt in S3 erstellt wurde. Besucher sehen eine Weltkarte, Ländersummen, beliebte Seiten und Charts zur Anforderungsrate. Sie erhalten niemals Rohprotokolle, IP-Adressen, Benutzeragenten oder individuelle Browserverläufe.
Die Website bleibt statisch. Die Daten werden an anderer Stelle vorbereitet und kommen als nur eine weitere statische Datei an.
Die Architektur in einem Anforderungspfad
Der Weg für öffentliche Anfragen bleibt bewusst kurz:
- Ein Besucher ruft die Website über Amazon CloudFront an.
- CloudFront bedient zwischengespeicherte Dateien, deren privater Ursprung ein S3-Bucket ist.
- Der Browser ruft später
content/public-visitors.jsonwie jedes andere statische Asset. - Client-seitiges JavaScript rendert die Karte und die Diagramme aus diesem anonymen Dokument.
Der Browser ruft Lambda nicht auf. Es fragt CloudWatch nicht ab. Es hat keine AWS-Anmeldeinformationen und kann nicht nach einem anderen Zeitraum oder einem detaillierteren Datensatz fragen. Alle teuren und sensiblen Arbeiten erfolgen außerhalb des öffentlichen Auftrags.
Hinter den Kulissen sieht der Datenpfad so aus:
CloudFront → CloudWatch Logs → scheduled Lambda → aggregated JSON → S3 → CloudFront → browser
Diese Trennung ist die wichtigste architektonische Entscheidung. Das Betriebssystem kann mit detaillierten Zugangsdaten arbeiten; das Veröffentlichungssystem gibt nur die kleine Teilmenge aus, die für die öffentliche Anzeige vorgesehen ist.
Einmal sammeln, weniger veröffentlichen
CloudFront Standard Logging Version 2 liefert ausgewählte Zugriffs-Log-Felder an eine CloudWatch Logs-Gruppe. Das Betriebsprotokoll enthält genügend Informationen, um Anfragen und Statuscodes zu untersuchen, aber das bedeutet nicht, dass alles in ein öffentliches Dashboard gehört.
Die Veröffentlichungsfunktion reduziert die Daten bewusst auf Aggregate:
- erfolgreiche HTML-Seitenansichten, gruppiert nach Landesvorwahl;
- die am häufigsten nachgefragten HTML-Pfade;
- Anfragen pro Minute, abgeleitet aus aggregierten HTTP-Statusmetriken;
- einen Aktualisierungszeitstempel und Beschriftungen, die jeden Zeitbereich beschreiben.
Die generierte Datei enthält keine Quell-IP-Adressen, Standorte auf Stadtebene, Cookies, User-Agent-Strings oder Sequenzen, die die Reise eines Besuchers identifizieren. Das öffentliche Ergebnis lautet: „Welchen Traffic hat die Seite erhalten?“ statt „Wer war da?“
Das ist auch der Grund, warum ich den Ausdruck verwende Seitenaufrufe, nicht Leute. Ein Leser kann viele Anfragen stellen. Suchcrawler, Link-Preview-Dienste, Überwachungssonden und andere Automatisierungen können zusammen mit menschlichem Traffic auftreten. Das Dashboard präsentiert Infrastruktursignale, keine Identitäten.
Warum CloudWatch in der Mitte steht
CloudWatch bietet zwei nützliche Darstellungen derselben Aktivität. CloudWatch Logs Insights kann strukturierte Anforderungsdatensätze für Länder- und Seitenaggregate abfragen. Metrikfilter zählen die vier HTTP-Statusfamilien — 2xx, 3xx, 4xx und 5xx —, sodass CloudWatch-Metrikdaten Serien mit Anforderungsraten erstellen können, ohne jedes Protokollereignis wiederholt zu analysieren.
Der öffentliche Datensatz bietet mehrere Ansichten:
- Gesamtwerte der Länder für die letzten 24 Stunden, 7 Tage und 30 Tage;
- Ratenpunkte für 24 Stunden, 7 Tage, 30 Tage und 12 Monate anfordern;
- gröbere Zeitfenster für größere Reichweiten, wodurch das Dokument kompakt bleibt.
CloudFront-Logs sind kein Event-Stream in Echtzeit. AWS stellt fest, dass Standardprotokolle in der Regel innerhalb einer Stunde geliefert werden, während einige Einträge gelegentlich später eintreffen können. Dadurch eignen sie sich gut für ein ehrliches Retrospektiv-Dashboard, nicht für einen Live-Besucherzähler.
Ein geplanter Snapshot statt einer öffentlichen API
Eine EventBridge-Regel ruft das veröffentlichende Lambda alle sechs Stunden auf. Die Funktion führt ihre begrenzten Abfragen aus, fordert die metrische Reihe an, stellt das Dokument zusammen und überschreibt genau einen S3-Schlüssel: content/public-visitors.json.
Sechs Stunden sind bewusst konservativ. Besucheranalysen müssen nicht sekundengenau aktualisiert werden, und bei jeder Aktualisierung werden Protokolldaten gescannt. Ein kürzeres Intervall würde zu mehr Abfrageausführungen und höheren Kosten führen, ohne die Seite wesentlich nützlicher zu machen.
Das JSON-Objekt wird mit Cache-Headern bereitgestellt, die sich an der Revalidierung orientieren. Die Homepage kann daher einen neueren Snapshot entdecken, während CloudFront den S3-Ursprung weiterhin schützt. Es sind keine vollständige Bereitstellung der Website und keine Invalidierung des globalen Caches erforderlich, wenn sich die Statistiken ändern.
Dieses Snapshot-Modell hat einen angenehmen Ausfallmodus. Wenn eine Abfrage oder ein Lambda-Aufruf fehlschlägt, bleibt das bestehende statische Dokument verfügbar. Das Dashboard kann veraltet sein, aber das Portfolio bleibt online und keine Anfrage wartet auf die Analytics-Pipeline.
Das geringste Privileg hält den Explosionsradius klein
Das veröffentlichende Lambda verwendet eine eigene IAM-Rolle. Die relevanten Berechtigungen sind bewusst eng gefasst:
- führt Abfragen nur für die angegebene Access-Log-Gruppe aus und ruft sie ab;
- lesen Sie die CloudWatch-Metriken, die für das Diagramm mit den Anforderungsraten erforderlich sind;
- nur schreiben
content/public-visitors.jsonim Site-Bucket; - schreibt seine eigenen Hinrichtungsprotokolle.
Es kann keine beliebigen Site-Dateien bereitstellen, die CloudFront-Distribution ändern oder den S3-Bucket verfügbar machen. EventBridge erhält die Erlaubnis, diese spezielle Funktion von der spezifischen geplanten Regel aufzurufen.
Der Site-Bucket selbst bleibt privat. CloudFront verwendet Origin Access Control, um signierte Anfragen an S3 zu senden, was verhindert, dass Zuschauer die Verteilung umgehen und den Bucket als öffentlichen Dateiserver behandeln.
Die öffentliche Karte ist absichtlich weniger genau.
Ein detaillierteres Dashboard ist nicht automatisch ein besseres öffentliches Dashboard. Stadtmarkierungen sehen beeindruckend aus, aber kleine Zählungen in Kombination mit einem präzisen Zeitstempel und einer bekannten Person können identifizierbar werden. Gesamtwerte auf Landesebene reichen aus, um die globale Geschichte der Website zu erzählen, ohne so zu tun, als ob die Infrastrukturtelemetrie beweist, wo ein bestimmter Leser lebt.
Das visuelle Design verstärkt diese Einschränkung. Die Karte zeigt die Intensität nach Ländern und eine Rangfolge, während eine Erklärung direkt darunter besagt, dass Anfragen Signale und nicht Personen sind. Die Oberfläche bietet keine Aufschlüsselung einzelner Ereignisse.
Diese Unterscheidung ist wichtig, weil ausgefeilte Charts zu falscher Sicherheit führen können. Ein IP-abgeleitetes Land ist eine Beobachtung, die von einer Edge-Plattform gemacht wurde. VPNs, Unternehmensnetzwerke, Mobilfunkanbieter, Crawler und zwischengespeicherte Vorschauen verkomplizieren die menschliche Geschichte dahinter.
Die Kosten richten sich nach dem Scanvolumen, nicht nach der visuellen Komplexität
Die Karte und die Diagramme werden im Browser mit Code gerendert, der bereits von der statischen Website bereitgestellt wird, sodass aufgrund ihrer visuellen Komplexität keine serverseitige Rendering-Rechnung entsteht. Die erheblichen Betriebskosten entstehen durch das Sammeln und Aufbewahren von Protokollen, das Erfassen von Metriken und das Scannen von Protokolldaten mit geplanten Abfragen.
Die Steuerung ist daher eher architektonisch als kosmetisch:
- eine 30-tägige Richtlinie zur Aufbewahrung von Protokollen verhindert unbegrenztes Wachstum;
- Die Funktion wird nur viermal am Tag ausgeführt;
- Anfragen fordern begrenzte Zeitfenster und nur Pflichtfelder an;
- längere Chartbereiche verwenden gröbere metrische Perioden;
- Die veröffentlichte JSON-Datei ist winzig im Vergleich zu den Quellprotokollen.
Die Lambda-Ausführungszeit und der S3-Speicher für ein kompaktes Dokument sind in dieser Größenordnung vernachlässigbar. Das Scanvolumen von Logs Insights ist die Komponente, die es wert ist, beobachtet zu werden, wenn der Traffic oder die Kundenbindung erheblich zunehmen.
Was mir die Implementierung beigebracht hat
Statisch heißt nicht blind. Observability kann neben einer statischen Site existieren, ohne in ihren synchronen Anforderungspfad übergehen zu müssen.
Aggregation ist eine Sicherheitsgrenze. Die Umwandlung von Betriebsprotokollen in ein öffentliches Dokument sollte explizit, überprüft und einseitig erfolgen.
Frisch genug ist besser als fälschlicherweise in Echtzeit. Ein sechsstündiger Snapshot entspricht dem verzögerten Charakter von Standardzugriffsprotokollen und vermeidet unnötige Arbeit.
Misserfolg sollte die vorherige Wahrheit bewahren. Ein veralteter Snapshot ist einer Homepage vorzuziehen, die ausfällt, weil ein Analysedienst nicht verfügbar ist.
Erläutern Sie die Grenzwerte neben dem Diagramm. Eine öffentliche Visualisierung benötigt Kontext über Bots, wiederholte Anfragen, geografische Inferenz und den Unterschied zwischen Traffic und Personen.
Wann würde ich ein anderes Design wählen
Dieses Muster eignet sich gut für eine persönliche Website mit moderatem Traffic und einer kleinen Anzahl vorgegebener Aufrufe. Ich würde es noch einmal überdenken, wenn Benutzer beliebige Abfragen, authentifizierte Dashboards, Aktualität der zweiten Ebene oder große multidimensionale Datensätze benötigen würden. Diese Anforderungen könnten eine API, einen speziellen Analyseshop oder eine verwaltete Visualisierungsplattform rechtfertigen.
Für dieses Portfolio würden diese Ergänzungen ein Problem lösen, das ich nicht habe. Eine geplante Funktion und ein statisches Dokument bewahren die Eigenschaften, die die Website von Anfang an attraktiv gemacht haben: eine kleine Angriffsfläche, vorhersehbares Verhalten und Komponenten, über die man leicht nachdenken kann.
Letzter Imbiss
Der wichtigste Teil dieses Besucher-Dashboards ist nicht die Weltkarte. Es ist die Grenze dahinter.
Die detaillierten Anforderungsdaten verbleiben in der Betriebsumgebung. Ein Prozess mit den geringsten Rechten wandelt es regelmäßig in anonyme Aggregate um. Die Website erhält nur einen kompakten statischen Snapshot und der Browser wandelt diesen Schnappschuss in eine Story um.
Das gibt der Seite einen Puls, ohne ihr ein verwundbares dynamisches Herz zu geben.