Katalog oder eigene App
Zwei Wege zum Ziel
Über 20 Apps aus dem Managed-Apps-Katalog oder Ihre Individualsoftware via Bring-your-own-App – beides auf derselben Betriebsplattform.
App Hosting in
Kubernetes
Lassen Sie Ihre cloud-native Fachanwendung von Experten betreiben. Auf europäischer Infrastruktur, mit 99,9 % Verfügbarkeitsgarantie.
Made in Germany
ISO 27001
ISO 9001
DSGVO-konform
DORA Compliant
24/7 Support
Software-Betrieb wie aus der Fabrik
Ihre Anwendung läuft produktionsreif auf Kubernetes in Europa – wir übernehmen Infrastruktur, Betrieb und den operativen Rahmen. Sie liefern Code oder wählen aus dem Katalog, wir sorgen für Verfügbarkeit, Skalierung und Compliance.
Kubernetes als Basis
Produktionsreife Basis
Managed Kubernetes Hosting aus Deutschland mit Cilium, CSI, Ingress, WAF und integriertem Monitoring – kein Eigenbau der Plattform.
Vollständig gemanagt
Operations inklusive
Updates, Backups, Alerts, Endpoint Monitoring und 24/7-Support – Sie konzentrieren sich auf Produktentwicklung.
Wie wir das machen
Von der Plattform bis zum Support – modular buchbar oder als Paket. Jede Schicht baut auf der vorherigen auf.
Plattform
Managed Kubernetes
Cluster, Netzwerk, Storage, Ingress und Zertifikate – produktionsreif in Deutschland.
Addons
Katalog-Apps
Bewährte Tools aus dem Managed-Apps-Katalog – installiert, aktualisiert und betrieben.
Fachanwendung
GitOps mit Argo CD
Auslieferung Ihrer Individualsoftware – kontrollierte Releases von Staging bis Produktion.
Überwachung
Observability
Metriken, Logs, Traces und Endpoint-Checks – Alerts und Runbooks inklusive.
Onboarding
Ihr Team startklar
Zugänge, Tools und Deployment-Prozesse – wir bringen Sie in GitLab, Argo CD und den Betriebsablauf ein.
Support
Experten-Support
Definierte Reaktionszeiten, optional 24/7 – wenn es brennt, sind wir da.
Added Value
Edge-Services, Storage und Tooling rund um Ihr App Hosting – modular auf souveräner Infrastruktur buchbar.
Endpoint Monitoring
Wir überwachen Ihre Endpoints minütlich von unserer Edge Cloud aus.
Anycast DNS
Multi-Region DNS mit Anycast-Routing auf eigener Infrastruktur – schnell, resilient und souverän.
Anycast Loadbalancing
EU-weites TCP-Loadbalancing (Layer 4) mit Anycast-Routing und eigenem AS – Made in Germany.
S3 Storage
S3-kompatibler Object Storage auf europäischer Infrastruktur – für Backups, App-Daten und Archive.
Container Registry
Private Container Registry für Ihre Images – sicher, performant und nahtlos in Kubernetes integriert.
Code Repository
Managed GitLab für Quellcode, CI/CD und DevSecOps – Repositories und Pipelines auf souveräner Infrastruktur.
Secrets Management
Managed OpenBao für Secrets, Zertifikate und dynamische Credentials – zentral und auditierbar.
Delivery
Managed Argo CD für GitOps-Deployments – deklarative Continuous Delivery in Ihren Kubernetes-Clustern.
Backups
Automatisierte Backups für Kubernetes, Apps und Daten – mit getesteter Wiederherstellung und EU-Speicherung.
Cloud + IaaS
Unsere Technologien und Produkte sind verfügbar zahlreichen Standorten in Europa sowie On-Premises.
Gründe für die Arbeit mit uns
Technologien und Services von ayedo ermöglichen Ihnen den Betrieb Ihrer SaaS-Lösung ohne eigenes DevOps Team. Sie entwickeln Software, wir übernehmen den Betrieb auf Infrastruktur Ihrer Wahl.
100% preiswert
Unsere Managed Services und der individuelle Support durch unser Plattform-Team bieten den Mehrwert eines 3-köpfigen DevOps-Teams.
24/7 verfügbar
Unser Priority-Support bietet Ihnen Rund-um-die-Uhr Betreuung Ihrer kritischen Services. Auch am Wochenende und an Feiertagen.
90% weniger Operations
Wir kümmern uns um die Operations, damit Sie entwickeln können. Auf Wunsch inklusive Packaging, Pipelines, Monitoring und Backups.
2-fach zertifizierte Sicherheit
Unsere Managed Services sind nach ISO9001 und ISO27001 zertifiziert und in Anlehnung an die Standards des BSI abgesichert.
70% kürzere MTTR
Unsere 360° Observability und intelligentes Forecasting ermöglichen uns das pro-aktive Entdecken und Beheben von Fehlern und Echtzeit-Reaktion auf Ausfälle.
100% compliant
Wir bieten den Betrieb Ihrer Software auf zertifizierter Infrastruktur nach auditierbaren Methoden, sodass Sie immer compliant sind.
You build it. We run it.
Exzellente Performance und maximale Uptime - dafür stehen wir morgens auf. Und manchmal sogar mitten in der Nacht.
100+ Cluster
under Management
Mehr als 100 Kubernetes-Cluster betreiben wir produktiv für unsere Kunden.
300+ Datenbanken
under Management
Mehr als 300 Datenbanken betreiben, überwachen und sichern wir im produktiven Betrieb.
1 Petabyte Object-Storage
under Management
Ein Petabyte Object-Storage betreiben wir für Backups, Artefakte und Anwendungsdaten.
100 Millionen Timeseries
im Durchschnitt
4 Millionen Datapoints werden pro Sekunde von unseren Monitoring-Systemen ingestiert.
38.000+ Logs
pro Sekunde
Unsere Kollektoren erfassen Logs kontinuierlich und speichern sie DSGVO-konform – über 100 Milliarden Einträge pro Monat.
5.000+ Backups
pro Tag
Mehr als 5.000 Backups sichern wir jeden Tag auf verschlüsseltem Langzeit-Storage – rund 150 Terabyte Backup-Volumen pro Monat.
270 Millionen User-Sessions
pro Monat
Mehr als 9 Millionen User-Sessions laufen täglich über Software, die wir betreiben.
99,99% Uptime
im Jahresmittel
Unsere Managed Services sind im Schnitt weniger als 1 Stunde pro Jahr nicht verfügbar.
MTTD < 5 Minuten
im Durchschnitt
Unser Alerting erkennt Fehler und Ausfälle in der Regel innerhalb weniger Minuten.
Wir arbeiten mit digitalen Pionieren
Unternehmen aus den verschiedensten Branchen des Europäischen Wirtschaftsraumes setzen auf unsere Technologien und Dienstleistungen für den Betrieb Ihrer Software-as-a-Service Produkte.
Was können wir für Sie tun?
ayedo bietet zertifizierte Lösungen für den Betrieb von container-basierten Workloads nach cloud-nativen Standards für Unternehmen mit hohen Anforderungen an Verfügbarkeit, Compliance und Souveränität.
Betriebsplattform
Betriebsplattform für SaaS, Demos, Mandanten und Releases – Tooling und Integration in Ihre IT-Landschaft.
Delivery
Ihre App zuverlässig zum Kunden bringen – GitOps mit Argo CD auf Kubernetes.
Vollkasko-Versicherung
Wir bieten Rund-um-die-Uhr Entstörung und Support für die von uns verwalteten Kubernetes-Cluster und -Apps und auf Wunsch ein individuelles SLA.
Edge Services
Bei uns haben Sie Zugriff auf über 700 TLDs, Multi-Region DNS und Loadbalancing, custom IP-Prefixes sowie WAF- und DDOS-Protection für Ihre Apps.
Convenience Services
Sie brauchen Europäischen S3-kompatiblen Object Storage? Mail-Gateways in IP-Bereichen mit guter Reputation? Eine Alternative für Datadog?
Knowledge Transfer
Von manuellen Servern zu skalierbarem App-Betrieb? Wir begleiten Sie mit mehr als 15 Jahren Betriebspraxis.
Compliance & regulatorische Anforderungen
Die ayedo Cloud ist ISO 27001-zertifiziert und erfüllt im Standard die Anforderungen aktueller EU-Verordnungen: GDPR, NIS-2, DORA, CRA, Data Act und Cloud Sovereignty Framework.
GDPR-konforme Datenverarbeitung
Privacy by Design & Default.
EU-Datenhaltung (Deutschland), Customer-Managed Keys (BYOK/BYOHSM), Verschlüsselung at rest/in transit. ISO 27001-zertifiziertes Datenschutz-Management. Mehr zur GDPR.
NIS-2-konformer Betrieb
Resilienz im Betrieb.
24/7 Monitoring, Incident-Response, BCP/DR-Prozesse, Supply-Chain-Transparenz (SBOM). Mehr zu NIS-2.
DORA-ready
IKT-Resilienz nach Maß.
IKT-Risikomanagement, dokumentierte Exit-Strategien, Drittpartei-Risiko-Management, TLPT-Readiness. Mehr zu DORA.
CRA-konforme Software Supply Chain
Security by Design über den gesamten Lifecycle.
SBOM-Generation, CVE-Scanning, signierte Container-Images, GitOps-basierte Audit-Trails. Mehr zum CRA.
Cloud Sovereignty Framework
Digitale Souveränität messbar gemacht.
EU-basierte Operations, offene Standards, Exit-Fähigkeit ohne Lock-in. Mehr zum Framework.
Data Act-konforme Portabilität
Switching ohne Hürden.
Offene APIs, standardisierte Formate, vollständige Exit-Runbooks. Mehr zum Data Act.
Integrierte Compliance-Roadmap
Ganzheitlicher Ansatz.
Wie ayedo GDPR, NIS-2, DORA, CRA, Data Act und ISO 27001/9001 systematisch adressiert. Zur Übersicht.
Neu bei ayedo: Praxisnahe IT-Workshops für Cloud Native, Kubernetes und DevOps
Praxisnahe ayedo Workshops zu Kubernetes, Docker, GitOps, Security und Polycrate: kleine Gruppen, vorbereitete Cloud-Labs, online oder vor Ort.
Backup vorhanden, Wiederherstellung unmöglich? Restore-Tests in der Praxis
Wie Restore-Tests RPO, RTO und die tatsächliche Wiederherstellbarkeit von PostgreSQL, S3 und Kubernetes-Anwendungen prüfen.
Kubernetes verstehen statt nur benutzen: ayedo bietet ab sofort praxisnahe IT-Workshops an
Technologische Unabhängigkeit beginnt mit dem eigenen Know-how. ayedo bietet praxisnahe Workshops zu Kubernetes, Docker, GitOps und Polycrate für IT-Teams.
Neu bei ayedo: Domains, Anycast DNS und Edge Cloud aus einer Hand
Domains jetzt bei ayedo registrieren: Von der Domain über Anycast DNS bis zu Loadbalancern auf der Edge Cloud – digitale Infrastruktur aus einer Hand.
Cloud-Kosten richtig kalkulieren: Was kostet eine Anwendung wirklich?
Cloud-Angebote fair vergleichen: TCO, Compute, Storage, Traffic, Betriebskosten und eine Beispielrechnung inklusive Checkliste.
DDoS-Scrubbing und Resilienz: Schutz bei Überlast
Wie DDoS-Scrubbing, Anycast, getrennte Failure Domains und kontrolliertes Failover Anwendungen bei Überlast schützen.
Kubernetes migriert von cgroup v1 zu v2
Was der Wechsel auf cgroup v2 für Clustermanagement, Ressourcenisolierung und Betrieb bedeutet – und warum Europa konsistente Infrastrukturstandards braucht.
NUXOA – Eine souveräne Edge Cloud braucht ein Netzfundament
Eine souveräne Edge Cloud braucht ein belastbares Netzfundament. Warum wir beim Frankfurter Edge-Standort mit NUXOA und AS51202 zusammenarbeiten.
JD Group – Eine leistungsfähige Edge Cloud beginnt im Netzwerk
Partner Spotlight: Warum eine leistungsfähige Edge Cloud nicht nur Compute, sondern starke Netzwerkanbindung, Peering, Routing und Redundanz braucht.
Authentik-Föderation in der Praxis: undokumentiertes Verhalten bei Sources, Gruppen und Enrollment
Praxisbericht zur Föderation zweier Authentik-Instanzen per OIDC: undokumentiertes Verhalten bei Gruppen-Sync, Source-Enrollment, Expression Policies und Login-Flows – mit konkreten Mustern, die stattdessen funktionieren.
Building the Edge — Part 8
Der Anfang einer Plattform – warum jede Architektur irgendwann an den Punkt gelangt, an dem sie das Netzwerk neu denken muss.
Building the Edge — Part 7
Gute Plattformen entstehen nicht durch mehr Infrastruktur – sondern durch klar definierte Verantwortlichkeiten.
Building the Edge — Part 6
Eine Verbindung ist noch kein HTTP-Request – warum moderne Edge-Plattformen deutlich früher beginnen, als viele Architekturdiagramme vermuten lassen.
Building the Edge — Part 5
Compute ist nicht die Plattform – warum moderne Anwendungen heute aus zwei Plattformen bestehen.
Building the Edge — Part 4
Warum Hochverfügbarkeit heute im Netzwerk beginnt – Ausfälle sind kein Ausnahmezustand, sondern ein Architekturprinzip.
Building the Edge — Part 3
Eine IP-Adresse kann an drei Orten gleichzeitig existieren – warum Anycast keine Funktion, sondern eine Eigenschaft des Internets ist.
Building the Edge — Part 2
Das Internet kennt keine Anwendungen – warum BGP nicht versucht, den schnellsten Weg zu finden.
level66 – Wenn Hosting nur das Nebenprodukt ist
Partner Spotlight: Warum level66.network mit Peering, hoher Netzwerkkapazität und DDoS-Mitigation ein wichtiger Infrastrukturpartner für die ayedo Edge Cloud ist.
Kubernetes 1.38: Was wir bisher wissen
Kubernetes 1.38 ist für Dezember 2026 geplant. Wir zeigen, welche Features sich abzeichnen und welche Termine für den Release-Zyklus wichtig sind.
MCP-Integrationen für modernes Content Management
Wie das ayedo Brand Team mit Backplane Website-Inhalte im Dialog erstellt, überarbeitet und vor der Veröffentlichung prüft.
Digitale Souveränität endet nicht im Rechenzentrum:
Eine Anwendung kann vollständig in Deutschland betrieben werden und trotzdem bei jedem einzelnen Zugriff von US-Infrastruktur abhängig sein.
DNS, Routing, Anycast: Warum Europas Cloud auch eine eigene Edge braucht
Wir haben vor Kurzem die ayedo Edge Cloud vorgestellt. Eine europäische Edge-Infrastruktur für DNS, Anycast, Loadbalancing, Web Application Firewall, DDoS-Schutz und den kontrollierten Zugang zu Anwendungen.
Building the Edge — Part 1
Die unterschätzte Architektur moderner Anwendungen – warum moderne Anwendungen nicht erst im Rechenzentrum beginnen.
TLS-Zertifikate für öffentliche Kubernetes-Endpunkte
TLS für Kubernetes endet nicht zwingend am Ingress. Eine zentrale TLS-Termination an der ayedo Edge Cloud vereinfacht Zertifikatsverwaltung, WAF-Integration und Traffic-Steuerung. Zusätzliche Verschlüsselung bis zum Cluster schützt jedoch weitere Netzwerkabschnitte. Die richtige Entscheidung hängt von Trust Boundaries, Betriebsmodell, Compliance und gewünschter Fehlerisolierung ab.
DNS-Automatisierung für Kubernetes hinter der Edge Cloud
Kubernetes-DNS und öffentliche Namensauflösung lösen unterschiedliche Probleme. Cluster-Ressourcen kennen Services, Ingresses und Workloads; die Edge Cloud verwaltet öffentliche Endpunkte, DNS-Zonen und die Weiterleitung zum Backend. Ein belastbares Betriebsmodell trennt diese Zuständigkeiten, automatisiert aber ihre Übergaben über klar definierte Schnittstellen.
Loadbalancer für Kubernetes providerunabhängig betreiben
Ein Kubernetes Service vom Typ `LoadBalancer` bindet den öffentlichen Zugang häufig an den jeweiligen Cloud- oder Infrastrukturprovider. Eine eigenständige Edge-Schicht trennt diese Verantwortung vom Cluster: Routing, Schutz, TLS und Erreichbarkeit werden zentral organisiert, während Kubernetes bei ayedo oder einem anderen Provider betrieben werden kann. Das reduziert Providerabhängigkeiten und vereinfacht Multi-Cloud-Architekturen.
Kubernetes-API-Server sicher über die Edge erreichbar
Ein öffentlich erreichbarer Kubernetes-API-Server muss nicht direkt aus dem Internet auf seine Backend-Adresse zugreifen lassen. Eine vorgeschaltete Edge-Schicht kann Routing, TLS, DDoS-Schutz und Backend-Cloaking übernehmen. Entscheidend bleibt die Trennung zwischen öffentlicher Erreichbarkeit, kryptografischer Authentisierung und tatsächlicher Berechtigung im Cluster.
Ingress und Edge Cloud: Zuständigkeiten sauber trennen
Kubernetes Ingress und Edge Cloud lösen unterschiedliche Aufgaben. Die Edge Cloud kontrolliert den öffentlichen Eingang, schützt Anwendungen und terminiert TLS. Kubernetes Ingress beschreibt dagegen die Weiterleitung innerhalb des Clusters. Eine klare Trennung verhindert doppelte Regeln, widersprüchliche Sicherheitskonfigurationen und schwer nachvollziehbare Betriebszustände.
Security-Entscheidungen an der Edge nachvollziehbar machen
Edge Security Monitoring macht sichtbar, wie sich Schutzmaßnahmen auf den öffentlichen Traffic auswirken. Traffic- und Usage-Statistiken helfen, WAF-Regeln, DDoS-Schutz und exponierte Endpunkte betrieblich zu bewerten. Sie erklären jedoch weder individuelle Angriffe vollständig noch ersetzen sie Logs, Traces und anwendungsnahe Security-Telemetrie.
Multi-Cloud-Security mit zentraler Edge-Architektur
Multi-Cloud Security scheitert häufig nicht an fehlenden Schutzfunktionen, sondern an ihrer verteilten Umsetzung. Eine zentrale Edge-Architektur bündelt öffentlichen Zugang, WAF, DDoS-Schutz, TLS-Terminierung und Routing vor heterogenen Backends. Provider-Unabhängigkeit, eigenes Autonomous System und Aktiv-Aktiv-Betrieb reduzieren dabei Kontroll- und Abhängigkeitspunkte.
DDoS-Schutz an der Edge mit Anwendungslogik koppeln
DDoS-Schutz und Anwendungssicherheit adressieren unterschiedliche Angriffsebenen. Die Edge kann Volumen, Protokolle, Verbindungsraten und Request-Muster bewerten und schädlichen Traffic frühzeitig verwerfen. Ob ein gültiger Request fachlich missbräuchlich ist, lässt sich jedoch meist erst im Anwendungskontext erkennen. Wirksamer Schutz kombiniert daher beide Ebenen mit klaren Zuständigkeiten.
TLS, WAF und Backend: Eine Schichtenarchitektur
Eine belastbare **Security-Schichtenarchitektur** verteilt Schutzaufgaben auf unterschiedliche Ebenen: TLS schützt die Transportverbindung, die WAF bewertet HTTP-Anfragen und das Backend bleibt für Autorisierung, Validierung und Datenschutz verantwortlich. Entscheidend sind die Übergabepunkte zwischen diesen Schichten. Jede Entschlüsselung, Weiterleitung und Protokollumwandlung erzeugt dabei eigene Vertrauens- und Betriebsanforderungen.
Security-Funktionen zwischen Edge und Anwendung verteilen
Security-Funktionen gehören nicht pauschal an einen einzigen Ort. Die Edge eignet sich für Schutzmaßnahmen mit hoher Sichtbarkeit, großem Skalierungsbedarf und standardisierbaren Regeln. Die Anwendung bleibt für Identität, Autorisierung und fachliche Zugriffskontrollen verantwortlich. Entscheidend sind Kontextbedarf, Fehlkonfigurationsrisiko und die Frage, wie früh ein Angriff erkannt und begrenzt werden kann.
Öffentliche Angriffsflächen systematisch reduzieren
Eine öffentliche Angriffsfläche entsteht nicht nur durch einzelne Schwachstellen, sondern durch die gesamte Internet-exponierte Architektur. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination und Backend Cloaking müssen deshalb als zusammenhängende Security-Zone vor den Backends betrachtet werden. Entscheidend ist, welcher Traffic die Backends überhaupt erreicht und unter welchen Bedingungen.
TLS Termination an der Edge architektonisch planen
TLS Termination an der Edge verkürzt den Weg von Client zu geschütztem Einstiegspunkt, verschiebt aber Verantwortlichkeiten. Zertifikate, Vertrauensgrenzen und Backend-Verbindungen müssen deshalb getrennt geplant werden. Die zentrale Frage lautet nicht, ob TLS am öffentlichen Eingang endet, sondern welche Verbindungen danach weiterhin verschlüsselt und wie ihre Identitäten geprüft werden.
Backend Cloaking als Baustein der Edge-Security
Backend Cloaking reduziert die direkte öffentliche Erreichbarkeit von Ursprungsdiensten, indem Clients nicht unmittelbar mit den Backends kommunizieren. Das senkt die öffentliche Angriffsfläche, ersetzt aber weder WAF-Regeln noch Anwendungsschutz. Entscheidend sind sauberes Routing, kontrollierte Backend-Zugriffe und ein Betriebsmodell für Health Checks und Failover.
DDoS-Schutz an der Edge und seine Grenzen im Backend
DDoS-Schutz an der Edge reduziert volumetrischen und netzwerkseitigen Angriffsdruck, bevor er die öffentliche Infrastruktur eines Unternehmens erreicht. Scrubbing schützt damit den Eingang zu Anwendungen und APIs. Es ersetzt jedoch weder Backend-Sicherheit noch Authentisierung, Ressourcenlimits oder fachliche Prüfungen gegen missbräuchliche Nutzung.
WAF an der Edge: Regeln, Grenzen und Betriebsmodelle
Eine WAF an der Edge prüft HTTP- und HTTPS-Anfragen, bevor sie Backends erreichen. Sie eignet sich für protokoll- und anfragespezifische Muster wie Injection, unerlaubte Methoden oder auffällige Request-Strukturen. Fachlicher Kontext, Geschäftslogik und komplexe Autorisierung bleiben jedoch Aufgabe der Anwendung. Entscheidend ist ein Betriebsmodell, das Schutzwirkung und Fehlalarmrisiko kontrolliert.
Health Checks als Grundlage stabiler Traffic-Pfade
Health Checks im Loadbalancing bewerten nicht nur, ob ein Backend-Netzwerkziel erreichbar ist. Entscheidend ist, ob der Service tatsächlich Anfragen verarbeiten kann. Die Ergebnisse beeinflussen Pool-Zustände, Failover und Traffic-Steuerung. Damit werden Health Checks zur Grundlage verlässlicher Backend-Auswahl und stabiler öffentlicher Zugriffspfade.
Traffic-Pfade mit TLS und Proxy Protocol steuern
Ein stabiler Traffic-Pfad endet nicht bei der TLS Termination. Entscheidend ist das abgestimmte Zusammenspiel aus TLS-Endpunkt, Routing, Backend-Auswahl, Health Checks und Proxy Protocol. Die Edge bestimmt den öffentlichen Verbindungsweg; die Anwendung muss festlegen, wie sie übertragene Client-Informationen verarbeitet und welche Protokollparameter sie akzeptiert.
L7-Routing für APIs: Regeln, Pools und Backends
L7-Routing verteilt API-Anfragen nicht nur nach IP-Adresse oder Port, sondern nach Merkmalen der Anwendung. Pfad, Hostname, HTTP-Methode oder Header können unterschiedliche Backend-Pools ansprechen. Entscheidend sind klare Regeln, definierte Prioritäten und eine saubere Grenze zwischen Edge-Routing und anwendungsinterner Logik.
Anycast und Backend-Failover im Aktiv-Aktiv-Betrieb
Aktiv-Aktiv-Failover entsteht nicht durch einen einzelnen Mechanismus, sondern durch das Zusammenspiel von Anycast, verteilten Edge-PoPs, belastbaren Health Checks und dynamischer Backend-Auswahl. Fällt ein Backend aus, muss die Edge den Zustand erkennen und neue Verbindungen gezielt an verfügbare Backends verteilen, ohne einen zentralen Primärpfad vorauszusetzen.
Netzwerk-Routing und Application-Routing trennen
Netzwerk-Routing und Application-Routing lösen unterschiedliche Probleme. Anycast und Layer 4 bestimmen, wie Traffic einen Edge-Einstieg erreicht und zu welchem Transportziel weiterläuft. Layer 7 entscheidet dagegen anhand von Hostnames, Pfaden oder HTTP-Eigenschaften, welcher Service die Anfrage verarbeitet. Diese Ebenen müssen getrennt modelliert werden, damit Architektur, Betrieb und Fehlersuche beherrschbar bleiben.
Proxy Protocol im Backend-Pool korrekt einsetzen
Proxy Protocol überträgt Verbindungsinformationen aus einem Proxy- oder Loadbalancing-Layer an das Backend. Damit können Anwendungen die ursprüngliche Client-IP und weitere Transportdaten auswerten. Voraussetzung sind ein abgestimmtes Protokoll, kompatible Listener und eine konsistente Konfiguration im gesamten Backend-Pool.
TLS Termination an der Edge: Routing sicher gestalten
TLS Termination beendet die äußere HTTPS-Verbindung an der Edge und schafft den technischen Übergabepunkt für anwendungsbezogenes Routing. Damit werden Host-, Pfad- und Header-Regeln möglich. Die Architektur muss jedoch klar festlegen, welche Sicherheits- und Routingaufgaben die Edge übernimmt und welche Kontrolle beim Backend verbleibt.
Backend-Pools planen: Health Checks und Failover
Backend-Pools sind keine bloßen Listen von Zielsystemen. Ihre Zusammensetzung bestimmt, welche Backends Traffic erhalten, wie Ausfälle erkannt werden und wann Failover greift. Aussagekräftige Health Checks, klare Pool-Grenzen und ein definierter Rückfallpfad verhindern, dass die Edge Traffic an technisch erreichbare, aber nicht funktionsfähige Systeme verteilt.
Anycast im Traffic-Management: Routing bis zum Backend
Anycast Traffic Management beginnt mit einem global erreichbaren Einstiegspunkt, endet aber nicht am nächstgelegenen Edge-Standort. Anycast Routing führt den Traffic zu einer Edge-Instanz; dort entscheiden Layer-4- und Layer-7-Regeln über Backend-Pools, Health Status und gegebenenfalls Application-Routing. Erst diese Trennung schafft einen kontrollierbaren Pfad bis zur Anwendung.
L4 oder L7: Traffic-Management in der Edge Cloud
L4- und L7-Loadbalancing lösen unterschiedliche Aufgaben. Layer 4 vermittelt Verbindungen anhand von IP, Port und Transportprotokoll, ohne den Anwendungsinhalt auszuwerten. Layer 7 versteht HTTP oder HTTPS und ermöglicht Routing nach Hostname, Pfad oder weiteren Request-Merkmalen. Die Entscheidung bestimmt TLS-Verarbeitung, Backend-Pools und Betriebsaufwand.