{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "ayedo",
  "home_page_url": "https://ayedo.de/",
  "feed_url": "https://ayedo.de/en/",
  "description": "At ayedo you find all the modules for successfully operating cloud-native software to the highest security standards. ISO-certified, DORA-compliant, and with 24/7 support.",
  "icon": "https://ayedo.de/ayedo-logo-color.png",
  "favicon": "https://ayedo.de/ayedo-logo-color.png",
  "authors": [
    {
      "name": "Fabian Peter",
      "url": "https://www.linkedin.com/in/derfabianpeter/"
    }
  ],
  "language": "en",
  "items": [{
      "id": "https://ayedo.de/en/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/",
      "url": "https://ayedo.de/en/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/",
      "title": "Digital Sovereignty Does Not End at the Data Center",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/digitale-souveranitat-endet-nicht-im-rechenzentrum/digitale-souveranitat-endet-nicht-im-rechenzentrum.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"why-we-built-the-ayedo-edge-cloud\"\u003eWhy We Built the ayedo Edge Cloud\u003c/h2\u003e\n\u003cp\u003eAn application can be fully operated in Germany and still rely on US infrastructure for every single access.\u003c/p\u003e\n\u003cp\u003eBecause before a request reaches the first pod in the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n, a lot has already happened. DNS has resolved the name. The internet has chosen a network path. A public IP has been reached. TLS has been terminated or forwarded. Traffic has been inspected and distributed to a backend.\u003c/p\u003e\n\u003cp\u003eThis layer is exactly what we call the Edge.\u003c/p\u003e\n\u003cp\u003eAnd this is precisely where the question begins for us: who actually has technical control over an application?\u003c/p\u003e\n\u003ch2 id=\"it-starts-not-with-the-server-but-with-the-routing\"\u003eIt Starts Not with the Server, but with the Routing\u003c/h2\u003e\n\u003cp\u003eThe technical foundation of our Edge Cloud is our own Autonomous System. This allows us to operate the network layer through which our Edge locations announce their routes on the internet.\u003c/p\u003e\n\u003cp\u003eAt launch, five Points of Presence are active in Germany: Hamburg, Alsbach, and three locations in Frankfurt. All five are active and announce the same Anycast prefixes.\u003c/p\u003e\n\u003cp\u003eThis is a significant difference from an architecture where a service is bound to a specific location and its IP address.\u003c/p\u003e\n\u003cp\u003eWith Anycast, the same public IP is accessible simultaneously from multiple locations. Routing decides through which accessible PoP a new connection is established. If a location fails, there is no need to activate a standby system and wait for DNS propagation. The remaining PoPs continue to announce the route.\u003c/p\u003e\n\u003cp\u003eAvailability is thus achieved at the network level.\u003c/p\u003e\n\u003ch2 id=\"dns-is-part-of-the-infrastructure\"\u003eDNS Is Part of the Infrastructure\u003c/h2\u003e\n\u003cp\u003eAlmost every connection is preceded by a DNS query. Therefore, we do not treat DNS as an external add-on service.\u003c/p\u003e\n\u003cp\u003eDNS zones are provided via the Edge infrastructure with Anycast. Queries can thus use an accessible PoP. Internal and external zones can be centrally managed, and external zones can be synchronized with supported DNS providers.\u003c/p\u003e\n\u003cp\u003eBut it is also crucial how DNS is operated.\u003c/p\u003e\n\u003cp\u003eThe configuration can be integrated into automation processes. DNS thus becomes part of Infrastructure as Code, CI/CD, and GitOps instead of a configuration that someone manually maintains in a foreign web interface.\u003c/p\u003e\n\u003cp\u003eThis is practical for developers. For companies, it is above all traceable and reproducible.\u003c/p\u003e\n\u003ch2 id=\"the-public-ip-does-not-have-to-belong-to-the-cloud-provider\"\u003eThe Public IP Does Not Have to Belong to the Cloud Provider\u003c/h2\u003e\n\u003cp\u003eAn often underestimated lock-in occurs with IP addresses.\u003c/p\u003e\n\u003cp\u003eIf a company changes providers and thus its public IPs, it quickly affects more than one DNS record. Allowlists with partners, firewall rules, APIs, certificate processes, and other systems can be tied to these addresses.\u003c/p\u003e\n\u003cp\u003eTherefore, the Edge Cloud supports Bring Your Own IP.\u003c/p\u003e\n\u003cp\u003eCompanies can use their own IP prefixes. We announce and route these through our Edge infrastructure.\u003c/p\u003e\n\u003cp\u003eThis allows the public address space to be separated from the compute provider. A backend can change without necessarily having to change its public identity on the network.\u003c/p\u003e\n\u003cp\u003eThis is a very concrete difference between \u0026ldquo;we can theoretically change the provider\u0026rdquo; and \u0026ldquo;our architecture is actually prepared for it.\u0026rdquo;\u003c/p\u003e\n\u003ch2 id=\"edge-and-compute-are-deliberately-separated\"\u003eEdge and Compute Are Deliberately Separated\u003c/h2\u003e\n\u003cp\u003eThe Edge Cloud is not tied to the ayedo Compute Cloud.\u003c/p\u003e\n\u003cp\u003eThe application can run in our Compute Cloud, in another \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n, with another provider, or on-premises. DNS and traffic can still be provided via the Edge.\u003c/p\u003e\n\u003cp\u003eThis fundamentally changes the architecture.\u003c/p\u003e\n\u003cp\u003eThe public entry point and the location where compute takes place become two separate decisions.\u003c/p\u003e\n\u003cp\u003eA company can thus change its compute location without having to completely rebuild external accessibility at the same time. Conversely, the Edge infrastructure can be replaced or expanded without fundamentally changing the application architecture.\u003c/p\u003e\n\u003cp\u003eThis decoupling precisely reduces dependencies.\u003c/p\u003e\n\u003ch2 id=\"the-path-from-the-internet-to-the-pod-is-clearly-defined\"\u003eThe Path from the Internet to the Pod Is Clearly Defined\u003c/h2\u003e\n\u003cp\u003eTechnically, the path of a request for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes workloads\u003c/a\u003e\n looks like this:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eClient → ayedo Edge / Loadbalancer → Node → Ingress Controller or Gateway Proxy → Service → Pod.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe individual layers have different tasks.\u003c/p\u003e\n\u003cp\u003eThe Edge load balancer holds the public virtual IP, performs health checks, and can terminate or forward TCP or HTTP traffic. In the cluster, the Ingress Controller or Gateway Proxy then takes over routing based on hostname and path. TLS can be terminated there or passed through.\u003c/p\u003e\n\u003cp\u003eFor existing \u003ca href=\"/en/kubernetes/\"\u003eKubernetes workloads\u003c/a\u003e\n, we support NGINX Ingress with the established \u003ccode\u003eIngress\u003c/code\u003e and \u003ccode\u003eIngressClass\u003c/code\u003e resources.\u003c/p\u003e\n\u003cp\u003eFor new architectures, Envoy Gateway with the Kubernetes Gateway API is available. Routing is described there using resources like \u003ccode\u003eGateway\u003c/code\u003e, \u003ccode\u003eHTTPRoute\u003c/code\u003e, and \u003ccode\u003eTLSRoute\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis is deliberately not a proprietary ayedo routing API that technically binds applications to our platform.\u003c/p\u003e\n\u003ch2 id=\"protection-occurs-before-traffic-reaches-the-application\"\u003eProtection Occurs Before Traffic Reaches the Application\u003c/h2\u003e\n\u003cp\u003eTherefore, the Edge also includes the security functions that take effect before the actual workload.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud bundles DNS, TLS, Layer-4 and Layer-7 load balancing, Web Application Firewall, DDoS protection, and health checks.\u003c/p\u003e\n\u003cp\u003eThe WAF is thus not located somewhere within the application but can inspect HTTP(S) traffic already at the Edge. Only then does legitimate traffic reach cluster ingress, services, and pods.\u003c/p\u003e\n\u003cp\u003eHealth checks fulfill an equally important function: A route can be technically reachable even though the backend behind it no longer functions. Therefore, network redundancy alone is not enough. The Edge must also know which targets are actually available.\u003c/p\u003e\n\u003cp\u003eNetwork, routing, application health, and protection mechanisms thus belong together.\u003c/p\u003e\n\u003ch2 id=\"a-european-cloud-needs-a-european-network-layer\"\u003eA European Cloud Needs a European Network Layer\u003c/h2\u003e\n\u003cp\u003eCloudflare has shown how valuable it is to combine DNS, routing, load balancing, and security at a global Edge.\u003c/p\u003e\n\u003cp\u003eThe problem is not this technical model. On the contrary: It is very good.\u003c/p\u003e\n\u003cp\u003eThe problem arises when we operate applications, databases, and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n in Europe under European conditions, but let the entire public access be permanently controlled by infrastructure operated outside of Europe.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s why we are building this layer ourselves.\u003c/p\u003e\n\u003cp\u003eWith our own Autonomous System. Our own Edge infrastructure in the EU. Anycast over multiple active PoPs. Our own routing. Anycast DNS. Load balancing. WAF and DDoS protection. Open Kubernetes interfaces. And the ability to keep compute and even the public IP address space independent of the platform provider.\u003c/p\u003e\n\u003cp\u003eBecause the crucial question is not only, \u003cstrong\u003ewhere an application runs\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eBut who controls DNS, IP addresses, routing, and the path to this application.\u003c/p\u003e\n",
      "summary": "\nWhy We Built the ayedo Edge Cloud An application can be fully operated in Germany and still rely on US infrastructure for every single access.\nBecause before a request reaches the first pod in the Kubernetes cluster , a lot has already happened. DNS has resolved the name. The internet has chosen a network path. A public IP has been reached. TLS has been terminated or forwarded. Traffic has been inspected and distributed to a backend.\n",
      "image": "https://ayedo.de/digitale-souveranitat-endet-nicht-im-rechenzentrum.png",
      "date_published": "2026-09-09T08:26:13Z",
      "date_modified": "2026-09-09T08:26:13Z",
      "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}],
      "tags": ["kubernetes","digital-sovereignty","politics","operations","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/",
      "url": "https://ayedo.de/en/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/",
      "title": "DNS, Routing, Anycast: Why Europe's Cloud Also Needs Its Own Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003eWe recently introduced the ayedo Edge Cloud, a European edge infrastructure for DNS, Anycast, load balancing, web application firewall, DDoS protection, and controlled access to applications.\u003c/p\u003e\n\u003cp\u003eThe response showed us that a closer look at the technology is worthwhile. An Edge Cloud is far more than just a front-end load balancer.\u003c/p\u003e\n\u003cp\u003eIt controls a crucial part of the infrastructure: the path from the public internet to the actual application.\u003c/p\u003e\n\u003cp\u003eBefore a request reaches the first pod in the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n, several processes have already occurred. DNS has resolved a name. The internet has chosen a network path based on BGP routes. A public IP has been reached. A connection has been accepted, traffic checked, and then forwarded to an available backend.\u003c/p\u003e\n\u003cp\u003eWhoever operates these components controls a significant part of the access to the application.\u003c/p\u003e\n\u003cp\u003eTherefore, we didn\u0026rsquo;t start with a single product feature for our Edge Cloud. We built the underlying infrastructure.\u003c/p\u003e\n\u003ch2 id=\"an-autonomous-system-as-the-foundation\"\u003eAn Autonomous System as the Foundation\u003c/h2\u003e\n\u003cp\u003eThe technical basis of our Edge Cloud is our own Autonomous System.\u003c/p\u003e\n\u003cp\u003eAn Autonomous System, or AS, is essentially an independently managed part of the internet with its own routing policy. Through BGP, such networks exchange which IP networks are reachable through them.\u003c/p\u003e\n\u003cp\u003eFor our Edge, this means: We operate the network layer through which our locations announce their routes on the internet.\u003c/p\u003e\n\u003cp\u003eTo start, five Points of Presence are operational in Germany: Hamburg, Alsbach, and three locations in Frankfurt. All five are active and announce the same Anycast prefixes.\u003c/p\u003e\n\u003ch2 id=\"one-ip-address-multiple-locations\"\u003eOne IP Address, Multiple Locations\u003c/h2\u003e\n\u003cp\u003eAnycast is a central component of this architecture.\u003c/p\u003e\n\u003cp\u003eThe same IP prefix is announced simultaneously from multiple locations. A user connects to the same public IP address, but this IP is not tied to a single server or location.\u003c/p\u003e\n\u003cp\u003eBGP determines, based on available routes, through which PoP the connection reaches the Edge.\u003c/p\u003e\n\u003cp\u003eThis has a crucial advantage: If a location fails and its route is withdrawn, the other locations remain reachable. New connections can be routed through another PoP. There is no need to change a public IP or wait for a DNS entry update.\u003c/p\u003e\n\u003cp\u003eRedundancy thus begins not at the server but already in the routing.\u003c/p\u003e\n\u003ch2 id=\"dns-also-runs-over-the-edge\"\u003eDNS Also Runs Over the Edge\u003c/h2\u003e\n\u003cp\u003eIn most cases, DNS precedes the actual connection. Therefore, this layer is also part of the Edge Cloud.\u003c/p\u003e\n\u003cp\u003eDNS zones are provided via our Edge infrastructure with Anycast. Thus, name resolution is not tied to a single location.\u003c/p\u003e\n\u003cp\u003eAt the same time, we do not treat DNS as a configuration that can only be managed via a web interface. DNS can be automated and integrated into Infrastructure-as-Code, CI/CD, and GitOps processes.\u003c/p\u003e\n\u003cp\u003eThis is particularly important for platform teams: Infrastructure remains reproducible and can be managed with the same processes as the rest of the stack.\u003c/p\u003e\n\u003ch2 id=\"the-public-ip-doesnt-have-to-belong-to-us\"\u003eThe Public IP Doesn\u0026rsquo;t Have to Belong to Us\u003c/h2\u003e\n\u003cp\u003eAnother component is Bring Your Own IP, or BYOIP.\u003c/p\u003e\n\u003cp\u003eCompanies can bring their own IP prefixes, which we announce and route via our Edge infrastructure.\u003c/p\u003e\n\u003cp\u003eThis initially sounds like a detail for network administrators. However, it is relevant for the independence of an infrastructure.\u003c/p\u003e\n\u003cp\u003ePublic IP addresses end up in firewall rules, allowlists of business partners, APIs, and other configurations over time. If these addresses belong to the cloud provider, switching providers can mean much more than just moving some workloads.\u003c/p\u003e\n\u003cp\u003eWith BYOIP, the addresses remain with the company. The public address space and the underlying compute infrastructure are separated.\u003c/p\u003e\n\u003ch2 id=\"edge-and-compute-are-two-different-decisions\"\u003eEdge and Compute Are Two Different Decisions\u003c/h2\u003e\n\u003cp\u003eThis separation runs through the entire architecture.\u003c/p\u003e\n\u003cp\u003eThe application behind our Edge does not have to run in the ayedo Compute Cloud. It can be operated there, in a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n with another provider, or in its own infrastructure.\u003c/p\u003e\n\u003cp\u003eThe Edge takes over public access and forwards traffic to the defined backend.\u003c/p\u003e\n\u003cp\u003eThis decouples two things that often coincide in cloud platforms: \u003cstrong\u003eWhere does my application run – and through whose infrastructure is it accessible?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis enables hybrid and multi-provider architectures without having to build a completely separate public access layer for each compute location.\u003c/p\u003e\n\u003ch2 id=\"from-the-internet-to-the-kubernetes-pod\"\u003eFrom the Internet to the Kubernetes Pod\u003c/h2\u003e\n\u003cp\u003eIn \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, this path can be traced very concretely:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eClient → ayedo Edge / Load Balancer → Node → Ingress Controller or Gateway Proxy → Service → Pod\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe Edge load balancer holds the public virtual IP, checks the availability of the backends, and forwards or terminates TCP or HTTP traffic.\u003c/p\u003e\n\u003cp\u003eWithin the cluster, an Ingress Controller or Gateway Proxy then takes over application-specific routing. For example, it decides based on hostname and path which service receives an HTTP request.\u003c/p\u003e\n\u003cp\u003eFor existing \u003ca href=\"/en/kubernetes/\"\u003eKubernetes architectures\u003c/a\u003e\n, we support NGINX Ingress with \u003ccode\u003eIngress\u003c/code\u003e and \u003ccode\u003eIngressClass\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFor new architectures, Envoy Gateway with the Kubernetes Gateway API and resources like \u003ccode\u003eGateway\u003c/code\u003e, \u003ccode\u003eHTTPRoute\u003c/code\u003e, and \u003ccode\u003eTLSRoute\u003c/code\u003e is available.\u003c/p\u003e\n\u003cp\u003eThis is an important architectural principle for us: The transition from our infrastructure to the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n is based on established cloud-native standards and not on proprietary ayedo routing logic.\u003c/p\u003e\n\u003ch2 id=\"security-belongs-in-front-of-the-application\"\u003eSecurity Belongs in Front of the Application\u003c/h2\u003e\n\u003cp\u003eThe protection mechanisms sit on the same level.\u003c/p\u003e\n\u003cp\u003eTherefore, the Edge Cloud includes Layer-4 and Layer-7 load balancing, TLS, web application firewall, DDoS protection, and health checks.\u003c/p\u003e\n\u003cp\u003eThe WAF can inspect HTTP(S) traffic before it reaches the underlying applications. DDoS protection starts at the upstream infrastructure. Health checks ensure that traffic is not simply sent to a target just because its network route still exists.\u003c/p\u003e\n\u003cp\u003eThis is an important distinction: A reachable server is not necessarily a functioning service.\u003c/p\u003e\n\u003cp\u003eEdge infrastructure must therefore consider routing, availability, and security together.\u003c/p\u003e\n\u003ch2 id=\"a-european-alternative-must-convince-technically\"\u003eA European Alternative Must Convince Technically\u003c/h2\u003e\n\u003cp\u003eCloudflare has successfully turned this infrastructure layer into a product. Getting DNS, Anycast, routing, load balancing, and security from a single source solves real technical problems.\u003c/p\u003e\n\u003cp\u003eA European alternative cannot consist of simply labeling the same concept with an EU tag.\u003c/p\u003e\n\u003cp\u003eIt needs its own infrastructure.\u003c/p\u003e\n\u003cp\u003eIts own Autonomous System. Its own routing. Multiple active PoPs. Anycast. DNS. Load balancing. WAF and DDoS protection. Open interfaces to \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. The ability to choose compute independently. And with BYOIP, even the ability to retain one\u0026rsquo;s own public address space.\u003c/p\u003e\n\u003cp\u003eThis is exactly the infrastructure we are building with the ayedo Edge Cloud.\u003c/p\u003e\n\u003cp\u003eBecause European cloud infrastructure is only a real alternative when it not only differs regulatorily but also technically regains control over the critical layers.\u003c/p\u003e\n",
      "summary": "\nWe recently introduced the ayedo Edge Cloud, a European edge infrastructure for DNS, Anycast, load balancing, web application firewall, DDoS protection, and controlled access to applications.\nThe response showed us that a closer look at the technology is worthwhile. An Edge Cloud is far more than just a front-end load balancer.\nIt controls a crucial part of the infrastructure: the path from the public internet to the actual application.\n",
      "image": "https://ayedo.de/dns-routing-anycast-warum-europas-cloud-auch-eine-eigene-edge-braucht.png",
      "date_published": "2026-09-09T08:19:24Z",
      "date_modified": "2026-09-09T08:19:24Z",
      "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}],
      "tags": ["kubernetes","cloud-native","security","politics","cloud"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/building-the-edge-part-1/",
      "url": "https://ayedo.de/en/posts/building-the-edge-part-1/",
      "title": "Building the Edge — Part 1",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/building-the-edge-part-1/building-the-edge-part-1.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"the-underestimated-architecture-of-modern-applications\"\u003eThe Underestimated Architecture of Modern Applications\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eModern applications no longer start in the data center.\u003c/em\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThere is a peculiar characteristic of modern software.\u003c/p\u003e\n\u003cp\u003eThe more powerful our platforms have become, the simpler their architecture seems at first glance.\u003c/p\u003e\n\u003cp\u003eToday, we talk about \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, GitOps, Infrastructure as Code, or Continuous Deployment as if they were self-evident components of every application. Clusters are created within minutes, \u003ca href=\"/en/kubernetes/\"\u003econtainers\u003c/a\u003e\n are automatically scaled, and new versions reach production without users even noticing. Compared to the infrastructure of past decades, modern software seems almost elegant.\u003c/p\u003e\n\u003cp\u003ePerhaps even surprisingly simple.\u003c/p\u003e\n\u003cp\u003eBut this impression is misleading.\u003c/p\u003e\n\u003cp\u003eNot because modern systems are more complicated than their predecessors.\u003c/p\u003e\n\u003cp\u003eBut because their complexity has shifted to a place we surprisingly rarely discuss.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eLet\u0026rsquo;s consider for a moment how most architecture diagrams begin.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#cdd6f4;background-color:#1e1e2e;-moz-tab-size:2;-o-tab-size:2;tab-size:2;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eApplication\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    +----------------------+\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |    Kubernetes        |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    +----------------------+\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e             |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    +----------------------+\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |      Database        |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    +----------------------+\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e             |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         Internet ☁\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eIt\u0026rsquo;s a diagram that probably everyone knows.\u003c/p\u003e\n\u003cp\u003eOn the left is the Internet.\u003c/p\u003e\n\u003cp\u003eThen follows a load balancer, perhaps an ingress controller, then \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, and finally the actual application.\u003c/p\u003e\n\u003cp\u003eInterestingly, we almost exclusively discuss the right part of this diagram.\u003c/p\u003e\n\u003cp\u003eWe talk about \u003ca href=\"/en/kubernetes/\"\u003econtainers\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eAbout databases.\u003c/p\u003e\n\u003cp\u003eAbout replication.\u003c/p\u003e\n\u003cp\u003eAbout observability.\u003c/p\u003e\n\u003cp\u003eAbout deployments.\u003c/p\u003e\n\u003cp\u003eThe left part, however, often disappears behind a small cloud labeled \u003cem\u003eInternet\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eAs if nothing else of significance lies between a user and our platform.\u003c/p\u003e\n\u003cp\u003ePerhaps this is one of the greatest misunderstandings of modern infrastructure.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThe notion that an application begins where the first process is started or the first pod is scheduled comes from a time when applications and infrastructure were almost synonymous.\u003c/p\u003e\n\u003cp\u003eA web server was an application.\u003c/p\u003e\n\u003cp\u003eAn application was a server.\u003c/p\u003e\n\u003cp\u003eBetween a user\u0026rsquo;s browser and the actual software, there were comparatively few technical layers. A router forwarded packets, a web server answered HTTP requests, and a database stored information. Routing, transport, and application formed a unit that could still be explained on a sheet of paper.\u003c/p\u003e\n\u003cp\u003eToday, this picture seems almost nostalgic.\u003c/p\u003e\n\u003cp\u003eNot because it was wrong.\u003c/p\u003e\n\u003cp\u003eBut because it describes a world that hardly exists in this form anymore.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eIn the past decade and a half, we have made enormous efforts to decouple applications from their infrastructure.\u003c/p\u003e\n\u003cp\u003eVirtual machines replaced physical servers.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/en/kubernetes/\"\u003eContainers\u003c/a\u003e\n made applications portable.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n detached workloads from individual hosts.\u003c/p\u003e\n\u003cp\u003eInfrastructure as Code replaced manual configurations.\u003c/p\u003e\n\u003cp\u003eGitOps made infrastructure reproducible.\u003c/p\u003e\n\u003cp\u003eEach of these developments pursued the same goal.\u003c/p\u003e\n\u003cp\u003eTo reduce complexity within a platform.\u003c/p\u003e\n\u003cp\u003eAnd they were extraordinarily successful.\u003c/p\u003e\n\u003cp\u003ePerhaps therein lies a remarkable irony.\u003c/p\u003e\n\u003cp\u003eBecause while we abstracted applications further and further, a completely new architectural layer emerged outside these platforms, whose responsibility continuously grew.\u003c/p\u003e\n\u003cp\u003eInfrastructure hasn\u0026rsquo;t become simpler.\u003c/p\u003e\n\u003cp\u003eIt has moved.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThe first contact between a user and a modern application no longer takes place in the data center.\u003c/p\u003e\n\u003cp\u003eIt occurs at a point that often doesn\u0026rsquo;t even appear in architecture diagrams.\u003c/p\u003e\n\u003cp\u003eEven before \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n selects a pod.\u003c/p\u003e\n\u003cp\u003eEven before a service decides which backend processes a request.\u003c/p\u003e\n\u003cp\u003eEven before a single line of application code is executed.\u003c/p\u003e\n\u003cp\u003eThere already exists an infrastructure whose sole purpose is to prepare exactly these decisions.\u003c/p\u003e\n\u003cp\u003eIt determines which path a connection takes through the Internet.\u003c/p\u003e\n\u003cp\u003eWhere it ends.\u003c/p\u003e\n\u003cp\u003eWhether it is encrypted.\u003c/p\u003e\n\u003cp\u003eWhether it is legitimate.\u003c/p\u003e\n\u003cp\u003eWhether it is even allowed to reach the actual application.\u003c/p\u003e\n\u003cp\u003eThis distinction may initially seem subtle.\u003c/p\u003e\n\u003cp\u003eIn reality, however, it changes our entire perspective on modern platforms.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eBecause suddenly an application no longer begins where it is executed.\u003c/p\u003e\n\u003cp\u003eIt begins where a user first interacts with it.\u003c/p\u003e\n\u003cp\u003eThis thought initially seems almost self-evident.\u003c/p\u003e\n\u003cp\u003eAnd yet we usually treat our systems as if that were not the case.\u003c/p\u003e\n\u003cp\u003eWe invest weeks in planning our \u003ca href=\"/en/kubernetes/\"\u003eKubernetes architecture\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eWe discuss storage classes, deployment strategies, or service meshes.\u003c/p\u003e\n\u003cp\u003eAt the same time, the entire path up to that point often disappears behind a single line labeled \u003cem\u003eInternet\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003ePerhaps that is the real problem.\u003c/p\u003e\n\u003cp\u003eThe Internet is not a cloud.\u003c/p\u003e\n\u003cp\u003eIt is not a connection between two boxes in a diagram.\u003c/p\u003e\n\u003cp\u003eAnd certainly not a transparent transport channel through which requests simply flow.\u003c/p\u003e\n\u003cp\u003eIt is probably the largest distributed system ever built.\u003c/p\u003e\n\u003cp\u003eA system that makes routing decisions.\u003c/p\u003e\n\u003cp\u003eThat connects networks.\u003c/p\u003e\n\u003cp\u003eThat continuously evaluates which paths are reachable and which are not.\u003c/p\u003e\n\u003cp\u003eAnd that influences every single request long before an application even has the opportunity to respond.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eGood infrastructure has a remarkable characteristic.\u003c/p\u003e\n\u003cp\u003eIt disappears.\u003c/p\u003e\n\u003cp\u003eNo one cares about DNS as long as a domain reliably resolves.\u003c/p\u003e\n\u003cp\u003eNo one thinks about routing as long as web pages load within milliseconds.\u003c/p\u003e\n\u003cp\u003eNo one deals with TLS as long as the small lock symbol appears in the browser.\u003c/p\u003e\n\u003cp\u003eAnd hardly anyone wonders which path a request actually took as long as the response comes back quickly enough.\u003c/p\u003e\n\u003cp\u003eGood infrastructure does not attract attention.\u003c/p\u003e\n\u003cp\u003eIt generates trust.\u003c/p\u003e\n\u003cp\u003ePerhaps that is why we find it so difficult to think about it.\u003c/p\u003e\n\u003cp\u003eWe usually only see it when it fails.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003ePerhaps it is time to start our architecture diagrams at a different point.\u003c/p\u003e\n\u003cp\u003eNot here.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#cdd6f4;background-color:#1e1e2e;-moz-tab-size:2;-o-tab-size:2;tab-size:2;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eInternet ☁\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eKubernetes\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e     |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eApplication\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eBut here.\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre style=\"color:#cdd6f4;background-color:#1e1e2e;-moz-tab-size:2;-o-tab-size:2;tab-size:2;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eBrowser\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eDNS\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eRouting\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ePeering\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eAnycast\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eTLS\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eEdge\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eLoad balancing\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eKubernetes\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eApplication\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eBecause modern applications no longer start in the data center.\u003c/p\u003e\n\u003cp\u003ePerhaps they never did.\u003c/p\u003e\n",
      "summary": "\nThe Underestimated Architecture of Modern Applications Modern applications no longer start in the data center.\nThere is a peculiar characteristic of modern software.\nThe more powerful our platforms have become, the simpler their architecture seems at first glance.\nToday, we talk about Kubernetes , GitOps, Infrastructure as Code, or Continuous Deployment as if they were self-evident components of every application. Clusters are created within minutes, containers are automatically scaled, and new versions reach production without users even noticing. Compared to the infrastructure of past decades, modern software seems almost elegant.\n",
      "image": "https://ayedo.de/building-the-edge-part-1.png",
      "date_published": "2026-09-09T07:38:27Z",
      "date_modified": "2026-09-09T07:38:27Z",
      "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}],
      "tags": ["kubernetes","operations","software-delivery","cloud-native","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/",
      "url": "https://ayedo.de/en/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/",
      "title": "TLS Certificates for Public Kubernetes Endpoints",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-zertifikate-fur-offentliche-kubernetes-endpunkte/tls-zertifikate-fur-offentliche-kubernetes-endpunkte.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n does not necessarily end at the Ingress. Central TLS termination at the ayedo Edge Cloud simplifies certificate management, WAF integration, and traffic control. However, additional encryption up to the cluster protects further network segments. The right decision depends on trust boundaries, operating model, \u003ca href=\"/en/compliance/\"\u003ecompliance\u003c/a\u003e\n, and desired fault isolation.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA publicly accessible \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n endpoint requires more than just a certificate at the Ingress. The critical factor is where the TLS connection ends and which path still needs protection afterward. If TLS is terminated solely at the edge, the backend typically receives HTTP or another unencrypted forwarding within the infrastructure. This can be operationally efficient but shifts the trust boundary. A second TLS path up to the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n service increases both protection and complexity. Therefore, for TLS for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, the question is not \u0026ldquo;Edge or Ingress?\u0026rdquo; but rather the clear assignment of responsibility, certificate lifecycle, and network trust.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-at-the-edge-as-a-central-architecture\"\u003e1. TLS Termination at the Edge as a Central Architecture\u003c/h2\u003e\n\u003cp\u003eWith TLS termination at the edge, the ayedo Edge Cloud receives the public HTTPS connection. The certificate for the external hostname is managed there, and the encrypted data stream is decrypted at the edge. Subsequently, the edge can forward the traffic to a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n backend based on hostnames, paths, and other rules.\u003c/p\u003e\n\u003cp\u003eThis approach centralizes a key operational task. Certificates do not need to be deployed in every \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster, namespace, or Ingress controller. Rotation, assignment of multiple domains, and public accessibility are handled at an upstream point. Simultaneously, the Edge Cloud can apply functions such as WAF, DDoS protection, and load balancing on the already decrypted HTTP/HTTPS traffic.\u003c/p\u003e\n\u003cp\u003eThe consequence is a clear trust boundary: The network between the edge and backend must be considered sufficiently trustworthy or secured separately. Particularly with multiple providers, distributed clusters, or administratively separated platforms, this assumption should be documented and regularly reviewed.\u003c/p\u003e\n\u003ch2 id=\"2-encryption-up-to-the-kubernetes-backend\"\u003e2. Encryption up to the Kubernetes Backend\u003c/h2\u003e\n\u003cp\u003eAn additional TLS connection from the edge location to the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n backend reduces the unencrypted trust zone. The traffic remains encrypted even on the segment between edge and cluster. This is relevant when network paths run over shared infrastructure, clusters are operated outside one\u0026rsquo;s own network domain, or internal security policies require end-to-end protection.\u003c/p\u003e\n\u003cp\u003eHowever, this creates a second certificate responsibility. The backend requires a certificate whose hostname matches the connection or whose verification is specifically configured. Additionally, trust stores, certificate rotation, and error diagnosis must be considered. A public certificate is not always necessary for this; for the internal path, a custom trusted certificate chain can be used, provided all involved components validate it correctly.\u003c/p\u003e\n\u003cp\u003eIt is important to distinguish terms: TLS termination at the edge does not automatically mean that the backend path must be unencrypted. Between client and edge, as well as between edge and backend, two separate TLS sessions can exist. This is not a technical end-to-end connection in the cryptographic sense because the edge can terminate and process the traffic. However, it is an encrypted connection over both network segments.\u003c/p\u003e\n\u003ch2 id=\"3-certificate-management-across-multiple-endpoints\"\u003e3. Certificate Management Across Multiple Endpoints\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n applications often publish multiple endpoints: different domains, APIs, tenants, or environments. Therefore, certificate management must align with the routing model. A certificate can cover multiple DNS names via Subject Alternative Names, while separate certificates can more clearly isolate responsibilities and rotation. Key factors are SNI, host header, and the mapping between public name, edge configuration, and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Ingress.\u003c/p\u003e\n\u003cp\u003eWith central termination, the management of public certificates lies at the edge. The Ingress then only needs the configuration for the internal forwarding path. If certificates are additionally used in the cluster, their validity and rotation must function independently. An error in an internal certificate chain should not become visible only when the public certificate expires.\u003c/p\u003e\n\u003cp\u003eFor platform teams, this means: Certificate management is not an isolated \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n task. DNS, edge routing, Ingress rules, secret distribution, and monitoring form a common operational chain. The ayedo Edge Cloud can serve as a provider-independent public entry point in front of \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters operated on one\u0026rsquo;s own or by other providers. This prevents each cluster from having to fully replicate its public TLS and traffic architecture separately.\u003c/p\u003e\n\u003ch2 id=\"4-responsibility-boundaries-and-operational-implications\"\u003e4. Responsibility Boundaries and Operational Implications\u003c/h2\u003e\n\u003cp\u003eThe most important architectural decision is the division of responsibilities. The Edge Cloud takes over the public entry, TLS termination, protection, and forwarding. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n typically handles service discovery, Ingress rules within the cluster, and the application itself. This separation reduces coupling but does not replace clear documentation of data flows.\u003c/p\u003e\n\u003cp\u003eFor operations, at least four error scenarios must be distinguishable: an expired edge certificate, an unreachable backend, an error in internal TLS verification, and incorrect routing for hostname or SNI. Traffic and usage statistics at the edge can support the analysis of public data streams. Health checks and failover are relevant when multiple backends or clusters serve as targets.\u003c/p\u003e\n\u003cp\u003eBackend cloaking complements this model: Public clients do not need to know the actual \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n endpoints. This keeps cluster addresses and internal topology out of the public DNS and routing model. The Edge Cloud thus not only provides a certificate function but also forms a controlled boundary between the internet and compute infrastructure.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-api-with-separate-trust-boundaries\"\u003ePractical Scenario: API with Separate Trust Boundaries\u003c/h2\u003e\n\u003cp\u003eA company operates an API in its own \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster and publishes it under \u003ccode\u003eapi.example.org\u003c/code\u003e. The TLS connection from the client ends at the ayedo Edge Cloud. There, WAF rules, DDoS protection, and routing are applied. For a protected internal network path, a second TLS connection to the Ingress is then established.\u003c/p\u003e\n\u003cp\u003eThe public certificate rotation remains at the edge. The cluster only manages the certificate for the internal connection and its trust chain. In a less isolated environment, forwarding could occur unencrypted if the network path is controlled. However, the decision should be made consciously based on data classification, provider boundaries, and operational effort—not out of habit.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-the-kubernetes-ingress-always-need-its-own-public-certificate\"\u003eDoes the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Ingress always need its own public certificate?\u003c/h3\u003e\n\u003cp\u003eNo. With TLS termination at the edge, the Ingress does not need a public certificate. However, for an additional encrypted backend path, a suitable internal certificate and trust configuration are required.\u003c/p\u003e\n\u003ch3 id=\"is-tls-passthrough-synonymous-with-tls-termination\"\u003eIs TLS passthrough synonymous with TLS termination?\u003c/h3\u003e\n\u003cp\u003eNo. With passthrough, the TLS connection remains intact up to the backend. With termination, the edge decrypts the traffic and can inspect, route, and secure it.\u003c/p\u003e\n\u003ch3 id=\"how-many-certificates-are-needed-for-multiple-kubernetes-clusters\"\u003eHow many certificates are needed for multiple \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters?\u003c/h3\u003e\n\u003cp\u003eThis depends on domains, trust boundaries, and the chosen termination. A public certificate at the edge can serve multiple backends; internal TLS paths may each require their own certificates.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eTLS for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n is an architectural question, not merely an Ingress configuration. Central TLS termination at the edge reduces certificate and operational effort and creates a unified public entry point. Additional encryption up to the backend protects further network segments but requires more certificate and trust management. The ayedo Edge Cloud positions these tasks ahead of the compute infrastructure, enabling a deliberate separation of public traffic, edge responsibility, and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n operations.\u003c/p\u003e\n",
      "summary": "\nTL;DR TLS for Kubernetes does not necessarily end at the Ingress. Central TLS termination at the ayedo Edge Cloud simplifies certificate management, WAF integration, and traffic control. However, additional encryption up to the cluster protects further network segments. The right decision depends on trust boundaries, operating model, compliance , and desired fault isolation.\nIntroduction A publicly accessible Kubernetes endpoint requires more than just a certificate at the Ingress. The critical factor is where the TLS connection ends and which path still needs protection afterward. If TLS is terminated solely at the edge, the backend typically receives HTTP or another unencrypted forwarding within the infrastructure. This can be operationally efficient but shifts the trust boundary. A second TLS path up to the Kubernetes service increases both protection and complexity. Therefore, for TLS for Kubernetes , the question is not \u0026ldquo;Edge or Ingress?\u0026rdquo; but rather the clear assignment of responsibility, certificate lifecycle, and network trust.\n",
      "image": "https://ayedo.de/tls-zertifikate-fur-offentliche-kubernetes-endpunkte.png",
      "date_published": "2026-09-08T17:15:05Z",
      "date_modified": "2026-09-08T17:15:05Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","compliance","security","operations","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/",
      "url": "https://ayedo.de/en/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/",
      "title": "DNS Automation for Kubernetes Behind the Edge Cloud",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes DNS and public name resolution address different challenges. Cluster resources are aware of services, ingresses, and workloads; the Edge Cloud manages public endpoints, DNS zones, and backend forwarding. A resilient operational model separates these responsibilities but automates their handovers through clearly defined interfaces.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n environments initially treat DNS automation as a cluster task. This works for internal service names but falls short for public endpoints. Once applications are accessible via a front-end Edge Cloud, at least two separate states emerge: Kubernetes knows the desired application and its service, while DNS represents public accessibility and the Edge depicts the actual traffic path. Mixing both layers directly leads to unclear responsibilities, accidentally published endpoints, and hard-to-trace operational processes. Kubernetes DNS automation should not mean that every cluster resource immediately lands in a public zone.\u003c/p\u003e\n\u003ch2 id=\"1-separate-internal-name-resolution-and-public-endpoints\"\u003e1. Separate Internal Name Resolution and Public Endpoints\u003c/h2\u003e\n\u003cp\u003eKubernetes primarily uses DNS for communication within the cluster. Services receive stable names through which pods can reach applications, even if their IP addresses change. These names belong to the internal cluster model and need not be publicly resolvable.\u003c/p\u003e\n\u003cp\u003eA public endpoint, on the other hand, serves a different function. It describes a functionally or technically stable name like \u003ccode\u003eapi.example.com\u003c/code\u003e, accessible via the Edge Cloud. The public DNS zone does not directly point to pod or node addresses. It points to an edge service that accepts, protects, terminates, distributes traffic, and then forwards it to an appropriate backend.\u003c/p\u003e\n\u003cp\u003eThis separation reduces the risk of exposing internal topology externally. It also allows workloads to be moved within the cluster without changing public DNS entries or client configurations. Backend cloaking is an important architectural principle: for external users, the public edge endpoint remains constant while the underlying infrastructure can change.\u003c/p\u003e\n\u003ch2 id=\"2-organize-responsibilities-across-zones-and-namespaces\"\u003e2. Organize Responsibilities Across Zones and Namespaces\u003c/h2\u003e\n\u003cp\u003eA practical operational model starts with a clear division of DNS zones. The central corporate or domain management remains responsible for the overarching zone. Teams or platforms can receive delegated areas beneath it, such as \u003ccode\u003eapps.example.com\u003c/code\u003e or \u003ccode\u003ecluster-a.example.com\u003c/code\u003e. The key is not the specific naming but the traceable ownership.\u003c/p\u003e\n\u003cp\u003eKubernetes resources should not automatically have write access to the entire public zone. Automation can derive a desired public endpoint from ingress or gateway definitions. Publication then occurs in a controlled manner within a designated namespace and is assigned to an edge service. This includes hostname, protocol, TLS configuration, and backend reference.\u003c/p\u003e\n\u003cp\u003eThis keeps functional DNS decisions and technical cluster states distinguishable. A deleted ingress does not necessarily have to immediately remove a productive DNS entry; depending on the operational model, protection periods, approvals, or checks may be required. These rules are not unnecessary bureaucracy but prevent short-lived test resources from inadvertently affecting public names or productive endpoints.\u003c/p\u003e\n\u003ch2 id=\"3-properly-classify-anycast-dns-and-multi-provider-dns\"\u003e3. Properly Classify Anycast DNS and Multi-Provider DNS\u003c/h2\u003e\n\u003cp\u003eAnycast DNS distributes DNS queries over a distributed infrastructure, reducing dependency on a single accessible location. This is relevant for public Kubernetes applications because DNS is the first step in establishing a connection. However, robust resolution is of little use if the endpoint used afterward is not reachable. DNS availability and traffic availability must therefore be considered together.\u003c/p\u003e\n\u003cp\u003eMulti-provider DNS complements this model with additional organizational and technical decoupling. Authoritative DNS services can be operated across multiple providers, so configuration, failure behavior, and change processes are not tied to a single platform. However, this increases the requirements for consistency, monitoring, and change management. Different TTLs, delayed synchronization, or divergent zone configurations can otherwise lead to hard-to-explain effects.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud provides Anycast DNS and Multi-Provider DNS as components of its edge platform. In the context of \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n, this means: The public name can be modeled independently of the cluster, while its assignment to an edge service is centrally managed. The application remains provider-independent, without public DNS entries needing to point to cluster IP addresses.\u003c/p\u003e\n\u003ch2 id=\"4-automation-requires-a-controlled-handover\"\u003e4. Automation Requires a Controlled Handover\u003c/h2\u003e\n\u003cp\u003eKubernetes DNS automation should be designed as a handover process between two control levels. The cluster side describes which public endpoint is needed for an application. The edge side decides how this endpoint is published, protected, and connected to a backend. There must be a clearly defined state and authorization boundary between both levels.\u003c/p\u003e\n\u003cp\u003eTechnically, automation can, for example, observe changes to ingress or gateway resources, derive a desired hostname from them, and hand over the necessary assignment to the edge platform. Validations should check whether the zone is approved, the name matches the intended naming scheme, and the target backend is permissible. Status messages are equally important: A Kubernetes object should be able to distinguish whether DNS is published, the edge service is active, or the backend is healthy.\u003c/p\u003e\n\u003cp\u003eOperationally, this creates clear responsibilities. The platform team manages cluster integration and resource models; network or edge managers control zones, public endpoints, and security policies. With ayedo Managed Kubernetes or own Kubernetes clusters at other providers, this pattern can be used regardless of the compute location. The Edge Cloud remains the central entry layer, not the internal DNS of the cluster.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-three-levels-one-public-name\"\u003ePractical Scenario: Three Levels, One Public Name\u003c/h2\u003e\n\u003cp\u003eA company operates an API in its own \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n cluster and publishes it under \u003ccode\u003eapi.example.com\u003c/code\u003e. An ingress with this hostname exists in the cluster. The automation checks the delegated zone and does not create a direct DNS entry on a node but assigns the hostname to an edge service.\u003c/p\u003e\n\u003cp\u003eThe public DNS resolution points to the Anycast-capable edge infrastructure. There, TLS is terminated, traffic is processed based on the hostname, and forwarded via a protected backend path to the cluster. If a backend fails, the configured health checks and failover mechanisms of the edge layer take effect. If the API is later moved to a cluster at another provider, the DNS name and edge service remain; only the backend assignment is adjusted.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-every-kubernetes-service-resource-need-public-dns\"\u003eDoes every Kubernetes service resource need public DNS?\u003c/h3\u003e\n\u003cp\u003eNo. Only explicitly published applications require public endpoints. Internal services remain accessible via \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes DNS\u003c/a\u003e\n and are not included in public zones.\u003c/p\u003e\n\u003ch3 id=\"does-anycast-dns-replace-the-traffic-distribution-of-the-edge\"\u003eDoes Anycast DNS replace the traffic distribution of the Edge?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast DNS distributes DNS queries. Subsequent processing, TLS termination, WAF, load distribution, and backend connection are tasks of the edge service layer.\u003c/p\u003e\n\u003ch3 id=\"can-the-model-work-with-a-cluster-outside-of-ayedo\"\u003eCan the model work with a cluster outside of ayedo?\u003c/h3\u003e\n\u003cp\u003eYes. The Edge Cloud can be used with ayedo Managed Kubernetes as well as with own or other provider-operated Kubernetes clusters.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDNS automation for \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n is resilient when internal cluster names and public endpoints are not treated as the same area of responsibility. Kubernetes describes the desired application state; DNS and Edge Cloud ensure public accessibility. Anycast DNS and Multi-Provider DNS complement this model but do not replace clear ownership. The ayedo Edge Cloud is relevant as a provider-independent public entry layer: It connects name resolution, edge service, and backend connection without mixing DNS responsibility with the cluster.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes DNS and public name resolution address different challenges. Cluster resources are aware of services, ingresses, and workloads; the Edge Cloud manages public endpoints, DNS zones, and backend forwarding. A resilient operational model separates these responsibilities but automates their handovers through clearly defined interfaces.\nIntroduction Many Kubernetes environments initially treat DNS automation as a cluster task. This works for internal service names but falls short for public endpoints. Once applications are accessible via a front-end Edge Cloud, at least two separate states emerge: Kubernetes knows the desired application and its service, while DNS represents public accessibility and the Edge depicts the actual traffic path. Mixing both layers directly leads to unclear responsibilities, accidentally published endpoints, and hard-to-trace operational processes. Kubernetes DNS automation should not mean that every cluster resource immediately lands in a public zone.\n",
      "image": "https://ayedo.de/dns-automatisierung-fur-kubernetes-hinter-der-edge-cloud.png",
      "date_published": "2026-09-08T17:15:04Z",
      "date_modified": "2026-09-08T17:15:04Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","cloud-native","development","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/",
      "url": "https://ayedo.de/en/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/",
      "title": "Ingress and Edge Cloud: Clearly Separating Responsibilities",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress and Edge Cloud serve different purposes. The Edge Cloud controls the public entry point, protects applications, and terminates TLS. In contrast, Kubernetes Ingress describes the routing within the cluster. A clear separation prevents duplicate rules, contradictory security configurations, and complex operational states.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany Kubernetes architectures treat Ingress as a complete entry layer for applications. This works technically but mixes two areas of responsibility: public network access and routing within the cluster. Once TLS, WAF, DDoS protection, and backend accessibility are additionally managed on an external edge platform, duplicate or contradictory configurations can quickly arise. A hostname can then be terminated, checked, and forwarded at multiple points. The critical architectural question is not whether Kubernetes Ingress or an Edge Cloud is used. What matters is which layer takes on which responsibility and where the respective configuration is binding.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-ingress-describes-access-to-cluster-services\"\u003e1. Kubernetes Ingress Describes Access to Cluster Services\u003c/h2\u003e\n\u003cp\u003eA Kubernetes Ingress resource is primarily a declarative description for HTTP and HTTPS routing. It maps hostnames and paths to specific services within the cluster. The resource itself does not process traffic. This task is handled by an Ingress Controller, which translates the configuration into a concrete proxy or load balancer configuration.\u003c/p\u003e\n\u003cp\u003eThus, the core responsibility of Ingress lies within the cluster: An incoming request is forwarded after being handed over to the Kubernetes service. This includes rules like \u003ccode\u003eapi.example.de\u003c/code\u003e to an API service or \u003ccode\u003e/checkout\u003c/code\u003e to a specific backend. The division between services, namespaces, or versions can also be modeled there.\u003c/p\u003e\n\u003cp\u003eThis layer is closely tied to the deployment model. Changes to services, pods, and Ingress resources can be managed together via Kubernetes workflows. This is sensible as long as the task is limited to internal accessibility and routing to workloads. However, Ingress should not automatically be understood as a complete security and internet access layer.\u003c/p\u003e\n\u003ch2 id=\"2-the-edge-cloud-takes-over-the-public-entry\"\u003e2. The Edge Cloud Takes Over the Public Entry\u003c/h2\u003e\n\u003cp\u003eThe Edge Cloud is architecturally positioned in front of the cluster. It receives public traffic, distributes it via a distributed multi-PoP infrastructure, and forwards permissible connections to defined backends. At ayedo, this is done through Anycast-based Layer-4 and Layer-7 load balancing. The Edge Cloud is thus not merely a pre-configured load balancer for ayedo Managed Kubernetes but can also be deployed in front of Kubernetes clusters operated by other providers.\u003c/p\u003e\n\u003cp\u003eAt this level, tasks apply that are independent of individual Kubernetes services. These include TLS termination, WAF rules, DDoS protection and scrubbing at the edge, and backend cloaking. With backend cloaking, internal target addresses remain hidden from the public client. Backend health checks and failover additionally determine if a target is reachable and where traffic is redirected in case of disruptions.\u003c/p\u003e\n\u003cp\u003eThis centralization reduces the pressure to replicate security-relevant rules in each cluster separately. At the same time, the cluster remains responsible for the actual application and service configuration.\u003c/p\u003e\n\u003ch2 id=\"3-routing-and-tls-need-clear-ownership\"\u003e3. Routing and TLS Need Clear Ownership\u003c/h2\u003e\n\u003cp\u003eRouting becomes problematic when the same decision is made at multiple points. For example, the Edge Cloud forwards \u003ccode\u003e/api\u003c/code\u003e to a cluster endpoint, while the Ingress further splits the same path. This is not fundamentally wrong but increases the number of rules that must remain synchronized during changes. Different priorities, rewrite rules, or status codes complicate troubleshooting.\u003c/p\u003e\n\u003cp\u003eA reliable structure thus broadly separates external and internal routing. The Edge Cloud decides which public hostname or service reaches which protected backend endpoint. The Kubernetes Ingress then decides which service within the cluster processes the request. This division should be documented and verifiable based on request flow, responsibility, and change process.\u003c/p\u003e\n\u003cp\u003eThe same applies to TLS termination. If TLS is terminated at the edge, the Ingress typically receives an already forwarded connection. Then protocol, original scheme, and possibly client information must be consistently transmitted. If TLS is additionally terminated within the cluster, it is a deliberate end-to-end decision with its own certificate and operational effort, not an accidental double configuration.\u003c/p\u003e\n\u003ch2 id=\"4-security-logic-belongs-at-the-appropriate-boundary\"\u003e4. Security Logic Belongs at the Appropriate Boundary\u003c/h2\u003e\n\u003cp\u003eWAF and DDoS protection are most effective before harmful or excessive traffic reaches the cluster. An edge platform can perform these checks at the public entry and only pass allowed traffic to the Kubernetes environment. This not only protects individual Ingress rules but also the overall accessibility of the upstream application layer.\u003c/p\u003e\n\u003cp\u003eIngress remains security-relevant nonetheless. It limits which services are internally accessible over HTTP and can support the application\u0026rsquo;s routing or authentication requirements. However, it does not replace edge protection functions when attacks or large traffic spikes already consume network and cluster resources.\u003c/p\u003e\n\u003cp\u003eOrganizationally, it is crucial who is allowed to change rules and how changes are tested. Edge rules should not emerge uncontrollably from individual deployment repositories, while Ingress configurations simultaneously alter global public accessibility. A shared model of responsibilities, version control, and monitoring of traffic and usage statistics prevents security and routing logic from diverging between platform and application teams.\u003c/p\u003e\n\u003ch2 id=\"practical-and-architectural-scenario\"\u003ePractical and Architectural Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a Kubernetes cluster with an external provider. The public API should be accessible under \u003ccode\u003eapi.example.de\u003c/code\u003e. The ayedo Edge Cloud handles Anycast DNS, TLS termination, WAF, DDoS protection, and backend cloaking. A publicly accessible cluster endpoint is stored as a backend; health checks detect if it is available.\u003c/p\u003e\n\u003cp\u003eWithin the cluster, a Kubernetes Ingress resource only describes the forwarding from \u003ccode\u003eapi.example.de\u003c/code\u003e to the services \u003ccode\u003eapi-v1\u003c/code\u003e and \u003ccode\u003eapi-v2\u003c/code\u003e. The Edge Cloud does not decide on internal pod or service names, and the Ingress does not know global DDoS or WAF rules. If the cluster endpoint fails, the edge-side failover takes effect. If the team changes the API versioning, the change remains confined to the cluster configuration.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-the-ayedo-edge-cloud-replace-kubernetes-ingress\"\u003eDoes the ayedo Edge Cloud replace Kubernetes Ingress?\u003c/h3\u003e\n\u003cp\u003eNo. The Edge Cloud takes over the public entry and protection functions. Kubernetes Ingress routes within the cluster to services and remains part of the application-related configuration.\u003c/p\u003e\n\u003ch3 id=\"does-tls-always-have-to-be-terminated-at-the-edge\"\u003eDoes TLS always have to be terminated at the edge?\u003c/h3\u003e\n\u003cp\u003eNo. TLS termination at the edge is an architectural decision. Additional encryption to the backend may be required but must be consciously planned in terms of certificates and operational effort.\u003c/p\u003e\n\u003ch3 id=\"can-the-edge-cloud-be-used-in-front-of-any-kubernetes-cluster\"\u003eCan the Edge Cloud be used in front of any Kubernetes cluster?\u003c/h3\u003e\n\u003cp\u003eIt can be used with ayedo Managed Kubernetes as well as with Kubernetes clusters operated by other providers. Defined, reachable backends and a consistent request flow are crucial.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress and Edge Cloud are not competing implementations of the same layer. Ingress organizes the forwarding to services within the cluster; the Edge Cloud controls public access, protection, TLS termination, and backend accessibility. This separation reduces configuration conflicts and makes responsibilities verifiable. For companies with multiple clusters or providers, a provider-independent edge platform also creates a consistent external architecture, while teams can independently develop their internal \u003ca href=\"/en/kubernetes/\"\u003eKubernetes configuration\u003c/a\u003e\n.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes Ingress and Edge Cloud serve different purposes. The Edge Cloud controls the public entry point, protects applications, and terminates TLS. In contrast, Kubernetes Ingress describes the routing within the cluster. A clear separation prevents duplicate rules, contradictory security configurations, and complex operational states.\nIntroduction Many Kubernetes architectures treat Ingress as a complete entry layer for applications. This works technically but mixes two areas of responsibility: public network access and routing within the cluster. Once TLS, WAF, DDoS protection, and backend accessibility are additionally managed on an external edge platform, duplicate or contradictory configurations can quickly arise. A hostname can then be terminated, checked, and forwarded at multiple points. The critical architectural question is not whether Kubernetes Ingress or an Edge Cloud is used. What matters is which layer takes on which responsibility and where the respective configuration is binding.\n",
      "image": "https://ayedo.de/ingress-und-edge-cloud-zustandigkeiten-sauber-trennen.png",
      "date_published": "2026-09-08T17:15:04Z",
      "date_modified": "2026-09-08T17:15:04Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","development","cloud"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/",
      "url": "https://ayedo.de/en/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/",
      "title": "Operating Load Balancers for Kubernetes Independently of Providers",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/loadbalancer-fur-kubernetes-providerunabhangig-betreiben/loadbalancer-fur-kubernetes-providerunabhangig-betreiben.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Service of type \u003ccode\u003eLoadBalancer\u003c/code\u003e often ties public access to the respective cloud or infrastructure provider. An independent edge layer separates this responsibility from the cluster: routing, protection, TLS, and accessibility are centrally organized, while Kubernetes can be operated at ayedo or another provider. This reduces provider dependencies and simplifies multi-cloud architectures.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n load balancer is not just a technical resource but an architectural decision: Is public access to a service controlled by the compute provider or operated as an independent network layer? In many clusters, a \u003ccode\u003eService\u003c/code\u003e of type \u003ccode\u003eLoadBalancer\u003c/code\u003e automatically creates provider-bound infrastructure. This is pragmatic for single environments but complicates migrations, multi-cloud operations, and a unified security architecture. To operate Kubernetes independently of providers, responsibilities between the cluster and public traffic entry must be clearly separated.\u003c/p\u003e\n\u003ch2 id=\"1-provider-bound-load-balancers-simple-but-tightly-coupled\"\u003e1. Provider-Bound Load Balancers: Simple but Tightly Coupled\u003c/h2\u003e\n\u003cp\u003eThe classic approach uses the load balancer integration of the respective Kubernetes or cloud provider. A service resource triggers the provision of an external endpoint. The provider typically handles addressing, forwarding, and possibly health checks. The operational advantage lies in the short integration path: cluster, network, and load balancer come from the same platform.\u003c/p\u003e\n\u003cp\u003eHowever, this coupling has consequences. Public IP addresses, DNS connections, firewall rules, and operational processes are aligned with a provider\u0026rsquo;s specifications. When switching clusters or setting up a second cloud, these dependencies must be modeled again. Security functions are often spread across multiple providers, increasing the number of different configurations and complicating consistent traffic and error evaluation.\u003c/p\u003e\n\u003cp\u003eFor a single, stable environment, a provider-bound \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n load balancer can be sensible. However, it is not a neutral component for provider-independent Kubernetes. The central question is not only how a service becomes accessible but where the responsibility for public entry should permanently reside.\u003c/p\u003e\n\u003ch2 id=\"2-an-independent-edge-layer-separates-responsibilities\"\u003e2. An Independent Edge Layer Separates Responsibilities\u003c/h2\u003e\n\u003cp\u003eIn an independent edge architecture, the cluster\u0026rsquo;s responsibility does not end at the external load balancer. The edge cloud takes over public traffic entry and forwards requests to backends in a controlled manner. The cluster remains responsible for workloads, services, and internal distribution; the edge organizes accessibility, routing, and protection from the backend.\u003c/p\u003e\n\u003cp\u003eThis separation changes architectural boundaries. A \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster can be operated at ayedo, in a public cloud, or in its own infrastructure without the public endpoint being tied to the load balancer implementation of the respective compute provider. The edge can distribute Layer-4 and Layer-7 traffic via Anycast. Backend cloaking prevents actual backend addresses from becoming a public part of the architecture.\u003c/p\u003e\n\u003cp\u003eWith its own network infrastructure and autonomous system, ayedo forms an independent network layer in front of the clusters. This is more than an outsourced load balancer: DNS, routing, termination, and protection functions are located at a central public entry. The compute platform can thus be independently developed or replaced.\u003c/p\u003e\n\u003ch2 id=\"3-centralization-creates-unified-protection-and-routing-rules\"\u003e3. Centralization Creates Unified Protection and Routing Rules\u003c/h2\u003e\n\u003cp\u003eProvider independence is only robust if not only the load balancer is moved, while DNS, TLS, and security continue to be operated separately per provider. A central edge layer bundles these functions at the point where traffic can first be controlled.\u003c/p\u003e\n\u003cp\u003eFor HTTP and HTTPS services, TLS termination and web application firewall can occur at the edge. DDoS protection and scrubbing keep harmful traffic away from the backends as much as possible. Anycast DNS and multi-provider DNS support public name resolution that does not rely solely on a single compute platform. Health checks and failover complement the architecture with a controlled response to unreachable backends.\u003c/p\u003e\n\u003cp\u003eThis does not automatically reduce all complexity. Routing decisions must be transparently documented, certificates and policies centrally managed, and backend targets cleanly segmented. However, unified operational and security processes emerge across multiple clusters. Traffic and usage statistics provide a common view of the public entry, instead of retrospectively merging data from different provider load balancers.\u003c/p\u003e\n\u003ch2 id=\"4-anycast-and-active-active-change-the-operational-approach\"\u003e4. Anycast and Active-Active Change the Operational Approach\u003c/h2\u003e\n\u003cp\u003eA provider-bound load balancer is usually tied to the availability and network architecture of a single platform. A distributed edge layer, on the other hand, can organize public access across multiple points of presence and an active-active architecture. Anycast ensures that requests reach the appropriate entry through the edge infrastructure without the cluster itself having to map this global distribution.\u003c/p\u003e\n\u003cp\u003eFor operations, it is crucial that this distribution is not confused with the scaling of \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Kubernetes scales pods and services within the compute layer. The edge distributes and protects external traffic before this layer. Both systems require their own health checks and clear fault domains. If a backend fails, the edge can switch to another target or cluster; if a pod fails, Kubernetes responds within the cluster.\u003c/p\u003e\n\u003cp\u003eThis decoupling is relevant for multi-cloud. A company can, for example, operate a primary cluster at one provider and a second cluster at another without establishing a separate public entry for each environment. The specific failover logic remains an architectural decision and must fit data retention, session behavior, and application.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters: the primary cluster runs in a public cloud, the second at an independent infrastructure provider. With provider-bound load balancers, two public endpoints, separate DNS and security configurations, and different operational processes arise.\u003c/p\u003e\n\u003cp\u003eAlternatively, the public endpoint lies in an edge layer. Anycast load balancing receives the traffic, TLS termination, and WAF rules are applied centrally. The edge uses health checks for both backend targets and can switch in case of a disruption. The \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters remain technically operable independently. The price for this is additional architectural work in routing, state management, and failover tests. The gain is a unified public access independent of the compute provider.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-a-provider-bound-kubernetes-load-balancer-fundamentally-wrong\"\u003eIs a provider-bound \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n load balancer fundamentally wrong?\u003c/h3\u003e\n\u003cp\u003eNo. For a single cluster, it can be efficient and sufficient. The coupling becomes problematic when provider changes, multi-cloud, or central security and routing rules are requirements.\u003c/p\u003e\n\u003ch3 id=\"does-the-edge-cloud-need-to-operate-kubernetes-with-the-same-provider\"\u003eDoes the edge cloud need to operate \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n with the same provider?\u003c/h3\u003e\n\u003cp\u003eNo. An edge layer can be used in front of ayedo Managed Kubernetes as well as in front of Kubernetes clusters operated independently or by other providers.\u003c/p\u003e\n\u003ch3 id=\"does-the-edge-replace-the-kubernetes-service\"\u003eDoes the edge replace the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n service?\u003c/h3\u003e\n\u003cp\u003eNo. The \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n service remains relevant for internal or cluster-related accessibility. The edge takes over the public entry, routing, protection, and forwarding to the backends.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eProvider-independent \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n requires a clear separation between compute and public traffic. Provider-bound load balancers reduce startup effort but often anchor DNS, addressing, and protection in a single platform. An independent edge layer creates a stable public entry across cluster and provider boundaries. The ayedo Edge Cloud positions itself here as an Anycast-based, active-active traffic and protection layer that can connect Kubernetes at ayedo or other providers.\u003c/p\u003e\n",
      "summary": "\nTL;DR A Kubernetes Service of type LoadBalancer often ties public access to the respective cloud or infrastructure provider. An independent edge layer separates this responsibility from the cluster: routing, protection, TLS, and accessibility are centrally organized, while Kubernetes can be operated at ayedo or another provider. This reduces provider dependencies and simplifies multi-cloud architectures.\nIntroduction A Kubernetes load balancer is not just a technical resource but an architectural decision: Is public access to a service controlled by the compute provider or operated as an independent network layer? In many clusters, a Service of type LoadBalancer automatically creates provider-bound infrastructure. This is pragmatic for single environments but complicates migrations, multi-cloud operations, and a unified security architecture. To operate Kubernetes independently of providers, responsibilities between the cluster and public traffic entry must be clearly separated.\n",
      "image": "https://ayedo.de/loadbalancer-fur-kubernetes-providerunabhangig-betreiben.png",
      "date_published": "2026-09-08T17:15:04Z",
      "date_modified": "2026-09-08T17:15:04Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud","cloud-native","operations"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/",
      "url": "https://ayedo.de/en/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/",
      "title": "Securely Accessing the Kubernetes API Server Over the Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-api-server-sicher-uber-die-edge-erreichbar/kubernetes-api-server-sicher-uber-die-edge-erreichbar.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA publicly accessible \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n doesn\u0026rsquo;t need to allow direct internet access to its backend address. A preceding edge layer can handle routing, TLS, DDoS protection, and backend cloaking. The key remains the separation between public accessibility, cryptographic authentication, and actual authorization within the cluster.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA common architectural mistake is running a publicly needed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n directly on a public IP address of the cluster. This not only exposes the port and endpoint but often also network paths and operational structures relevant to attackers. The alternative is not a completely isolated API server, but a controlled public entry: The client reaches a defined endpoint while the actual backend remains hidden. However, this architecture does not automatically shift responsibility. TLS, \u003ca href=\"/en/kubernetes/\"\u003eKubernetes authentication\u003c/a\u003e\n, authorization, rate limiting, and network rules must still work together appropriately.\u003c/p\u003e\n\u003ch2 id=\"1-public-accessibility-is-not-the-same-as-open-accessibility\"\u003e1. Public Accessibility Is Not the Same as Open Accessibility\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n requires public accessibility if external administrators, CI/CD systems, GitOps components, or platform services outside the cluster need to access it. However, this does not mean the API server must be directly attached to a publicly routed backend address.\u003c/p\u003e\n\u003cp\u003eA more sensible approach is a dedicated public API endpoint that only accepts the intended traffic and forwards it to the API server backend. The public DNS name does not need to point to the cluster\u0026rsquo;s infrastructure address. An edge layer can establish accessibility via Anycast and load balancing, while the backend itself remains non-publicly addressable.\u003c/p\u003e\n\u003cp\u003eFor operations, this separation is relevant: Address changes, failover, and the replacement of individual API servers do not necessarily need to change the external endpoint definition. At the same time, backend cloaking reduces the amount of information that can be inferred from the internet about the internal topology. However, it does not replace authentication or authorization.\u003c/p\u003e\n\u003ch2 id=\"2-tls-and-access-control-must-be-considered-separately\"\u003e2. TLS and Access Control Must Be Considered Separately\u003c/h2\u003e\n\u003cp\u003eTLS protects the connection between the client and the public endpoint. With TLS termination at the edge, the outer connection ends there; further securing to the backend must be treated as a separate architectural decision. Depending on the security model, the connection to the API server can be re-encrypted or secured in another suitable form. It is crucial that a secure outer TLS channel does not automatically protect the entire path.\u003c/p\u003e\n\u003cp\u003eEqually important is the distinction between transport and access protection. A valid certificate confirms the identity of an endpoint but does not grant \u003ca href=\"/en/kubernetes/\"\u003eKubernetes authorization\u003c/a\u003e\n. The API server must still authenticate clients through its intended mechanisms and authorize access via RBAC and other cluster rules.\u003c/p\u003e\n\u003cp\u003eThe edge can protect the public entry and discard unwanted traffic early. However, it should not be seen as a replacement for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes identities\u003c/a\u003e\n, short-lived credentials, or restrictive roles. Especially for administrative endpoints, the combination of network limitation and strong application authentication is required.\u003c/p\u003e\n\u003ch2 id=\"3-edge-routing-for-the-api-server-is-not-application-traffic\"\u003e3. Edge Routing for the API Server Is Not Application Traffic\u003c/h2\u003e\n\u003cp\u003eThe \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n is not an ordinary web service. In addition to HTTPS requests for resources, it processes streaming connections, watch calls, and interactions that differ in operational behavior from normal application traffic. Therefore, timeout, keepalive, and protocol settings must match the API server.\u003c/p\u003e\n\u003cp\u003eFor the public API endpoint, Layer-4 load balancing is often the clearer foundation because the edge service does not need to interpret Kubernetes traffic like a classic web application. Layer-7 functions such as a web application firewall can be useful for HTTP/HTTPS services but should not be applied indiscriminately to the API server. A rule that works for REST applications can unexpectedly affect long connections or specific API requests.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud supports Anycast-based Layer-4 and Layer-7 load balancing, TLS termination, DDoS protection, and health checks. Therefore, a specific routing and inspection strategy is required for a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n. Application traffic and control plane traffic should receive separate endpoints and rules.\u003c/p\u003e\n\u003ch2 id=\"4-ddos-protection-reduces-operational-risks-but-does-not-replace-isolation\"\u003e4. DDoS Protection Reduces Operational Risks but Does Not Replace Isolation\u003c/h2\u003e\n\u003cp\u003eA public API endpoint is an accessible attack point, regardless of its actual function. Even if \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n correctly rejects authentication errors, the requests must first be processed. Large amounts of unwanted traffic can therefore burden network paths, load balancers, or API servers before an authorization check takes place.\u003c/p\u003e\n\u003cp\u003eDDoS protection and scrubbing at the edge move the defense closer to the public entry. This is particularly relevant if the API server is not to be operated with the same protection mechanisms as a public web frontend. Health checks and failover additionally help include only functional backends in the distribution. However, they do not resolve misconfigurations in the control plane.\u003c/p\u003e\n\u003cp\u003eFor architecture, this means: The API server needs its own security and availability context. Backend cloaking, dedicated DNS entries, restrictive firewall rules, and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes-side authorization\u003c/a\u003e\n together form a control chain. The Edge Cloud can support this chain as a public entry—regardless of whether the cluster is operated at ayedo, another provider, or on its own infrastructure.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n with an external provider. External platform teams need to reach the API server, while the control plane should not be exposed with a directly advertised backend address on the internet. For this, a dedicated DNS name is bound to an edge endpoint. The edge handles Anycast routing, DDoS protection, and the acceptance of the TLS connection. The actual API server remains hidden behind the edge endpoint; health checks control the forwarding to available backends.\u003c/p\u003e\n\u003cp\u003eThe comparison is clear: With direct publication, backend addresses, protection mechanisms, and failover must be operated on the cluster itself. With a preceding edge entry, public accessibility is centralized, while authentication and authorization remain within the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes context\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-a-kubernetes-api-server-need-to-be-publicly-accessible\"\u003eDoes a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n need to be publicly accessible?\u003c/h3\u003e\n\u003cp\u003eNo. It only needs to be accessible to the systems that require it. This can be achieved through private networks, VPNs, or a controlled public endpoint.\u003c/p\u003e\n\u003ch3 id=\"is-backend-cloaking-a-replacement-for-rbac\"\u003eIs backend cloaking a replacement for RBAC?\u003c/h3\u003e\n\u003cp\u003eNo. Backend cloaking hides the internal target address. RBAC determines which authenticated identities are allowed to read or modify \u003ca href=\"/en/kubernetes/\"\u003eKubernetes resources\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch3 id=\"should-the-waf-inspect-every-api-server-traffic\"\u003eShould the WAF inspect every API server traffic?\u003c/h3\u003e\n\u003cp\u003eNot indiscriminately. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API traffic\u003c/a\u003e\n requires appropriate protocol, timeout, and rule configurations. For many scenarios, a specifically configured Layer-4 routing is more suitable.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/en/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n can be made publicly accessible without unnecessarily exposing its backend structure. For this, edge routing, TLS, DDoS protection, and backend cloaking must be clearly separated from \u003ca href=\"/en/kubernetes/\"\u003eKubernetes authentication\u003c/a\u003e\n and authorization. In this model, the ayedo Edge Cloud acts as the controlled public entrance—not a replacement for cluster security controls. The critical factor is the architectural boundary between edge, control plane, and application traffic.\u003c/p\u003e\n",
      "summary": "\nTL;DR A publicly accessible Kubernetes API Server doesn\u0026rsquo;t need to allow direct internet access to its backend address. A preceding edge layer can handle routing, TLS, DDoS protection, and backend cloaking. The key remains the separation between public accessibility, cryptographic authentication, and actual authorization within the cluster.\nIntroduction A common architectural mistake is running a publicly needed Kubernetes API Server directly on a public IP address of the cluster. This not only exposes the port and endpoint but often also network paths and operational structures relevant to attackers. The alternative is not a completely isolated API server, but a controlled public entry: The client reaches a defined endpoint while the actual backend remains hidden. However, this architecture does not automatically shift responsibility. TLS, Kubernetes authentication , authorization, rate limiting, and network rules must still work together appropriately.\n",
      "image": "https://ayedo.de/kubernetes-api-server-sicher-uber-die-edge-erreichbar.png",
      "date_published": "2026-09-08T17:15:04Z",
      "date_modified": "2026-09-08T17:15:04Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","software-delivery","cloud-native","development","operations"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/",
      "url": "https://ayedo.de/en/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/",
      "title": "Making Security Decisions at the Edge Transparent",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/security-entscheidungen-an-der-edge-nachvollziehbar-machen/security-entscheidungen-an-der-edge-nachvollziehbar-machen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEdge Security Monitoring reveals how protective measures impact public traffic. Traffic and usage statistics help operationally assess WAF rules, DDoS protection, and exposed endpoints. However, they do not fully explain individual attacks nor replace logs, traces, and application-centric security telemetry.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eSecurity decisions at the edge are often made once and only questioned when disruptions occur. This is problematic: An activated WAF rule can block legitimate requests, a DDoS protection can alter patterns, and a publicly accessible endpoint can receive significantly more traffic than expected. Without statistical visibility, it remains unclear whether a measure is effective, too restrictive, or operationally relevant. Edge Security Monitoring provides a reliable observation layer here. It connects traffic and usage statistics with the decisions made at the public entry of an application. This view is valuable but not complete: Aggregated data assess patterns and impacts, not every single request or the entire technical cause of an incident.\u003c/p\u003e\n\u003ch2 id=\"1-questions-traffic-statistics-answer\"\u003e1. Questions Traffic Statistics Answer\u003c/h2\u003e\n\u003cp\u003eTraffic statistics initially create a common quantitative basis for security and operational decisions. They show, for example, how much traffic reaches a public service, how the volume changes over time, and whether individual endpoints are used conspicuously heavily. This allows checking whether an expected usage pattern matches the actual exposure.\u003c/p\u003e\n\u003cp\u003eFor security analysis, changes are also crucial: Does the request share of an endpoint suddenly increase? Is there an unusual load spike? Does the ratio between allowed and blocked traffic change after a rule modification? Such questions can be answered faster at the edge level than solely from backend logs because the edge observes the traffic before forwarding.\u003c/p\u003e\n\u003cp\u003eThe statistics thus support prioritization and capacity decisions. A publicly accessible endpoint with consistently high usage deserves different scrutiny than a rarely used administrative access. However, they do not automatically assess the technical legitimacy of a request. Application logs and identity information remain necessary for that.\u003c/p\u003e\n\u003ch2 id=\"2-waf-monitoring-as-a-verifiable-operational-process\"\u003e2. WAF Monitoring as a Verifiable Operational Process\u003c/h2\u003e\n\u003cp\u003eA Web Application Firewall is not effective solely through its activation. What matters is whether rules recognize relevant attacks, allow legitimate use, and remain manageable in operation. WAF monitoring should therefore not only count blocked requests but also connect rule changes with traffic and usage developments.\u003c/p\u003e\n\u003cp\u003eWhen a rule is activated or tightened, statistics can provide clues about its operational impact: Does the number of rejected requests change? Are certain public services more affected than others? Does the effect occur only during a single event or persistently? This information helps distinguish misconfigurations from actual attack patterns.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud provides traffic and usage statistics in the context of its edge functions. This allows operators to assess the effect of the WAF where public HTTP and HTTPS traffic is processed. For a reliable decision, these data must be correlated with WAF events, release times, and known usage patterns. An aggregated statistic does not replace a detailed examination of individual requests.\u003c/p\u003e\n\u003ch2 id=\"3-evaluating-ddos-protection-and-public-endpoints\"\u003e3. Evaluating DDoS Protection and Public Endpoints\u003c/h2\u003e\n\u003cp\u003eIn DDoS protection, the central question is not only whether traffic was blocked. It is also relevant which traffic reaches the backends, whether load spikes concentrate on specific services, and whether legitimate use remains available during an event. Traffic statistics make this development visible across the edge and support subsequent operational evaluation.\u003c/p\u003e\n\u003cp\u003eFor public endpoints, it can also be checked whether the technical exposure matches the intended architecture. An endpoint intended only for a limited user group but showing consistently high or highly fluctuating access patterns should be examined regarding routing, authentication, and accessibility. The edge can protect and distribute public access but cannot derive the technical legitimacy of a call solely from traffic volumes.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud combines Anycast-based Layer-4 and Layer-7 load balancing with DDoS protection and scrubbing at the edge. For operational analysis, it is important not to consider these functions separately from the traffic view: Protective effect, forwarding, and backend load form a coherent chain of consideration.\u003c/p\u003e\n\u003ch2 id=\"4-where-aggregated-visibility-ends\"\u003e4. Where Aggregated Visibility Ends\u003c/h2\u003e\n\u003cp\u003eStatistics answer questions about volume, distribution, temporal changes, and impacts on the public entry. However, they do not reliably answer which user initiated a request, what data was processed, or whether a technically valid operation was misused. Similarly, an increased request volume alone does not reliably indicate an attack.\u003c/p\u003e\n\u003cp\u003eFor forensic analyses, teams need additional layers: detailed WAF and access logs, correlation with identities, application logs, traces, and information from authentication and backend systems. Only this connection can sufficiently explain the cause of an incident and its technical damage.\u003c/p\u003e\n\u003cp\u003eOrganizationally, the distinction is also relevant. Edge teams assess protective effect and traffic patterns, while application and security teams examine the significance of individual requests. A common time model, consistent service names, and traceable changes to rules facilitate correlation. Edge Security Monitoring is thus a control and evaluation layer but not a substitute for complete application observability or incident response.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a public API and a web-based self-service. After tightening a WAF rule, blocked requests increase significantly. The traffic statistics show that the increase almost exclusively affects the API and a new client release was rolled out simultaneously. The edge view thus provides a reliable indication of the affected zone but not yet proof of the cause. The team correlates the values with WAF events, API logs, and release information. This allows them to adjust the rule specifically instead of withdrawing the entire protection. In a parallel DDoS event, the same statistics would additionally show whether the backends were relieved and which endpoints continued to process legitimate traffic.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"are-traffic-statistics-a-security-proof\"\u003eAre traffic statistics a security proof?\u003c/h3\u003e\n\u003cp\u003eNo. They demonstrate observable patterns and operational impacts. For a security proof, rule configurations, event logs, application data, and organizational processes must also be considered.\u003c/p\u003e\n\u003ch3 id=\"what-should-be-correlated-in-waf-monitoring\"\u003eWhat should be correlated in WAF monitoring?\u003c/h3\u003e\n\u003cp\u003eWAF events should be correlated with traffic volume, affected services, rule changes, deployments, and backend errors. Only then can protective effect and false blockings be meaningfully distinguished.\u003c/p\u003e\n\u003ch3 id=\"does-edge-monitoring-replace-a-siem\"\u003eDoes edge monitoring replace a SIEM?\u003c/h3\u003e\n\u003cp\u003eNo. Edge statistics can be an important data source. A SIEM or comparable analysis processes additionally handle correlation, retention, alerting, and the classification of further infrastructure and application data.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eTransparent security decisions require an observation layer that connects protective measures with their real operational effect. Traffic and usage statistics help examine WAF rules, DDoS protection, and public endpoints for patterns and impacts. However, they must be consciously separated from forensic application analysis. The ayedo Edge Cloud integrates this view into a distributed edge platform with protection, routing, and load balancing. The decisive factor remains the combination of edge data and application-centric telemetry.\u003c/p\u003e\n",
      "summary": "\nTL;DR Edge Security Monitoring reveals how protective measures impact public traffic. Traffic and usage statistics help operationally assess WAF rules, DDoS protection, and exposed endpoints. However, they do not fully explain individual attacks nor replace logs, traces, and application-centric security telemetry.\nIntroduction Security decisions at the edge are often made once and only questioned when disruptions occur. This is problematic: An activated WAF rule can block legitimate requests, a DDoS protection can alter patterns, and a publicly accessible endpoint can receive significantly more traffic than expected. Without statistical visibility, it remains unclear whether a measure is effective, too restrictive, or operationally relevant. Edge Security Monitoring provides a reliable observation layer here. It connects traffic and usage statistics with the decisions made at the public entry of an application. This view is valuable but not complete: Aggregated data assess patterns and impacts, not every single request or the entire technical cause of an incident.\n",
      "image": "https://ayedo.de/security-entscheidungen-an-der-edge-nachvollziehbar-machen.png",
      "date_published": "2026-09-08T17:10:09Z",
      "date_modified": "2026-09-08T17:10:09Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","operations","cloud-native","kubernetes","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/",
      "url": "https://ayedo.de/en/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/",
      "title": "Distributing Security Functions Between Edge and Application",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/security-funktionen-zwischen-edge-und-anwendung-verteilen/security-funktionen-zwischen-edge-und-anwendung-verteilen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSecurity functions should not be confined to a single location. The edge is suitable for protective measures with high visibility, significant scaling needs, and standardizable rules. The application remains responsible for identity, authorization, and business access controls. Key factors include context requirements, misconfiguration risks, and how early an attack can be detected and mitigated.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA common architectural mistake is to shift security responsibility entirely to the edge or entirely to the application. Both create blind spots: An edge can intercept volumetric attacks and many HTTP patterns early but usually lacks understanding of the business significance of a transaction. The application can assess users, roles, and business objects, but this decision is made only after traffic has already burdened infrastructure and runtime. A robust model distributes security functions according to their visibility, context requirements, and scaling needs. Misconfigurations must also be considered: A misplaced or overly broad rule can either lose protective effect or block legitimate requests.\u003c/p\u003e\n\u003ch2 id=\"1-visibility-determines-the-appropriate-security-layer\"\u003e1. Visibility Determines the Appropriate Security Layer\u003c/h2\u003e\n\u003cp\u003eThe edge sees public traffic before it reaches the backends. It can evaluate source networks, protocols, ports, TLS connections, HTTP requests, headers, and typical attack patterns. This visibility suffices for DDoS defense, rate-limiting concepts, broad access patterns, and many WAF checks. The advantage lies in early decision-making: Malicious traffic consumes fewer resources in load balancing, clusters, and applications.\u003c/p\u003e\n\u003cp\u003eThe application, on the other hand, possesses additional information. It knows user accounts, roles, tenants, shopping carts, approval statuses, or the permissible state transitions of a transaction. This information is indispensable for business access controls. An edge rule can recognize that a request calls \u003ccode\u003e/api/orders/123\u003c/code\u003e. However, without application context, it does not know if the authenticated user is allowed to view this order. Thus, visibility is the first decision criterion: What is recognizable at the network or HTTP edge can be protected there; what requires business logic must be decided in the application.\u003c/p\u003e\n\u003ch2 id=\"2-scaling-favors-early-defense\"\u003e2. Scaling Favors Early Defense\u003c/h2\u003e\n\u003cp\u003eDDoS defense and standardizable WAF checks benefit from upstream, distributed enforcement. The earlier invalid or abusive requests are discarded, the less work arises in firewalls, ingress components, API processes, and databases. This is not only a security issue but also a matter of availability and operational costs. Protection directly in the application scales with its resources and can become a bottleneck under high attack pressure.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud takes on DDoS protection and scrubbing at the edge as the public entry point, along with WAF functions for HTTP and HTTPS services. TLS termination can additionally help centrally inspect encrypted requests before forwarding. Backend cloaking reduces the direct visibility of the actual backends. These functions do not replace application security. However, they shift the first protection decision to a location where traffic can be centrally, distributedly, and pre-compute infrastructure evaluated.\u003c/p\u003e\n\u003ch2 id=\"3-identity-and-authorization-need-application-context\"\u003e3. Identity and Authorization Need Application Context\u003c/h2\u003e\n\u003cp\u003eAuthentication and authorization are often mixed. Authentication answers who a caller is. Authorization decides what this caller is allowed to do under certain conditions. Depending on the architecture, a central edge component can take over the verification of tokens or client certificates. Whether this function is sensible depends on the existing identity sources, protocols, and trust boundaries. It should not automatically be understood as a replacement for every check in the application.\u003c/p\u003e\n\u003cp\u003eThe application must continue to ensure that identity, tenant, resource, and action match. Especially with APIs, a broad rule like \u0026ldquo;logged-in users may call \u003ccode\u003e/orders\u003c/code\u003e\u0026rdquo; is not sufficient. It may be necessary for a user to only read orders of their tenant or to change a transaction only in a specific status. Such rules belong in the application or in a closely coupled policy layer. An edge check can reduce load and reject obviously invalid accesses but cannot reliably anticipate the business decision.\u003c/p\u003e\n\u003ch2 id=\"4-misconfiguration-as-its-own-decision-criterion\"\u003e4. Misconfiguration as Its Own Decision Criterion\u003c/h2\u003e\n\u003cp\u003eEach security layer creates operational risks. An overly restrictive WAF rule can block legitimate requests, while an overly permissive rule allows attacks to pass. In the application, inconsistent checks can arise: One endpoint validates tenant affiliation, another forgets it. Distribution should therefore not only occur based on technical feasibility but also on the likelihood and impact of misconfigurations.\u003c/p\u003e\n\u003cp\u003eEdge rules are suitable for centrally visible, traceable protection requirements: allowed protocols, known attack patterns, broad request limits, or shielding of non-public backends. Business policies should be close to the domain models and operated with tests, code reviews, and traceable change processes. Observability is also important: Blockages at the edge and rejections in the application must be distinguishable. Traffic and usage statistics from the edge can make the effect of upstream rules visible; application logs explain why a business decision was rejected.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a public API on a \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n cluster. The edge handles Anycast-based Layer-7 load balancing, TLS termination, WAF checks, and DDoS defense. Non-public backend addresses are hidden through backend cloaking. The application then checks tokens, tenant affiliation, and authorization for individual resources.\u003c/p\u003e\n\u003cp\u003eWhen a change introduces a new parameter that the WAF initially blocks as suspicious, edge statistics show increased rejections while the application sees no corresponding requests. The rule can be specifically adjusted without altering the business authorization checks. Conversely, a faulty tenant check remains an application problem and is not solved by a generic edge rule. This model clearly separates infrastructure and domain responsibility.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"should-every-waf-rule-also-be-implemented-in-the-application\"\u003eShould every WAF rule also be implemented in the application?\u003c/h3\u003e\n\u003cp\u003eNo. WAF rules and application validation have different goals. Security-critical inputs must be validated in the application independently because only it knows their business context.\u003c/p\u003e\n\u003ch3 id=\"can-the-edge-fully-take-over-authorization\"\u003eCan the edge fully take over authorization?\u003c/h3\u003e\n\u003cp\u003eOnly for clearly defined, context-free rules. Resource and transaction-related permissions belong in the application, where identity, tenant, and business status are combined.\u003c/p\u003e\n\u003ch3 id=\"why-is-ddos-protection-in-the-application-not-sufficient\"\u003eWhy is DDoS protection in the application not sufficient?\u003c/h3\u003e\n\u003cp\u003eThe application only becomes active after traffic has reached the network, routing, and runtime. Upstream defense reduces resource consumption and protects even when the application itself is already overloaded.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eSecurity functions should be distributed according to their decision basis. The edge protects what is early visible, standardizable, and scaling-relevant. The application decides where identity, resources, and business logic interact. For companies, this is not an either-or but a coordinated security layer model. The ayedo Edge Cloud is the public protection and distribution point in this model; authorization and business access control remain the responsibility of the respective application.\u003c/p\u003e\n",
      "summary": "\nTL;DR Security functions should not be confined to a single location. The edge is suitable for protective measures with high visibility, significant scaling needs, and standardizable rules. The application remains responsible for identity, authorization, and business access controls. Key factors include context requirements, misconfiguration risks, and how early an attack can be detected and mitigated.\nIntroduction A common architectural mistake is to shift security responsibility entirely to the edge or entirely to the application. Both create blind spots: An edge can intercept volumetric attacks and many HTTP patterns early but usually lacks understanding of the business significance of a transaction. The application can assess users, roles, and business objects, but this decision is made only after traffic has already burdened infrastructure and runtime. A robust model distributes security functions according to their visibility, context requirements, and scaling needs. Misconfigurations must also be considered: A misplaced or overly broad rule can either lose protective effect or block legitimate requests.\n",
      "image": "https://ayedo.de/security-funktionen-zwischen-edge-und-anwendung-verteilen.png",
      "date_published": "2026-09-08T17:10:08Z",
      "date_modified": "2026-09-08T17:10:08Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","cloud-native","operations","kubernetes","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/",
      "url": "https://ayedo.de/en/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/",
      "title": "Integrating DDoS Protection with Application Logic at the Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDDoS protection and application security address different levels of attacks. The edge can assess volume, protocols, connection rates, and request patterns to discard malicious traffic early. However, whether a valid request is being misused can often only be determined in the application context. Effective protection combines both levels with clear responsibilities.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA successful HTTP request is not automatically a legitimate business transaction. An attacker can access valid URLs, establish correct TLS connections, and operate within technical limits—such as deliberately burdening login, search, or shopping cart functions. A traditional DDoS protection might not detect a volumetric attack in this scenario. Conversely, an application cannot economically assess incoming traffic if large volumes of malicious packets and connections already reach the infrastructure. Therefore, the critical architectural question is not whether the edge or the application provides protection, but rather which signals each layer can reliably evaluate and how both protection mechanisms interact.\u003c/p\u003e\n\u003ch2 id=\"1-the-edge-evaluates-technical-attack-signals\"\u003e1. The Edge Evaluates Technical Attack Signals\u003c/h2\u003e\n\u003cp\u003eDDoS protection and scrubbing operate close to the network and transport layers. They analyze packet and connection volumes, protocol behavior, sources, target systems, and unusual request or connection rates. At Layer 4, TCP or UDP patterns are central; at Layer 7, HTTP requests, headers, and paths can be included in the evaluation. The advantage lies in the position in front of the backend: harmful traffic is discarded before it burdens application servers, \u003ca href=\"/en/kubernetes/\"\u003eKubernetes Ingress\u003c/a\u003e\n, or databases.\u003c/p\u003e\n\u003cp\u003eFor this protection, the technical identity of the request is crucial, not its business significance. An unusually high number of connections, invalid protocol sequences, or a significantly altered request pattern are recognizable signals. A single, formally correct login request, on the other hand, may be technically inconspicuous. ayedo\u0026rsquo;s Edge Cloud combines Anycast-based Layer 4 and Layer 7 load balancing with DDoS protection, scrubbing, and a distributed active-active architecture. This forms a protection and routing layer in front of the backends, not just a downstream distributor.\u003c/p\u003e\n\u003ch2 id=\"2-business-misuse-begins-behind-the-valid-request\"\u003e2. Business Misuse Begins Behind the Valid Request\u003c/h2\u003e\n\u003cp\u003eApplication security must assess whether an operation is permissible within the business process. This includes too many failed logins per user account, unusual password reset requests, repeated queries of expensive search operations, or the misuse of coupons and order processes. Such patterns cannot be reliably derived solely from IP address, transport protocol, or global request rate.\u003c/p\u003e\n\u003cp\u003eHere, the relevant signals lie in identity, session, tenant, permissions, resource consumption, and process state. A rate limit of 100 requests per minute may be appropriate for a public product list but too generous for a login endpoint. Conversely, a global limit may affect legitimate users behind NAT or corporate proxies. Misuse protection, therefore, belongs in the application logic or a responsible service. The edge can support these decisions, but it should not simulate a business authority it does not possess. Its task is to reduce technical load and recognizable attack patterns early.\u003c/p\u003e\n\u003ch2 id=\"3-coupling-requires-signals-instead-of-mixed-responsibilities\"\u003e3. Coupling Requires Signals Instead of Mixed Responsibilities\u003c/h2\u003e\n\u003cp\u003eThe connection of both layers arises through coordinated rules and actionable signals. The edge can, for example, protect requests to sensitive paths, block obvious anomalies, and distribute the remaining traffic to the correct backend. The application can evaluate business events and derive stricter controls from them. This includes application-related rate limits, temporary blocks, or additional authentication requirements.\u003c/p\u003e\n\u003cp\u003eA clear direction of responsibility is important: the edge decides on technical accessibility and forwarding; the application decides on business permissibility. Mixing both layers results in either overly broad blockades or unnecessary load on the backend. TLS termination at the edge can enable HTTP-level inspection before the backend. At the same time, identity, session, and business context remain in the application. Traffic and usage statistics help to observe technical patterns and operational impacts separately. This way, it can be determined whether a rule reduces the attack or merely impairs legitimate use.\u003c/p\u003e\n\u003ch2 id=\"4-architecture-and-operations-must-account-for-misjudgments\"\u003e4. Architecture and Operations Must Account for Misjudgments\u003c/h2\u003e\n\u003cp\u003eEvery protection rule can misclassify. An edge limit may trigger during a campaign or an API client, even if no attack is present. An application block may act too late if many TLS connections, requests, or costly preprocessing steps have already consumed resources. Therefore, the architecture requires multiple protection levels: coarse filters and scrubbing at the public entrance, targeted HTTP controls at the edge, and business rules in the backend.\u003c/p\u003e\n\u003cp\u003eOperationally, traceable metrics and controlled failover are crucial. Teams must be able to recognize whether traffic was discarded at the edge, forwarded, or rejected only in the application. Backend health checks and failover do not automatically limit misuse but prevent an already affected target from being uncontrollably further burdened. Provider-independent usage is relevant when applications run in self-managed or other providers\u0026rsquo; \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n. The edge then remains the central protection and routing layer, while business control stays where the application context exists.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn API offers login, product search, and order functionalities. A volumetric attack on the API is reduced at the edge through scrubbing and technical filters. Simultaneously, a bot sends valid login requests with changing IP addresses, staying below a global request limit. The edge only partially recognizes this pattern. The application, however, detects many failed attempts per account and increases control for this operation.\u003c/p\u003e\n\u003cp\u003eFor product search, a higher rate limit may apply, while login and password reset are treated more strictly. The edge continues to protect overall capacity and public endpoints. The application decides which identities or sessions are acting abusively. Both layers solve different problems without implementing the same rule twice or contradictorily.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-ddos-protection-replace-application-security\"\u003eDoes DDoS Protection Replace Application Security?\u003c/h3\u003e\n\u003cp\u003eNo. DDoS protection reduces technical attack volumes. Business misuse requires information about identity, session, permissions, and business processes, which usually only the application possesses.\u003c/p\u003e\n\u003ch3 id=\"is-rate-limiting-a-task-for-the-edge-or-the-application\"\u003eIs Rate Limiting a Task for the Edge or the Application?\u003c/h3\u003e\n\u003cp\u003eBoth are possible, but with different goals. The edge limits technical load and broad patterns. The application sets context-specific limits for users, tenants, sessions, or business operations.\u003c/p\u003e\n\u003ch3 id=\"why-isnt-a-waf-rule-enough\"\u003eWhy Isn\u0026rsquo;t a WAF Rule Enough?\u003c/h3\u003e\n\u003cp\u003eA WAF can check HTTP structures and known patterns. However, it does not reliably recognize whether a formally valid operation is being misused. Additional application data is required for that.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDDoS protection and application security are not competing mechanisms but protection layers with different information bases. The edge reduces volume, protocol misuse, and recognizable request anomalies before they reach backends. The application assesses business legitimacy and misuse. In this model, the ayedo Edge Cloud is the public, distributed protection and routing layer in front of applications and APIs—even when their \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n or compute infrastructure is operated independently.\u003c/p\u003e\n",
      "summary": "\nTL;DR DDoS protection and application security address different levels of attacks. The edge can assess volume, protocols, connection rates, and request patterns to discard malicious traffic early. However, whether a valid request is being misused can often only be determined in the application context. Effective protection combines both levels with clear responsibilities.\nIntroduction A successful HTTP request is not automatically a legitimate business transaction. An attacker can access valid URLs, establish correct TLS connections, and operate within technical limits—such as deliberately burdening login, search, or shopping cart functions. A traditional DDoS protection might not detect a volumetric attack in this scenario. Conversely, an application cannot economically assess incoming traffic if large volumes of malicious packets and connections already reach the infrastructure. Therefore, the critical architectural question is not whether the edge or the application provides protection, but rather which signals each layer can reliably evaluate and how both protection mechanisms interact.\n",
      "image": "https://ayedo.de/ddos-schutz-an-der-edge-mit-anwendungslogik-koppeln.png",
      "date_published": "2026-09-08T17:10:08Z",
      "date_modified": "2026-09-08T17:10:08Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","security","operations","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/multi-cloud-security-mit-zentraler-edge-architektur/",
      "url": "https://ayedo.de/en/posts/multi-cloud-security-mit-zentraler-edge-architektur/",
      "title": "Multi-Cloud Security with Centralized Edge Architecture",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/multi-cloud-security-mit-zentraler-edge-architektur/multi-cloud-security-mit-zentraler-edge-architektur.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud Security often fails not due to a lack of protective features, but because of its distributed implementation. A centralized edge architecture consolidates public access, WAF, DDoS protection, TLS termination, and routing in front of heterogeneous backends. Provider independence, an autonomous system, and active-active operation reduce control and dependency points.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMulti-cloud architectures distribute workloads across multiple providers, regions, and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments. However, public access is often managed separately for each platform: individual load balancers, WAFs, DNS, and failover logic. This results in different security models, configurations, and operational processes. The technical trade-off is clear: backends gain in distribution, while internet access becomes more complex and harder to control. A centralized edge architecture establishes a unified control layer in front of these heterogeneous environments. It separates public traffic entry from the respective compute infrastructure, creating a consistent location for protection, routing, and load balancing.\u003c/p\u003e\n\u003ch2 id=\"1-centralized-edge-as-a-control-layer-in-front-of-heterogeneous-backends\"\u003e1. Centralized Edge as a Control Layer in Front of Heterogeneous Backends\u003c/h2\u003e\n\u003cp\u003eIn a multi-cloud environment, applications should not necessarily be accessible through the public entry points of their respective providers. Instead, a pre-positioned edge can accept incoming traffic, inspect it, and forward it to backends in different clouds or \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters. These backends can be operated by ayedo, other providers, or on your own infrastructure.\u003c/p\u003e\n\u003cp\u003eTechnically, the edge consolidates several functions: Anycast-based Layer 4 and Layer 7 load balancing, TLS termination, web application firewall, DDoS protection, and backend health checks. Routing and failover decisions are thus not implemented separately in each backend cluster. This reduces configuration divergence and facilitates the enforcement of uniform security rules.\u003c/p\u003e\n\u003cp\u003eIt is important to delineate: the edge does not replace security measures within workloads. Network segmentation, identities, secrets, and runtime protection remain tasks of the respective compute environment. The edge focuses on the public entrance and prevents each platform from establishing its own, differing perimeter layer.\u003c/p\u003e\n\u003ch2 id=\"2-provider-independence-reduces-dependency-points\"\u003e2. Provider Independence Reduces Dependency Points\u003c/h2\u003e\n\u003cp\u003eProvider independence does not mean that every infrastructure must be built identically. It means that public access and central security functions are not inextricably linked to the implementation of a single cloud or \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n provider. Such an approach facilitates migrations, failover scenarios, and the distribution of workloads across multiple environments.\u003c/p\u003e\n\u003cp\u003eBackend cloaking supports this model by ensuring that the actual origin addresses are not used as public entry points. The edge communicates with the backends, while clients address only the central public access. This reduces the direct attack surface and prevents the unnecessary external mapping of internal topology. Additionally, proxy protocol and health checks can be used for controlled transmission of connection information and assessment of backend reachability.\u003c/p\u003e\n\u003cp\u003eOperationally, a unified handover point for DNS, certificates, routing, and statistics is created. This simplifies responsibilities but requires clear processes: changes to the edge potentially affect multiple applications and providers. A central architecture thus reduces distributed control points but increases the importance of governance, testing, and traceable approvals.\u003c/p\u003e\n\u003ch2 id=\"3-autonomous-system-and-own-network-infrastructure\"\u003e3. Autonomous System and Own Network Infrastructure\u003c/h2\u003e\n\u003cp\u003eAn own \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n is primarily a routing and operational decision, not an automatic security gain. However, it lays the foundation for making public accessibility and edge connectivity more independent from individual upstream or cloud networks. Together with own network infrastructure, a clearer separation between edge operation and the networks where the backends are run is created.\u003c/p\u003e\n\u003cp\u003eFor multi-cloud security, this separation is relevant because security and routing decisions do not lie entirely within individual provider boundaries. Anycast DNS and multi-provider DNS can help organize public access across multiple networks and environments. The edge cloud handles the processing and distribution of traffic, while the compute platforms retain their respective internal operational responsibility.\u003c/p\u003e\n\u003cp\u003eThe security effect lies mainly in the reduction of dependencies and the controllable responsibility model. An own autonomous system does not eliminate misconfigurations or attack risks. However, it expands the architectural scope for action in routing, provider changes, and decoupling from the public entry point of individual clouds.\u003c/p\u003e\n\u003ch2 id=\"4-active-active-instead-of-a-central-single-point-of-failure\"\u003e4. Active-Active Instead of a Central Single Point of Failure\u003c/h2\u003e\n\u003cp\u003eA central edge should not be equated with a single central system. If public access, WAF, and routing are operated in only one instance, consolidation itself can become a risk of failure. For a resilient architecture, the control layer must be distributed and redundant.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud uses a distributed multi-PoP architecture and an active-active principle. Multiple edge instances can process traffic simultaneously, rather than a passive reserve waiting to take over. This improves fault tolerance and avoids a single location or active component determining public access.\u003c/p\u003e\n\u003cp\u003eFor the security architecture, it is crucial that protection functions and routing do not have to fall back on another provider-specific entry point in the event of a failure. Health checks and failover can consider backends based on their reachability. Active-active thus does not reduce every operational disruption, but it limits the number of critical failure and dependency points in front of the backends.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-one-service-three-execution-environments\"\u003ePractical Scenario: One Service, Three Execution Environments\u003c/h2\u003e\n\u003cp\u003eA company operates a web application in an ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster, a second instance in another Kubernetes cluster, and an API backend with another cloud provider. Without a central edge, each environment requires its own public endpoints, certificates, WAF rules, and failover mechanisms.\u003c/p\u003e\n\u003cp\u003eWith a provider-independent edge, all clients receive a common public access. TLS is terminated at the edge, traffic is processed through WAF and DDoS protection, and then distributed to available backends based on health checks. The clusters remain internally addressable, while backend cloaking hides their public origin addresses. If an environment fails, the edge can direct traffic to a healthy backend without the client needing to know the provider structure.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-a-central-edge-sensible-for-every-multi-cloud-environment\"\u003eIs a central edge sensible for every multi-cloud environment?\u003c/h3\u003e\n\u003cp\u003eNo. For a few, tightly coupled workloads, a provider-near solution may suffice. The central edge becomes relevant primarily with multiple clouds, clusters, public APIs, and different operational models.\u003c/p\u003e\n\u003ch3 id=\"does-the-edge-replace-the-security-functions-of-cloud-providers\"\u003eDoes the edge replace the security functions of cloud providers?\u003c/h3\u003e\n\u003cp\u003eNo. It complements them at the public entrance. Identity management, internal segmentation, workload protection, and securing the backends remain tasks of the respective platform.\u003c/p\u003e\n\u003ch3 id=\"does-an-own-autonomous-system-automatically-make-the-architecture-more-secure\"\u003eDoes an own autonomous system automatically make the architecture more secure?\u003c/h3\u003e\n\u003cp\u003eNo. It reduces certain network dependencies and expands control over routing and reachability. Security gains arise only through appropriate operational processes, redundancy, and consistent protection rules.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eMulti-cloud security is not just a matter of individual WAF rules or provider services. What matters is where public access is controlled, protected, and operated. A distributed, provider-independent edge architecture consolidates this responsibility in front of heterogeneous backends without mixing compute and edge. An own autonomous system, own network infrastructure, and active-active operation support an architecture with fewer dependency points. The ayedo Edge Cloud is in this model the central entry layer in front of different cloud and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments.\u003c/p\u003e\n",
      "summary": "\nTL;DR Multi-Cloud Security often fails not due to a lack of protective features, but because of its distributed implementation. A centralized edge architecture consolidates public access, WAF, DDoS protection, TLS termination, and routing in front of heterogeneous backends. Provider independence, an autonomous system, and active-active operation reduce control and dependency points.\nIntroduction Multi-cloud architectures distribute workloads across multiple providers, regions, and Kubernetes environments. However, public access is often managed separately for each platform: individual load balancers, WAFs, DNS, and failover logic. This results in different security models, configurations, and operational processes. The technical trade-off is clear: backends gain in distribution, while internet access becomes more complex and harder to control. A centralized edge architecture establishes a unified control layer in front of these heterogeneous environments. It separates public traffic entry from the respective compute infrastructure, creating a consistent location for protection, routing, and load balancing.\n",
      "image": "https://ayedo.de/multi-cloud-security-mit-zentraler-edge-architektur.png",
      "date_published": "2026-09-08T17:10:08Z",
      "date_modified": "2026-09-08T17:10:08Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","kubernetes","cloud","cloud-native","operations"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/offentliche-angriffsflachen-systematisch-reduzieren/",
      "url": "https://ayedo.de/en/posts/offentliche-angriffsflachen-systematisch-reduzieren/",
      "title": "Systematically Reducing Public Attack Surfaces",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/offentliche-angriffsflachen-systematisch-reduzieren/offentliche-angriffsflachen-systematisch-reduzieren.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA public attack surface is not just created by individual vulnerabilities, but by the entire internet-exposed architecture. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination, and Backend Cloaking must therefore be considered as an interconnected security zone in front of the backends. The key is which traffic actually reaches the backends and under what conditions.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany companies evaluate public endpoints individually: an API receives a WAF rule, a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes service\u003c/a\u003e\n is published via a Loadbalancer, another service gets a separate DDoS protection. Technically, each measure can make sense. Architecturally, however, this quickly creates an inconsistent and difficult-to-control attack surface. The central mistake lies in planning security functions as isolated products instead of as a processing chain. A robust edge security architecture therefore begins with a clear question: Which layer accepts internet traffic, what checks are performed there, and how is it prevented that attackers can directly reach the backends?\u003c/p\u003e\n\u003ch2 id=\"1-model-public-endpoints-as-an-interconnected-zone\"\u003e1. Model Public Endpoints as an Interconnected Zone\u003c/h2\u003e\n\u003cp\u003eThe public attack surface encompasses more than DNS entries and IP addresses. It also includes TLS endpoints, routing paths, exposed ports, API gateways, Kubernetes ingresses, and the accessible backend networks. Each additional direct connection to the internet increases the control effort and potentially creates an alternative path past central security rules.\u003c/p\u003e\n\u003cp\u003eA pre-positioned edge zone separates the public entry from the compute infrastructure. In this zone, connections are accepted, routed, checked, and distributed to suitable backends. As a result, the backends do not have to handle the entire public load and every security function themselves. Consistent enforcement is crucial: A service is only truly shielded if its backend is not simultaneously reachable via a second public route.\u003c/p\u003e\n\u003cp\u003eFor attack surface management, this means inventorying by endpoints and data flows, not just by applications. Each public service includes at least a DNS target, protocol, port, TLS behavior, protection rules, backend target, and failover behavior. This makes it visible which systems are actually exposed and where security controls are inconsistently applied.\u003c/p\u003e\n\u003ch2 id=\"2-connect-anycast-loadbalancing-and-ddos-protection\"\u003e2. Connect Anycast Loadbalancing and DDoS Protection\u003c/h2\u003e\n\u003cp\u003eAnycast Loadbalancing distributes the public access point over a distributed network architecture. Requests are not bound to a single central entry but are directed to the edge infrastructure. Different requirements can be mapped for Layer-4 and Layer-7 traffic: TCP connections require different checking and forwarding logic than HTTP requests with hostnames, paths, or headers.\u003c/p\u003e\n\u003cp\u003eDDoS Protection complements this distribution with the ability to handle volumetric or protocol-based attacks at the edge before they burden the compute environment. The security gain does not arise solely from the existence of a protection mechanism but from its position in the data path. The later traffic is filtered, the more network, firewall, or application capacity is already bound.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud connects Anycast-based Layer-4 and Layer-7 Loadbalancing with DDoS Protection and scrubbing at the edge. Its own network infrastructure and autonomous system form the infrastructural framework. This does not automatically reduce every risk but creates a clearly defined point where public traffic is accepted, distributed, and assessed before backend access.\u003c/p\u003e\n\u003ch2 id=\"3-deploy-waf-and-tls-termination-at-the-right-place\"\u003e3. Deploy WAF and TLS Termination at the Right Place\u003c/h2\u003e\n\u003cp\u003eA WAF protects HTTP and HTTPS services at the application level. It can evaluate requests based on characteristics that pure Layer-4 Loadbalancing does not know. These include, for example, HTTP methods, paths, or headers. To remain effective, relevant traffic must not bypass the WAF. Direct backend accesses, alternative ingress paths, or separate public listeners undermine central control.\u003c/p\u003e\n\u003cp\u003eTLS Termination at the edge shifts decryption to the public entry. There, HTTPS requests can be processed and then controlled forwarded to the backend. This simplifies the central enforcement of certificate and routing logic but also changes the trust boundaries: The path between edge and backend must be consciously modeled and secured. Encryption at the edge is therefore not a substitute for a clear backend architecture.\u003c/p\u003e\n\u003cp\u003eIn the ayedo Edge Cloud, TLS Termination and WAF for HTTP/HTTPS services can be combined with pre-positioned routing. The edge thus becomes a continuous processing layer: accepting connections, terminating TLS, checking requests, and only forwarding allowed traffic to the appropriate backend. The concrete security effect still depends on suitable rules, exceptions, and controlled backend access.\u003c/p\u003e\n\u003ch2 id=\"4-backend-cloaking-as-an-enforcement-principle\"\u003e4. Backend Cloaking as an Enforcement Principle\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking does not merely refer to hiding an IP address. It describes an architecture where backends do not need directly usable public addresses or alternative access paths. The public client knows the edge endpoint; the backend remains behind the pre-positioned processing layer. This makes attacks on exposed service addresses, direct port scans, and bypass attempts more difficult.\u003c/p\u003e\n\u003cp\u003eTechnically, more than DNS needs to be adjusted for this. Firewall rules, routing, source address validation, and health checks must ensure that only intended traffic reaches the application. Proxy Protocol can transmit relevant connection information to the backend without relocating the public entry directly to the application. Health checks and failover additionally control which backend currently receives traffic.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud supports Backend Cloaking, Proxy Protocol, as well as Backend Health Checks and Failover. This is particularly relevant in environments where applications are distributed across multiple clusters, providers, or own infrastructures. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n does not necessarily have to be operated in ayedo Managed Kubernetes: The edge functions can also be used in front of own or Kubernetes clusters operated by other providers. This keeps the security zone separate from the respective compute location.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a public web application, an API, and several internal services in Kubernetes clusters with different providers. In the first model, each cluster has its own public Loadbalancers, TLS configurations, and WAF rules. Failures, rule changes, and new endpoints are handled separately for each environment. In the second model, DNS entries point to the edge zone. Anycast Loadbalancing accepts the traffic, DDoS Protection and WAF check it, TLS is terminated at the edge, and only allowed requests reach the backends. The clusters remain provider-independent. The operational advantage lies not in fewer components but in a clear control boundary: Changes to the public access logic are made centrally, while the compute teams can operate their backends separately.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-a-waf-replace-systematic-attack-surface-management\"\u003eDoes a WAF replace systematic attack surface management?\u003c/h3\u003e\n\u003cp\u003eNo. A WAF primarily evaluates HTTP/HTTPS requests. It neither prevents direct backend reachability nor uncontrolled ports, DNS misconfigurations, or alternative access paths.\u003c/p\u003e\n\u003ch3 id=\"does-the-application-have-to-run-in-ayedo-managed-kubernetes-for-this\"\u003eDoes the application have to run in ayedo Managed Kubernetes for this?\u003c/h3\u003e\n\u003cp\u003eNo. The ayedo Edge Cloud can also be used in front of own or Kubernetes clusters operated by other providers. Edge and compute remain separate areas of responsibility.\u003c/p\u003e\n\u003ch3 id=\"is-backend-cloaking-synonymous-with-complete-invisibility\"\u003eIs Backend Cloaking synonymous with complete invisibility?\u003c/h3\u003e\n\u003cp\u003eNo. The backends remain reachable for the edge. The goal is to avoid direct public access and enforce the controlled edge path as the intended entry.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA public attack surface cannot be reliably reduced by adding individual security functions. The key is an architecture that accepts, distributes, checks, and controls public traffic at a clearly defined edge zone before forwarding it to hidden backends. Anycast, DDoS Protection, WAF, TLS Termination, and Backend Cloaking fulfill different tasks within the same processing chain. The ayedo Edge Cloud integrates these functions into a provider-independent, active-active edge infrastructure and consistently separates them from compute responsibility.\u003c/p\u003e\n",
      "summary": "\nTL;DR A public attack surface is not just created by individual vulnerabilities, but by the entire internet-exposed architecture. Anycast Loadbalancing, WAF, DDoS Protection, TLS Termination, and Backend Cloaking must therefore be considered as an interconnected security zone in front of the backends. The key is which traffic actually reaches the backends and under what conditions.\nIntroduction Many companies evaluate public endpoints individually: an API receives a WAF rule, a Kubernetes service is published via a Loadbalancer, another service gets a separate DDoS protection. Technically, each measure can make sense. Architecturally, however, this quickly creates an inconsistent and difficult-to-control attack surface. The central mistake lies in planning security functions as isolated products instead of as a processing chain. A robust edge security architecture therefore begins with a clear question: Which layer accepts internet traffic, what checks are performed there, and how is it prevented that attackers can directly reach the backends?\n",
      "image": "https://ayedo.de/offentliche-angriffsflachen-systematisch-reduzieren.png",
      "date_published": "2026-09-08T17:10:08Z",
      "date_modified": "2026-09-08T17:10:08Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","operations","development","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/tls-waf-und-backend-eine-schichtenarchitektur/",
      "url": "https://ayedo.de/en/posts/tls-waf-und-backend-eine-schichtenarchitektur/",
      "title": "TLS, WAF, and Backend: A Layered Architecture",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-waf-und-backend-eine-schichtenarchitektur/tls-waf-und-backend-eine-schichtenarchitektur.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA robust \u003cstrong\u003esecurity layered architecture\u003c/strong\u003e distributes protection tasks across different levels: TLS secures the transport connection, the WAF evaluates HTTP requests, and the backend remains responsible for authorization, validation, and data protection. The critical points are the handover points between these layers. Each decryption, forwarding, and protocol conversion creates its own trust and operational requirements.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eTLS, WAF, and backend are often treated as a cohesive protection mechanism in practice. This leads to a problematic assumption: if TLS is active and a WAF is in place, the application is automatically sufficiently secured. In reality, the three components fulfill different tasks and each sees only part of the traffic. TLS primarily protects the transport path, the WAF analyzes application requests, and the backend must secure business logic, identities, and data itself. A security layered architecture is therefore mainly a question of clearly defined responsibilities, handover points, and remaining risks.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-defines-the-first-trust-boundary\"\u003e1. TLS Termination Defines the First Trust Boundary\u003c/h2\u003e\n\u003cp\u003eTLS protects the confidentiality and integrity of a connection between a client and a TLS endpoint. With \u003cstrong\u003eTLS termination\u003c/strong\u003e at the edge, this connection does not end at the backend but at the edge platform. There, the encrypted HTTP traffic is decrypted and can be evaluated for downstream security functions.\u003c/p\u003e\n\u003cp\u003eThis architecture is technically necessary if a WAF is to examine HTTP methods, headers, cookies, or request bodies. A WAF cannot meaningfully evaluate encrypted content without decryption. At the same time, a new trust boundary is created at the edge: the decrypted traffic is available in plaintext and must be processed and forwarded accordingly within the platform.\u003c/p\u003e\n\u003cp\u003eFor the backend, this results in a clear duty to verify. Securing the client-to-edge connection says nothing about the connection from the edge to the backend. This path requires its own transport and trust decision. TLS termination does not automatically reduce every backend risk; it shifts part of the security responsibility to a defined handover point.\u003c/p\u003e\n\u003ch2 id=\"2-the-waf-operates-at-the-application-layer\"\u003e2. The WAF Operates at the Application Layer\u003c/h2\u003e\n\u003cp\u003eA WAF protects HTTP and HTTPS services by evaluating requests based on application layer properties. These include methods, paths, headers, parameters, or typical attack patterns. Its strength lies where network and transport protection are insufficient: with exploitable requests, unexpected inputs, and known attack patterns against web applications.\u003c/p\u003e\n\u003cp\u003eHowever, the WAF is not a substitute for TLS and not a complete protection of the backend. It can only examine data that it actually reaches and can interpret. Protocol deviations, unclear header forwarding, or faulty TLS configurations can therefore affect the analysis. Likewise, technical errors remain possible if a request appears technically correct but violates business logic.\u003c/p\u003e\n\u003cp\u003eIn the ayedo Edge Cloud, the WAF is positioned in front of the actual backends and can be connected with TLS termination at the edge. This creates a central checkpoint before the compute infrastructure. Nevertheless, the application remains responsible for authentication, authorization, input validation, and secure processing.\u003c/p\u003e\n\u003ch2 id=\"3-backend-security-begins-behind-the-waf\"\u003e3. Backend Security Begins Behind the WAF\u003c/h2\u003e\n\u003cp\u003eThe backend must not be viewed as a passive recipient of already verified requests. It must validate its own security assumptions: identities and permissions need to be checked, inputs must be contextually validated, and sensitive operations require server-side controls. A WAF can recognize attack indicators but cannot replace business authorization.\u003c/p\u003e\n\u003cp\u003eParticularly relevant is the question of which headers and source information are passed to the backend. If client IP, host, or protocol information is used for logging, rate limits, or security decisions, their origin must be clear. The \u003cstrong\u003eProxy Protocol\u003c/strong\u003e mechanism can structurally transfer such connection information to downstream systems. However, the backend must correctly support this protocol and not treat unvalidated headers as trustworthy.\u003c/p\u003e\n\u003cp\u003eAdditionally, the backend should not be directly publicly accessible if all external traffic is to be routed through the edge. Backend cloaking reduces this attack surface by ensuring internal targets do not serve as a public entry point. Health checks and failover assist in operations but do not replace access controls or securing the backend connection.\u003c/p\u003e\n\u003ch2 id=\"4-handover-points-determine-remaining-risks\"\u003e4. Handover Points Determine Remaining Risks\u003c/h2\u003e\n\u003cp\u003eEach layer can only evaluate its own view of the traffic. Between the client, edge, and backend, handover points arise where protocols are terminated, information is added, or security decisions are passed on. It is precisely here that hard-to-detect misconfigurations often occur.\u003c/p\u003e\n\u003cp\u003eA typical example is the different interpretation of URL paths or headers at the edge, WAF, and application. If the WAF normalizes a request differently than the backend, a request may appear inconspicuous at the protection layer but have a different meaning in the backend. Similar risks arise from inconsistent TLS, host, or proxy protocol assumptions.\u003c/p\u003e\n\u003cp\u003eA robust security layered architecture therefore documents for each path: Who terminates TLS? Which instance sees the plaintext? What information is passed on? Which source is considered trustworthy? And what verification occurs only in the backend? In the ayedo Edge Cloud, public routing, protection, and forwarding functions can be centrally bundled before workloads. However, the specific security quality depends on the consistent configuration of all involved layers.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API on its own \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n with a cloud provider. The public DNS entry points to the ayedo Edge Cloud. There, TLS ends, the WAF checks the HTTP requests, and the traffic is then forwarded to the backend. The backend is not directly publicly exposed and only accepts the intended forwarding path.\u003c/p\u003e\n\u003cp\u003eFor operations, several points must now be monitored separately: certificate status and TLS errors at the edge, blocked or suspicious requests in the WAF, and authentication and authorization errors in the API. If a backend fails, health checks can influence the forwarding. However, they do not indicate whether the application is functioning correctly or securely. Only separate consideration makes the cause of an error visible.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-tls-termination-also-protect-the-connection-to-the-backend\"\u003eDoes TLS Termination Also Protect the Connection to the Backend?\u003c/h3\u003e\n\u003cp\u003eNo. TLS termination protects the connection to the TLS endpoint at the edge. The path between the edge and the backend must be evaluated separately and secured according to the application\u0026rsquo;s protection requirements.\u003c/p\u003e\n\u003ch3 id=\"does-a-waf-replace-validation-in-the-backend\"\u003eDoes a WAF Replace Validation in the Backend?\u003c/h3\u003e\n\u003cp\u003eNo. A WAF recognizes certain HTTP-based attack patterns. Business authorization, input validation, business logic, and the protection of sensitive data remain the application\u0026rsquo;s responsibilities.\u003c/p\u003e\n\u003ch3 id=\"why-are-handover-points-security-relevant\"\u003eWhy Are Handover Points Security-Relevant?\u003c/h3\u003e\n\u003cp\u003eAt handover points, connections are terminated, information is passed on, or protocols are interpreted. Divergent assumptions between edge, WAF, and backend can render protection mechanisms ineffective.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA \u003cstrong\u003esecurity layered architecture\u003c/strong\u003e is not a single product feature but a clear distribution of security tasks. TLS protects the transport up to the defined termination, the WAF evaluates HTTP requests, and the backend bears responsibility for identity, business logic, and data. The ayedo Edge Cloud can centrally bundle these upstream functions and connect backends independently of providers. It remains crucial to explicitly design the handover points and assign each remaining risk to a specific layer.\u003c/p\u003e\n",
      "summary": "\nTL;DR A robust security layered architecture distributes protection tasks across different levels: TLS secures the transport connection, the WAF evaluates HTTP requests, and the backend remains responsible for authorization, validation, and data protection. The critical points are the handover points between these layers. Each decryption, forwarding, and protocol conversion creates its own trust and operational requirements.\nIntroduction TLS, WAF, and backend are often treated as a cohesive protection mechanism in practice. This leads to a problematic assumption: if TLS is active and a WAF is in place, the application is automatically sufficiently secured. In reality, the three components fulfill different tasks and each sees only part of the traffic. TLS primarily protects the transport path, the WAF analyzes application requests, and the backend must secure business logic, identities, and data itself. A security layered architecture is therefore mainly a question of clearly defined responsibilities, handover points, and remaining risks.\n",
      "image": "https://ayedo.de/tls-waf-und-backend-eine-schichtenarchitektur.png",
      "date_published": "2026-09-08T17:10:08Z",
      "date_modified": "2026-09-08T17:10:08Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","operations","digital-sovereignty","kubernetes","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/tls-termination-an-der-edge-architektonisch-planen/",
      "url": "https://ayedo.de/en/posts/tls-termination-an-der-edge-architektonisch-planen/",
      "title": "Architectural Planning for TLS Termination at the Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-termination-an-der-edge-architektonisch-planen/tls-termination-an-der-edge-architektonisch-planen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS termination at the edge shortens the path from client to protected entry point but shifts responsibilities. Certificates, trust boundaries, and backend connections must therefore be planned separately. The central question is not whether TLS ends at the public entrance, but which connections remain encrypted afterwards and how their identities are verified.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eTLS termination at the public entrance is not merely a technical optimization. It determines where certificates are managed, which component is allowed to decrypt HTTP requests, and what trust boundaries arise between the edge and the backend. A common architectural mistake is planning encryption only up to the edge and treating internal forwarding as automatically trustworthy. This quickly turns a clear outer protection boundary into an uncontrolled internal zone. A robust TLS architecture therefore separates three questions: Where does the public TLS connection end? How is the connection to the backend protected? And which component is responsible for identity, encryption, and access control?\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-shifts-the-trust-boundary\"\u003e1. TLS Termination Shifts the Trust Boundary\u003c/h2\u003e\n\u003cp\u003eWith TLS termination at the ayedo Edge Cloud, the client connection does not end at the application server but at the distributed edge infrastructure. There, certificates are presented, the TLS handshake is processed, and the encrypted data stream is made accessible for further processing. This is architecturally sensible because WAF, routing, load balancing, and health checks at the application level are only possible after decryption.\u003c/p\u003e\n\u003cp\u003eAt the same time, the edge becomes a consciously defined trust component. It can process HTTP headers, paths, and content and must therefore be included in the threat model. The certificate and associated private key no longer reside solely in the compute environment. For companies, this means certificate access, roles, rotation, and auditability must be regulated for the edge just as for ingress components in the cluster. TLS termination is thus a decision about responsibilities, not just network paths.\u003c/p\u003e\n\u003ch2 id=\"2-centralize-certificate-management-but-separate-responsibilities\"\u003e2. Centralize Certificate Management but Separate Responsibilities\u003c/h2\u003e\n\u003cp\u003eCentral termination reduces the number of public TLS endpoints. Instead of distributing certificates separately across multiple clusters, ingress controllers, or providers, the public entrance can be consistently operated at the edge. This simplifies certificate management, rotation, and enforcement of common TLS policies. Especially in multi-cluster or multi-provider architectures, it reduces operational dependencies.\u003c/p\u003e\n\u003cp\u003eHowever, this simplification should not be confused with a single global certificate responsibility. Public certificates for customer access, internal certificates for backend connections, and potentially service-specific identities serve different purposes. A certificate for \u003ccode\u003eapi.example.com\u003c/code\u003e does not automatically prove the identity of an internal service. Likewise, central termination does not replace control over which edge path may reach which backend. Responsibilities should therefore be documented separately for each connection: client to edge, edge to backend, and potentially service to service.\u003c/p\u003e\n\u003ch2 id=\"3-the-backend-connection-is-a-separate-security-decision\"\u003e3. The Backend Connection is a Separate Security Decision\u003c/h2\u003e\n\u003cp\u003eAfter TLS termination, the connection to the backend must be evaluated separately. An unencrypted forwarding can be acceptable in a strictly controlled, locally confined environment, but assumes that network path, access protection, and data classification correspond to these trust assumptions. In distributed environments, across provider boundaries, or with sensitive data, this assumption is much harder to justify.\u003c/p\u003e\n\u003cp\u003eThe alternative is a renewed TLS connection between edge and backend. This keeps the data traffic encrypted even after public termination. However, additional requirements arise: the backend must verify the identity of the counterparty, certificates must be issued and rotated, and hostname and certificate chain must match the target architecture. While the edge can provide the public TLS endpoint, the backend side still requires its own certificate and trust model. Encryption alone is not enough; what matters is whether both sides authenticate the expected counterparty.\u003c/p\u003e\n\u003ch2 id=\"4-logging-and-identity-must-consider-termination\"\u003e4. Logging and Identity Must Consider Termination\u003c/h2\u003e\n\u003cp\u003eTLS termination also changes the technical interpretation of requests. The backend sees the edge as the direct network connection, not the original client. For rate limiting, auditing, incident response, or application-related access control, trusted information about the original connection must therefore be correctly forwarded and processed. Proxy Protocol can transport network metadata; HTTP headers require a clear trust policy and should not be uncritically adopted from arbitrary sources.\u003c/p\u003e\n\u003cp\u003eThese questions belong to the TLS architecture because an encrypted connection does not automatically provide a reliable client identity. The application must know which information comes from the edge and which it must validate itself. At the same time, backend cloaking should prevent internal targets from being publicly accessible. The ayedo Edge Cloud connects TLS termination with backend protection, routing, and health checks at this point. However, it does not replace the decision on which identity and authorization information applies within the application.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers. The ayedo Edge Cloud terminates the public TLS, checks the available backend path, and distributes requests to the healthy clusters. Variant A forwards unencrypted within an isolated network. This reduces certificate effort but extends the trust zone to the backend. Variant B uses TLS again between the edge and both clusters. This keeps provider and cluster boundaries protected even during transport, while additional certificate rotation and backend validation become necessary. The decision should be based on data classification, network control, \u003ca href=\"https://compliance/\" target=\"_blank\" rel=\"noopener\"\u003ecompliance\u003c/a\u003e\n requirements, and operational capability, not merely on the existence of edge termination.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-tls-termination-at-the-edge-automatically-end-to-end-encryption\"\u003eIs TLS termination at the edge automatically end-to-end encryption?\u003c/h3\u003e\n\u003cp\u003eNo. The client connection is encrypted up to the edge. For end-to-end encryption, the connection from the edge to the backend must also be protected separately by TLS.\u003c/p\u003e\n\u003ch3 id=\"who-manages-the-certificates-after-termination\"\u003eWho manages the certificates after termination?\u003c/h3\u003e\n\u003cp\u003eThis depends on the architecture. Public certificates are the responsibility of edge operations; internal backend certificates remain part of the respective backend and platform model.\u003c/p\u003e\n\u003ch3 id=\"can-the-backend-still-recognize-the-original-client\"\u003eCan the backend still recognize the original client?\u003c/h3\u003e\n\u003cp\u003eOnly through trusted forwarded metadata and appropriate validation. The direct TCP connection comes from the edge, not the original client.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eTLS termination at the ayedo Edge Cloud creates a central, distributed public TLS endpoint and can simplify certificate management across multiple backends. It also defines a new trust boundary. Therefore, backend encryption, identity verification, metadata forwarding, and access protection must be independently planned. The right architecture is not simply \u0026ldquo;TLS at the edge\u0026rdquo; or \u0026ldquo;TLS everywhere,\u0026rdquo; but a documented division of encryption and operational responsibility.\u003c/p\u003e\n",
      "summary": "\nTL;DR TLS termination at the edge shortens the path from client to protected entry point but shifts responsibilities. Certificates, trust boundaries, and backend connections must therefore be planned separately. The central question is not whether TLS ends at the public entrance, but which connections remain encrypted afterwards and how their identities are verified.\nIntroduction TLS termination at the public entrance is not merely a technical optimization. It determines where certificates are managed, which component is allowed to decrypt HTTP requests, and what trust boundaries arise between the edge and the backend. A common architectural mistake is planning encryption only up to the edge and treating internal forwarding as automatically trustworthy. This quickly turns a clear outer protection boundary into an uncontrolled internal zone. A robust TLS architecture therefore separates three questions: Where does the public TLS connection end? How is the connection to the backend protected? And which component is responsible for identity, encryption, and access control?\n",
      "image": "https://ayedo.de/tls-termination-an-der-edge-architektonisch-planen.png",
      "date_published": "2026-09-08T17:10:07Z",
      "date_modified": "2026-09-08T17:10:07Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","kubernetes","security","operations","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/backend-cloaking-als-baustein-der-edge-security/",
      "url": "https://ayedo.de/en/posts/backend-cloaking-als-baustein-der-edge-security/",
      "title": "Backend Cloaking as a Component of Edge Security",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-cloaking-als-baustein-der-edge-security/backend-cloaking-als-baustein-der-edge-security.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking reduces the direct public accessibility of origin services by preventing clients from communicating directly with the backends. This decreases the public attack surface but does not replace WAF rules or application protection. Key factors include clean routing, controlled backend access, and an operational model for health checks and failover.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA publicly accessible origin server is not only a technical target for legitimate requests but also an additional attack surface. Even if all regular traffic runs through an edge platform, a known or incorrectly published backend address can allow direct access. Backend Cloaking addresses this issue: The application is addressed via the edge, while the origin services no longer serve as the primary public entry point. However, this also changes the routing model. Backends must be able to process requests from the edge, correctly assess states, and report failures. Cloaking is therefore an independent security measure—but not a complete security architecture.\u003c/p\u003e\n\u003ch2 id=\"backend-cloaking-reduces-the-direct-access-path\"\u003eBackend Cloaking Reduces the Direct Access Path\u003c/h2\u003e\n\u003cp\u003eIn Backend Cloaking, the public connection between client and application is terminated at the edge. The client communicates with the edge address, which then forwards the traffic to a defined backend. The origin address does not need to be used as a publicly visible target of the application. For the client, a unified access point is created, while the actual origin services lie behind the edge.\u003c/p\u003e\n\u003cp\u003eThis separation reduces the public attack surface at the network level. Direct scans, uncontrolled access to origin addresses, or attempts to bypass edge processing are made more difficult. However, it is essential that backends are not still unrestrictedly accessible from the internet. Cloaking loses a significant part of its effectiveness if the origin address remains known and any sender can establish connections there.\u003c/p\u003e\n\u003cp\u003eIn the context of the ayedo Edge Cloud, Backend Cloaking is part of the upstream edge functions. Anycast-based Layer-4 and Layer-7 load balancing takes in the public traffic and distributes it to the configured backends. The edge is thus not merely an additional proxy but the controlled public entrance before the origin services.\u003c/p\u003e\n\u003ch2 id=\"routing-accessibility-and-failover-must-match\"\u003eRouting, Accessibility, and Failover Must Match\u003c/h2\u003e\n\u003cp\u003eCloaking changes the question of how a backend is accessible. The service must be able to accept connections from the edge but must not serve as an uncontrolled direct internet endpoint. In practice, this requires coordinated network rules, routing paths, and responsibilities. Particularly important is the distinction between the address that clients reach and the target to which the edge internally forwards.\u003c/p\u003e\n\u003cp\u003eHealth checks are also part of this model. A backend can be reachable from the network\u0026rsquo;s perspective while the application itself no longer processes requests correctly. If such states are not recognized, the edge continues to distribute traffic to a technically available but functionally disrupted service. Backend health checks and failover must therefore match the application, the deployment model, and the expected error patterns.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud supports backend health checks and failover as well as an active-active architecture over a distributed multi-PoP infrastructure. This does not eliminate the need for appropriate backend configuration. However, it creates the foundation to operate the public entry and forwarding to the origins independently of a single edge or backend path.\u003c/p\u003e\n\u003ch2 id=\"cloaking-does-not-replace-waf-or-application-protection\"\u003eCloaking Does Not Replace WAF or Application Protection\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking primarily protects the access path to the origin. It does not automatically determine whether an HTTP request is technically permissible, whether a user is authenticated, or whether a payload exploits a vulnerability. An attacker can still reach a service via the edge and send valid-looking but harmful requests there. This is precisely why cloaking should not be equated with complete application protection.\u003c/p\u003e\n\u003cp\u003eA WAF complements the routing model with rules for HTTP and HTTPS services. It can, for example, evaluate requests based on protocol characteristics, paths, or known attack patterns. DDoS protection, in turn, addresses volumetric or protocol-related overload at the edge. These layers pursue different goals: Cloaking reduces direct origin accessibility, the WAF checks application traffic, and DDoS protection limits certain attack forms before the backend.\u003c/p\u003e\n\u003cp\u003eIn the ayedo Edge Cloud, these functions can interact within a common edge platform. TLS termination, WAF, and DDoS protection are positioned before the origin. The security effect arises not from a single function but from the clear separation of tasks and a configuration that enforces the intended path.\u003c/p\u003e\n\u003ch2 id=\"clearly-define-operational-model-and-responsibility-boundaries\"\u003eClearly Define Operational Model and Responsibility Boundaries\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking shifts responsibility, it does not remove it. Teams must determine who operates DNS entries, edge routing, backend releases, certificates, and health check endpoints. Changes to the origin must not occur in isolation if they affect accessibility, source addressing, or failover. Particularly in \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments, it is important not to equate the edge with the cluster entrance: The Edge Cloud takes over the public traffic entrance, while the cluster executes the workloads.\u003c/p\u003e\n\u003cp\u003eFor diagnostics and access control, source information must also remain traceable. Depending on the routing model, Proxy Protocol may be relevant if a backend requires the original client address or connection information. This must be compatible with the proxies, firewalls, and applications used. If source addresses are misinterpreted, incorrect rate limits, unusable logs, or unnecessary releases may result.\u003c/p\u003e\n\u003cp\u003eAnother advantage of the model is provider-independent usage. The ayedo Edge Cloud can be used with ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n as well as with self-hosted or provider-hosted Kubernetes clusters. This keeps the edge as an independent security and routing area, even if the compute infrastructure changes.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster with an external cloud provider. Without cloaking, a DNS entry points directly to a public load balancer of the cluster. The Edge Cloud is later placed in front, but the old endpoint remains accessible. An attacker can thus bypass WAF and rate-limit rules.\u003c/p\u003e\n\u003cp\u003eWith Backend Cloaking, the public DNS entry only points to the edge. The backend accepts connections exclusively via the intended edge path and reports its application state through appropriate health checks. The edge distributes requests to available backends. The WAF remains responsible for checking HTTP traffic; cloaking merely reduces direct origin access.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-backend-cloaking-fully-hide-the-origin-address\"\u003eDoes Backend Cloaking Fully Hide the Origin Address?\u003c/h3\u003e\n\u003cp\u003eNo. Addresses can become known through misconfigurations, leaks, or external information. Cloaking reduces direct usability but does not replace restrictive network rules and careful asset and DNS management.\u003c/p\u003e\n\u003ch3 id=\"is-backend-cloaking-only-relevant-for-kubernetes\"\u003eIs Backend Cloaking Only Relevant for Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNo. The principle applies to all publicly accessible applications and APIs. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n offers additional routing and operational variants but is not a prerequisite for the separation between edge and backend.\u003c/p\u003e\n\u003ch3 id=\"does-the-application-need-to-be-adapted-for-cloaking\"\u003eDoes the Application Need to Be Adapted for Cloaking?\u003c/h3\u003e\n\u003cp\u003eNot necessarily. However, it must be compatible with edge routing, TLS model, health checks, and possibly Proxy Protocol. Logging, client IP evaluation, and access controls should be specifically checked.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking is a clearly defined measure to reduce the public attack surface. It protects the origin by removing it from the direct public access path but does not solve application-level issues. The model becomes effective only through coordinated routing, restrictive backend accessibility, reliable health checks, and complementary edge security such as WAF and DDoS protection. The ayedo Edge Cloud integrates these tasks into an independent, provider-independent edge platform.\u003c/p\u003e\n",
      "summary": "\nTL;DR Backend Cloaking reduces the direct public accessibility of origin services by preventing clients from communicating directly with the backends. This decreases the public attack surface but does not replace WAF rules or application protection. Key factors include clean routing, controlled backend access, and an operational model for health checks and failover.\nIntroduction A publicly accessible origin server is not only a technical target for legitimate requests but also an additional attack surface. Even if all regular traffic runs through an edge platform, a known or incorrectly published backend address can allow direct access. Backend Cloaking addresses this issue: The application is addressed via the edge, while the origin services no longer serve as the primary public entry point. However, this also changes the routing model. Backends must be able to process requests from the edge, correctly assess states, and report failures. Cloaking is therefore an independent security measure—but not a complete security architecture.\n",
      "image": "https://ayedo.de/backend-cloaking-als-baustein-der-edge-security.png",
      "date_published": "2026-09-08T17:10:07Z",
      "date_modified": "2026-09-08T17:10:07Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/",
      "url": "https://ayedo.de/en/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/",
      "title": "DDoS Protection at the Edge and Its Limitations in the Backend",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDDoS protection at the edge reduces volumetric and network-based attack pressure before it reaches a company\u0026rsquo;s public infrastructure. Scrubbing thus protects the entry to applications and APIs. However, it does not replace backend security, authentication, resource limits, or domain-specific checks against misuse.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eDDoS protection often fails not due to a lack of filtering capability, but due to an incorrect delineation of protection layers. An attack can be effectively mitigated at the network edge and still exhaust backend resources if each valid request triggers extensive processing. Conversely, a backend is hardly capable of economically and stably processing large amounts of unwanted traffic on its own. The central architectural decision is therefore not \u0026ldquo;Edge or Backend,\u0026rdquo; but: What type of load is recognized and handled at which point? DDoS Protection and Scrubbing at the edge primarily address the public entry point. Authentication, authorization, and domain-specific misuse remain tasks of the application.\u003c/p\u003e\n\u003ch2 id=\"1-what-ddos-protection-at-the-edge-can-achieve\"\u003e1. What DDoS Protection at the Edge Can Achieve\u003c/h2\u003e\n\u003cp\u003eA DDoS attack often initially targets availability: lines, network components, load balancers, or servers are to be impaired by high request or packet volumes. An edge platform can intercept this pressure before the actual backends are reached. DDoS Protection and Scrubbing analyze incoming traffic and filter out unwanted patterns as close to the public entry as possible.\u003c/p\u003e\n\u003cp\u003eIn a distributed edge architecture, traffic is not first routed to a single location. The ayedo Edge Cloud uses an Anycast-based, distributed infrastructure with its own Autonomous System and active-active principle. This is not proof that every attack is automatically resolved. However, it creates an architecture where protection and routing functions are positioned in front of the backends and do not solely depend on their own capacity.\u003c/p\u003e\n\u003ch2 id=\"2-why-scrubbing-protects-the-public-entry\"\u003e2. Why Scrubbing Protects the Public Entry\u003c/h2\u003e\n\u003cp\u003eScrubbing fulfills a different task than a security mechanism within the application. The goal is to remove harmful or unwanted traffic from the data stream before it burdens network paths and resources of the backend environment. This particularly concerns volumetric attacks as well as certain network or protocol-related loads.\u003c/p\u003e\n\u003cp\u003eThe effect arises from the position of the protection function. When DNS, routing, load balancing, and DDoS defense work together at the edge, the public entry of applications and APIs remains under central control. The backends then do not have to accept and process every incoming connection themselves. Backend Cloaking reinforces this separation: the actual origin addresses do not have to be publicly visible as direct attack points.\u003c/p\u003e\n\u003cp\u003eThis architecture reduces the attack surface but does not eliminate it. Even after scrubbing, legitimate requests continue. For these, the backend must still provide sufficient capacity, appropriate timeouts, and controlled processing.\u003c/p\u003e\n\u003ch2 id=\"3-where-edge-protection-reaches-its-limits\"\u003e3. Where Edge Protection Reaches Its Limits\u003c/h2\u003e\n\u003cp\u003eNot every harmful request is recognizable as an attack at the network level. An attacker can establish valid TCP connections, send correct HTTP requests, and even successfully authenticate. Technically, the traffic initially appears as regular usage. DDoS protection at the edge cannot reliably assess such requests based on their domain-specific intent.\u003c/p\u003e\n\u003cp\u003eThe next limit lies in resource exhaustion through expensive operations. A single valid API request can, for example, trigger database queries, external calls, or complex calculations. If such requests are made in large numbers, an application-layer problem arises. Protection mechanisms such as rate limits, quotas, concurrency limits, caching, backpressure, and targeted contingents must intervene where the domain-specific significance is known.\u003c/p\u003e\n\u003cp\u003eAuthentication and authorization also remain backend tasks. The edge can protect the entry and secure HTTP/HTTPS services via a WAF. However, it does not automatically decide whether an authenticated user is misusing a particular resource.\u003c/p\u003e\n\u003ch2 id=\"4-backend-security-as-a-second-layer-of-protection\"\u003e4. Backend Security as a Second Layer of Protection\u003c/h2\u003e\n\u003cp\u003eBackend security begins with the assumption that edge protection does not replace a trust boundary for the application. Applications must verify incoming identities, permissions, and input parameters themselves. Additionally, they should limit resources per user, tenant, API key, or client. This prevents a valid access from triggering uncontrolled large amounts of processing.\u003c/p\u003e\n\u003cp\u003eFor operations, measurable protection boundaries are crucial: maximum request duration, queue size, connection limits, error rates, and controlled abort conditions. Health checks and failover help to remove unavailable backends from the traffic. However, they do not prevent domain-specific valid but harmful requests. If a backend is distributed across multiple clusters or providers, the edge can route and distribute public traffic independently of the provider. The security logic within these targets must still be consistently implemented.\u003c/p\u003e\n\u003cp\u003eEconomically, the separation is also relevant. Edge scrubbing can prevent unnecessary traffic from consuming expensive network and compute resources. Investments in application protection remain necessary because a smaller but domain-specific costly attack can still generate costs and operational risks.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a public API on its own \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster. A volumetric attack generates large amounts of unwanted packets and HTTP requests. Without a preceding edge protection layer, the cluster, ingress, and provider connection must at least partially absorb the attack traffic. With DDoS Protection and Scrubbing at the ayedo Edge Cloud, the public entry is protected before the backend; only scrubbed traffic is forwarded.\u003c/p\u003e\n\u003cp\u003eLater, an attacker uses valid credentials to repeatedly invoke a costly search function. This traffic is domain-specifically plausible and passes the edge. Only rate limits per identity, a request budget, and a limitation of parallel search operations in the backend prevent resource exhaustion. Both protection layers solve different problems.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-ddos-protection-at-the-edge-automatically-protect-every-api-application\"\u003eDoes DDoS protection at the edge automatically protect every API application?\u003c/h3\u003e\n\u003cp\u003eNo. It primarily reduces unwanted traffic at the public entry. Authentication, authorization, rate limits, and domain-specific misuse rules must still be implemented in the API and backend.\u003c/p\u003e\n\u003ch3 id=\"what-is-the-difference-between-scrubbing-and-a-waf\"\u003eWhat is the difference between scrubbing and a WAF?\u003c/h3\u003e\n\u003cp\u003eScrubbing primarily addresses harmful or excessive traffic at the network and transport level. A WAF examines HTTP/HTTPS requests and can filter application-specific attack patterns. Both functions are positioned before the backend but pursue different protection tasks.\u003c/p\u003e\n\u003ch3 id=\"is-backend-security-sufficient-without-edge-protection\"\u003eIs backend security sufficient without edge protection?\u003c/h3\u003e\n\u003cp\u003ePossibly for small attacks, but rarely as a reliable architecture. The backend must first reach and process the traffic. Edge protection reduces this preliminary load; the application still requires its own security and limitation mechanisms.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDDoS protection at the edge and backend security are not competing measures. The edge protects the public entry, filters volumetric pressure, and keeps unwanted traffic as far away from network and compute resources as possible. The backend, on the other hand, evaluates identities, permissions, and the domain-specific costs of a request. The ayedo Edge Cloud is in this model the upstream, distributed protection and routing platform; its effect arises in conjunction with robust boundaries within the applications.\u003c/p\u003e\n",
      "summary": "\nTL;DR DDoS protection at the edge reduces volumetric and network-based attack pressure before it reaches a company\u0026rsquo;s public infrastructure. Scrubbing thus protects the entry to applications and APIs. However, it does not replace backend security, authentication, resource limits, or domain-specific checks against misuse.\nIntroduction DDoS protection often fails not due to a lack of filtering capability, but due to an incorrect delineation of protection layers. An attack can be effectively mitigated at the network edge and still exhaust backend resources if each valid request triggers extensive processing. Conversely, a backend is hardly capable of economically and stably processing large amounts of unwanted traffic on its own. The central architectural decision is therefore not \u0026ldquo;Edge or Backend,\u0026rdquo; but: What type of load is recognized and handled at which point? DDoS Protection and Scrubbing at the edge primarily address the public entry point. Authentication, authorization, and domain-specific misuse remain tasks of the application.\n",
      "image": "https://ayedo.de/ddos-schutz-an-der-edge-und-seine-grenzen-im-backend.png",
      "date_published": "2026-09-08T17:10:07Z",
      "date_modified": "2026-09-08T17:10:07Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","security","development","operations","kubernetes"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/",
      "url": "https://ayedo.de/en/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/",
      "title": "WAF at the Edge: Rules, Limits, and Operational Models",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA WAF at the edge inspects HTTP and HTTPS requests before they reach backends. It is suitable for protocol and request-specific patterns like injection, unauthorized methods, or suspicious request structures. However, the application remains responsible for business context, logic, and complex authorization. A crucial operational model controls both protection effectiveness and false alarm risk.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA WAF is not a substitute for application security. The typical architectural mistake is to shift all security decisions to a central rule set before the backend. This works for clearly identifiable attack patterns but fails with business-related contexts: Whether an order is permissible depends not only on URL and HTTP method but also on user, inventory, status, and business process. A robust WAF architecture therefore separates generic filtering at the edge from context-dependent validation within the application. The ayedo Edge Cloud forms the public entry point before HTTP/HTTPS services and can inspect requests there with a Web Application Firewall before distributing them to the backends.\u003c/p\u003e\n\u003ch2 id=\"1-which-requests-a-waf-sensibly-inspects-at-the-edge\"\u003e1. Which Requests a WAF Sensibly Inspects at the Edge\u003c/h2\u003e\n\u003cp\u003eA WAF is particularly effective when an attack can be deduced from request properties. This includes suspicious payloads in query parameters, paths, form fields, or HTTP headers, typical patterns for SQL Injection and Cross-Site Scripting, as well as unauthorized HTTP methods. Size limits, unusual content types, unusual request structures, or known signatures can also be centrally evaluated.\u003c/p\u003e\n\u003cp\u003eThe advantage of the edge position lies in the timing of the inspection: Malicious traffic is discarded before reaching the application, thus not burdening backend processes or downstream security components. This is particularly relevant for publicly accessible APIs and web applications. The WAF does not become the sole protection layer. TLS can be terminated at the edge, while the backend remains hidden and only processes traffic forwarded by the edge. Filtering thus reduces the attack surface but does not replace secure implementation or patch and permission management.\u003c/p\u003e\n\u003ch2 id=\"2-waf-rules-between-standard-and-application-context\"\u003e2. WAF Rules Between Standard and Application Context\u003c/h2\u003e\n\u003cp\u003eRule sets can be broadly divided into generic and application-specific rules. Generic rules recognize known attack classes regardless of the specific application. Application-specific rules, on the other hand, consider defined paths, allowed methods, parameter formats, or expected content types of an API. The more precisely a rule describes legitimate traffic, the higher its protective effect can be—at the same time, the maintenance effort increases.\u003c/p\u003e\n\u003cp\u003eA WAF should not block every unusual input. Many valid applications accept special characters, large JSON documents, or dynamic parameters. Too restrictive rules generate false alarms and can interrupt regular business processes. Therefore, rules must be introduced observably, evaluated based on real requests, and operated with clear responsibility. The technical decision is not only \u0026ldquo;block or allow\u0026rdquo; but also which rule applies in which mode, who is responsible for exceptions, and how changes remain traceable.\u003c/p\u003e\n\u003ch2 id=\"3-operational-models-and-handling-false-alarms\"\u003e3. Operational Models and Handling False Alarms\u003c/h2\u003e\n\u003cp\u003eIn practice, three operational modes have been established: monitoring, targeted blocking, and comprehensive enforcement. In monitoring mode, the WAF logs hits without rejecting requests. This is suitable for the introduction phase and for new rule groups. Targeted blocking is limited to reliable rules or particularly critical endpoints. Comprehensive enforcement presupposes that application, data formats, and exceptions are sufficiently known.\u003c/p\u003e\n\u003cp\u003eA defined feedback process between platform, security, and application teams is crucial. A false alarm is not just a technical problem: It can interrupt revenue processes, integrations, or internal APIs. Conversely, a high number of observed hits should not automatically be interpreted as a security incident. Context, prioritization, and a decision on whether an exception refines the WAF rule or if there is an error in the application are needed. Traffic and usage statistics at the edge can support traffic evaluation but do not replace professional analysis.\u003c/p\u003e\n\u003ch2 id=\"4-where-edge-filtering-ends-and-application-protection-begins\"\u003e4. Where Edge Filtering Ends and Application Protection Begins\u003c/h2\u003e\n\u003cp\u003eA WAF can recognize that a request is formally suspicious. However, it usually cannot reliably assess whether an authenticated user is allowed to modify a particular resource or whether a business process is proceeding in the correct order. These decisions belong in the application or in designated authorization services. The same applies to plausibility checks, transaction consistency, tenant separation, and abuse logic with domain knowledge.\u003c/p\u003e\n\u003cp\u003eThe separation of responsibilities also improves the architecture. The edge takes over the public traffic entry, TLS-near processing, WAF inspection, and distribution; the backend validates identity, permissions, and business semantics. Through backend cloaking, the application does not have to be directly publicly addressable. With multiple backends or failure paths, health checks and failover remain tasks of the edge infrastructure, while the application remains responsible for the correctness of its decisions. A WAF architecture is thus an additional control layer, not a central replacement for secure coding.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA public API accepts JSON requests for account changes. At the ayedo Edge Cloud, only HTTPS requests on the intended API paths are initially accepted. The WAF inspects method, content type, request size, and known attack patterns. New rules initially run in monitoring mode. After evaluation, clearly unauthorized methods are blocked, while business checks—such as whether the account belongs to the authenticated tenant—remain in the backend.\u003c/p\u003e\n\u003cp\u003eIf this tenant check were shifted to the edge, the rule set would need to know business data and application states. Any change to the business model would then also affect the central filter logic. The edge thus remains stable at the protocol and request level, while the application continues to develop its domain logic independently.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"can-a-waf-prevent-all-api-attacks\"\u003eCan a WAF Prevent All API Attacks?\u003c/h3\u003e\n\u003cp\u003eNo. It recognizes many protocol and payload-related attack patterns. Authorization, business logic, abuse detection, and secure implementation must still be implemented in the application.\u003c/p\u003e\n\u003ch3 id=\"should-every-waf-rule-immediately-block\"\u003eShould Every WAF Rule Immediately Block?\u003c/h3\u003e\n\u003cp\u003eNo. New or complex rules should first be observed and evaluated based on legitimate requests. Blocking is suitable for rules with a low false alarm probability and a clear technical basis.\u003c/p\u003e\n\u003ch3 id=\"where-is-the-waf-placed-in-the-architecture\"\u003eWhere is the WAF Placed in the Architecture?\u003c/h3\u003e\n\u003cp\u003eIn front of publicly accessible backends, typically at the edge. There, it can inspect requests before they are TLS-terminated, distributed, and forwarded to the actual applications.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA sustainable WAF architecture consciously distributes security tasks: The edge filters recognizable attack and protocol patterns, the application decides on identity, permission, and business legitimacy. For the ayedo Edge Cloud, this means a clear role as a public entrance with WAF inspection before the backends—not as a replacement for application protection. Controlled rule changes, traceable exceptions, and an operational model that takes false alarms as seriously as real attacks are crucial.\u003c/p\u003e\n",
      "summary": "\nTL;DR A WAF at the edge inspects HTTP and HTTPS requests before they reach backends. It is suitable for protocol and request-specific patterns like injection, unauthorized methods, or suspicious request structures. However, the application remains responsible for business context, logic, and complex authorization. A crucial operational model controls both protection effectiveness and false alarm risk.\nIntroduction A WAF is not a substitute for application security. The typical architectural mistake is to shift all security decisions to a central rule set before the backend. This works for clearly identifiable attack patterns but fails with business-related contexts: Whether an order is permissible depends not only on URL and HTTP method but also on user, inventory, status, and business process. A robust WAF architecture therefore separates generic filtering at the edge from context-dependent validation within the application. The ayedo Edge Cloud forms the public entry point before HTTP/HTTPS services and can inspect requests there with a Web Application Firewall before distributing them to the backends.\n",
      "image": "https://ayedo.de/waf-an-der-edge-regeln-grenzen-und-betriebsmodelle.png",
      "date_published": "2026-09-08T17:10:07Z",
      "date_modified": "2026-09-08T17:10:07Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/",
      "url": "https://ayedo.de/en/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/",
      "title": "Controlling Traffic Paths with TLS and Proxy Protocol",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/traffic-pfade-mit-tls-und-proxy-protocol-steuern/traffic-pfade-mit-tls-und-proxy-protocol-steuern.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA stable traffic path doesn\u0026rsquo;t end at TLS termination. The key is the coordinated interaction of TLS endpoint, routing, backend selection, health checks, and \u003ca href=\"/en/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n. The edge determines the public connection path; the application must decide how to process transmitted client information and which protocol parameters it accepts.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eTLS termination, routing, and \u003ca href=\"/en/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n are often configured separately in practice. This leads to errors: a backend may receive connections but cannot process the additional Proxy Protocol line. Or the edge terminates TLS while the application still expects a direct HTTPS connection from the client. Therefore, the traffic path must be considered as a continuous process. Each component alters the connection or adds information. The central architectural question is not only where TLS ends but also which identity and metadata are passed to the backend and what responsibility remains there.\u003c/p\u003e\n\u003ch2 id=\"1-the-traffic-path-begins-at-the-tls-endpoint\"\u003e1. The Traffic Path Begins at the TLS Endpoint\u003c/h2\u003e\n\u003cp\u003eWhen connecting to a public service, the client first reaches an anycast-based edge entry point. For HTTP and HTTPS services, the ayedo Edge Cloud can terminate TLS at the edge. The TLS endpoint thus handles the negotiation with the client and provides an already decrypted connection for downstream processing.\u003c/p\u003e\n\u003cp\u003eThis decision separates two areas of responsibility. The edge is responsible for the public TLS entry, while the application remains responsible for its own protocol and security logic. A backend should not automatically assume that the connection to it still corresponds to the original client TLS channel. Information such as the originally used protocol must be evaluated via defined headers or other transfer mechanisms if they are relevant to the application.\u003c/p\u003e\n\u003cp\u003eFor configuration, it is particularly important to align the certificate, hostname, listener, and the expected application protocol. A TLS error at the edge endpoint is different from an error between edge and backend. These paths should be considered separately in monitoring and troubleshooting.\u003c/p\u003e\n\u003ch2 id=\"2-after-termination-the-edge-decides-on-the-destination\"\u003e2. After Termination, the Edge Decides on the Destination\u003c/h2\u003e\n\u003cp\u003eAfter TLS termination, the routing decision follows. For HTTP services, hostname or URL path can contribute to the selection of the target service. On Layer 4, the decision remains more oriented towards network parameters such as IP and port. Which level is used depends on the service and its protocol.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud connects this routing logic with backend pools, health checks, and failover. A pool not only describes a list of reachable targets but also an operational decision space: which backends are considered available, and where is traffic distributed if individual targets fail? Therefore, the routing configuration must match the actually exposed ports, protocols, and health checks.\u003c/p\u003e\n\u003cp\u003eThe boundary between edge and application is important: the edge decides which backend receives the connection. It does not decide whether the application is functionally authorized or processes a request correctly. Successful routing and a successful health check only prove technical reachability or the defined test state, not the functional capability of the service.\u003c/p\u003e\n\u003ch2 id=\"3-proxy-protocol-transfers-connection-metadata\"\u003e3. \u003ca href=\"/en/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n Transfers Connection Metadata\u003c/h2\u003e\n\u003cp\u003eWhen Proxy Protocol is activated for a backend pool, the backend service receives additional information about the original connection before the actual payload. This includes source and destination information at the connection level. This is relevant if a service needs the client IP for logging, access control, rate limiting, or forensic analysis.\u003c/p\u003e\n\u003cp\u003eHowever, this function changes the expected input protocol. An HTTP server, TLS listener, or TCP service must explicitly support Proxy Protocol and evaluate it at the correct point. A backend that immediately expects HTTP or TLS data may otherwise interpret the additional transfer as invalid payload. The problem then does not necessarily lie in routing but in a non-coordinated backend integration.\u003c/p\u003e\n\u003cp\u003eProxy Protocol is also not a substitute for a functional identity. The transmitted connection information must be processed within the trusted edge-to-backend path. Applications should not derive unrestricted user identity from it. Suitable application mechanisms remain responsible for authentication and authorization.\u003c/p\u003e\n\u003ch2 id=\"4-edge-and-application-configuration-must-be-tested-separately\"\u003e4. Edge and Application Configuration Must Be Tested Separately\u003c/h2\u003e\n\u003cp\u003eA complete test must consider each transfer point: TLS connection to the edge endpoint, certificate and hostname verification, routing rule, selection of the backend pool, health check status, Proxy Protocol processing, and subsequent application communication. Individual tests at the backend are not sufficient if they bypass the actual public traffic path.\u003c/p\u003e\n\u003cp\u003eProtocol boundaries must also be clearly documented. The edge processes and distributes incoming traffic; the backend decides how Proxy Protocol, HTTP headers, and the actual payload are interpreted. For the application, it is particularly important whether it expects the connection as HTTP, HTTPS, or pure TCP. If TLS is terminated at the edge, the application must map its assumptions about the original transport accordingly.\u003c/p\u003e\n\u003cp\u003eIn \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, an additional integration boundary is added: the edge must be able to reach the externally accessible service and its backends, while the Kubernetes service or ingress provides the expected listener. This applies regardless of whether the cluster is operated with ayedo Managed Kubernetes or another provider. Provider independence does not change the protocol requirements of the backend.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an HTTPS API in its own Kubernetes cluster. The public traffic reaches the ayedo Edge Cloud, TLS is terminated there, and routed to a backend pool based on the hostname. The pool uses health checks and transfers client connection data via Proxy Protocol.\u003c/p\u003e\n\u003cp\u003eThe first test against the service fails because the upstream listener only expects HTTP and does not process Proxy Protocol. After adjusting the listener, the connection works. However, a second test shows that the application generates redirects with the \u003ccode\u003ehttp\u003c/code\u003e scheme because it does not account for TLS termination. The problem is no longer in Proxy Protocol but in the application logic for determining the original scheme. Both errors occur along the same traffic path but require different responsibilities and checks.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-tls-always-have-to-be-terminated-at-the-edge\"\u003eDoes TLS always have to be terminated at the edge?\u003c/h3\u003e\n\u003cp\u003eNo. The decision depends on the security model, protocol, and backend requirements. If TLS is terminated at the edge, the downstream protocol and trust boundaries must be explicitly defined.\u003c/p\u003e\n\u003ch3 id=\"does-proxy-protocol-replace-http-headers-for-the-client-ip\"\u003eDoes Proxy Protocol replace HTTP headers for the client IP?\u003c/h3\u003e\n\u003cp\u003eNo. Proxy Protocol transfers connection information at the transport level. HTTP headers belong to the application level and have different requirements for processing, trust, and validation.\u003c/p\u003e\n\u003ch3 id=\"does-proxy-protocol-work-with-any-backend\"\u003eDoes Proxy Protocol work with any backend?\u003c/h3\u003e\n\u003cp\u003eNo. The backend listener must support the protocol and be configured correctly. Otherwise, the additional data before the actual payload will be interpreted as an invalid request.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eTLS termination, routing, and \u003ca href=\"/en/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n are not independent switches but consecutive stations of a traffic path. Each station changes the context of the connection and shifts part of the responsibility between edge and application. The ayedo Edge Cloud consolidates these tasks at the public entry and can forward traffic via edge routing, backend pools, health checks, and Proxy Protocol. The architecture becomes stable only when the protocol expectations at each transfer are explicitly documented and tested.\u003c/p\u003e\n",
      "summary": "\nTL;DR A stable traffic path doesn\u0026rsquo;t end at TLS termination. The key is the coordinated interaction of TLS endpoint, routing, backend selection, health checks, and Proxy Protocol . The edge determines the public connection path; the application must decide how to process transmitted client information and which protocol parameters it accepts.\nIntroduction TLS termination, routing, and Proxy Protocol are often configured separately in practice. This leads to errors: a backend may receive connections but cannot process the additional Proxy Protocol line. Or the edge terminates TLS while the application still expects a direct HTTPS connection from the client. Therefore, the traffic path must be considered as a continuous process. Each component alters the connection or adds information. The central architectural question is not only where TLS ends but also which identity and metadata are passed to the backend and what responsibility remains there.\n",
      "image": "https://ayedo.de/traffic-pfade-mit-tls-und-proxy-protocol-steuern.png",
      "date_published": "2026-09-08T17:04:59Z",
      "date_modified": "2026-09-08T17:04:59Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","cloud-native","kubernetes","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/health-checks-als-grundlage-stabiler-traffic-pfade/",
      "url": "https://ayedo.de/en/posts/health-checks-als-grundlage-stabiler-traffic-pfade/",
      "title": "Health Checks as the Foundation of Stable Traffic Paths",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/health-checks-als-grundlage-stabiler-traffic-pfade/health-checks-als-grundlage-stabiler-traffic-pfade.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHealth Checks in load balancing assess not only whether a backend network target is reachable. Crucially, they determine if the service can actually process requests. The results influence pool states, failover, and traffic management. Thus, Health Checks become the foundation for reliable backend selection and stable public access paths.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA reachable server is not automatically a functional backend. A network target can respond to connection attempts while the web server, application, or a dependent database has already failed. If this distinction is not considered in load balancing, traffic remains on a technically reachable but practically unusable target.\u003c/p\u003e\n\u003cp\u003eHealth Checks provide a robust decision-making basis here. They provide the edge platform with information about which backends are currently suitable for traffic. This not only affects the distribution of incoming requests but also failover behavior, error rates, and recovery after disruptions. Therefore, Health Checks are not an optional addition to load balancing but part of its core control logic.\u003c/p\u003e\n\u003ch2 id=\"1-reachability-and-usability-are-different-states\"\u003e1. Reachability and Usability Are Different States\u003c/h2\u003e\n\u003cp\u003eThe simplest check determines if a backend is reachable at the network level. A connection can be established, a port can respond, or a target can generally return data. However, for backend availability, this is only a necessary, not necessarily a sufficient condition.\u003c/p\u003e\n\u003cp\u003eA service can, for example, accept connections even though its request processing is blocked. Similarly, an HTTP endpoint can respond while the application internally no longer executes business logic or a critical dependency cannot be reached. Therefore, a Health Check must match the service whose usability is to be evaluated.\u003c/p\u003e\n\u003cp\u003eArchitecturally, this means the checkpoint should be as close as possible to the actual function of the backend without introducing too many dependencies itself. A check that is too superficial leaves faulty targets in the pool. A check that is too complex can signal false failures due to individual downstream disruptions. The check logic is thus a deliberate balance between significance and stability.\u003c/p\u003e\n\u003ch2 id=\"2-check-results-become-pool-states\"\u003e2. Check Results Become Pool States\u003c/h2\u003e\n\u003cp\u003eHealth Checks are only operationally relevant when their results are translated into states. From the load balancing perspective, a backend is not simply \u0026ldquo;there\u0026rdquo; or \u0026ldquo;not there.\u0026rdquo; It can be assessed as usable, removed from traffic, or re-enter the selection after recovery. These states form the basis for routing decisions.\u003c/p\u003e\n\u003cp\u003eIf a target fails, traffic management should not have to wait for individual error messages. The edge can remove a backend assessed as unusable from the active selection and redirect requests to other suitable targets. For this, multiple backends must be present and correctly grouped. Failover is not a property of a single Health Check but the interplay of checking, pool configuration, and routing behavior.\u003c/p\u003e\n\u003cp\u003eEqually important is the return to the active pool. A short-term error should not lead to unnecessary oscillation between states. Conversely, a backend should not receive traffic too early if its recovery is not yet reliable. The specific assessment must therefore match the error characteristics of the respective service.\u003c/p\u003e\n\u003ch2 id=\"3-health-checks-influence-operations-before-the-incident\"\u003e3. Health Checks Influence Operations Before the Incident\u003c/h2\u003e\n\u003cp\u003eWithout reliable Health Checks, a failure often becomes visible only through user errors. Monitoring, support reports, or increasing error rates then show that traffic has already reached unsuitable targets. Health Checks shift the response to an earlier point: The platform can incorporate backend states into traffic management before each client experiences the error.\u003c/p\u003e\n\u003cp\u003eThis does not automatically reduce the cause of a failure. However, it limits its spread. A defective backend stays out of the active traffic path, while other targets can continue to handle requests. For operations, this means a clearer separation between error detection, routing reaction, and root cause analysis.\u003c/p\u003e\n\u003cp\u003eThe evaluation must still be aligned with the application. A check that only examines the infrastructure can overlook application failures. A check that includes every external dependency can remove the entire service from the pool in the event of a limited partial failure. Teams must therefore define which function is crucial for public accessibility and which errors should be handled separately.\u003c/p\u003e\n\u003ch2 id=\"4-edge-based-evaluation-reduces-dependencies-in-the-traffic-path\"\u003e4. Edge-Based Evaluation Reduces Dependencies in the Traffic Path\u003c/h2\u003e\n\u003cp\u003eIf Health Checks are conducted only behind multiple network or provider boundaries, the assessment may differ from the actual access path used. A backend may be reachable from a specific monitoring zone but not reliably usable for public traffic. The position of the check is thus a component of the architecture.\u003c/p\u003e\n\u003cp\u003eIn a distributed edge platform like the ayedo Edge Cloud, backend Health Checks flow into the selection of suitable targets. The Edge Cloud forms the public entry point before applications and APIs, taking on routing, load distribution, and failover. This directly connects the assessment of backend availability with the traffic path controlled by the platform.\u003c/p\u003e\n\u003cp\u003eThis is particularly relevant for provider-independent architectures and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments that are not necessarily operated by ayedo. The edge functions remain separate from the respective compute location: Kubernetes or other infrastructures run the workloads, while the edge evaluates their public accessibility and distributes traffic to usable backends. Thus, backend availability becomes an overarching routing question rather than a local cluster function.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two backend pools: one cluster in its own infrastructure and another with a cloud provider. Both targets are reachable over the network. However, in the primary pool, the API process accepts connections but can no longer complete requests due to an internal error.\u003c/p\u003e\n\u003cp\u003eA pure TCP check might still assess the target as available. Traffic would remain there, even though clients receive errors or timeouts. A Health Check aligned with the actual service function recognizes the state as unusable. The ayedo Edge Cloud can remove the backend from the active selection and redirect traffic to the other pool as part of the configured failover logic. The application remains accessible regardless of which compute location processes the traffic.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"do-health-checks-automatically-test-the-entire-application\"\u003eDo Health Checks automatically test the entire application?\u003c/h3\u003e\n\u003cp\u003eNo. They only evaluate the function defined in the respective check. Which dependencies are included must match the service\u0026rsquo;s role and the desired failure response.\u003c/p\u003e\n\u003ch3 id=\"what-happens-if-all-backends-are-deemed-unavailable\"\u003eWhat happens if all backends are deemed unavailable?\u003c/h3\u003e\n\u003cp\u003eThen normal failover to a usable target cannot occur. The resulting reaction depends on the routing and service configuration; Health Checks do not replace a redundant backend architecture.\u003c/p\u003e\n\u003ch3 id=\"are-health-checks-only-relevant-for-kubernetes\"\u003eAre Health Checks only relevant for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n?\u003c/h3\u003e\n\u003cp\u003eNo. They are a general load balancing principle and apply equally to virtual machines, bare-metal systems, or backends with different providers.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eHealth Checks in load balancing determine which backends are not only reachable but actually suitable for traffic. Their quality depends on the check logic, pool evaluation, and failover architecture. Companies should therefore treat Health Checks as part of the routing design. The ayedo Edge Cloud connects this evaluation with its public traffic entry, creating a foundation for provider-independent, controlled backend selection.\u003c/p\u003e\n",
      "summary": "\nTL;DR Health Checks in load balancing assess not only whether a backend network target is reachable. Crucially, they determine if the service can actually process requests. The results influence pool states, failover, and traffic management. Thus, Health Checks become the foundation for reliable backend selection and stable public access paths.\nIntroduction A reachable server is not automatically a functional backend. A network target can respond to connection attempts while the web server, application, or a dependent database has already failed. If this distinction is not considered in load balancing, traffic remains on a technically reachable but practically unusable target.\n",
      "image": "https://ayedo.de/health-checks-als-grundlage-stabiler-traffic-pfade.png",
      "date_published": "2026-09-08T17:04:59Z",
      "date_modified": "2026-09-08T17:04:59Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/l7-routing-fur-apis-regeln-pools-und-backends/",
      "url": "https://ayedo.de/en/posts/l7-routing-fur-apis-regeln-pools-und-backends/",
      "title": "L7 Routing for APIs: Rules, Pools, and Backends",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l7-routing-fur-apis-regeln-pools-und-backends/l7-routing-fur-apis-regeln-pools-und-backends.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eL7 routing distributes API requests not just by IP address or port, but based on application characteristics. Path, hostname, HTTP method, or headers can direct to different backend pools. Clear rules, defined priorities, and a clean boundary between edge routing and internal application logic are crucial.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA common backend pool for all API requests is easy to configure but quickly leads to unnecessary coupling. Versioned APIs, administrative endpoints, and public resources often have different scaling, security, and operational requirements. If they are indiscriminately forwarded to the same backends, the application itself must evaluate these differences.\u003c/p\u003e\n\u003cp\u003eL7 routing shifts part of this decision to the public entry point. The edge analyzes HTTP characteristics and assigns requests to appropriate services or backend pools. This creates a clear separation: the edge decides the general direction of traffic, while the application continues to manage its business logic.\u003c/p\u003e\n\u003ch2 id=\"1-l7-routing-starts-with-an-explicit-rule-structure\"\u003e1. L7 Routing Starts with an Explicit Rule Structure\u003c/h2\u003e\n\u003cp\u003eA routing rule consists of three parts: a match criterion, a target, and a defined order. The match criterion describes which requests the rule applies to. Typical characteristics include hostname, URL path, HTTP method, or selected headers. The target refers to a service or a backend pool that should process the request.\u003c/p\u003e\n\u003cp\u003eThe order is crucial. A general rule like \u003ccode\u003e/api/*\u003c/code\u003e should not overshadow a more specific rule for \u003ccode\u003e/api/v2/*\u003c/code\u003e. Therefore, rules should be arranged from specific to general or evaluated by a clearly defined priority. A final default rule prevents unmatched requests from being forwarded to any backend uncontrollably.\u003c/p\u003e\n\u003cp\u003eFor the ayedo Edge Cloud, L7 load balancing means that HTTP and HTTPS traffic can be distributed to different targets based on such application characteristics. The specific rule structure should be documented as part of the architecture, not just as a configuration of individual teams.\u003c/p\u003e\n\u003ch2 id=\"2-backend-pools-define-technical-responsibility-boundaries\"\u003e2. Backend Pools Define Technical Responsibility Boundaries\u003c/h2\u003e\n\u003cp\u003eA backend pool is more than a list of servers. It describes a group of backends that should process the same API traffic both functionally and operationally. A pool for \u003ccode\u003e/api/v1\u003c/code\u003e can, for example, be served by a different deployment than a pool for \u003ccode\u003e/api/v2\u003c/code\u003e. Public and administrative endpoints can also be separated.\u003c/p\u003e\n\u003cp\u003eThis separation affects scaling, release processes, and error patterns. If a pool for a new API version is scaled independently, it does not automatically influence the load of the old version. A faulty deployment remains limited to the assigned traffic, provided the routing rules do not create a common dependency.\u003c/p\u003e\n\u003cp\u003eHealth checks and failover complement this structure. They check whether backends are generally reachable and operational. However, they do not replace functional error handling: a backend can return HTTP 200 and still provide incorrect data. The edge decides on availability and forwarding, not on the correctness of the API response.\u003c/p\u003e\n\u003ch2 id=\"3-api-routing-must-align-with-versioning-and-releases\"\u003e3. API Routing Must Align with Versioning and Releases\u003c/h2\u003e\n\u003cp\u003eL7 routing is particularly suitable for controlled transitions between API versions or deployments. A path like \u003ccode\u003e/v1/\u003c/code\u003e can permanently point to a stable pool, while \u003ccode\u003e/v2/\u003c/code\u003e is forwarded to a new implementation. Alternatively, headers or hostnames can be used if versions or tenants should not be visible in the path.\u003c/p\u003e\n\u003cp\u003eIt is important not to confuse the routing decision with complete application logic. The edge can classify requests based on visible protocol characteristics. However, it should not take over functional authorization, complex tenant logic, or the consistency of business processes. These tasks remain within the API service.\u003c/p\u003e\n\u003cp\u003eEven with canary releases, clear boundaries are needed. A division based on a stable technical characteristic is more comprehensible than a multitude of hard-to-test special rules. If, for example, only certain headers are used for test access, clients, monitoring, and rollback processes must support this convention. Otherwise, the edge configuration itself becomes a hidden release system.\u003c/p\u003e\n\u003ch2 id=\"4-handover-to-the-backend-defines-the-operational-boundary\"\u003e4. Handover to the Backend Defines the Operational Boundary\u003c/h2\u003e\n\u003cp\u003eBetween edge and application, headers, TLS, and source information must be handled unambiguously. With TLS termination at the edge, the backend must be able to recognize that the original request was received over HTTPS. For logging, access control, and diagnostics, it is also relevant which client and proxy information is passed to the application.\u003c/p\u003e\n\u003cp\u003eProxy Protocol can supplement the connection between edge and backend with information about the original connection in suitable architectures. However, the backend must explicitly expect this protocol. An inconsistent configuration does not lead to a mere routing error but can prevent the connection establishment between edge and service.\u003c/p\u003e\n\u003cp\u003eBackend cloaking shifts public visibility entirely to the edge: clients do not need to know the internal backend addresses. This reduces the direct attack surface and prevents API clients from coupling to individual workload addresses. In the ayedo Edge Cloud, the public access is thus in front of the actual backends; the application remains responsible for the functional processing.\u003c/p\u003e\n\u003ch2 id=\"practice-two-api-versions-with-separate-pools\"\u003ePractice: Two API Versions with Separate Pools\u003c/h2\u003e\n\u003cp\u003eA company operates \u003ccode\u003e/api/v1\u003c/code\u003e and \u003ccode\u003e/api/v2\u003c/code\u003e in parallel. Both versions are accessible under the same hostname but differ in data model and scaling needs. A general forwarding to a common pool would shift version recognition to the application and complicate rollbacks.\u003c/p\u003e\n\u003cp\u003eInstead, a specific rule for \u003ccode\u003e/api/v2/*\u003c/code\u003e is evaluated before a more general rule for \u003ccode\u003e/api/v1/*\u003c/code\u003e. Both rules refer to separate backend pools. Health checks remove unreachable backends from the respective pool. A rollback of version 2 then only changes the assignment of this path, while version 1 remains unchanged. The edge controls the direction; authentication and functional validation remain in the APIs.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"what-characteristics-are-suitable-for-l7-routing\"\u003eWhat Characteristics Are Suitable for L7 Routing?\u003c/h3\u003e\n\u003cp\u003eTypical criteria include hostname, URL path, HTTP method, and selected headers. It is crucial that the characteristic is stable, comprehensible for clients, and visible for operations and monitoring.\u003c/p\u003e\n\u003ch3 id=\"does-l7-routing-replace-an-api-gateway-service\"\u003eDoes L7 Routing Replace an API Gateway Service?\u003c/h3\u003e\n\u003cp\u003eNo. L7 routing distributes requests. Functions such as functional authorization, transformations, or complex quota logic still belong in designated API or platform components.\u003c/p\u003e\n\u003ch3 id=\"when-is-a-common-backend-pool-sufficient\"\u003eWhen Is a Common Backend Pool Sufficient?\u003c/h3\u003e\n\u003cp\u003eA common pool may suffice if API versions, scaling profiles, and release cycles are identical. Once these properties differ, separate assignment usually creates clearer operational boundaries.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eL7 routing for APIs is primarily a matter of clear responsibility boundaries. Rules determine the direction, backend pools bundle similar operational requirements, and the handover defines what information a service receives. The ayedo Edge Cloud can centrally implement these decisions as a public entry point for HTTP and HTTPS services—regardless of whether the backends are operated in ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in their own cluster, or with another provider.\u003c/p\u003e\n",
      "summary": "\nTL;DR L7 routing distributes API requests not just by IP address or port, but based on application characteristics. Path, hostname, HTTP method, or headers can direct to different backend pools. Clear rules, defined priorities, and a clean boundary between edge routing and internal application logic are crucial.\nIntroduction A common backend pool for all API requests is easy to configure but quickly leads to unnecessary coupling. Versioned APIs, administrative endpoints, and public resources often have different scaling, security, and operational requirements. If they are indiscriminately forwarded to the same backends, the application itself must evaluate these differences.\n",
      "image": "https://ayedo.de/l7-routing-fur-apis-regeln-pools-und-backends.png",
      "date_published": "2026-09-08T17:04:59Z",
      "date_modified": "2026-09-08T17:04:59Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","development","kubernetes","cloud-native","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/",
      "url": "https://ayedo.de/en/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/",
      "title": "Anycast and Backend Failover in Active-Active Operations",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-und-backend-failover-im-aktiv-aktiv-betrieb/anycast-und-backend-failover-im-aktiv-aktiv-betrieb.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eActive-active failover is not achieved through a single mechanism but through the interplay of Anycast, distributed edge PoPs, robust health checks, and dynamic backend selection. When a backend fails, the edge must detect the state and distribute new connections to available backends without relying on a central primary path.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA common architectural mistake is equating Anycast with high availability. While a globally reachable IP address reduces dependency on a single entry point, it does not prevent application failure. Only when the edge continuously assesses the state of backends and aligns routing decisions accordingly does a resilient active-active operation emerge. Two levels work together: Anycast and distributed edge PoPs keep public access available, while backend failover manages traffic within the available application infrastructure. The quality of this architecture depends less on a single failover switch and more on error detection, the selection of suitable targets, and handling existing connections.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-distributes-entry-not-automatically-the-application\"\u003e1. Anycast Distributes Entry, Not Automatically the Application\u003c/h2\u003e\n\u003cp\u003eIn Anycast, the same IP address is announced by multiple geographically distributed network nodes. Internet routing typically directs packets to a reachable PoP deemed suitable from a network perspective. This means there is no single public entry point whose failure must block all traffic. A distributed edge can thus make access more robust against individual site or network path failures.\u003c/p\u003e\n\u003cp\u003eHowever, Anycast does not solve the question of whether the underlying backend is available. An edge PoP can be reachable while an application, cluster, or individual service returns errors. Similarly, a backend might be disrupted only for certain protocols or paths. High availability thus requires a second decision level: The edge must select a healthy backend for new connections. At ayedo, the Anycast-based edge with multiple distributed PoPs and active-active principle forms the entry level; backend failover then decides on the reachable application targets.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-are-the-foundation-for-backend-failover\"\u003e2. Health Checks Are the Foundation for Backend Failover\u003c/h2\u003e\n\u003cp\u003eBackend failover begins with the question of when a target is considered unavailable. A simple TCP check merely confirms that a port is reachable. For HTTP or HTTPS applications, it may also be relevant whether a defined endpoint returns the expected status. A check that is too superficial leaves faulty backends in the pool; a check that is too strict unnecessarily removes functioning targets from routing.\u003c/p\u003e\n\u003cp\u003eThe timing of the assessment is also crucial. Individual packet losses or brief response delays should not immediately lead to unstable switching. Conversely, detecting an actual failure must not take so long that further requests hit a defective target. Health checks should therefore match the application, protocol, and error domain. They must also distinguish between reachability and serviceability. For the ayedo Edge Cloud, backend health checks and failover are central components for dynamically directing traffic to available targets.\u003c/p\u003e\n\u003ch2 id=\"3-active-active-changes-the-failover-logic\"\u003e3. Active-Active Changes the Failover Logic\u003c/h2\u003e\n\u003cp\u003eIn active-active operations, multiple backends are intended for traffic simultaneously. Failover then does not primarily mean switching from an active to a passive server. Instead, the set of available targets is dynamically adjusted: A healthy backend remains in the pool, while a faulty one is no longer considered for new connections. Traffic is distributed across the remaining targets, provided they can handle the load.\u003c/p\u003e\n\u003cp\u003eThis reduces dependency on a defined primary path but places higher demands on the application. States must either be replicated, held externally, or treated so that requests can switch between backends. Database connections, sessions, and long-running streams also require separate consideration. Health checks mostly affect new connections; existing sessions may still break during a backend failure. Active-active is therefore not an automatic fix for stateful workloads but an architectural decision with implications for data management, capacity planning, and error handling.\u003c/p\u003e\n\u003ch2 id=\"4-error-domains-and-operational-boundaries-must-be-considered-separately\"\u003e4. Error Domains and Operational Boundaries Must Be Considered Separately\u003c/h2\u003e\n\u003cp\u003eA backend failure, an edge PoP failure, and an upstream routing error are different events. Backend failover can remove an unreachable application target from the pool. However, it cannot compensate for every disruption, such as when all backends are affected or a common data dependency fails. Conversely, Anycast can direct traffic to another edge PoP without changing the backend itself.\u003c/p\u003e\n\u003cp\u003eFor operations, this separation is important. Monitoring and incident response must reveal whether the error lies at the public entry, in the connection to the application, or within the backend itself. A distributed active-active architecture thus requires capacity reserves, consistent configurations, and traceable health check signals. The ayedo Edge Cloud\u0026rsquo;s own network infrastructure and autonomous system are relevant in this context because the edge is operated as a cohesive, distributed entry layer. However, they do not replace a resilient backend architecture.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers. Both clusters are active and accessible via the edge. A health check detects that the API service in one cluster accepts TCP connections but no longer successfully responds to the defined HTTP endpoint. The edge no longer considers this target for new connections and distributes traffic to the remaining backend. The public DNS or Anycast entry remains unchanged. At the same time, operators must check whether the remaining cluster has sufficient capacity and whether ongoing connections are terminated in a controlled manner. After recovery, the backend should not be fully loaded again based on a single successful check.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-anycast-alone-an-active-active-failover\"\u003eIs Anycast Alone an Active-Active Failover?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast distributes public access to reachable edge PoPs. Active-active failover additionally requires \u003ca href=\"/en/kubernetes/\"\u003ehealth checks\u003c/a\u003e\n and dynamic selection of healthy backends.\u003c/p\u003e\n\u003ch3 id=\"what-happens-to-existing-connections\"\u003eWhat Happens to Existing Connections?\u003c/h3\u003e\n\u003cp\u003eThis depends on the protocol and the error. Backend failover typically affects new connections. Existing sessions may break during a backend failure and may need to be re-established by the application.\u003c/p\u003e\n\u003ch3 id=\"can-backend-failover-compensate-for-database-failures\"\u003eCan Backend Failover Compensate for Database Failures?\u003c/h3\u003e\n\u003cp\u003eNo. It can keep traffic away from faulty application targets. Shared databases, replication, and state consistency remain separate requirements of the application and its infrastructure.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eHigh availability arises between edge and compute, not exclusively at one of these levels. Anycast and distributed PoPs make public access more resilient; \u003ca href=\"/en/kubernetes/\"\u003ehealth checks\u003c/a\u003e\n and backend failover ensure that new connections reach available application targets. The active-active principle avoids a single primary path but requires consistent backends and sufficient reserves. The ayedo Edge Cloud integrates these functions into its own distributed edge infrastructure—independently of where the Kubernetes or other backends are operated.\u003c/p\u003e\n",
      "summary": "\nTL;DR Active-active failover is not achieved through a single mechanism but through the interplay of Anycast, distributed edge PoPs, robust health checks, and dynamic backend selection. When a backend fails, the edge must detect the state and distribute new connections to available backends without relying on a central primary path.\nIntroduction A common architectural mistake is equating Anycast with high availability. While a globally reachable IP address reduces dependency on a single entry point, it does not prevent application failure. Only when the edge continuously assesses the state of backends and aligns routing decisions accordingly does a resilient active-active operation emerge. Two levels work together: Anycast and distributed edge PoPs keep public access available, while backend failover manages traffic within the available application infrastructure. The quality of this architecture depends less on a single failover switch and more on error detection, the selection of suitable targets, and handling existing connections.\n",
      "image": "https://ayedo.de/anycast-und-backend-failover-im-aktiv-aktiv-betrieb.png",
      "date_published": "2026-09-08T17:04:58Z",
      "date_modified": "2026-09-08T17:04:58Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/",
      "url": "https://ayedo.de/en/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/",
      "title": "Correctly Implementing Proxy Protocol in the Backend Pool",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/proxy-protocol-im-backend-pool-korrekt-einsetzen/proxy-protocol-im-backend-pool-korrekt-einsetzen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProxy Protocol transmits connection information from a proxy or load balancing layer to the backend. This allows applications to evaluate the original client IP and other transport data. Prerequisites include a coordinated protocol, compatible listeners, and consistent configuration across the entire backend pool.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eProxy Protocol is not an optional detail in load balancing but an integration contract between the edge and backend. When activated on the ayedo Edge Cloud, every target system in the corresponding backend pool expects the additional protocol line before the actual application communication. A standard TCP or HTTP listener cannot automatically interpret this data. The result can be rejected connections, incorrect client IP evaluation, or hard-to-trace differences between individual backends. Therefore, it is crucial not only whether Proxy Protocol is generally supported but whether the edge, protocol type, listener, and application share the same assumptions about the connection setup.\u003c/p\u003e\n\u003ch2 id=\"1-what-information-proxy-protocol-conveys\"\u003e1. What Information Proxy Protocol Conveys\u003c/h2\u003e\n\u003cp\u003eA proxy terminates the original TCP connection of the client and establishes a new connection to the backend. Without additional metadata, the backend initially sees the source address of the edge system. For access controls, rate limits, audit logs, or forensic analysis, this information may be insufficient.\u003c/p\u003e\n\u003cp\u003eProxy Protocol supplements the new connection with connection information from the original session. This typically includes source and destination addresses as well as the ports used. The backend can thus distinguish between the edge connection and the original client without having to derive this information from application-specific headers.\u003c/p\u003e\n\u003cp\u003eIt is important to differentiate from HTTP headers like \u003ccode\u003eX-Forwarded-For\u003c/code\u003e: Proxy Protocol operates at the transport layer and is therefore relevant for TCP services as well. However, it does not replace authentication and does not prove that the transmitted data comes from a trusted source. The backend should only accept Proxy Protocol on the designated, controlled entry.\u003c/p\u003e\n\u003ch2 id=\"2-the-backend-pool-as-a-protocol-contract\"\u003e2. The Backend Pool as a Protocol Contract\u003c/h2\u003e\n\u003cp\u003eActivating Proxy Protocol is a feature of the interaction between edge and backend pool. The ayedo Edge Cloud can forward connections via Proxy Protocol to backends. Whether these connections are successfully processed then depends on the listener of the respective target system.\u003c/p\u003e\n\u003cp\u003eA backend pool should therefore not only be modeled based on reachability, port, and health check. The expected connection form is also part of the pool definition. All targets of a pool must fulfill the same protocol contract: They must accept Proxy Protocol at the used listener and correctly pass the subsequent data to the service.\u003c/p\u003e\n\u003cp\u003eA common mistake is mixing incompatible targets. A pool might contain an Ingress configured for Proxy Protocol and additionally a direct TCP service. The load balancer can technically reach both targets, but only one understands the connection initiation. Health checks can be misleading if they use a different listener or testing methodology than the actual traffic. Protocol compatibility must therefore be explicitly tested.\u003c/p\u003e\n\u003ch2 id=\"3-protocol-compatibility-along-the-connection\"\u003e3. Protocol Compatibility Along the Connection\u003c/h2\u003e\n\u003cp\u003eProxy Protocol is transmitted before the actual payload. The receiving listener must recognize, process this information, and then pass the original data stream to the application. If the listener is designed exclusively for unaltered TLS, HTTP, or proprietary TCP data, it interprets the proxy header as invalid payload.\u003c/p\u003e\n\u003cp\u003eThis affects multiple layers: the external listener of the Ingress, a possible sidecar or reverse proxy, and the actual application process. Even a single incompatible intermediate component can terminate the connection. With TLS, it is particularly important that Proxy Protocol arrives before the TLS handshake and that the TLS listener supports this order. Proxy Protocol does not encrypt the metadata itself.\u003c/p\u003e\n\u003cp\u003eThe variant used must also match. The text-based and binary variants differ in structure and parser behavior. If an edge expects a variant that the listener does not support, there is no reliable fallback. Therefore, protocol variant, transport type, and listener behavior belong in the technical interface description of the service.\u003c/p\u003e\n\u003ch2 id=\"4-systematically-avoiding-operational-errors\"\u003e4. Systematically Avoiding Operational Errors\u003c/h2\u003e\n\u003cp\u003eThe most common errors arise from configuration changes without considering the entire pool. If Proxy Protocol is activated at the edge but only part of the backends are adjusted, outages initially appear as random health or network problems. In reality, availability then depends on which target the load balancer selects.\u003c/p\u003e\n\u003cp\u003eFor operations, separate pools with clear protocol behavior are usually more robust than a mixed pool. Migrations should proceed step-by-step: first provide a compatible listener, then test with realistic connections, and only then add more targets. Logs must make the connection setup at the listener, the recognized client address, and possible parser errors visible.\u003c/p\u003e\n\u003cp\u003eSpecial attention should be paid to the trust boundary. A backend should only use the source address contained in Proxy Protocol for security decisions if only known edge paths can reach this listener. If the same port is directly accessible from the internet or uncontrolled networks, an attacker can inject false connection information. Proxy Protocol thus improves transparency but does not replace network segmentation and access control.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an HTTPS service on \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n and a TCP-based legacy service on virtual machines. Both should be accessible via the ayedo Edge Cloud. For the HTTPS service, an Ingress is used whose listener understands Proxy Protocol. The legacy service, on the other hand, continues to use a standard TCP listener.\u003c/p\u003e\n\u003cp\u003eIt would be wrong to manage both target systems in a common backend pool: the ayedo Edge Cloud would deliver the same connection setup to different listeners. Instead, separate pools with appropriate protocol agreements are defined. The HTTPS pool processes Proxy Protocol up to the compatible Ingress; the legacy pool only receives connections whose target system actually supports the agreed transport. A separate health check per pool additionally checks the correct listener and not just the host\u0026rsquo;s reachability.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-proxy-protocol-only-relevant-for-http-services\"\u003eIs Proxy Protocol only relevant for HTTP services?\u003c/h3\u003e\n\u003cp\u003eNo. Proxy Protocol operates at the transport layer and can also provide TCP services with original connection information. However, the respective listener must explicitly support the protocol.\u003c/p\u003e\n\u003ch3 id=\"can-proxy-protocol-be-replaced-by-http-headers\"\u003eCan Proxy Protocol be replaced by HTTP headers?\u003c/h3\u003e\n\u003cp\u003eIn HTTP, forwarding headers can transmit client information. However, this is not equivalent for TCP services and requires trust in the header chain. Proxy Protocol lies below the application layer.\u003c/p\u003e\n\u003ch3 id=\"why-do-health-checks-work-despite-faulty-proxy-protocol\"\u003eWhy do health checks work despite faulty Proxy Protocol?\u003c/h3\u003e\n\u003cp\u003eA health check can use a different port, listener, or connection setup than the productive traffic. Reachability alone does not confirm that the backend service processes Proxy Protocol correctly.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eProxy Protocol is a clearly definable integration point between edge proxy and backend service. The technical question is not only whether client IP information is needed, but which listener processes it in which form and under what trust boundary. In the ayedo Edge Cloud, this decision is part of the backend pool coordination. Cleanly separated pools, compatible listeners, and appropriate health checks prevent a small protocol deviation from becoming an intermittent operational problem.\u003c/p\u003e\n",
      "summary": "\nTL;DR Proxy Protocol transmits connection information from a proxy or load balancing layer to the backend. This allows applications to evaluate the original client IP and other transport data. Prerequisites include a coordinated protocol, compatible listeners, and consistent configuration across the entire backend pool.\nIntroduction Proxy Protocol is not an optional detail in load balancing but an integration contract between the edge and backend. When activated on the ayedo Edge Cloud, every target system in the corresponding backend pool expects the additional protocol line before the actual application communication. A standard TCP or HTTP listener cannot automatically interpret this data. The result can be rejected connections, incorrect client IP evaluation, or hard-to-trace differences between individual backends. Therefore, it is crucial not only whether Proxy Protocol is generally supported but whether the edge, protocol type, listener, and application share the same assumptions about the connection setup.\n",
      "image": "https://ayedo.de/proxy-protocol-im-backend-pool-korrekt-einsetzen.png",
      "date_published": "2026-09-08T17:04:58Z",
      "date_modified": "2026-09-08T17:04:58Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","compliance","kubernetes","cloud-native","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/netzwerk-routing-und-application-routing-trennen/",
      "url": "https://ayedo.de/en/posts/netzwerk-routing-und-application-routing-trennen/",
      "title": "Separating Network Routing and Application Routing",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/netzwerk-routing-und-application-routing-trennen/netzwerk-routing-und-application-routing-trennen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eNetwork routing and application routing solve different problems. Anycast and Layer 4 determine how traffic reaches an edge entry and to which transport destination it proceeds. In contrast, Layer 7 decides based on hostnames, paths, or HTTP properties which service processes the request. These layers must be modeled separately to keep architecture, operations, and troubleshooting manageable.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA common architectural mistake is to consider a request from the public network path to the backend as a single routing decision. This mixes Anycast, Layer 4 forwarding, and application-specific rules. This not only complicates troubleshooting: Security rules, health checks, and failovers also apply in places where they cannot reliably take effect.\u003c/p\u003e\n\u003cp\u003eIn an edge architecture, it should be clear which decision is made based on network and transport information and which is possible only after protocol termination. Anycast determines the reachable edge entry. Layer 4 works with IP addresses, ports, and transport protocols. Application routing on Layer 7, on the other hand, understands hostnames, paths, and HTTP services. This separation is the foundation for predictable operational models.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-and-layer-4-determine-the-transport-path\"\u003e1. Anycast and Layer 4 Determine the Transport Path\u003c/h2\u003e\n\u003cp\u003eAnycast is initially a decision at the network level. Multiple edge locations or PoPs can announce the same IP address. Internet routing directs a request to a suitable reachable entry point. However, it does not decide which application or specific service processes the request. Anycast primarily answers the question: Where does the traffic enter the edge infrastructure?\u003c/p\u003e\n\u003cp\u003eLayer 4 builds on this transport path. The decision is based on information such as destination IP, port, and transport protocol, such as TCP or UDP. A Layer 4 listener can, for example, forward incoming connections on port 443 to a defined backend pool without evaluating the HTTP content of the connection.\u003c/p\u003e\n\u003cp\u003eThis separation has operational consequences. Changes to IP or port structures affect the transport path, while the application may remain unchanged. Conversely, a new HTTP route can be introduced without altering the Anycast or Layer 4 model. The ayedo Edge Cloud combines Anycast with Layer 4 and Layer 7 load balancing, providing both control layers within an edge platform.\u003c/p\u003e\n\u003ch2 id=\"2-application-routing-begins-with-the-application-protocol\"\u003e2. Application Routing Begins with the Application Protocol\u003c/h2\u003e\n\u003cp\u003eApplication routing becomes necessary when forwarding depends on application characteristics. For HTTP and HTTPS, these can be hostnames like \u003ccode\u003eapi.example.com\u003c/code\u003e, paths like \u003ccode\u003e/checkout\u003c/code\u003e, or properties of a request. A Layer 7 router can thus distinguish multiple virtual services over a common public entry.\u003c/p\u003e\n\u003cp\u003eThe process is logically separated: First, the connection reaches the edge via Anycast and the appropriate transport port. Then the application protocol is evaluated. For HTTPS, TLS can be terminated at the edge so that hostname, path, and other HTTP features are available for the routing decision. The request is then distributed to the appropriate backend service.\u003c/p\u003e\n\u003cp\u003eThis layer is also suitable for a clear separation of APIs, web applications, and individual services. However, it does not replace network routing. A path can only be evaluated if the connection reaches the correct edge entry and the protocol allows it. Application routing is therefore not an alternative term for Anycast but a downstream control layer with a different information model and different operational risks.\u003c/p\u003e\n\u003ch2 id=\"3-separate-layers-improve-security-and-troubleshooting\"\u003e3. Separate Layers Improve Security and Troubleshooting\u003c/h2\u003e\n\u003cp\u003eThe distinction between network routing and application routing directly impacts security and incident response. DDoS protection or a Layer 4 filter operates at a different point than a web application firewall that checks HTTP requests for application patterns. If these functions are mentally mixed, it is unclear whether a problem lies at the edge entry, the transport connection, or the application route.\u003c/p\u003e\n\u003cp\u003eBackend cloaking also follows this principle. The backend does not need to appear as a publicly reachable routing target if the public entry is provided by the edge. The edge can accept connections, terminate TLS, apply rules, and then forward the traffic to a protected backend. Layer 7 rules decide on the target application; network and transport mechanisms provide the connection to it.\u003c/p\u003e\n\u003cp\u003eFor operations, metrics and logs should represent these layers separately: Reachability of the Anycast entry, connection errors on Layer 4, rule decisions on Layer 7, and the state of the backends. Health checks and failovers must also match the respective model. A reachable TCP port, for example, does not prove that a specific API path is working correctly.\u003c/p\u003e\n\u003ch2 id=\"4-separation-facilitates-multi-cloud-and-kubernetes-architectures\"\u003e4. Separation Facilitates Multi-Cloud and Kubernetes Architectures\u003c/h2\u003e\n\u003cp\u003eIn distributed environments, backends change more frequently than the public entry. Kubernetes services can be moved, new clusters connected, or workloads operated with different providers. If public IPs, transport ports, and application-specific routes are tightly coupled to a single cluster, such changes become operationally complex.\u003c/p\u003e\n\u003cp\u003eA separate application routing model keeps public access more stable. Hostnames and paths can be bound to backend pools or services while their concrete infrastructure changes in the background. This is particularly relevant when multiple \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters or providers are involved. The Kubernetes-native integration of the ayedo Edge Cloud can be used with ayedo Managed Kubernetes as well as with self-managed or provider-operated clusters.\u003c/p\u003e\n\u003cp\u003eThe platform thus remains separate from the compute location: The edge handles public traffic entry, routing, protection, and load distribution; the compute infrastructure executes the workloads. Own network infrastructure, own autonomous system, and an active-active architecture are relevant in this context because they anchor the edge entry and its operation as an independent domain of responsibility. However, they do not make Layer 7 rules superfluous.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a web application and an API in two Kubernetes clusters. Both use a common public HTTPS entry. Anycast directs the traffic to a reachable edge PoP. Layer 4 accepts TCP connections on port 443. Only after TLS termination does Layer 7 decide: \u003ccode\u003ewww.example.com\u003c/code\u003e is directed to the web application, \u003ccode\u003eapi.example.com/v1\u003c/code\u003e to the API.\u003c/p\u003e\n\u003cp\u003eIf an API backend fails, a health check at the pool or service level takes effect. The Anycast entry does not need to be changed. If the entire logic were modeled only via network addresses, separate public endpoints or manual switches would be more likely. The example shows: The transport path can remain stable while the application-specific target changes.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-anycast-already-application-routing\"\u003eIs Anycast Already Application Routing?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast determines the reachable network entry based on the internet\u0026rsquo;s routing logic. Application routing then evaluates application-specific information such as hostnames or paths.\u003c/p\u003e\n\u003ch3 id=\"when-is-layer-4-sufficient\"\u003eWhen Is Layer 4 Sufficient?\u003c/h3\u003e\n\u003cp\u003eLayer 4 is sufficient when forwarding based on IP, port, and transport protocol is enough. This is relevant, for example, for non-HTTP-based services or TCP passthrough.\u003c/p\u003e\n\u003ch3 id=\"why-should-tls-be-terminated-at-the-edge\"\u003eWhy Should TLS Be Terminated at the Edge?\u003c/h3\u003e\n\u003cp\u003eTLS termination at the edge enables the evaluation of HTTP information for Layer 7 routing and web application firewall. Without termination, such decisions are limited at the public entry.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eNetwork routing and application routing should be modeled as separate but interdependent control layers. Anycast and Layer 4 secure the transport path to the edge entry; Layer 7 then assigns requests to specific applications or services. In this model, the ayedo Edge Cloud is not merely a forwarding layer but an independent edge platform in front of changing backends and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments.\u003c/p\u003e\n",
      "summary": "\nTL;DR Network routing and application routing solve different problems. Anycast and Layer 4 determine how traffic reaches an edge entry and to which transport destination it proceeds. In contrast, Layer 7 decides based on hostnames, paths, or HTTP properties which service processes the request. These layers must be modeled separately to keep architecture, operations, and troubleshooting manageable.\nIntroduction A common architectural mistake is to consider a request from the public network path to the backend as a single routing decision. This mixes Anycast, Layer 4 forwarding, and application-specific rules. This not only complicates troubleshooting: Security rules, health checks, and failovers also apply in places where they cannot reliably take effect.\n",
      "image": "https://ayedo.de/netzwerk-routing-und-application-routing-trennen.png",
      "date_published": "2026-09-08T17:04:58Z",
      "date_modified": "2026-09-08T17:04:58Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","security","kubernetes","cloud-native","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/tls-termination-an-der-edge-routing-sicher-gestalten/",
      "url": "https://ayedo.de/en/posts/tls-termination-an-der-edge-routing-sicher-gestalten/",
      "title": "TLS Termination at the Edge: Designing Secure Routing",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/tls-termination-an-der-edge-routing-sicher-gestalten/tls-termination-an-der-edge-routing-sicher-gestalten.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eTLS Termination ends the external HTTPS connection at the edge, creating the technical handover point for application-specific routing. This enables host, path, and header rules. However, the architecture must clearly define which security and routing tasks the edge handles and what control remains with the backend.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eTLS Termination is not merely a performance or convenience feature. It changes the point at which encrypted client traffic becomes visible, can be inspected, and distributed based on Layer-7 characteristics. A common architectural mistake is to end HTTPS at the edge without defining a clear separation between edge routing and backend responsibility. This can lead to unclear trust boundaries, conflicting routing rules, or unnecessary dependencies on specific infrastructures. Therefore, it is crucial not only to determine \u003cem\u003ewhere\u003c/em\u003e TLS ends but also to evaluate what information is processed there and how traffic is subsequently controlled when handed over to applications and APIs.\u003c/p\u003e\n\u003ch2 id=\"1-tls-termination-creates-a-controlled-handover-point\"\u003e1. TLS Termination Creates a Controlled Handover Point\u003c/h2\u003e\n\u003cp\u003eIn a TLS connection, the client encrypts HTTP traffic up to the termination point. When TLS Termination occurs at the edge, the external connection is accepted there, the TLS handshake is performed, and the request is made accessible for further processing. Only then can HTTP attributes like hostname, path, method, or specific headers be used for Layer-7 routing.\u003c/p\u003e\n\u003cp\u003eArchitecturally, this creates a clear handover: The edge is responsible for public access, TLS processing, and initial traffic management. The backend does not need to represent the entire public HTTPS entry itself. This separation reduces the number of directly exposed components and supports backend cloaking, as internal target systems do not have to appear as public endpoints.\u003c/p\u003e\n\u003cp\u003eHowever, the edge becomes a security-relevant trust boundary. Certificate management, allowed protocols, routing rules, and the handling of forwarded request information must be considered together. TLS Termination is therefore an architectural decision about responsibilities, not just a setting on the load balancer.\u003c/p\u003e\n\u003ch2 id=\"2-layer-7-routing-requires-robust-decision-rules\"\u003e2. Layer-7 Routing Requires Robust Decision Rules\u003c/h2\u003e\n\u003cp\u003eAfter TLS Termination, the edge can implement HTTPS routing at the application level. Typical rules differentiate between multiple hostnames, API paths, or versions of a service. For instance, \u003ccode\u003eapi.example.de\u003c/code\u003e can lead to a different backend than \u003ccode\u003eapp.example.de\u003c/code\u003e; similarly, \u003ccode\u003e/v1\u003c/code\u003e can be treated separately from \u003ccode\u003e/v2\u003c/code\u003e. Layer-7 rules thus connect the public entry point with the logical structure of the applications.\u003c/p\u003e\n\u003cp\u003eThis flexibility increases complexity, however. Routing should not rely on randomly varying headers, implicit sequences, or hard-to-understand exceptions. Deterministic rules with clear priorities, documented fallbacks, and defined behavior for unknown hosts or paths are sensible. Otherwise, new services may inadvertently become accessible through existing rules.\u003c/p\u003e\n\u003cp\u003eFor operations, it is also important that the edge considers the state of the backends. Health checks and failover prevent traffic from being permanently directed to unavailable targets. The ayedo Edge Cloud combines TLS Termination with Layer-4 and Layer-7 load balancing as well as backend health checks. This treats routing not as static forwarding but as a controlled part of the public traffic entry.\u003c/p\u003e\n\u003ch2 id=\"3-the-tls-path-to-the-backend-must-be-deliberately-defined\"\u003e3. The TLS Path to the Backend Must Be Deliberately Defined\u003c/h2\u003e\n\u003cp\u003eWith the end of the client TLS connection, communication is not automatically equally protected on every segment. Between the edge and backend, a new encrypted connection or another secured transport path may be required, depending on the target architecture. This decision depends on protection needs, network segmentation, compliance requirements, and the capabilities of the downstream platform.\u003c/p\u003e\n\u003cp\u003eIt is important to clearly distinguish between the external and internal identity of a request. The backend must be able to recognize whether a request originally came in over HTTPS, which hostname it addressed, and under which path it was routed. Such information should not be indiscriminately adopted from arbitrary client headers. They must be consistently set, validated at the trust boundary, and appropriately evaluated in the backend.\u003c/p\u003e\n\u003cp\u003eThe source address also deserves attention. For logging, rate limiting, or security analyses, the original client IP may be relevant. Techniques like Proxy Protocol can transport this information, provided the backend side processes it securely and correctly. The key remains: The edge defines the handover, and the backend must correctly handle the handed-over metadata within its trust zone.\u003c/p\u003e\n\u003ch2 id=\"4-edge-and-backend-need-separate-responsibilities\"\u003e4. Edge and Backend Need Separate Responsibilities\u003c/h2\u003e\n\u003cp\u003eThe edge should manage public traffic entry but not replace the application\u0026rsquo;s business logic. It decides which backend a request reaches, can secure access, and reject faulty or unwanted patterns before they reach the application. The backend remains responsible for authentication, authorization, business logic, and functional validation.\u003c/p\u003e\n\u003cp\u003eThis separation directly impacts operations. Routing changes, failover, and the distribution of incoming load can be organized independently of the deployment of individual applications. At the same time, edge rules must not become a second, uncoordinated configuration system alongside ingress or gateway configurations in the cluster. Responsibilities, change processes, and rollback procedures must therefore be established.\u003c/p\u003e\n\u003cp\u003eThis also applies to \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n: The integration of the edge can be done with ayedo Managed Kubernetes, but also with clusters operated independently or by other providers. The edge remains an independent platform for public access, TLS Termination, and traffic management. This provider-independent usage prevents HTTPS routing from being automatically tied to the lifecycle of a specific compute cluster.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-two-applications-one-public-entry\"\u003ePractical Scenario: Two Applications, One Public Entry\u003c/h2\u003e\n\u003cp\u003eA company operates a web application and an API in separate Kubernetes clusters. Both should be accessible under a common domain. TLS is terminated at the edge. A Layer-7 rule directs \u003ccode\u003e/api\u003c/code\u003e to the API backend, while all other paths go to the web application. If the API backend fails, its health checks and failover rules take effect without altering the web application\u0026rsquo;s routing.\u003c/p\u003e\n\u003cp\u003eThe backends remain not directly publicly addressable. For log evaluation and access controls, the relevant origin information is passed in a controlled manner. The clusters can be operated or replaced independently, while the public TLS endpoint and the basic routing structure remain at the edge.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-tls-always-have-to-be-continuous-to-the-backend\"\u003eDoes TLS always have to be continuous to the backend?\u003c/h3\u003e\n\u003cp\u003eNot necessarily. The appropriate transport security between edge and backend depends on protection needs, network architecture, and trust boundaries. It must be explicitly defined and technically implemented.\u003c/p\u003e\n\u003ch3 id=\"what-information-is-suitable-for-layer-7-routing\"\u003eWhat information is suitable for Layer-7 routing?\u003c/h3\u003e\n\u003cp\u003eTypical criteria are hostname, path, and HTTP method. Rules should be stable, understandable, and prioritized. Random or unchecked headers are problematic as a routing basis.\u003c/p\u003e\n\u003ch3 id=\"does-tls-termination-replace-application-security\"\u003eDoes TLS Termination replace application security?\u003c/h3\u003e\n\u003cp\u003eNo. The edge protects and manages public access. Authentication, authorization, input validation, and business logic remain the responsibilities of the application or its backend services.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eTLS Termination at the edge is an architectural handover point: From the encrypted public connection, it leads to controlled Layer-7 routing and defined backend responsibilities. Those who design this boundary cleanly can combine public accessibility, backend cloaking, and provider-independent operation. The ayedo Edge Cloud is not merely a pre-configured load balancer in this model but the platform for TLS processing, traffic entry, and structured handover to different compute environments.\u003c/p\u003e\n",
      "summary": "\nTL;DR TLS Termination ends the external HTTPS connection at the edge, creating the technical handover point for application-specific routing. This enables host, path, and header rules. However, the architecture must clearly define which security and routing tasks the edge handles and what control remains with the backend.\nIntroduction TLS Termination is not merely a performance or convenience feature. It changes the point at which encrypted client traffic becomes visible, can be inspected, and distributed based on Layer-7 characteristics. A common architectural mistake is to end HTTPS at the edge without defining a clear separation between edge routing and backend responsibility. This can lead to unclear trust boundaries, conflicting routing rules, or unnecessary dependencies on specific infrastructures. Therefore, it is crucial not only to determine where TLS ends but also to evaluate what information is processed there and how traffic is subsequently controlled when handed over to applications and APIs.\n",
      "image": "https://ayedo.de/tls-termination-an-der-edge-routing-sicher-gestalten.png",
      "date_published": "2026-09-08T17:04:58Z",
      "date_modified": "2026-09-08T17:04:58Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","operations","kubernetes","cloud-native","development"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/anycast-im-traffic-management-routing-bis-zum-backend/",
      "url": "https://ayedo.de/en/posts/anycast-im-traffic-management-routing-bis-zum-backend/",
      "title": "Anycast in Traffic Management: Routing to the Backend",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-im-traffic-management-routing-bis-zum-backend/anycast-im-traffic-management-routing-bis-zum-backend.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast Traffic Management starts with a globally reachable entry point but doesn\u0026rsquo;t end at the nearest edge location. Anycast \u003ca href=\"/en/kubernetes/\"\u003erouting\u003c/a\u003e\n directs traffic to an edge instance; there, Layer-4 and Layer-7 rules determine backend pools, health status, and, if necessary, application routing. Only this separation creates a controllable path to the application.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eAnycast is often understood as the answer to which location receives a request. For robust traffic management, this view is too narrow. The network first determines at which edge point a packet is processed. Only then are decisions made about protocol, hostname, path, port, backend pool, and failover. Equating Anycast \u003ca href=\"/en/kubernetes/\"\u003erouting\u003c/a\u003e\n directly with application routing mixes two different control levels and complicates operations and troubleshooting. An edge architecture must therefore make the path from the public entry point to the specific backend traceable. This is precisely where the technical value of Anycast in the ayedo Edge Cloud lies: as an entry into a distributed, active-active traffic management platform.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-is-the-global-network-entry\"\u003e1. Anycast is the Global Network Entry\u003c/h2\u003e\n\u003cp\u003eWith Anycast, multiple edge locations announce the same IP address via routing. A client thus addresses not a single server but a distributed service. Internet routing directs the traffic to an announcement point suitable from a network perspective. This selection is based on routing information and network topology, not automatically on the physically shortest distance or the currently best application latency.\u003c/p\u003e\n\u003cp\u003eFor operations, this distinction is important. Anycast \u003ca href=\"/en/kubernetes/\"\u003erouting\u003c/a\u003e\n determines where a connection enters the edge. It does not yet decide which backend processes the request. If an edge location or a route fails, other announcement points can keep the public service accessible. This requires a consistent address and routing architecture. The ayedo Edge Cloud uses its own Autonomous System and network infrastructure in a distributed Multi-PoP architecture. The active-active principle prevents a single location from becoming the implicit central entry point.\u003c/p\u003e\n\u003ch2 id=\"2-from-edge-acceptance-to-controlled-path\"\u003e2. From Edge Acceptance to Controlled Path\u003c/h2\u003e\n\u003cp\u003eAfter entering the edge, traffic is not simply forwarded to any available server. The edge first processes it at the appropriate level: Layer 4 for connection-oriented traffic management or Layer 7 for HTTP and HTTPS requests. Depending on the service, TLS termination, WAF checks, or additional routing conditions may be relevant. These functions change the character of the public entry: The edge is not just a transit point but a controlled processing layer.\u003c/p\u003e\n\u003cp\u003eThe path to the backend is thus decoupled from the public network topology. Backends do not need to be globally announced themselves and can remain hidden from the internet. Backend cloaking reduces the direct attack and dependency surface but does not replace clean segmentation or application security. Proxy Protocol can be used for passing connection information, provided the backend supports this handover. The Edge Cloud thus bundles network entry, protection, and forwarding while the application continues to operate in a separate compute infrastructure.\u003c/p\u003e\n\u003ch2 id=\"3-backend-pools-connect-routing-with-operational-state\"\u003e3. Backend Pools Connect Routing with Operational State\u003c/h2\u003e\n\u003cp\u003eAssignment to a backend typically occurs via pools. A pool groups suitable backends for a service; health checks provide the operational state, based on which the edge considers available targets. This turns the global Anycast entry into a specific forwarding path. If a backend fails, traffic can be redistributed within the pool or directed to another pool or failover path.\u003c/p\u003e\n\u003cp\u003eThis logic is to be distinguished from Anycast \u003ca href=\"/en/kubernetes/\"\u003erouting\u003c/a\u003e\n. Anycast decides on the edge entry, health checks, and pool rules on the forwarding behind it. Both levels must still match: An accessible edge point could otherwise send traffic to a completely failed backend pool. For SRE and platform teams, this means observing routing, pool state, and backend errors separately. Traffic and usage statistics help verify the actually used paths and avoid misconceptions about reachability or load.\u003c/p\u003e\n\u003ch2 id=\"4-application-routing-begins-only-behind-the-network\"\u003e4. Application Routing Begins Only Behind the Network\u003c/h2\u003e\n\u003cp\u003eApplication routing operates on a different abstraction level than Anycast. A DNS name or an Anycast IP brings the request to the edge. Only there can HTTP attributes like hostname, URL path, or other application-related criteria influence the selection of a backend pool. In contrast, connection parameters like IP address and port are at the forefront for Layer-4 services. Therefore, the specific routing logic must match the protocol and application.\u003c/p\u003e\n\u003cp\u003eThis separation is also relevant for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. A cluster can be operated with ayedo Managed Kubernetes, in its own environment, or with another provider. The Edge Cloud remains the public entry and assigns traffic to suitable backend pools; the Kubernetes service remains part of the compute and application layer. This prevents application routing from being tied to a single cluster or provider. At the same time, responsibilities must be clearly documented: The edge decides on the external path, the application on internal service and request logic.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two Kubernetes clusters with different providers. Both clusters are published via the same Anycast IP. Anycast \u003ca href=\"/en/kubernetes/\"\u003erouting\u003c/a\u003e\n directs client connections to an edge point. After TLS termination and a Layer-7 rule for the API host, the edge selects the appropriate backend pool. Health checks mark faulty targets; in case of a failure, traffic can switch to the available pool of the second cluster.\u003c/p\u003e\n\u003cp\u003eIn this model, the public address remains stable, even though the compute assignment changes. A purely DNS-based method would additionally depend on cache times and resolver behavior. Direct backend access, on the other hand, would publicly expose the clusters and their providers. Anycast, pool selection, and application routing each fulfill a clearly separated task here.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-anycast-automatically-the-fastest-way-to-the-backend\"\u003eIs Anycast automatically the fastest way to the backend?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast determines the edge entry based on internet routing. The backend assignment is then made by edge rules, pool logic, and health checks.\u003c/p\u003e\n\u003ch3 id=\"can-anycast-replace-application-routing\"\u003eCan Anycast replace application routing?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast operates at the network level. Application routing evaluates, for example, hostnames or URL paths and typically occurs only at the Layer-7-capable edge.\u003c/p\u003e\n\u003ch3 id=\"do-all-backends-need-to-be-operated-at-the-same-location\"\u003eDo all backends need to be operated at the same location?\u003c/h3\u003e\n\u003cp\u003eNo. Backend pools can group suitable targets in different compute environments. What matters are reachability, protocol compatibility, and the configured operational state.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eAnycast Traffic Management is not a single routing decision but a chain of clearly separated levels: The network leads to the edge, the edge processes and protects the traffic, and pool and application routing determine the specific backend. This separation improves troubleshooting, failover, and provider independence. The ayedo Edge Cloud forms the public, active-active entry in front of different compute environments—not as a replacement for the application, but as controlled mediation to it.\u003c/p\u003e\n",
      "summary": "\nTL;DR Anycast Traffic Management starts with a globally reachable entry point but doesn\u0026rsquo;t end at the nearest edge location. Anycast routing directs traffic to an edge instance; there, Layer-4 and Layer-7 rules determine backend pools, health status, and, if necessary, application routing. Only this separation creates a controllable path to the application.\nIntroduction Anycast is often understood as the answer to which location receives a request. For robust traffic management, this view is too narrow. The network first determines at which edge point a packet is processed. Only then are decisions made about protocol, hostname, path, port, backend pool, and failover. Equating Anycast routing directly with application routing mixes two different control levels and complicates operations and troubleshooting. An edge architecture must therefore make the path from the public entry point to the specific backend traceable. This is precisely where the technical value of Anycast in the ayedo Edge Cloud lies: as an entry into a distributed, active-active traffic management platform.\n",
      "image": "https://ayedo.de/anycast-im-traffic-management-routing-bis-zum-backend.png",
      "date_published": "2026-09-08T17:04:57Z",
      "date_modified": "2026-09-08T17:04:57Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/",
      "url": "https://ayedo.de/en/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/",
      "title": "L4 or L7: Traffic Management in the Edge Cloud",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l4-oder-l7-traffic-management-in-der-edge-cloud/l4-oder-l7-traffic-management-in-der-edge-cloud.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eL4 and L7 load balancing address different tasks. Layer 4 routes connections based on IP, port, and transport protocol without evaluating application content. Layer 7 understands HTTP or HTTPS and enables routing based on hostname, path, or other request characteristics. The decision impacts TLS processing, backend pools, and operational effort.\u003c/p\u003e\n\u003cp\u003eA common mistake is to operate every application with Layer 7 rules. This increases protocol complexity and shifts additional responsibility to the edge, even though many TCP or UDP services only require reliable transport routing. Conversely, a purely Layer 4 model is inadequate when multiple applications share a public address or requests need to reach different backends based on HTTP characteristics.\u003c/p\u003e\n\u003ch2 id=\"1-layer-4-transport-routing-without-application-awareness\"\u003e1. Layer 4: Transport Routing Without Application Awareness\u003c/h2\u003e\n\u003cp\u003eLayer 4 routing operates at the level of IP and transport protocol. The edge knows, for example, the destination port and connection state, but not the HTTP method, URL path, or headers. It distributes TCP or UDP connections to an appropriate backend pool, leaving the application to handle the actual protocol processing.\u003c/p\u003e\n\u003cp\u003eThis approach is suitable for services where the connection should be forwarded as a whole: for example, for non-HTTP-based protocols, TLS passthrough, or applications where routing is already handled in the backend. Even if all requests of a service belong to the same pool, additional protocol knowledge is not required.\u003c/p\u003e\n\u003cp\u003eThe operational advantage lies in the reduced coupling between the edge and the application. Changes to URL structures or HTTP headers do not affect traffic management. At the same time, possibilities like WAF inspection or content-based forwarding are excluded. Layer 4 is therefore not \u0026ldquo;less professional,\u0026rdquo; but an appropriate level of abstraction for transport routing.\u003c/p\u003e\n\u003ch2 id=\"2-layer-7-routing-based-on-the-application\"\u003e2. Layer 7: Routing Based on the Application\u003c/h2\u003e\n\u003cp\u003eLayer 7 routing requires that the edge understands the application protocol being used. With HTTP and HTTPS, rules can consider hostnames, paths, or other request properties. This allows multiple applications to be operated behind a public address or different API versions to be specifically routed to separate backend pools.\u003c/p\u003e\n\u003cp\u003eHowever, this flexibility changes the distribution of responsibilities. The edge becomes part of the HTTP processing and must correctly terminate, inspect, and forward requests. With HTTPS, TLS processing is particularly relevant: for content-based rules, encrypted traffic must be decrypted at the edge. The ayedo Edge Cloud supports TLS termination at the edge and can additionally protect HTTP/HTTPS services with a Web Application Firewall.\u003c/p\u003e\n\u003cp\u003eLayer 7 thus creates more control options but also more dependencies. Changes to routing rules, certificates, or security policies can immediately affect public access. Therefore, rule sets should be versioned, tested, and clearly assigned to the responsible teams.\u003c/p\u003e\n\u003ch2 id=\"3-tls-determines-the-boundary-between-l4-and-l7\"\u003e3. TLS Determines the Boundary Between L4 and L7\u003c/h2\u003e\n\u003cp\u003eThe decision between Layer 4 and Layer 7 is closely linked to the handling of TLS. With TLS passthrough, the edge routes encrypted connections without reading the HTTP content. The backend remains responsible for the certificate, decryption, and application-specific processing. For simple forwarding or specific protocol requirements, this can be the cleaner architecture.\u003c/p\u003e\n\u003cp\u003eIf the edge is to route based on HTTP paths or other request characteristics, it must be able to process the content. TLS termination at the edge ends the external TLS connection there; subsequently, the request is forwarded within the defined backend communication. This shifts the security and operational boundary: certificate management, encryption, and protection mechanisms are at least partially in front of the backend.\u003c/p\u003e\n\u003cp\u003eThis is not automatically better. TLS termination centralizes functions and enables consistent L7 rules but increases the significance of the edge as a trusted control instance. Companies must determine which data may be processed there and how the connection to the application remains secure.\u003c/p\u003e\n\u003ch2 id=\"4-backend-pools-health-checks-and-operational-consequences\"\u003e4. Backend Pools, Health Checks, and Operational Consequences\u003c/h2\u003e\n\u003cp\u003eThe choice of layer influences how backend pools are formed and monitored. With Layer 4, the focus is typically on the availability of a service or port. Layer 7 can additionally map application-related health checks and different pools for hosts, paths, or API areas. This allows failures to be handled more specifically, provided the routing logic actually fits the application.\u003c/p\u003e\n\u003cp\u003eHowever, with multiple L7 pools, the number of states that must remain traceable in operation increases: routing rules, certificates, health checks, failover behavior, and the assignment to the respective deployments. A faulty path match can then make part of the application unreachable, even though all backends are technically healthy.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud combines Anycast-based Layer 4 and Layer 7 load balancing with backend health checks and failover. This allows public traffic distribution to be organized independently of the compute platform – even with \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n operated on one\u0026rsquo;s own or by other providers. Backend cloaking separates the public access layer from the internally operated endpoints. It remains crucial to model pools and rules according to the actual application topology.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePractical and Decision Scenario\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eA company operates a TCP-based service and an HTTP API. The TCP service should forward encrypted connections unchanged to a pool; TLS processing remains in the backend. Here, Layer 4 is sufficient and avoids unnecessary application dependency. The API, on the other hand, uses \u003ccode\u003e/v1\u003c/code\u003e and \u003ccode\u003e/v2\u003c/code\u003e with separate backend pools and different rollout cycles. For this, Layer 7 is sensible: the edge terminates TLS, evaluates the HTTP path, and forwards requests accordingly. Both models can be operated in parallel on an edge platform.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-layer-7-inherently-more-secure-than-layer-4\"\u003eIs Layer 7 inherently more secure than Layer 4?\u003c/h3\u003e\n\u003cp\u003eNo. Layer 7 enables application-related checks like HTTP rules or WAF protection. Layer 4, on the other hand, reduces processing depth. Security depends on the threat model, protocol, and correct configuration.\u003c/p\u003e\n\u003ch3 id=\"can-https-always-be-operated-with-layer-4\"\u003eCan HTTPS always be operated with Layer 4?\u003c/h3\u003e\n\u003cp\u003eYes, as TLS passthrough. The edge routes the connection but does not evaluate the HTTP content. For path- or host-based routing, TLS termination at the edge is required.\u003c/p\u003e\n\u003ch3 id=\"when-should-a-backend-pool-be-split\"\u003eWhen should a backend pool be split?\u003c/h3\u003e\n\u003cp\u003eWhen applications have different scaling, release, health check, or failover requirements. Splitting only for organizational reasons increases routing complexity without technical benefit.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eL4 and L7 load balancing are not competing product variants but different architectural boundaries. Layer 4 keeps the edge away from the application and is suitable for transparent transport routing. Layer 7 provides control over HTTP traffic but requires conscious decisions regarding TLS, rules, and backend pools. An edge cloud like ayedo is effectively used when these layers are combined per service – rather than subjecting every application to the same routing model.\u003c/p\u003e\n",
      "summary": "\nTL;DR L4 and L7 load balancing address different tasks. Layer 4 routes connections based on IP, port, and transport protocol without evaluating application content. Layer 7 understands HTTP or HTTPS and enables routing based on hostname, path, or other request characteristics. The decision impacts TLS processing, backend pools, and operational effort.\nA common mistake is to operate every application with Layer 7 rules. This increases protocol complexity and shifts additional responsibility to the edge, even though many TCP or UDP services only require reliable transport routing. Conversely, a purely Layer 4 model is inadequate when multiple applications share a public address or requests need to reach different backends based on HTTP characteristics.\n",
      "image": "https://ayedo.de/l4-oder-l7-traffic-management-in-der-edge-cloud.png",
      "date_published": "2026-09-08T17:04:57Z",
      "date_modified": "2026-09-08T17:04:57Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","kubernetes","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/backend-pools-planen-health-checks-und-failover/",
      "url": "https://ayedo.de/en/posts/backend-pools-planen-health-checks-und-failover/",
      "title": "Planning Backend Pools: Health Checks and Failover",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-pools-planen-health-checks-und-failover/backend-pools-planen-health-checks-und-failover.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend pools are not merely lists of target systems. Their composition determines which backends receive traffic, how failures are detected, and when failover is triggered. Meaningful health checks, clear pool boundaries, and a defined fallback path prevent the edge from distributing traffic to technically reachable but non-functional systems.\u003c/p\u003e\n\u003cp\u003eA backend pool connects public accessibility with specific internal targets. In practice, availability is determined not only by the load balancer but also by the planning of backend groups. If different applications, operational states, or failure domains are indiscriminately grouped in a pool, a failure can lead to unpredictable switching.\u003c/p\u003e\n\u003cp\u003eThe central architectural decision is: Which targets are allowed to take over the same traffic in case of failure? This question is more important than the mere number of available backends. A pool should only contain systems that are truly interchangeable from the application\u0026rsquo;s perspective. Different versions, data states, regions, or security zones often require separate pools or a deliberately defined failover path.\u003c/p\u003e\n\u003ch2 id=\"1-segment-backend-pools-by-interchangeability\"\u003e1. Segment Backend Pools by Interchangeability\u003c/h2\u003e\n\u003cp\u003eA pool should contain targets that are related both functionally and technically. This includes, for example, multiple instances of the same service with comparable configuration, identical protocol, and compatible data access. A second pool can be designated for another region, a separate data center, or a deliberately delayed emergency environment.\u003c/p\u003e\n\u003cp\u003eThe most important boundary is interchangeability: Can each target correctly process the same request without violating session state, data version, or permissions? If not, a shared pool is usually problematic. A backend may be reachable at the TCP level but not serve as a functional replacement.\u003c/p\u003e\n\u003cp\u003eThis structure directly impacts operations. Smaller, clearly defined pools simplify troubleshooting and make failover decisions transparent. Conversely, overly fragmented pools increase configuration effort and can unnecessarily isolate available capacity. Therefore, pool boundaries should be aligned with failure domains and operational models, not solely with topology.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-must-reflect-service-state\"\u003e2. Health Checks Must Reflect Service State\u003c/h2\u003e\n\u003cp\u003eHealth checks control whether a backend is considered available for target selection. A simple connection test only checks if a network path and a listener exist. For HTTP and HTTPS services, an application-specific check is usually more meaningful: It can check status codes, response behavior, or a defined readiness endpoint.\u003c/p\u003e\n\u003cp\u003eThe check must measure exactly the prerequisites relevant for traffic processing. A service might successfully respond to the check path while database access, dependencies, or relevant business logic are disrupted. Conversely, an overly complex check can overrate temporary disturbances and unnecessarily remove a functioning backend from the pool.\u003c/p\u003e\n\u003cp\u003eImportant evaluation parameters include check interval, timeout, and the number of consecutive failures. They influence the response speed and stability of target selection. Aggressive values can cause flapping between available and unavailable; conservative values extend the time traffic reaches a disturbed target. Health checks are thus an operational mechanism, not merely a technical checkbox.\u003c/p\u003e\n\u003ch2 id=\"3-model-failover-as-a-controlled-traffic-path\"\u003e3. Model Failover as a Controlled Traffic Path\u003c/h2\u003e\n\u003cp\u003eFailover should predefine the expected target behavior in case of a failure. One possible strategy distributes traffic initially to multiple primary backends and uses a separate pool only when the primary group is insufficiently available. Alternatively, a backup target can permanently take a limited share to verify its operational readiness.\u003c/p\u003e\n\u003cp\u003eThe distinction between the failure of a single backend and the failure of an entire pool is crucial. If an instance fails, traffic should ideally be redistributed within the same group. However, if a common failure domain becomes inaccessible, the fallback path must reach another domain. Without this separation, an apparent failover might merely shift traffic between equally affected systems.\u003c/p\u003e\n\u003cp\u003eIn the ayedo Edge Cloud, backend health checks and failover are considered at the public entry point of applications. The Edge Cloud can thus control target selection before backend access. However, this does not replace capacity and dependency planning: A failover target must be able to process requests, and its data or operational boundaries must be known.\u003c/p\u003e\n\u003ch2 id=\"4-evaluate-availability-security-and-operations-together\"\u003e4. Evaluate Availability, Security, and Operations Together\u003c/h2\u003e\n\u003cp\u003eBackend pools influence not only routing and availability. The choice of targets also determines which systems must be reachable from the public entry point. Backend cloaking can help prevent internal structures from being directly visible externally. Edge access is directed to defined targets, while the actual backend addresses do not become part of the public addressing model.\u003c/p\u003e\n\u003cp\u003eFor operations, state changes must be traceable. Traffic and usage statistics help identify unusual distributions, rising error rates, or a triggered failover. Particularly relevant is whether a backup pool unexpectedly takes over traffic permanently, thereby losing its own reserve.\u003c/p\u003e\n\u003cp\u003eThe Edge Cloud is not tied to ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Backend pools can also be used for Kubernetes clusters operated independently or with other providers. Kubernetes-native integration facilitates the inclusion of changing workloads but does not replace the functional decision on which services may failover together. Provider independence expands the architectural scope; it does not automatically make pool and dependency boundaries correct.\u003c/p\u003e\n\u003ch2 id=\"operational-scenario-primary-pool-with-separate-emergency-target\"\u003eOperational Scenario: Primary Pool with Separate Emergency Target\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two environments. Three backends in the primary pool handle regular traffic. A separate environment contains two additional backends and is used as a failover pool. The health check examines not only the port but also a dedicated readiness endpoint with the dependencies necessary for the API.\u003c/p\u003e\n\u003cp\u003eIf a primary instance fails, the Edge distributes traffic to the remaining targets. Only when the primary pool is no longer available does the failover path take effect. Before activation, it must be ensured that the emergency environment processes compatible data and has sufficient capacity. Otherwise, routing would technically work but merely shift the disturbance.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"how-many-backends-should-a-pool-contain\"\u003eHow many backends should a pool contain?\u003c/h3\u003e\n\u003cp\u003eAs many as are sensible for joint processing and desired redundancy. Key factors are interchangeability, capacity, and shared failure domains—not a blanket number of targets.\u003c/p\u003e\n\u003ch3 id=\"when-is-a-separate-failover-pool-advisable\"\u003eWhen is a separate failover pool advisable?\u003c/h3\u003e\n\u003cp\u003eWhen replacement systems are in a different failure domain, region, or operational environment or are deliberately prioritized differently. A separate pool makes this fallback path explicitly controllable.\u003c/p\u003e\n\u003ch3 id=\"what-should-a-health-check-not-test\"\u003eWhat should a health check not test?\u003c/h3\u003e\n\u003cp\u003eNo unnecessarily extensive business logic. The check should reliably reflect the readiness state relevant for traffic, without becoming unstable due to remote or volatile dependencies.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eWell-planned backend pools not only reflect availability but also control it. Key factors are clear interchangeability rules, realistic health checks, and a failover path with known technical and operational boundaries. The ayedo Edge Cloud integrates these decisions at the public entry point and distributes traffic to available targets—regardless of whether the backends are operated in ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, own clusters, or with other providers.\u003c/p\u003e\n",
      "summary": "\nTL;DR Backend pools are not merely lists of target systems. Their composition determines which backends receive traffic, how failures are detected, and when failover is triggered. Meaningful health checks, clear pool boundaries, and a defined fallback path prevent the edge from distributing traffic to technically reachable but non-functional systems.\nA backend pool connects public accessibility with specific internal targets. In practice, availability is determined not only by the load balancer but also by the planning of backend groups. If different applications, operational states, or failure domains are indiscriminately grouped in a pool, a failure can lead to unpredictable switching.\n",
      "image": "https://ayedo.de/backend-pools-planen-health-checks-und-failover.png",
      "date_published": "2026-09-08T17:04:57Z",
      "date_modified": "2026-09-08T17:04:57Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/",
      "url": "https://ayedo.de/en/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/",
      "title": "Failover Across Multiple Providers with the Edge Cloud",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-uber-mehrere-provider-mit-der-edge-cloud/failover-uber-mehrere-provider-mit-der-edge-cloud.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProvider-independent failover separates public traffic entry from the compute infrastructure. The edge handles Anycast, DNS, protection, TLS, and health checks, while backends or \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n are operated with different providers. Backend cloaking prevents failover architectures from being unnecessarily exposed by publicly accessible origin services.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA multi-cloud failover is not resilient if it only involves multiple backends but DNS, routing, and security functions remain tied to a single provider. The crucial architectural decision is: Where does provider dependency end? By separating public entry from the compute infrastructure, the edge can distribute traffic independently of the execution location. Failover is then modeled not as switching between publicly known endpoints but as a controlled change within a central traffic and protection layer. This reduces dependencies but also shifts responsibility: Health checks, state management, data replication, and operational processes must be planned across providers.\u003c/p\u003e\n\u003ch2 id=\"1-provider-independence-begins-at-the-public-entry\"\u003e1. Provider Independence Begins at the Public Entry\u003c/h2\u003e\n\u003cp\u003eA single DNS provider or a provider-bound load balancer can become a strategic bottleneck. If the underlying platform fails, not only is a backend affected, but potentially the ability to redirect traffic as well. A provider-independent approach therefore relies on an autonomous edge with its own network infrastructure and autonomous system.\u003c/p\u003e\n\u003cp\u003eAnycast ensures that requests reach a common IP structure of the edge. The edge then decides which available backend the traffic is forwarded to. This is different from DNS-based switching between provider addresses: The public address remains stable while the selection of the backend occurs within the edge.\u003c/p\u003e\n\u003cp\u003eFor companies, this separation reduces the number of directly coupled components. The compute provider does not have to control DNS, public routing, and protection functions simultaneously. The edge thus becomes an independent control layer for public access, while the choice of provider for workloads remains more flexible.\u003c/p\u003e\n\u003ch2 id=\"2-backend-cloaking-separates-reachability-from-visibility\"\u003e2. Backend Cloaking Separates Reachability from Visibility\u003c/h2\u003e\n\u003cp\u003eProvider-independent failover should not result in multiple origin services being publicly addressable and thus directly attackable. If backend IP addresses become visible in DNS entries or client configurations, traffic can bypass the central protection and routing layer. Additionally, each provider change creates an external change that caches, clients, and operations teams must consider.\u003c/p\u003e\n\u003cp\u003eBackend cloaking addresses this problem. Clients communicate exclusively with the edge, while the actual backends do not appear as public service endpoints. This also applies to applications on different \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n: A cluster can be operated with ayedo Managed Kubernetes or another provider without its public reachability becoming an architectural principle.\u003c/p\u003e\n\u003cp\u003eThis makes the separation of access and execution technically effective. TLS termination, web application firewall, DDoS protection, and load balancing remain bundled at the edge. The backends must continue to be secured and monitored but are no longer the primary location where public traffic decisions are made.\u003c/p\u003e\n\u003ch2 id=\"3-failover-needs-reliable-signals-and-clear-states\"\u003e3. Failover Needs Reliable Signals and Clear States\u003c/h2\u003e\n\u003cp\u003eAnycast alone does not detect an application failure. The edge requires health checks to determine if a backend is truly operational. For example, an accessible port does not prove that an application processes requests correctly. For reliable failover, checks must therefore match the respective application and distinguish between temporary disruption, overload, and permanent failure.\u003c/p\u003e\n\u003cp\u003eThe edge can distribute traffic to another backend or cluster in the event of a disruption. However, this does not solve problems outside of public routing. Sessions, non-replicated data, ongoing transactions, and asynchronous jobs can still be inconsistent during a provider switch. Failover is therefore a combination of edge decision and state-aware application architecture.\u003c/p\u003e\n\u003cp\u003eOperationally, new requirements arise: Teams must define responsibilities between edge and compute, version health checks, and test switching processes. Multi-cloud failover is not a switch but an operational model. Without regular testing, it remains unclear whether backends, data paths, and restart processes actually fit together in the event of a failure.\u003c/p\u003e\n\u003ch2 id=\"4-central-edge-functions-reduce-organizational-coupling\"\u003e4. Central Edge Functions Reduce Organizational Coupling\u003c/h2\u003e\n\u003cp\u003eWhen each provider provides its own DNS, TLS, WAF, and DDoS components, configurations, operational processes, and failure behaviors differ. A central edge platform standardizes these functions across multiple compute environments. This facilitates policies, monitoring, and changes but increases the significance of the edge itself as a critical infrastructure component.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud combines Anycast DNS and multi-provider DNS with Layer-4 and Layer-7 load balancing, TLS termination, WAF, DDoS protection, backend health checks, and failover. With its own network infrastructure, autonomous system, and distributed multi-PoP architecture, the edge is not tied to the provider where a specific backend runs. The active-active principle fits this model because public access does not have to be reduced to a single active location.\u003c/p\u003e\n\u003cp\u003eFor platform teams, this means a clear layering: The edge is responsible for entry and distribution, the compute platform for operating workloads. This separation can simplify provider strategy but demands binding ownership for configuration, security rules, and incident analysis.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API on a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n with Provider A and maintains a second cluster with Provider B. Both clusters are accessed via the same edge address. The edge performs health checks and redirects requests from Provider A to Provider B in case of a failure. The backend addresses are not published as public API endpoints.\u003c/p\u003e\n\u003cp\u003eIn normal operation, the second cluster can serve as a reserve or for controlled load shares. In the event of an error, DNS and client configuration remain unchanged. The operations team must ensure that both clusters have the same API contracts, security rules, and necessary data states. The edge simplifies switching; it does not replace application replication and consistency.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-anycast-alone-a-multi-cloud-failover\"\u003eIs Anycast alone a multi-cloud failover?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast brings traffic to the edge. Only health checks, backend selection, and suitable application configuration enable forwarding to an alternative provider.\u003c/p\u003e\n\u003ch3 id=\"does-backend-cloaking-prevent-every-direct-attack-on-a-backend\"\u003eDoes backend cloaking prevent every direct attack on a backend?\u003c/h3\u003e\n\u003cp\u003eNo. It reduces public visibility and prevents normal client traffic from bypassing the edge. Backends still require their own access and security controls.\u003c/p\u003e\n\u003ch3 id=\"does-kubernetes-have-to-be-operated-with-ayedo\"\u003eDoes \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n have to be operated with ayedo?\u003c/h3\u003e\n\u003cp\u003eNo. The Edge Cloud can also connect to \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n that are self-operated or run with other providers.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eProvider-independent failover is primarily a question of architectural boundaries. By separating public access and compute, routing, protection, and switching remain independent of the application\u0026rsquo;s execution location. Backend cloaking prevents this flexibility from being lost through publicly exposed origins. The ayedo Edge Cloud forms an independent edge layer with Anycast, its own network infrastructure, and central failover functions. The technical responsibility for data, states, and operational tests remains with the application and its platform teams.\u003c/p\u003e\n",
      "summary": "\nTL;DR Provider-independent failover separates public traffic entry from the compute infrastructure. The edge handles Anycast, DNS, protection, TLS, and health checks, while backends or Kubernetes clusters are operated with different providers. Backend cloaking prevents failover architectures from being unnecessarily exposed by publicly accessible origin services.\nIntroduction A multi-cloud failover is not resilient if it only involves multiple backends but DNS, routing, and security functions remain tied to a single provider. The crucial architectural decision is: Where does provider dependency end? By separating public entry from the compute infrastructure, the edge can distribute traffic independently of the execution location. Failover is then modeled not as switching between publicly known endpoints but as a controlled change within a central traffic and protection layer. This reduces dependencies but also shifts responsibility: Health checks, state management, data replication, and operational processes must be planned across providers.\n",
      "image": "https://ayedo.de/failover-uber-mehrere-provider-mit-der-edge-cloud.png",
      "date_published": "2026-09-07T13:54:41Z",
      "date_modified": "2026-09-07T13:54:41Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","security","cloud","operations"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/",
      "url": "https://ayedo.de/en/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/",
      "title": "Active-Active Failover: Load Distribution and Consistency",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-failover-lastverteilung-und-konsistenz/aktiv-aktiv-failover-lastverteilung-und-konsistenz.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eActive-active failover distributes production traffic simultaneously across multiple backends, making individual failures often transparent to users and clients. The trade-off is additional effort: sessions, data changes, and side effects must be designed to be consistent or deliberately fault-tolerant across the involved instances.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eActive-active is not merely a redundancy decision but an architectural choice for the entire request and data path. Utilizing multiple backends simultaneously in production reduces dependency on a single failure domain. However, it does not automatically eliminate failure risks: a backend can be reachable but deliver outdated data, lose sessions, or produce conflicting changes. Therefore, the central question is not just how traffic is distributed, but which states need to be distributed. For publicly accessible applications and APIs, this separation determines whether active-active failover truly enables continuous use or merely creates a more complex operational mode.\u003c/p\u003e\n\u003ch2 id=\"1-traffic-distribution-across-multiple-failure-domains\"\u003e1. Traffic Distribution Across Multiple Failure Domains\u003c/h2\u003e\n\u003cp\u003eIn an active-active architecture, multiple backends process production requests simultaneously. A failure does not necessarily lead to a complete switch to a passive system; traffic distribution can reduce the share of an affected backend or remove it entirely from the pool. This decouples failure domains, such as individual clusters, data centers, providers, or network paths.\u003c/p\u003e\n\u003cp\u003eTechnically, this approach requires a public entry point that continuously evaluates reachability and backend status. Anycast-based Layer-4 and Layer-7 load balancing can route requests through a distributed edge infrastructure to available backends. Health checks are not consistency checks: they indicate whether a service is reachable and functional enough, not whether its data is current.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud takes on exactly these edge tasks with Anycast, backend health checks, and failover. It can connect multiple proprietary or cross-provider operated backends. However, ensuring application consistency remains the responsibility of the backend and data architecture.\u003c/p\u003e\n\u003ch2 id=\"2-sessions-and-states-in-the-request-path\"\u003e2. Sessions and States in the Request Path\u003c/h2\u003e\n\u003cp\u003eThe simplest active-active case is a stateless application. Each request contains all the information the backend needs or accesses a commonly available state. Then traffic can be distributed without a fixed binding to an instance. This improves fault tolerance and facilitates scaling but requires a consistent separation of request processing and session state.\u003c/p\u003e\n\u003cp\u003eProblems arise when sessions reside in the local storage of a backend. If the next request is distributed to another instance, authentication, shopping cart, or workflow data may be missing. Sticky sessions can limit this issue but worsen load distribution and make a backend failure more noticeable. Moreover, they do not resolve data consistency between instances.\u003c/p\u003e\n\u003cp\u003eFor publicly accessible APIs, short-lived tokens, idempotent operations, and a clearly defined shared state are often more robust. TLS termination at the edge, proxy protocol, or backend cloaking can structure the network path and protect the backends. However, they do not replace the decision on where session data resides and how its failure is handled.\u003c/p\u003e\n\u003ch2 id=\"3-data-consistency-as-the-actual-complexity-boundary\"\u003e3. Data Consistency as the Actual Complexity Boundary\u003c/h2\u003e\n\u003cp\u003eWith multiple active backends, data management is usually the most demanding part. If two instances read different replication states, visible discrepancies arise: a newly created object does not appear yet, a status change is overwritten, or an API delivers conflicting responses. Depending on the business process, this can be tolerable, technically critical, or unacceptable.\u003c/p\u003e\n\u003cp\u003eBefore making an active-active decision, consistency models and error behavior must be defined. Possible requirements range from eventual consistency to more coordinated processing. Write accesses can be partitioned, led through defined leaders, or secured against repetition with idempotency keys. Conflict resolution should not be implicitly left to the load balancer.\u003c/p\u003e\n\u003cp\u003eThis generates organizational and economic consequences. Development teams must specify state transitions, retries, and concurrency; operations teams need metrics for replication delay and failed synchronization. While active-active reduces dependency on individual infrastructure components, it can significantly increase the effort for data operations and testing.\u003c/p\u003e\n\u003ch2 id=\"4-failover-requires-application-knowledge\"\u003e4. Failover Requires Application Knowledge\u003c/h2\u003e\n\u003cp\u003eA backend is not automatically considered healthy just because a port responds. A superficial health check can report a process as available even though database accesses fail, dependencies are unreachable, or the backend cannot safely process new write operations. Overly aggressive checks, on the other hand, create unnecessary switches and additional load.\u003c/p\u003e\n\u003cp\u003eGraduated states are sensible: a backend can continue to read but not accept write operations; it can be removed from the traffic pool while ongoing connections expire. Layer-7 checks can test application-proximate availability but must be carefully defined technically. Failover should also be coordinated with retries, timeouts, and idempotency to ensure a resent request does not produce duplicate side effects.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud can evaluate available backends through health checks and distribute or redirect traffic accordingly. This provides a technical foundation for active-active failover but does not determine whether a service can be safely operated technically. This responsibility lies with the application, data management, and operational processes.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn API runs in two independent \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers. Both clusters are active and published via the ayedo Edge Cloud. Read requests can be distributed across both backends. For write operations, the application uses idempotency keys and a data model that accounts for replication delay. A health check removes a backend from the pool if the API is reachable but cannot perform valid database operations.\u003c/p\u003e\n\u003cp\u003eWithout these measures, a pure traffic failover would merely redirect requests. Users could then switch between different states or trigger write operations multiple times. Thus, the active-active architecture reduces the impact of a cluster or provider failure but requires deliberately modeled states and verifiable operational procedures.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-active-active-failover-suitable-for-every-application\"\u003eIs Active-Active Failover Suitable for Every Application?\u003c/h3\u003e\n\u003cp\u003eNo. Applications with strictly central, non-replicable state logic may benefit more from a controlled active-passive model.\u003c/p\u003e\n\u003ch3 id=\"are-sticky-sessions-a-sufficient-solution\"\u003eAre Sticky Sessions a Sufficient Solution?\u003c/h3\u003e\n\u003cp\u003eNo. They stabilize session assignment but do not resolve data replication or the failure of the bound backend.\u003c/p\u003e\n\u003ch3 id=\"what-role-does-anycast-play\"\u003eWhat Role Does Anycast Play?\u003c/h3\u003e\n\u003cp\u003eAnycast provides a distributed public entry point. The specific backend selection and its consistency remain separate architectural tasks.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eActive-active failover is beneficial when multiple backends need to continuously operate in production and failure domains must be deliberately decoupled. The critical boundary is not at load balancing but at sessions, write operations, and \u003ca href=\"/en/kubernetes/\"\u003edata consistency\u003c/a\u003e\n. An edge platform like the ayedo Edge Cloud can distribute public traffic via Anycast, check backends, and trigger failover. However, whether this mechanism is technically safe is determined by the architecture behind the edge.\u003c/p\u003e\n",
      "summary": "\nTL;DR Active-active failover distributes production traffic simultaneously across multiple backends, making individual failures often transparent to users and clients. The trade-off is additional effort: sessions, data changes, and side effects must be designed to be consistent or deliberately fault-tolerant across the involved instances.\nIntroduction Active-active is not merely a redundancy decision but an architectural choice for the entire request and data path. Utilizing multiple backends simultaneously in production reduces dependency on a single failure domain. However, it does not automatically eliminate failure risks: a backend can be reachable but deliver outdated data, lose sessions, or produce conflicting changes. Therefore, the central question is not just how traffic is distributed, but which states need to be distributed. For publicly accessible applications and APIs, this separation determines whether active-active failover truly enables continuous use or merely creates a more complex operational mode.\n",
      "image": "https://ayedo.de/aktiv-aktiv-failover-lastverteilung-und-konsistenz.png",
      "date_published": "2026-09-07T13:54:40Z",
      "date_modified": "2026-09-07T13:54:40Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["development","operations","kubernetes","hosting","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/",
      "url": "https://ayedo.de/en/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/",
      "title": "Active/Passive or Active-Active: Choosing the Right Failover",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eActive-passive failover is not inherently simpler, nor is active-active automatically superior. Key factors include switch-over time, data consistency, maintenance requirements, and the application\u0026rsquo;s ability to support parallel processing. The \u003ca href=\"/en/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n distributes public traffic regardless of the backend model used and must reliably handle health checks, routing, and failover.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany high availability concepts fail not due to lack of infrastructure, but due to an inappropriate failover strategy. A passive site can offer clear responsibilities and controlled data flows but results in unused capacity and extended restart times. Active-active reduces these disadvantages but imposes higher demands on application, data management, and operations. The decision should not start with which model seems more modern. The operational conditions are crucial: How quickly must a failure be mitigated? Which data can diverge? Can the application process requests at multiple locations simultaneously?\u003c/p\u003e\n\u003ch2 id=\"1-active-passive-controlled-failover-with-clear-responsibilities\"\u003e1. Active-Passive: Controlled Failover with Clear Responsibilities\u003c/h2\u003e\n\u003cp\u003eIn an active-passive architecture, a primary backend handles regular traffic. The secondary system remains either fully ready or partially operational. In case of failure, traffic must be switched to the passive target. This model simplifies responsibility: there is usually a leading data set and a defined production site.\u003c/p\u003e\n\u003cp\u003eThe cost is potentially lower capacity utilization. The passive system must be adequately sized for failure but remains largely unused during normal operation. Additionally, a switch-over chain arises from error detection, routing change, application startup, and possibly database recovery. Health checks only detect if a target is reachable and functional enough. They do not replace a professional examination of data consistency.\u003c/p\u003e\n\u003cp\u003eActive-passive failover is particularly suitable for applications with strictly controlled write paths, limited parallelization, or high demands on a unique primary location.\u003c/p\u003e\n\u003ch2 id=\"2-active-active-utilize-capacity-distribute-complexity\"\u003e2. Active-Active: Utilize Capacity, Distribute Complexity\u003c/h2\u003e\n\u003cp\u003eIn an active-active architecture, multiple locations or instances simultaneously handle productive traffic. This better utilizes existing capacity, and maintenance can sometimes occur without full switch-over. If a site fails, traffic does not need to be activated on a previously unused system.\u003c/p\u003e\n\u003cp\u003eThese advantages do not arise solely from additional routing. The application must support parallel requests, distributed sessions, and possibly multiple write paths. Data management is particularly demanding: replication can cause delays, competing changes must be resolved, and not every transaction can be distributed without a central coordination point.\u003c/p\u003e\n\u003cp\u003eActive-active thus reduces infrastructural restart but shifts complexity into application design, data model, and operations. Without clear consistency requirements, higher availability can quickly become a difficult-to-trace error pattern.\u003c/p\u003e\n\u003ch2 id=\"3-the-edge-cloud-as-a-switching-and-distribution-layer\"\u003e3. The \u003ca href=\"/en/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n as a Switching and Distribution Layer\u003c/h2\u003e\n\u003cp\u003eThe Edge Cloud does not decide whether a backend operates internally as active-passive or active-active. It forms the public entry point and can distribute incoming traffic over Anycast Layer-4 and Layer-7 load balancing to suitable backends. Backend health checks and failover remove unreachable or faulty targets from distribution. Thus, the switch-over logic depends on the backend state, not just a manual DNS change.\u003c/p\u003e\n\u003cp\u003eIn active-active, the Edge Cloud can distribute traffic to multiple available backends simultaneously. In active-passive, the passive target becomes relevant only in case of failure. In both cases, session behavior, write consistency, and recovery tasks remain the responsibility of the application and its data management.\u003c/p\u003e\n\u003cp\u003eThe distributed multi-PoP architecture and active-active principle of the ayedo Edge Cloud address the public traffic layer. With its own autonomous system and network infrastructure, this layer is not solely under the control of a single compute provider. This does not replace a highly available backend but creates an independent control for routing, protection, and failover.\u003c/p\u003e\n\u003ch2 id=\"4-maintenance-restart-and-economic-implications\"\u003e4. Maintenance, Restart, and Economic Implications\u003c/h2\u003e\n\u003cp\u003eThe choice of model is particularly evident during maintenance windows. Active-passive allows a clear switch from the primary to the secondary system. However, this switch must be regularly tested; a passive system activated only in emergencies may contain outdated configurations, lack capacity, or have undetected errors. Failover tests are therefore part of the operational model and not a one-time project.\u003c/p\u003e\n\u003cp\u003eActive-active distributes the ongoing load and can enable maintenance without complete capacity loss. Deployments, configurations, and data changes must be controlled and synchronized between active units. The organizational effort increases because multiple operational states must be observed and evaluated simultaneously.\u003c/p\u003e\n\u003cp\u003eEconomically, unused reserve capacity and higher operational and development complexity stand opposed. An active-active architecture is not automatically worthwhile for every application. If consistency requirements are high and downtimes tolerable, active-passive can be the more robust and transparent decision.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn API service processes orders with central transaction logic. The database does not support conflict-free multi-master operation. Active-active at the application level would therefore require additional coordination and complex error handling. An active-passive model with a replicated standby is more plausible here: one site writes, the second takes over after defined checks.\u003c/p\u003e\n\u003cp\u003eA stateless read API with replicated data, on the other hand, can be actively operated at multiple locations. The \u003ca href=\"/en/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n distributes public traffic to healthy backends. If a target fails, it is removed from distribution via health checks. The decision is thus based on the characteristics of the application and data model, not on a blanket preference for active-active.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-active-active-always-more-highly-available-than-active-passive\"\u003eIs Active-Active always more highly available than Active-Passive?\u003c/h3\u003e\n\u003cp\u003eNo. Active-active avoids certain switch-over times but increases demands on data consistency and operation. A poorly distributed active-active application can be less reliable than a well-tested active-passive system.\u003c/p\u003e\n\u003ch3 id=\"what-role-do-health-checks-play-in-failover\"\u003eWhat role do health checks play in failover?\u003c/h3\u003e\n\u003cp\u003eHealth checks verify the reachability and defined functionality of a backend. They do not automatically detect professionally incorrect data, replication errors, or inconsistent transactions.\u003c/p\u003e\n\u003ch3 id=\"can-the-edge-cloud-completely-replace-an-active-passive-architecture\"\u003eCan the \u003ca href=\"/en/kubernetes/\"\u003eEdge Cloud\u003c/a\u003e\n completely replace an active-passive architecture?\u003c/h3\u003e\n\u003cp\u003eNo. The Edge Cloud distributes and protects public traffic. Restart, data replication, consistency, and activation of a passive backend remain tasks of the compute and application layer.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eThe right failover strategy follows from operational conditions: consistency model, tolerable switch-over time, maintenance requirements, and available operational competence. Active-passive offers clear control, active-active better resource utilization, and potentially lower switch-over dependency. An edge platform like the ayedo Edge Cloud connects both models with an independent layer for traffic distribution, health checks, and failover, without obscuring the responsibilities of the backends.\u003c/p\u003e\n",
      "summary": "\nTL;DR Active-passive failover is not inherently simpler, nor is active-active automatically superior. Key factors include switch-over time, data consistency, maintenance requirements, and the application\u0026rsquo;s ability to support parallel processing. The Edge Cloud distributes public traffic regardless of the backend model used and must reliably handle health checks, routing, and failover.\nIntroduction Many high availability concepts fail not due to lack of infrastructure, but due to an inappropriate failover strategy. A passive site can offer clear responsibilities and controlled data flows but results in unused capacity and extended restart times. Active-active reduces these disadvantages but imposes higher demands on application, data management, and operations. The decision should not start with which model seems more modern. The operational conditions are crucial: How quickly must a failure be mitigated? Which data can diverge? Can the application process requests at multiple locations simultaneously?\n",
      "image": "https://ayedo.de/aktiv-passiv-oder-aktiv-aktiv-failover-richtig-wahlen.png",
      "date_published": "2026-09-07T13:54:40Z",
      "date_modified": "2026-09-07T13:54:40Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/",
      "url": "https://ayedo.de/en/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/",
      "title": "Failover Response Paths Between Edge, DNS, and Backend",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-reaktionswege-zwischen-edge-dns-und-backend/failover-reaktionswege-zwischen-edge-dns-und-backend.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eFailover is not a single switch function but a chain of detection, decision, forwarding, and stabilization. Edge routing typically reacts closer to the ongoing traffic, while DNS failover is delayed by TTLs, resolver, and client caches. Existing connections follow different rules than new requests.\u003c/p\u003e\n\u003cp\u003eFailover is often described as a state change: A backend fails, and an alternative backend takes over. Technically, however, several interdependent steps lie in between. A health check must detect the failure, a routing instance must evaluate the information, new connections must receive a different path, and the traffic must stabilize. If DNS is changed instead, TTLs, resolver caches, and local client caches are added.\u003c/p\u003e\n\u003cp\u003eThe crucial difference is therefore not only in the detection time. The switch path, visibility for existing connections, and the point in the architecture where the decision is made are also relevant. Failover response paths should therefore be analyzed as a process—not as a switch with a blanket switch time.\u003c/p\u003e\n\u003ch2 id=\"1-backend-health-checks-determine-the-first-reaction-point\"\u003e1. Backend Health Checks Determine the First Reaction Point\u003c/h2\u003e\n\u003cp\u003eEvery failover begins with an observation. A backend health check, for example, checks whether a service is reachable and delivers an expected response. It is important to distinguish between network reachability and application state: A reachable server may still not be able to process functional requests.\u003c/p\u003e\n\u003cp\u003eA reliable state change only emerges from multiple check results. Too aggressive checks can interpret short-term network or load issues as failures. Too conservative checks, on the other hand, prolong the time traffic is directed to a non-functional target. Check interval, timeout, and the required number of consecutive errors directly influence the reaction characteristics.\u003c/p\u003e\n\u003cp\u003eIn an edge platform, such health checks are evaluated before forwarding to the backend. The edge can then remove a target from active routing or use an alternative path. However, the health check is not yet a failover: It only provides the information on which the routing decision is based.\u003c/p\u003e\n\u003ch2 id=\"2-edge-routing-specifically-switches-new-forwarding\"\u003e2. Edge Routing Specifically Switches New Forwarding\u003c/h2\u003e\n\u003cp\u003eIn edge failover, the public entry point remains unchanged. The edge continues to receive traffic over the existing address and decides based on the current backend state where new connections or requests are forwarded. This eliminates the dependency on a renewed DNS resolution for each switch operation.\u003c/p\u003e\n\u003cp\u003eThe reaction path is simplified: A health check detects an error, the edge updates the available backend pool, and then new forwarding is directed to an alternative target. At Layer 7, the decision can be made at the request level; at Layer 4, the connection\u0026rsquo;s lifespan is more influenced by TCP or UDP states. An already established TCP channel is not automatically moved to another endpoint.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud combines such backend health checks with edge routing in a distributed multi-PoP and active-active architecture. This is particularly relevant when the public entry point should remain stable while backends are operated in different environments—such as in self-hosted or provider-hosted \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n. The edge remains responsible for entry, protection, and forwarding; the compute infrastructure remains the place of application.\u003c/p\u003e\n\u003ch2 id=\"3-dns-failover-shifts-the-decision-to-resolvers-and-clients\"\u003e3. DNS Failover Shifts the Decision to Resolvers and Clients\u003c/h2\u003e\n\u003cp\u003eIn DNS failover, it is not primarily the forwarding at the edge that changes, but the response to a name resolution. A health check can determine that a target is unavailable, after which DNS provides an alternative address. However, the further traffic only reaches this target when a new DNS resolution occurs.\u003c/p\u003e\n\u003cp\u003eThe configured TTL limits the validity of a response but does not guarantee an exact switch time. Recursive resolvers, operating systems, applications, and local network components can cache responses for different lengths of time or apply their own reuse logics. This creates a distributed transition phase between the state change and the actual use of the new target.\u003c/p\u003e\n\u003cp\u003eDNS failover is useful when the public entry itself should switch between independent endpoints or when a change is required outside a single edge routing domain. Anycast DNS and multi-provider DNS can make the DNS layer more resilient but do not eliminate the effect of caches. In the ayedo Edge Cloud, DNS is therefore a separate response path alongside edge routing, not its replacement.\u003c/p\u003e\n\u003ch2 id=\"4-existing-connections-make-the-difference-visible\"\u003e4. Existing Connections Make the Difference Visible\u003c/h2\u003e\n\u003cp\u003eFailover affects new and existing connections differently. A new connection can reach a healthy backend after the routing decision. An already established connection, however, initially remains bound to its previous network path. If the backend fails, the client, a proxy, or the application must terminate the connection, rebuild it, or retry a request.\u003c/p\u003e\n\u003cp\u003eWith HTTP over an edge, the public address can remain stable for the client while the internal forwarding changes. This simplifies the recovery of new requests but does not replace transaction logic. Repeats are only safe if the application can handle them, for example, through idempotency or suitable request IDs. With long-running WebSockets, streaming connections, or stateful sessions, the interruption is much more visible.\u003c/p\u003e\n\u003cp\u003eIn DNS failover, an existing connection also remains on its original target. Additionally, new connections can still use the old address as long as the DNS response is cached. Stabilization therefore consists not only of switching but also of retry behavior, session handling, connection draining, and monitoring error rates after the decision.\u003c/p\u003e\n\u003ch2 id=\"scenario-edge-switching-or-dns-change\"\u003eScenario: Edge Switching or DNS Change?\u003c/h2\u003e\n\u003cp\u003eSuppose an API cluster is unavailable while a second cluster remains operational. In edge failover, the health check detects the error, removes the first backend from forwarding, and sends new requests to the second cluster. Clients retain the known public endpoint; however, existing connections must be rebuilt depending on the protocol.\u003c/p\u003e\n\u003cp\u003eIn DNS failover, a new target address is published instead. Resolvers and clients adopt this information with a delay. During the transition phase, part of the new connections still reaches the failed target. The edge path thus reduces the impact of DNS caches, while the DNS path shifts the decision further outward. Which variant fits depends on the desired control point and the connection typology.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-edge-failover-always-faster-than-dns-failover\"\u003eIs Edge Failover Always Faster Than DNS Failover?\u003c/h3\u003e\n\u003cp\u003eNot automatically. Key factors are health check parameters, routing updates, and protocol behavior. DNS failover is additionally dependent on TTLs and caches, which can cause the use of the new target to diverge more over time.\u003c/p\u003e\n\u003ch3 id=\"are-existing-tcp-connections-moved-during-failover\"\u003eAre Existing TCP Connections Moved During Failover?\u003c/h3\u003e\n\u003cp\u003eNo. An existing connection is bound to its original path. If this fails, connection termination, rebuilding, or an application-side retry is required.\u003c/p\u003e\n\u003ch3 id=\"does-dns-failover-need-additional-edge-routing\"\u003eDoes DNS Failover Need Additional Edge Routing?\u003c/h3\u003e\n\u003cp\u003eNot fundamentally. DNS can switch between independent endpoints. However, edge routing is more suitable if the public entry should remain stable and the forwarding decision should be made centrally at the edge.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eFailover should be modeled as a temporal process: detection by health checks, decision at edge or DNS, forwarding of new connections, and stabilization of ongoing communication. Edge routing reduces dependency on DNS caches, while DNS failover uses a broader but less immediately controllable switch path. The ayedo Edge Cloud integrates these mechanisms into a platform for public traffic entry, protection, and forwarding—regardless of where the backends are operated.\u003c/p\u003e\n",
      "summary": "\nTL;DR: Failover is not a single switch function but a chain of detection, decision, forwarding, and stabilization. Edge routing typically reacts closer to the ongoing traffic, while DNS failover is delayed by TTLs, resolver, and client caches. Existing connections follow different rules than new requests.\nFailover is often described as a state change: A backend fails, and an alternative backend takes over. Technically, however, several interdependent steps lie in between. A health check must detect the failure, a routing instance must evaluate the information, new connections must receive a different path, and the traffic must stabilize. If DNS is changed instead, TTLs, resolver caches, and local client caches are added.\n",
      "image": "https://ayedo.de/failover-reaktionswege-zwischen-edge-dns-und-backend.png",
      "date_published": "2026-09-07T13:54:40Z",
      "date_modified": "2026-09-07T13:54:40Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","kubernetes","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/failure-domains-im-edge-design-fur-offentliche-dienste/",
      "url": "https://ayedo.de/en/posts/failure-domains-im-edge-design-fur-offentliche-dienste/",
      "title": "Failure Domains in Edge Design for Public Services",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failure-domains-im-edge-design-fur-offentliche-dienste/failure-domains-im-edge-design-fur-offentliche-dienste.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eFailover is only resilient if backup paths do not depend on the same failure domain as the primary path. Therefore, backend, cluster, provider, network, and edge must be evaluated separately. A multi-PoP architecture with its own \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n and active-active operation expands the design space for high availability but does not replace a thorough dependency analysis.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA second backend does not automatically make a public service highly available. If both backends are operated in the same cluster, with the same provider, or behind the same network dependency, the relevant failure domain remains unchanged. This is exactly why failover in edge design must be considered from the outside in: Which component fails, which route remains accessible, and which dependencies are not dragged along? For public services, high availability is not decided at the application level. DNS, edge, transit network, provider, cluster, and backend form a chain. If a common section of this chain fails, seemingly redundant systems also fail together.\u003c/p\u003e\n\u003ch2 id=\"1-failure-domains-along-the-request-path\"\u003e1. Failure Domains Along the Request Path\u003c/h2\u003e\n\u003cp\u003eA request passes through several potential failure boundaries. At the backend level, individual instances, a service, or a database can be affected. At the cluster level, control plane, network, or storage issues may arise. The provider domain, on the other hand, includes infrastructure, power supply, routing, and operational processes of a single cloud or hosting provider.\u003c/p\u003e\n\u003cp\u003eAbove that lies the network domain: transit, BGP reachability, DNS resolution, or a central internet uplink can simultaneously affect multiple provider paths. The edge itself is another failure domain. A single ingress, load balancer, or PoP can fail without disturbing the backend or provider.\u003c/p\u003e\n\u003cp\u003eThese layers should not just be documented as a list. The key is correlation: If multiple components are in the same failure domain, their redundancy is ineffective in a common failure scenario. High availability design therefore begins with a dependency map, not with the number of backends provided.\u003c/p\u003e\n\u003ch2 id=\"2-why-a-backup-backend-often-isnt-enough\"\u003e2. Why a Backup Backend Often Isn\u0026rsquo;t Enough\u003c/h2\u003e\n\u003cp\u003eA classic failover setup distributes a service across two backends and activates the second when health checks fail on the first. This is sensible but only covers part of the failure scenario. Both backends can use the same cluster, region, provider, or network path. A failure above the application level then affects both targets.\u003c/p\u003e\n\u003cp\u003eThe switchover itself also requires a functioning control. DNS caching, TTLs, BGP convergence, session states, and the reachability of the failover mechanism determine how quickly an alternative path becomes effective. A technically available backup backend is therefore not synonymous with a usable failover path.\u003c/p\u003e\n\u003cp\u003eThe edge should evaluate health states and distribute traffic selectively without amplifying the primary system\u0026rsquo;s failure. Backend health checks, failover, and backend cloaking help decouple public access from internal target systems. True independence, however, only arises when targets and their upstream dependencies are consciously distributed across failure domains.\u003c/p\u003e\n\u003ch2 id=\"3-multi-pop-autonomous-system-and-active-active\"\u003e3. Multi-PoP, Autonomous System, and Active-Active\u003c/h2\u003e\n\u003cp\u003eA distributed multi-PoP architecture reduces dependency on a single edge location. If a PoP fails or part of the network is unreachable there, other PoPs can still accept requests. This is architecturally different from a second load balancer at the same location: The edge itself is distributed across multiple operational and network areas.\u003c/p\u003e\n\u003cp\u003eFor assessing the network failure domain, it is also relevant who controls the routing. The ayedo Edge Cloud uses its own \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n and network infrastructure. This allows the edge to be viewed as an independent routing and protection layer rather than solely as a function of a single compute provider. This does not eliminate external internet disruptions but reduces direct coupling to a single provider\u0026rsquo;s network architecture.\u003c/p\u003e\n\u003cp\u003eThe active-active principle also shifts the operational logic: Multiple edge paths are fundamentally usable simultaneously, rather than a fully passive standby needing activation. Failover thus becomes a matter of traffic distribution and health evaluation, not just a manual switchover process.\u003c/p\u003e\n\u003ch2 id=\"4-failure-domains-as-operational-and-cost-decision\"\u003e4. Failure Domains as Operational and Cost Decision\u003c/h2\u003e\n\u003cp\u003eThe technical separation of failure domains has operational consequences. Distributing backends across providers or clusters increases integration, monitoring, and network effort. If they are only replicated within one system, operations remain simpler, but resilience against provider or cluster failures is limited. Therefore, there is no universal redundancy level.\u003c/p\u003e\n\u003cp\u003eA resilient decision requires concrete failure assumptions: Should a single pod, a complete cluster, a provider, or even the edge itself be tolerated? Which data can be synchronized with delay between locations? Which dependencies like identity, database, or DNS remain central? Only from this do meaningful failover paths emerge.\u003c/p\u003e\n\u003cp\u003eThe Edge Cloud can bundle central functions like Anycast DNS, Layer-4 and Layer-7 load balancing, TLS termination, DDoS protection, and health-based forwarding over a distributed platform. For \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, it is not crucial whether the cluster is operated by ayedo or another provider. What matters is that the public entry layer can be planned independently of the respective compute operation.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-three-layers-instead-of-a-second-backend\"\u003ePractical Scenario: Three Layers Instead of a Second Backend\u003c/h2\u003e\n\u003cp\u003eA public API service initially runs in a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster with one provider. A second deployment in the same cluster increases availability at the workload level but does not protect against a cluster or provider failure. In an extended architecture, a second cluster is operated with another provider. Both clusters are published through the edge and monitored by health checks.\u003c/p\u003e\n\u003cp\u003eThe edge distributes traffic across multiple PoPs and keeps the backends hidden from the internet. If an application fails, the affected path is removed from distribution. In case of a cluster or provider failure, targets in the other environment remain available. If a single edge PoP fails, other PoPs take over the entry. The added value arises not from a single component but from the separation of failure boundaries.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-multi-provider-operation-automatically-highly-available\"\u003eIs Multi-Provider Operation Automatically Highly Available?\u003c/h3\u003e\n\u003cp\u003eNo. Common DNS, identity, database, or network dependencies can still form a common failure domain. Multi-provider operation is only effective if these couplings are also evaluated.\u003c/p\u003e\n\u003ch3 id=\"what-role-does-the-autonomous-system-play\"\u003eWhat Role Does the Autonomous System Play?\u003c/h3\u003e\n\u003cp\u003eIt forms an independent routing domain of the edge. This makes public access less tightly coupled to the network infrastructure of a single compute provider.\u003c/p\u003e\n\u003ch3 id=\"does-every-backend-need-to-be-actively-used\"\u003eDoes Every Backend Need to Be Actively Used?\u003c/h3\u003e\n\u003cp\u003eNot necessarily. A passive standby can be operationally sensible. Active-active, however, reduces dependency on a switchover process and allows simultaneous use of multiple edge paths.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eFailure domains are the crucial perspective for resilient failover. A backup backend is not enough if cluster, provider, network, or edge share the same failure boundary. The multi-PoP architecture, the own \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n, and the active-active operation of the ayedo Edge Cloud create an independent edge layer for this planning. However, their effectiveness depends on whether companies also consistently decouple compute, data, and operational dependencies.\u003c/p\u003e\n",
      "summary": "\nTL;DR Failover is only resilient if backup paths do not depend on the same failure domain as the primary path. Therefore, backend, cluster, provider, network, and edge must be evaluated separately. A multi-PoP architecture with its own Autonomous System and active-active operation expands the design space for high availability but does not replace a thorough dependency analysis.\nIntroduction A second backend does not automatically make a public service highly available. If both backends are operated in the same cluster, with the same provider, or behind the same network dependency, the relevant failure domain remains unchanged. This is exactly why failover in edge design must be considered from the outside in: Which component fails, which route remains accessible, and which dependencies are not dragged along? For public services, high availability is not decided at the application level. DNS, edge, transit network, provider, cluster, and backend form a chain. If a common section of this chain fails, seemingly redundant systems also fail together.\n",
      "image": "https://ayedo.de/failure-domains-im-edge-design-fur-offentliche-dienste.png",
      "date_published": "2026-09-07T13:54:40Z",
      "date_modified": "2026-09-07T13:54:40Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["hosting","kubernetes","cloud-native","operations","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/",
      "url": "https://ayedo.de/en/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/",
      "title": "Testing Failover: Runbooks, States, and Rollback Paths",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-testen-runbooks-zustande-und-ruckfallpfade/failover-testen-runbooks-zustande-und-ruckfallpfade.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eFailover is only reliable when failure, switchover, and return are reproducibly tested. A good failover runbook describes expected health check states, routing and DNS behavior, observation points, and a controlled rollback path. The key is not the configured rule, but the demonstrable operational behavior.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany failover architectures are configured once but never tested under realistic conditions. This is where an operational error lies: A backend can be removed from load balancing, while DNS caches, existing connections, health check intervals, or unclear rollback logic continue to produce different behavior. Testing failover means not only shutting down a server. It means validating states, timelines, and responsibilities. For publicly accessible services, routing, DNS, health checks, and the return to the primary system must be considered together.\u003c/p\u003e\n\u003ch2 id=\"1-the-failover-runbook-describes-states-not-just-commands\"\u003e1. The Failover Runbook Describes States, Not Just Commands\u003c/h2\u003e\n\u003cp\u003eA useful failover runbook begins with the expected state model. It should distinguish between \u0026ldquo;healthy,\u0026rdquo; \u0026ldquo;degraded,\u0026rdquo; \u0026ldquo;unhealthy,\u0026rdquo; \u0026ldquo;failed over,\u0026rdquo; and \u0026ldquo;recovered.\u0026rdquo; For each state, triggers, technical impacts, and permissible next steps should be documented.\u003c/p\u003e\n\u003cp\u003eIn the event of a backend failure, it must be specified when a health check is considered failed, how many consecutive errors trigger the switchover, and which target subsequently takes over traffic. Equally important is the question of what happens to existing connections. Layer-4 and Layer-7 behavior can differ: New requests can be handled differently from already established sessions.\u003c/p\u003e\n\u003cp\u003eThe runbook should also define roles and approvals. Who initiates the test? Who monitors metrics and logs? Who decides on abort or rollback? Clear responsibilities reduce the time between technical insight and operational decision. A runbook that only contains a sequence of commands is incomplete for complex failures.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-must-be-observed-as-a-state-machine\"\u003e2. Health Checks Must Be Observed as a State Machine\u003c/h2\u003e\n\u003cp\u003eHealth checks are not a neutral yes-no test. Their behavior depends on endpoint, timeout, interval, error thresholds, and restart conditions. A test must therefore document when a backend is first recognized as faulty, when it is removed from traffic, and when it is considered available again.\u003c/p\u003e\n\u003cp\u003eDuring the test, at least the backend state, request distribution, error rates, response times, and active connections should be observed. Additionally, it should be checked whether the expected backup backend actually takes over requests. A green health check alone does not prove that the entire failover path works.\u003c/p\u003e\n\u003cp\u003eThe transition from \u0026ldquo;unhealthy\u0026rdquo; to \u0026ldquo;healthy\u0026rdquo; is particularly critical. A backend may be technically reachable again but not yet stable enough for full traffic. Therefore, a failover runbook needs criteria for a controlled resumption. In the context of an edge platform like the ayedo Edge Cloud, these state transitions are relevant because backend health checks and failover directly influence public routing.\u003c/p\u003e\n\u003ch2 id=\"3-test-routing-and-dns-separately-but-together\"\u003e3. Test Routing and DNS Separately but Together\u003c/h2\u003e\n\u003cp\u003eRouting failover and DNS failover solve different problems. An Anycast Layer-4 or Layer-7 routing can redirect traffic at the edge to another backend without changing the public DNS entry. DNS failover, on the other hand, changes the resolution and is subject to caches, TTLs, and resolver behavior. Those who combine both mechanisms must measure their temporal effects separately.\u003c/p\u003e\n\u003cp\u003eA test should therefore first clarify which path actually fails. If a single backend is removed, the DNS resolution should not change unnecessarily. If, on the other hand, an entire edge or routing path fails, it must be checked whether Anycast DNS or Multi-Provider DNS reacts as intended. Measurements from multiple networks are useful because recursive resolvers and local caches can deliver different results.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud combines Anycast DNS, Multi-Provider DNS, and Layer-4 and Layer-7 load balancing in one edge platform. For tests, however, the separation of responsibilities remains important: DNS resolution, edge routing, and backend reachability must each be validated individually and then evaluated in conjunction.\u003c/p\u003e\n\u003ch2 id=\"4-control-rollback-and-secure-evidence\"\u003e4. Control Rollback and Secure Evidence\u003c/h2\u003e\n\u003cp\u003eRollback is not an automatic follow-up to failover but its own operational state. A previously failed backend should only receive traffic again when cause, stability, and capacity have been checked. Otherwise, an unstable system can immediately generate errors again or be overloaded by a sudden traffic increase.\u003c/p\u003e\n\u003cp\u003eThe runbook should therefore provide for a staged return: Check recovery, observe health check state, gradually increase traffic, and compare error rates. If a gradual distribution is not possible, at least a defined time window and clear abort criteria are needed. The rollback must also document whether sessions, caches, or connections are affected.\u003c/p\u003e\n\u003cp\u003eA disaster recovery test is only meaningful when evidence is secured: timestamps of state changes, routing decisions, DNS responses, metrics, and relevant logs. This can reveal whether the architecture reacted as planned or only appeared to be available. These proofs are also crucial for later improvements to the runbook.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-backend-failure-with-controlled-return\"\u003ePractical Scenario: Backend Failure with Controlled Return\u003c/h2\u003e\n\u003cp\u003eA publicly accessible API service runs on two backends. In the test, the primary backend is deactivated so that health checks fail. The team first measures the time to detection and checks whether new requests are distributed to the secondary backend. DNS remains unchanged; this allows the routing failover to be evaluated in isolation.\u003c/p\u003e\n\u003cp\u003eAfter the primary backend is restored, it initially remains out of productive traffic. The team checks logs, response times, and health check stability. Only then is the rollback approved. If an increased error rate occurs again, the documented rollback path takes effect: The primary backend is excluded again, and operations continue on the secondary target.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"how-often-should-failover-be-tested\"\u003eHow often should failover be tested?\u003c/h3\u003e\n\u003cp\u003eAfter relevant architecture or configuration changes and regularly in operation. The frequency depends on the criticality, change rate, and restart requirements of the service.\u003c/p\u003e\n\u003ch3 id=\"what-belongs-in-a-failover-runbook\"\u003eWhat belongs in a failover runbook?\u003c/h3\u003e\n\u003cp\u003eTriggers, expected states, observation points, responsibilities, abort criteria, switchover logic, rollback, and the necessary evidence.\u003c/p\u003e\n\u003ch3 id=\"why-is-a-successful-switchover-test-not-enough\"\u003eWhy is a successful switchover test not enough?\u003c/h3\u003e\n\u003cp\u003eBecause a service can switch to the backup backend, but the rollback, DNS caches, sessions, or the stability of the original backend can still be faulty.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eFailover quality does not arise from a single configuration but from repeatable processes. Those who test health check states, routing, DNS, and rollback as an interconnected operational process recognize deviations before they become critical in the event of a disruption. The ayedo Edge Cloud offers a unified edge layer with Anycast routing, DNS, health checks, and failover. However, its effectiveness must be demonstrated in the specific operational model through runbooks and tests.\u003c/p\u003e\n",
      "summary": "\nTL;DR Failover is only reliable when failure, switchover, and return are reproducibly tested. A good failover runbook describes expected health check states, routing and DNS behavior, observation points, and a controlled rollback path. The key is not the configured rule, but the demonstrable operational behavior.\nIntroduction Many failover architectures are configured once but never tested under realistic conditions. This is where an operational error lies: A backend can be removed from load balancing, while DNS caches, existing connections, health check intervals, or unclear rollback logic continue to produce different behavior. Testing failover means not only shutting down a server. It means validating states, timelines, and responsibilities. For publicly accessible services, routing, DNS, health checks, and the return to the primary system must be considered together.\n",
      "image": "https://ayedo.de/failover-testen-runbooks-zustande-und-ruckfallpfade.png",
      "date_published": "2026-09-07T13:54:40Z",
      "date_modified": "2026-09-07T13:54:40Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/",
      "url": "https://ayedo.de/en/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/",
      "title": "Backend Health Checks as a Foundation for Robust Failover",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-health-checks-als-grundlage-fur-belastbares-failover/backend-health-checks-als-grundlage-fur-belastbares-failover.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks provide the signals that an edge platform uses to distinguish between reachable and unreachable targets. Their significance depends on the checkpoint: network connection, process state, and actually usable service are different failure domains. Robust failover is achieved through appropriate check signals and controlled recovery.\u003c/p\u003e\n\u003cp\u003eA failover can only be as reliable as the signal it is based on. An accessible TCP port does not prove that an application processes requests correctly. Conversely, a single faulty application signal can mistakenly remove a healthy backend pool from routing. Health Checks are therefore not just an availability indicator but an operational decision logic: they influence which target receives traffic and when a backend is considered ready for use again.\u003c/p\u003e\n\u003cp\u003eIn a distributed edge architecture, this decision is made before reaching the actual backend. This reduces dependency on individual targets but increases responsibility for the quality of the check signals. Imprecise checks can prolong outages, remove healthy capacity from operation, or reintroduce an error state into traffic through premature recovery.\u003c/p\u003e\n\u003ch2 id=\"1-what-a-health-check-actually-measures\"\u003e1. What a Health Check Actually Measures\u003c/h2\u003e\n\u003cp\u003eA Health Check always answers a limited question. A network or Layer-4 check can show that a connection to a target can be established. This says something about reachability and an accessible listener, but not about database connections, application threads, or the processing of a realistic request.\u003c/p\u003e\n\u003cp\u003eAn HTTP-based check can better represent the application layer, provided the status and response content are meaningful. Even then, the checked path remains a snapshot of the overall system. A health endpoint can, for example, respond independently of a disrupted functional feature or only report the local process state.\u003c/p\u003e\n\u003cp\u003eFor the failover decision, it is crucial which failure domain the check covers: network, host, process, application, or dependent component. In the ayedo Edge Cloud, backend health checks form the basis for evaluating individual targets or backend pools and aligning routing and failover decisions accordingly. The technical question is not only whether a check fails, but whether its failure sufficiently represents the service\u0026rsquo;s usability.\u003c/p\u003e\n\u003ch2 id=\"2-misclassifications-occur-at-the-boundaries\"\u003e2. Misclassifications Occur at the Boundaries\u003c/h2\u003e\n\u003cp\u003eA backend failure is often modeled as a binary state: healthy or not healthy. In practice, there are intermediate states. A target may only reject certain requests, respond too late under high load, or be reachable from an edge location while a dependency is regionally disrupted.\u003c/p\u003e\n\u003cp\u003eThis results in false positives and false negatives. A false positive removes a functioning backend from routing. This reduces available capacity and can destabilize other targets due to additional load. A false negative keeps a truly unusable target in the pool. Clients then receive errors or timeouts, even though other backends would be available.\u003c/p\u003e\n\u003cp\u003eThe check location is also relevant. A check from the edge can see a different network path than an internal monitoring agent. Routing, firewall rules, or asymmetric reachability can therefore lead to different assessments. Health monitoring must consider this perspective. A global service is not automatically healthy just because a single target responds from a single checkpoint.\u003c/p\u003e\n\u003ch2 id=\"3-check-signals-must-match-the-failover-decision\"\u003e3. Check Signals Must Match the Failover Decision\u003c/h2\u003e\n\u003cp\u003eThe choice of signal is an architectural decision. For a TCP service, transport reachability can be a sensible minimal test. For HTTP or HTTPS applications, it should be checked whether the service responds as expected at the application level. Which response is considered healthy must match the operational model and should not merely represent a technical endpoint with little to do with the user function.\u003c/p\u003e\n\u003cp\u003eAt the same time, a check should not uncritically include all dependencies of the system. If the health endpoint fails with every temporary disruption of a downstream component, a local problem can remove the entire backend pool from routing. If the dependency is not considered, a formally reachable but practically unusable service remains active.\u003c/p\u003e\n\u003cp\u003eIn the ayedo Edge Cloud, these evaluations affect the distribution of incoming requests. This makes the semantics of the check operationally relevant: it decides not only on monitoring visibility but also on whether a single target continues to receive traffic or a failover to other targets or pools occurs. A health check should therefore represent the smallest meaningful failure domain relevant to the routing decision.\u003c/p\u003e\n\u003ch2 id=\"4-recovery-requires-controlled-state-transitions\"\u003e4. Recovery Requires Controlled State Transitions\u003c/h2\u003e\n\u003cp\u003eFailover is not complete once a target is identified as faulty. Equally critical is the recovery. A backend that responds again after a short disruption is not necessarily stable enough to immediately take on the full load. Individual successful checks can result from a transient state.\u003c/p\u003e\n\u003cp\u003eFor operations, two directions must therefore be considered: the transition from healthy to faulty and the return to the active pool. Consecutive check results, tolerated errors, and controlled re-admission reduce state flapping. Without such rules, a backend can be repeatedly excluded and included. This complicates analysis and generates additional load through changing connections or retries.\u003c/p\u003e\n\u003cp\u003eThe edge platform provides the routing and failover layer; however, the specific check logic must fit the service. Teams should determine which errors are considered temporary, when a pool is considered exhausted, and how a restored target is validated. Health monitoring and traffic control belong together but should not be confused: monitoring explains the state, failover changes the data path.\u003c/p\u003e\n\u003ch2 id=\"operational-scenario-reachable-but-not-usable\"\u003eOperational Scenario: Reachable but Not Usable\u003c/h2\u003e\n\u003cp\u003eA backend pool consists of multiple application targets. The process runs on all targets, and a simple network check remains successful. After a disruption of the shared database, the applications continue to answer connections but deliver errors or timeouts for productive requests.\u003c/p\u003e\n\u003cp\u003eA pure reachability check does not detect the service outage. An application-specific check that validates the relevant processing could remove the affected targets from routing. At the same time, this check should not deactivate the entire pool with every brief database delay. The decision therefore depends on the failure domain and the desired operational response: local failover, pool failover, or deliberate error visibility for the on-call service.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"are-successful-tcp-connections-a-sufficient-health-check\"\u003eAre successful TCP connections a sufficient health check?\u003c/h3\u003e\n\u003cp\u003eNo. They primarily prove network and listener reachability. For applications, it must also be assessed whether requests are processed at the relevant protocol and functional level.\u003c/p\u003e\n\u003ch3 id=\"why-can-an-overly-comprehensive-health-check-be-problematic\"\u003eWhy can an overly comprehensive health check be problematic?\u003c/h3\u003e\n\u003cp\u003eIt can transfer a local or dependent disruption to the entire backend pool. This removes more capacity from routing than the actual error requires.\u003c/p\u003e\n\u003ch3 id=\"what-should-be-checked-during-the-recovery-of-a-backend\"\u003eWhat should be checked during the recovery of a backend?\u003c/h3\u003e\n\u003cp\u003eNot just the first successful response. Stable check results and a controlled return to the active pool are crucial to prevent an unstable target from triggering a new error cycle.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks are not a neutral status display. They translate technical observations into routing and failover decisions and must therefore accurately represent the relevant failure domain. Network reachability, application health, and dependencies must be evaluated separately. The ayedo Edge Cloud integrates these backend evaluations into a distributed edge platform that controls traffic before the backends. Robust failover is not achieved through as many checks as possible, but through appropriate signals and controlled state transitions.\u003c/p\u003e\n",
      "summary": "\nTL;DR Backend Health Checks provide the signals that an edge platform uses to distinguish between reachable and unreachable targets. Their significance depends on the checkpoint: network connection, process state, and actually usable service are different failure domains. Robust failover is achieved through appropriate check signals and controlled recovery.\nA failover can only be as reliable as the signal it is based on. An accessible TCP port does not prove that an application processes requests correctly. Conversely, a single faulty application signal can mistakenly remove a healthy backend pool from routing. Health Checks are therefore not just an availability indicator but an operational decision logic: they influence which target receives traffic and when a backend is considered ready for use again.\n",
      "image": "https://ayedo.de/backend-health-checks-als-grundlage-fur-belastbares-failover.png",
      "date_published": "2026-09-07T13:54:39Z",
      "date_modified": "2026-09-07T13:54:39Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/backend-pools-im-failover-zustande-routing-und-recovery/",
      "url": "https://ayedo.de/en/posts/backend-pools-im-failover-zustande-routing-und-recovery/",
      "title": "Backend Pools in Failover: States, Routing, and Recovery",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-pools-im-failover-zustande-routing-und-recovery/backend-pools-im-failover-zustande-routing-und-recovery.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend pools are not a static directory of target systems but an operational model for load distribution, state assessment, and controlled recovery. Failover starts with health checks but only ends when fallback, consistency, and renewed resilience of the primary pool are verified. Without defined state transitions, returning to regular operations can create new failures.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA backend failover is not successful just because traffic is temporarily redirected to a backup target. What matters is how the backend pool evaluates states, derives routing decisions, and returns to regular operations after a disruption. A common architectural mistake is to view the secondary pool merely as a technical reserve. This leaves questions about data consistency, fallback, capacity, and the controlled resumption of the primary target unanswered. A robust model treats primary and backup targets as parts of a cohesive operational process. The edge handles public traffic control; the compute infrastructure remains responsible for applications, data, and their restart.\u003c/p\u003e\n\u003ch2 id=\"1-the-backend-pool-as-a-state-model\"\u003e1. The Backend Pool as a State Model\u003c/h2\u003e\n\u003cp\u003eA backend pool does not just describe a group of servers, services, or endpoints. It reflects which targets are fundamentally available, their priority, and under what conditions traffic may be routed to them. Health checks provide technical signals: reachability, response behavior, or the availability of a defined service endpoint.\u003c/p\u003e\n\u003cp\u003eFrom these signals, states such as \u0026ldquo;ready,\u0026rdquo; \u0026ldquo;degraded,\u0026rdquo; \u0026ldquo;unavailable,\u0026rdquo; or \u0026ldquo;recovering\u0026rdquo; emerge. It is important to distinguish between a single faulty backend and the failure of an entire pool. An individual target can be removed from load distribution while the pool remains active. Only when no sufficient capacity is available or defined error conditions occur is a backend failover triggered.\u003c/p\u003e\n\u003cp\u003eIn an edge platform like the ayedo Edge Cloud, health checks and load distribution combine into a routing decision. The pool thus becomes an operational abstraction: it determines which backends receive traffic and when a controlled switch to backup targets is necessary.\u003c/p\u003e\n\u003ch2 id=\"2-failover-is-a-routing-and-capacity-decision\"\u003e2. Failover is a Routing and Capacity Decision\u003c/h2\u003e\n\u003cp\u003eIn failover, traffic is not simply moved \u0026ldquo;somewhere.\u0026rdquo; The edge must select a target that is technically reachable and suitable for the expected load. A backup target may be available but only able to handle part of the normal traffic. Therefore, priorities, pool boundaries, and capacity assumptions belong together.\u003c/p\u003e\n\u003cp\u003eA sensible process first removes individual faulty backends from active load distribution. This allows a pool to continue operating in a degraded state without immediately switching all traffic. Only in the event of a pool failure or a defined minimum availability is the backup pool activated. This gradation prevents unnecessary switches and reduces state flapping.\u003c/p\u003e\n\u003cp\u003eThe consequences are also organizationally relevant. Teams must predefine whether the backup pool can fully serve the same application, provides only limited functionality, or if the switch merely ensures the availability of a static error page. The ayedo Edge Cloud supports this process through backend health checks, failover, and load distribution at the public entry point. However, the technical suitability and capacity of the backends remain the responsibility of the respective application and compute environment.\u003c/p\u003e\n\u003ch2 id=\"3-fallback-requires-controlled-state-transitions\"\u003e3. Fallback Requires Controlled State Transitions\u003c/h2\u003e\n\u003cp\u003eThe most challenging part of a failover often begins after stabilization. Once the primary pool is reachable again, it should not automatically take over the entire load immediately. A successful health check initially only proves that a checkpoint responds. It does not necessarily indicate that initialization, data consistency, dependencies, and scaling are complete.\u003c/p\u003e\n\u003cp\u003eA controlled recovery process therefore distinguishes at least between \u0026ldquo;reachable again,\u0026rdquo; \u0026ldquo;ready for limited traffic,\u0026rdquo; and \u0026ldquo;approved for regular operations.\u0026rdquo; During this phase, the primary pool can gradually return to load distribution. Parallel monitoring is necessary to ensure error rates, response times, and dependent systems remain stable. Only then should the backup pool be relieved or deactivated.\u003c/p\u003e\n\u003cp\u003eState consistency is particularly relevant. If write requests were processed during the failover, it must be clarified how the primary pool adopts this state. The edge can control routing and fallback but cannot replace technical data replication. In the ayedo Edge Cloud, recovery is therefore understood as an interplay of backend state, health checks, load distribution, and the operational mechanisms of the compute platform.\u003c/p\u003e\n\u003ch2 id=\"4-state-consistency-and-operations-in-an-active-active-model\"\u003e4. State Consistency and Operations in an Active-Active Model\u003c/h2\u003e\n\u003cp\u003eActive-active architectures change the failover logic. Multiple backends or locations can process traffic simultaneously; a failure does not necessarily lead to a complete switch between \u0026ldquo;primary\u0026rdquo; and \u0026ldquo;secondary.\u0026rdquo; Instead, faulty targets are removed from distribution while available targets take over the traffic. This can simplify recovery but increases the demands on consistency and capacity planning.\u003c/p\u003e\n\u003cp\u003eA backend pool therefore requires clear rules for the entry, exclusion, and resumption of targets. This includes suitable health check endpoints, defined thresholds, and a procedure against short-term state changes. Equally important is observability: traffic and usage statistics help assess the impact of a pool failure and the load during recovery.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud is designed as a distributed, active-active edge platform with its own network infrastructure and autonomous system for continuous traffic control. This does not replace a redundant application but creates a central place for routing, protection, and load distribution. Backend pools can thus be controlled independently of whether the actual workloads are operated at ayedo, in one\u0026rsquo;s own data center, or with another provider.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in a primary \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n cluster and maintains a second cluster with another provider. The primary pool initially loses individual backends. Health checks remove these targets, and the remaining instances take over the load. If the pool fails completely, the edge routes to the backup pool.\u003c/p\u003e\n\u003cp\u003eAfter repair, the primary pool reports successful checks again. An automatic full fallback would be risky if migrations, cache building, or scaling are still in progress. Instead, the primary pool is initially allowed limited access and evaluated based on operational data. Only with stable processing does it take over the regular load again. The backup pool remains active until the recovery process is complete.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"when-should-an-individual-backend-be-removed-from-the-pool\"\u003eWhen should an individual backend be removed from the pool?\u003c/h3\u003e\n\u003cp\u003eWhen health checks or defined error conditions show that this target does not reliably process requests. The entire pool should only fail if there is insufficient remaining capacity.\u003c/p\u003e\n\u003ch3 id=\"does-a-backup-pool-need-to-have-the-same-capacity-as-the-primary-pool\"\u003eDoes a backup pool need to have the same capacity as the primary pool?\u003c/h3\u003e\n\u003cp\u003eNo. It can also enable limited operations. However, this limitation must be known and considered in routing, communication, and load planning.\u003c/p\u003e\n\u003ch3 id=\"why-is-a-successful-health-check-not-enough-for-fallback\"\u003eWhy is a successful health check not enough for fallback?\u003c/h3\u003e\n\u003cp\u003eBecause reachability does not automatically mean application readiness, data consistency, or sufficient capacity. Recovery requires additional operational checks and controlled resumption.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eBackend failover is a state and operational model, not a single routing switch. Health checks, pool failure, backup routing, and fallback must reflect the same states and responsibilities. Those who do not define the recovery process merely shift the risk of failure to the restart. An edge platform like the ayedo Edge Cloud can bundle this traffic control provider-independently. The stability of the overall system, however, only arises through the interaction of edge, backends, data consistency, and operations.\u003c/p\u003e\n",
      "summary": "\nTL;DR Backend pools are not a static directory of target systems but an operational model for load distribution, state assessment, and controlled recovery. Failover starts with health checks but only ends when fallback, consistency, and renewed resilience of the primary pool are verified. Without defined state transitions, returning to regular operations can create new failures.\nIntroduction A backend failover is not successful just because traffic is temporarily redirected to a backup target. What matters is how the backend pool evaluates states, derives routing decisions, and returns to regular operations after a disruption. A common architectural mistake is to view the secondary pool merely as a technical reserve. This leaves questions about data consistency, fallback, capacity, and the controlled resumption of the primary target unanswered. A robust model treats primary and backup targets as parts of a cohesive operational process. The edge handles public traffic control; the compute infrastructure remains responsible for applications, data, and their restart.\n",
      "image": "https://ayedo.de/backend-pools-im-failover-zustande-routing-und-recovery.png",
      "date_published": "2026-09-07T13:54:39Z",
      "date_modified": "2026-09-07T13:54:39Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/",
      "url": "https://ayedo.de/en/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/",
      "title": "DNS-based Failover: TTL, Caching, and Downtime",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-basiertes-failover-ttl-caching-und-ausfallzeiten/dns-basiertes-failover-ttl-caching-und-ausfallzeiten.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS-based failover distributes requests to accessible targets but cannot redirect existing connections and does not take effect immediately everywhere due to caching. TTL, recursive resolvers, operating systems, and applications influence the switchover time. Anycast DNS and Multi-Provider DNS enhance controllability and resilience but do not completely eliminate this uncertainty.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eDNS-based failover is often equated with a quick switchover: A target becomes unreachable, the DNS entry changes, and clients automatically use an alternative backend. This assumption is technically simplistic. DNS distributes name resolutions, not already established connections. Additionally, TTL, recursive resolvers, local DNS caches, and application-specific caches determine when a change actually takes effect. This creates a central trade-off: DNS offers broad control across many clients and providers but no precise control over the timing of each individual switchover.\u003c/p\u003e\n\u003ch2 id=\"1-dns-controls-new-resolutions-not-existing-connections\"\u003e1. DNS Controls New Resolutions, Not Existing Connections\u003c/h2\u003e\n\u003cp\u003eIn a DNS-based failover, the response to a name resolution is altered. A resolver can return an alternative target instead of the previous IP address. This helps with new connections but does not reach already running TCP or TLS sessions. These remain until they are normally terminated or fail due to an error.\u003c/p\u003e\n\u003cp\u003eThe actual switchover time therefore depends not only on the detection of the failure. The duration of existing connections, retries at the application level, and client behavior also influence the interruption. A short-lived HTTP request reacts differently than a long-lived API connection or a streaming channel.\u003c/p\u003e\n\u003cp\u003eFor operational planning, this distinction is crucial: DNS failover is a mechanism for new connection attempts. It neither replaces session management nor application failover. Applications must be able to handle temporarily unreachable targets, for example, through timeouts, retry logic, and idempotent requests.\u003c/p\u003e\n\u003ch2 id=\"2-ttl-is-an-upper-limit-not-a-switchover-promise\"\u003e2. TTL is an Upper Limit, Not a Switchover Promise\u003c/h2\u003e\n\u003cp\u003eTTL specifies how long a DNS response can generally be cached. A low TTL can shorten the time until a new query. However, it does not guarantee that all clients will receive a new response exactly when it expires. Resolvers can perform queries at staggered times, and end devices or applications may use additional caches.\u003c/p\u003e\n\u003cp\u003eA high TTL typically reduces DNS queries and can relieve the infrastructure. In the event of a failure, however, it prolongs the binding to an unreachable target. A very low TTL improves responsiveness but increases dependency on DNS availability and the number of resolutions. Additionally, the TTL is ineffective if an application caches the address itself for longer.\u003c/p\u003e\n\u003cp\u003eThe sensible value therefore results from the failure model, not from the desire for the fastest possible switchover. For critical services, it should be tested how recursive resolvers, operating systems, libraries, and clients actually react. Only this observation turns a configured TTL into a reliable operational expectation.\u003c/p\u003e\n\u003ch2 id=\"3-anycast-dns-and-multi-provider-dns-enhance-resilience\"\u003e3. Anycast DNS and Multi-Provider DNS Enhance Resilience\u003c/h2\u003e\n\u003cp\u003eAnycast DNS distributes DNS queries across multiple accessible network nodes and uses routing to ensure resolvers reach an appropriate response point. This can improve the reachability of the DNS service and reduce dependency on a single location. The subsequent failover decision remains separate: Even a globally reachable DNS service can still deliver responses that individual clients have cached.\u003c/p\u003e\n\u003cp\u003eMulti-Provider DNS distributes authoritative DNS operations across multiple providers. This creates an additional failure boundary, for example, if a DNS provider itself becomes unreachable. At the same time, the requirements for configuration, monitoring, change processes, and consistency increase. A second provider is not an automatic failover if zones, health checks, or delegations are not coordinated.\u003c/p\u003e\n\u003cp\u003eAn edge platform like the ayedo Edge Cloud combines Anycast DNS and Multi-Provider DNS with its own network infrastructure and autonomous system. This strengthens independence in the public ingress path. However, the fundamental cache latency of DNS remains and must be considered in the architecture.\u003c/p\u003e\n\u003ch2 id=\"4-health-checks-detect-states-but-not-every-user-impact\"\u003e4. Health Checks Detect States, But Not Every User Impact\u003c/h2\u003e\n\u003cp\u003eHealth checks can verify whether a target is reachable or responds correctly to defined requests. Based on this, the DNS response can be adjusted to direct traffic to another target. However, several steps lie between detected disruption and effective switchover: The check must trigger, the authoritative response must be updated, resolvers must re-query, and clients must use the new address.\u003c/p\u003e\n\u003cp\u003eThe choice of the checkpoint is important. A check from a single network position can overlook regional routing or provider issues. A target can be reachable for the health check while an application is functionally disrupted. Conversely, a temporary error can lead to unnecessary switchovers. Thresholds, repetitions, and return logic therefore influence the stability of the failover.\u003c/p\u003e\n\u003cp\u003eOperationally, DNS failover requires traceable telemetry: Which targets are considered healthy, which responses are currently authoritatively issued, and how long do resolvers retain old data? The ayedo Edge Cloud provides backend health checks and failover as part of its edge functions. For assessing downtime, operators must still consider DNS caching and client behavior separately.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API at two locations and publishes it under a common DNS name. A health check detects that location A no longer provides valid responses. The authoritative DNS configuration then points to location B. New clients whose resolvers no longer use an old response reach B. Other clients continue to receive A as long as their resolver or application caches are valid. Existing connections to A additionally fail until the application performs a retry or re-establishes the connection.\u003c/p\u003e\n\u003cp\u003eA low TTL value reduces the expected delay but does not eliminate it. An Anycast DNS and Multi-Provider approach increases the availability of DNS control but does not replace application behavior for timeouts, retries, and sessions.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-a-ttl-of-a-few-seconds-equivalent-to-an-immediate-failover\"\u003eIs a TTL of a few seconds equivalent to an immediate failover?\u003c/h3\u003e\n\u003cp\u003eNo. It limits the intended cache duration but does not guarantee exact effectiveness. Resolvers, operating systems, and applications may adopt the switchover at different speeds.\u003c/p\u003e\n\u003ch3 id=\"can-dns-failover-shift-existing-connections-to-another-backend\"\u003eCan DNS failover shift existing connections to another backend?\u003c/h3\u003e\n\u003cp\u003eNo. DNS affects new resolutions. Existing TCP, TLS, or application sessions must expire, fail, or be re-established by the application.\u003c/p\u003e\n\u003ch3 id=\"what-does-anycast-dns-additionally-provide\"\u003eWhat does Anycast DNS additionally provide?\u003c/h3\u003e\n\u003cp\u003eAnycast DNS improves the reachability of the DNS entry point over distributed network paths. However, it neither eliminates old DNS responses in caches nor errors in the backends.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDNS-based failover is an effective control instrument for new connections but not a precise switch for all traffic. TTL and DNS caching determine how quickly changes become visible; health checks determine when a problem is detected. Anycast DNS and Multi-Provider DNS increase the resilience of the control path. The ayedo Edge Cloud integrates these mechanisms into a distributed edge platform. For reliable downtimes, companies must additionally plan sessions, retries, and application caches.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS-based failover distributes requests to accessible targets but cannot redirect existing connections and does not take effect immediately everywhere due to caching. TTL, recursive resolvers, operating systems, and applications influence the switchover time. Anycast DNS and Multi-Provider DNS enhance controllability and resilience but do not completely eliminate this uncertainty.\nIntroduction DNS-based failover is often equated with a quick switchover: A target becomes unreachable, the DNS entry changes, and clients automatically use an alternative backend. This assumption is technically simplistic. DNS distributes name resolutions, not already established connections. Additionally, TTL, recursive resolvers, local DNS caches, and application-specific caches determine when a change actually takes effect. This creates a central trade-off: DNS offers broad control across many clients and providers but no precise control over the timing of each individual switchover.\n",
      "image": "https://ayedo.de/dns-basiertes-failover-ttl-caching-und-ausfallzeiten.png",
      "date_published": "2026-09-07T13:54:39Z",
      "date_modified": "2026-09-07T13:54:39Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","development","kubernetes","hosting","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/",
      "url": "https://ayedo.de/en/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/",
      "title": "Routing-Based Failover for APIs and Web Applications",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/routing-basiertes-failover-fur-apis-und-webanwendungen/routing-basiertes-failover-fur-apis-und-webanwendungen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eRouting-based failover decides at the edge which accessible backend pool receives a request or connection. Unlike DNS failover, the client does not need to resolve a new target name first. This shortens the response path, makes health statuses immediately usable, and separates public access from the actual compute infrastructure.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA DNS entry cannot reliably reflect whether a specific backend pool is currently processing requests. DNS distributes names and addresses, while the actual availability decision becomes visible only during connection establishment and request processing. If failover is implemented solely via DNS, response time and effectiveness additionally depend on TTLs, resolvers, caches, and existing connections. Routing-based failover therefore intervenes at a different point: The edge receives the traffic, checks the reachability of configured backends, and directly selects the available pool for forwarding. This is particularly relevant for APIs and web applications with multiple operational locations or providers.\u003c/p\u003e\n\u003ch2 id=\"1-the-failover-decision-belongs-at-the-traffic-entry\"\u003e1. The Failover Decision Belongs at the Traffic Entry\u003c/h2\u003e\n\u003cp\u003eIn routing-based failover, the central decision lies between the client and the backend. The request first reaches a public edge endpoint. There, based on the protocol, the service, and the state of the backend pools, it is determined where the traffic will be forwarded. If the primary pool fails or is unreachable, the edge can route to an alternative pool.\u003c/p\u003e\n\u003cp\u003eAt Layer 4, this decision occurs at the level of connections and transport data. This is suitable for TCP-based services where the edge does not need to evaluate the application content. Layer 7 can additionally process HTTP or HTTPS traffic and distribute the respective web or API service at the application level. The key point in both cases is: The client remains at the public endpoint, while the internal target can change.\u003c/p\u003e\n\u003ch2 id=\"2-backend-health-checks-provide-the-basis-for-decision-making\"\u003e2. Backend Health Checks Provide the Basis for Decision-Making\u003c/h2\u003e\n\u003cp\u003eFailover is only reliable if the edge systematically evaluates the state of the backends. Health checks verify whether a backend or a backend pool is reachable and suitable for forwarding. It is important to distinguish between network reachability and actual service availability: An open TCP connection does not automatically mean that an API provides correct responses.\u003c/p\u003e\n\u003cp\u003eThe routing decision must also align with the pool model. A pool can contain multiple backends, while another pool serves as a fallback target. If the primary pool is deemed unavailable, the edge routes new connections or requests to the alternative pool. For operations, it is important to make state changes traceable. Traffic and usage statistics help recognize the impact of a failover and distinguish between backend problems, routing events, and normal load distribution.\u003c/p\u003e\n\u003ch2 id=\"3-direct-edge-decision-versus-dns-failover\"\u003e3. Direct Edge Decision versus DNS Failover\u003c/h2\u003e\n\u003cp\u003eDNS failover changes the response to a name resolution. Resolvers and clients then receive a different address or target. This approach can work but is tied to the DNS resolution path. TTLs are not always strictly adhered to, resolvers can cache responses, and existing connections do not automatically switch targets. Moreover, DNS primarily distributes addresses; the actual backend health must be integrated into the DNS logic.\u003c/p\u003e\n\u003cp\u003eRouting-based failover, on the other hand, decides when traffic enters at the edge. Name resolution still points to the public service, while the edge selects the reachable backend pool. This keeps the public address stable, and the failover path is not extended by additional DNS caches. DNS remains relevant for Anycast DNS and multi-provider DNS but does not replace the downstream routing decision for specific applications.\u003c/p\u003e\n\u003ch2 id=\"4-failover-also-changes-the-operational-architecture\"\u003e4. Failover Also Changes the Operational Architecture\u003c/h2\u003e\n\u003cp\u003eAn alternative backend pool is not just a technical switch. Applications must consider states, sessions, data storage, and dependencies across both targets. A stateless API service is usually easier to redirect than an application whose sessions or write accesses are tied to a single location. Routing can shift the traffic but cannot correct inconsistent data sets.\u003c/p\u003e\n\u003cp\u003eThe edge cloud separates public access from the compute infrastructure. Backends can be operated with ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in own \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters, or with other providers. Backend cloaking prevents internal target structures from becoming part of the public address space. A distributed multi-PoP architecture with an active-active principle also reduces dependence on a single edge location. Failover is thus treated as an interplay of reachability, routing, and application design—not as an isolated DNS configuration.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn API runs in parallel in two \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers. Both clusters are accessible via a common public service; one pool is primary, the other serves as a fallback target. The edge checks the backends and initially routes new API requests to the reachable primary pool. If its API service fails, the alternative pool takes over without clients needing to resolve a new DNS entry.\u003c/p\u003e\n\u003cp\u003eIn a DNS-based approach, a different address would first need to be published. Caches and existing connections can lead to a portion of the traffic still reaching the failed target. With edge routing, the public endpoint remains unchanged. However, the application must be designed for parallel states, data access, and possible request repetitions.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-routing-based-failover-completely-replace-dns\"\u003eDoes routing-based failover completely replace DNS?\u003c/h3\u003e\n\u003cp\u003eNo. DNS remains relevant for name resolution and for Anycast and multi-provider scenarios. Routing-based failover takes over the decision of which backend pool processes the already incoming traffic.\u003c/p\u003e\n\u003ch3 id=\"does-failover-apply-equally-to-layer-4-and-layer-7\"\u003eDoes failover apply equally to Layer 4 and Layer 7?\u003c/h3\u003e\n\u003cp\u003eThe basic principle applies to both levels. Layer 4 is connection-oriented, while Layer 7 processes HTTP or HTTPS traffic and can handle application services more distinctly.\u003c/p\u003e\n\u003ch3 id=\"what-happens-to-existing-connections\"\u003eWhat happens to existing connections?\u003c/h3\u003e\n\u003cp\u003eFailover primarily affects new connections or requests. Existing sessions may remain with the failed backend or fail and must be handled by the protocol and application.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eRouting-based failover shifts the availability decision to where the traffic is actually processed. This shortens the response path compared to a pure DNS redirection and keeps the public endpoint stable. For APIs and web applications, it is crucial to jointly plan health checks, backend pools, and application states. The ayedo Edge Cloud forms the upstream routing and protection layer—regardless of where the actual \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n or compute workloads are operated.\u003c/p\u003e\n",
      "summary": "\nTL;DR Routing-based failover decides at the edge which accessible backend pool receives a request or connection. Unlike DNS failover, the client does not need to resolve a new target name first. This shortens the response path, makes health statuses immediately usable, and separates public access from the actual compute infrastructure.\nIntroduction A DNS entry cannot reliably reflect whether a specific backend pool is currently processing requests. DNS distributes names and addresses, while the actual availability decision becomes visible only during connection establishment and request processing. If failover is implemented solely via DNS, response time and effectiveness additionally depend on TTLs, resolvers, caches, and existing connections. Routing-based failover therefore intervenes at a different point: The edge receives the traffic, checks the reachability of configured backends, and directly selects the available pool for forwarding. This is particularly relevant for APIs and web applications with multiple operational locations or providers.\n",
      "image": "https://ayedo.de/routing-basiertes-failover-fur-apis-und-webanwendungen.png",
      "date_published": "2026-09-07T13:54:39Z",
      "date_modified": "2026-09-07T13:54:39Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","development","operations","kubernetes","hosting"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/",
      "url": "https://ayedo.de/en/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/",
      "title": "Active-Active Architecture for Highly Available Platforms",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAn active-active architecture distributes edge functions across multiple PoPs, instead of maintaining a site as a passive backup. This makes failover and maintenance part of ongoing operational processes. For internal platform services, this means the public access, protection functions, and routing must be resilient themselves—regardless of where the backends are operated.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eHigh availability does not end at the cluster or data center edge. A platform service can have multiple backends and still fail if its central entry point relies on a single location, load balancer, or DNS system. This is where a frequently overlooked single point of failure arises: the upstream edge layer.\u003c/p\u003e\n\u003cp\u003eThe architectural decision between active-passive and active-active affects not only compute resources. It also determines how traffic is received, distributed, protected, and rerouted in case of disruptions. A distributed multi-PoP architecture with actively operated sites treats the edge as a shared platform component—not as a passive emergency site that only becomes relevant in a crisis.\u003c/p\u003e\n\u003ch2 id=\"1-active-active-begins-before-the-backend\"\u003e1. Active-Active Begins Before the Backend\u003c/h2\u003e\n\u003cp\u003eIn active-passive models, a primary site typically handles the traffic. A secondary site holds resources but only takes over after a disruption. This model can work if the switchover process is reliable, fast, and regularly tested. However, it creates an additional operational dependency: the passive path must be correctly activated, reachable, and sufficiently sized in case of failure.\u003c/p\u003e\n\u003cp\u003eActive-active, on the other hand, distributes processing across multiple simultaneously used PoPs. Each site is part of regular operations. If a PoP or part of its path fails, traffic can be processed through other active sites. This reduces dependency on a single switchover event.\u003c/p\u003e\n\u003cp\u003eFor platform services, this distinction is relevant because the edge entry often bundles multiple functions: Anycast L4 and L7 load balancing, TLS termination, WAF, DDoS protection, and routing to the backend. If these functions are concentrated at a single location, the platform remains vulnerable to outages despite redundant backends.\u003c/p\u003e\n\u003ch2 id=\"2-multi-pop-changes-the-failover-model\"\u003e2. Multi-PoP Changes the Failover Model\u003c/h2\u003e\n\u003cp\u003eFailover is not just about where traffic is directed after a failure. What matters is who detects the failure, at what level it is detected, and how the remaining path is evaluated. A DNS failover can cover different failure scenarios than Anycast-based routing or a backend health check.\u003c/p\u003e\n\u003cp\u003eIn a multi-PoP active-active architecture, these levels work together. The edge receives traffic in a distributed manner, checks the reachability of backends, and can remove faulty targets from distribution. This allows differentiation between a PoP failure, a network path failure, and an actual platform service failure.\u003c/p\u003e\n\u003cp\u003eThis also changes operational processes. Failover is not a rare emergency procedure but part of normal operations. Maintenance work, routing changes, and backend switches must be planned so that active paths can be controlled and modified. Regular tests are still necessary, but they test not just an unused backup path but the behavior of a continuously distributed system.\u003c/p\u003e\n\u003ch2 id=\"3-the-edge-remains-separate-from-compute\"\u003e3. The Edge Remains Separate from Compute\u003c/h2\u003e\n\u003cp\u003eActive-active at the edge does not automatically mean that backends are also operated in an active-active manner. A service can still run behind the edge in a single cluster, region, or with another provider. In this case, the edge increases the resilience of public access but does not eliminate backend failures.\u003c/p\u003e\n\u003cp\u003eThis separation is architecturally important. Edge functions handle public traffic entry, protection, termination, and load distribution. The compute infrastructure runs applications and platform components. For a robust failover model, both levels must be considered separately: What happens in case of a PoP failure? What if a cluster is unreachable? And what states should a backend health check consider as functional?\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud is designed for this separation as a distributed multi-PoP platform. Its own autonomous system and network infrastructure provide the framework for edge operations. Backends can be operated in ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in own clusters, or with other providers. This keeps the edge architecture decoupled from the chosen compute location.\u003c/p\u003e\n\u003ch2 id=\"4-high-availability-creates-operational-obligations\"\u003e4. High Availability Creates Operational Obligations\u003c/h2\u003e\n\u003cp\u003eAn active-active architecture reduces individual failure risks but does not automatically make operations easier. Multiple active paths mean more states that need to be monitored and evaluated. Routing, health checks, TLS configurations, WAF rules, and backend assignments must be consistently maintained.\u003c/p\u003e\n\u003cp\u003eDefining \u0026ldquo;healthy\u0026rdquo; is particularly critical. An accessible port does not prove that a platform service is usable. Health checks must match the respective service semantics and should not lead to unstable switching due to short-term errors. At the same time, a truly faulty backend must be quickly removed from traffic.\u003c/p\u003e\n\u003cp\u003eFor companies, this results in organizational consequences: network, platform, and application teams must define common failure scenarios. Runbooks should cover not only the failure of a cluster but also PoP, DNS, and routing scenarios. The active-active architecture is thus less a single feature than an operational model that connects technical responsibilities and tests across multiple levels.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an internal developer platform with API access, user interface, and automation services. The workloads run in two \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers. In an active-passive model, a central site handles all edge traffic; the backup path is only activated in case of a major failure.\u003c/p\u003e\n\u003cp\u003eIn an active-active architecture, traffic is received across multiple edge PoPs. A backend health check detects that a cluster no longer reliably provides the platform service and removes this target from distribution. If an edge PoP also fails, access remains available through other active PoPs. The application does not need to be operated at the same location as the edge. Failover is distributed across multiple levels instead of relying on a single switchover.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-active-active-the-same-as-two-active-kubernetes-clusters\"\u003eIs Active-Active the Same as Two Active Kubernetes Clusters?\u003c/h3\u003e\n\u003cp\u003eNo. Active-active can initially concern the edge. Whether multiple backends are used productively at the same time depends on the application, data model, and operational strategy.\u003c/p\u003e\n\u003ch3 id=\"does-anycast-replace-every-failover-mechanism\"\u003eDoes Anycast Replace Every Failover Mechanism?\u003c/h3\u003e\n\u003cp\u003eNo. Anycast distributes access but does not replace backend health checks or application-specific error detection and appropriate routing rules.\u003c/p\u003e\n\u003ch3 id=\"when-is-active-passive-sufficient\"\u003eWhen Is Active-Passive Sufficient?\u003c/h3\u003e\n\u003cp\u003eActive-passive can be sufficient if switchover, capacity, and data consistency are managed and regularly tested. The edge remains a separate failure domain.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eHigh availability is incomplete if only the compute level is redundantly designed. A single edge location can become a common point of failure despite multiple clusters. The active-active and multi-PoP architecture of the ayedo Edge Cloud classifies public access, protection, and failover as an independent platform layer. It remains crucial to plan edge and compute separately and consciously connect their failure and operational models.\u003c/p\u003e\n",
      "summary": "\nTL;DR An active-active architecture distributes edge functions across multiple PoPs, instead of maintaining a site as a passive backup. This makes failover and maintenance part of ongoing operational processes. For internal platform services, this means the public access, protection functions, and routing must be resilient themselves—regardless of where the backends are operated.\nIntroduction High availability does not end at the cluster or data center edge. A platform service can have multiple backends and still fail if its central entry point relies on a single location, load balancer, or DNS system. This is where a frequently overlooked single point of failure arises: the upstream edge layer.\n",
      "image": "https://ayedo.de/aktiv-aktiv-architektur-fur-hochverfugbare-plattformen.png",
      "date_published": "2026-09-07T13:49:18Z",
      "date_modified": "2026-09-07T13:49:18Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","operations","kubernetes","cloud-native","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/backend-cloaking-als-plattformstandard-fur-services/",
      "url": "https://ayedo.de/en/posts/backend-cloaking-als-plattformstandard-fur-services/",
      "title": "Backend Cloaking as a Platform Standard for Services",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-cloaking-als-plattformstandard-fur-services/backend-cloaking-als-plattformstandard-fur-services.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking separates the public service endpoint from the actual backend addresses. As a platform standard, it reduces the visible attack surface, facilitates network segmentation, and decouples service publication from internal infrastructure details. The ayedo Edge Cloud implements this separation at the edge—even for \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n outside of ayedo Managed Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA public service should not automatically reveal the address of its backend. However, in evolving platforms, direct dependencies often arise: DNS entries point to ingress addresses, firewall rules allow publicly accessible backend networks, or teams publish services with individual exceptions. This complicates rotation, migration, and incident response. Backend Cloaking sets a clear boundary here: Clients reach a public endpoint at the edge, while internal backend addresses remain outside the public visibility range. For an internal platform, it is crucial to establish this separation not as an optional special configuration but as a standard for service exposure.\u003c/p\u003e\n\u003ch2 id=\"1-public-endpoint-and-backend-are-different-roles\"\u003e1. Public Endpoint and Backend Are Different Roles\u003c/h2\u003e\n\u003cp\u003eA public endpoint is the address where a service is accessible to clients. The backend, on the other hand, is the technical target instance that processes requests. Both roles need not share the same IP address or network boundary. Backend Cloaking makes this distinction consistently visible in the data path.\u003c/p\u003e\n\u003cp\u003eThe client connects to the edge. There, routing, TLS termination, web application firewall, DDoS protection, and load balancing can occur before traffic is forwarded to the backend. For the client, the internal target address remains invisible. Only the public service endpoint and its intended properties are visible.\u003c/p\u003e\n\u003cp\u003eThis separation is more than a cosmetic DNS abstraction. Backend addresses can be changed, migrated, or replaced without republishing the public endpoint. The internal topology also does not need to be part of external documentation or client configuration. The ayedo Edge Cloud forms the public entry point for applications and APIs and keeps the backend target structure separate from this entry point.\u003c/p\u003e\n\u003ch2 id=\"2-less-visibility-improves-segmentation-and-security\"\u003e2. Less Visibility Improves Segmentation and Security\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking does not replace access controls. A backend must still be secured so that only the intended traffic reaches it. However, the reduced visibility lowers the number of directly addressable components, thereby supporting clearer network segmentation.\u003c/p\u003e\n\u003cp\u003eWithout this separation, public DNS entries, misconfigurations, or leaked configuration data can make internal addresses visible. This does not automatically mean that a backend is reachable, but it increases the attack surface for scans, misaccesses, and targeted attacks. When only the edge serves as the public entry point, network rules and monitoring can focus on this data path.\u003c/p\u003e\n\u003cp\u003eOperationally, there is another advantage: Backends do not need to be designed for arbitrary external networks. They can remain in private segments or within a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes network\u003c/a\u003e\n, while the edge takes over external accessibility. The ayedo Edge Cloud supports this model with Backend Cloaking, health checks, and failover. The specific securing of the backend path remains part of the respective network and platform architecture.\u003c/p\u003e\n\u003ch2 id=\"3-the-platform-standard-reduces-individual-service-exposure\"\u003e3. The Platform Standard Reduces Individual Service Exposure\u003c/h2\u003e\n\u003cp\u003eFor application teams, publishing a service becomes unnecessarily complicated if they have to coordinate public IPs, DNS, certificates, firewall rules, and backend accessibility themselves. At the same time, fully manual procedures lead to varying security levels. A platform standard shifts this responsibility to the central platform without cutting teams off from a clear service interface.\u003c/p\u003e\n\u003cp\u003eThe basic pattern can be defined as binding: A service receives a public endpoint at the edge; the backend remains internal and is connected via a controlled target configuration. Teams then do not have to decide whether their internal address may be published directly. Instead, they declare which service should be externally accessible and which backends should process the traffic.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/en/kubernetes/\"\u003eKubernetes-native\u003c/a\u003e\n integration is particularly relevant for this, as services and workloads are dynamically created. However, the approach is not limited to ayedo Managed Kubernetes. The ayedo Edge Cloud can also be used with Kubernetes clusters operated by others or by other providers. This keeps the publication pattern consistent across different compute environments.\u003c/p\u003e\n\u003ch2 id=\"4-cloaking-creates-decoupling-but-not-invisible-infrastructure\"\u003e4. Cloaking Creates Decoupling, But Not Invisible Infrastructure\u003c/h2\u003e\n\u003cp\u003eThe central architectural decision is not \u0026ldquo;edge instead of backend,\u0026rdquo; but \u0026ldquo;public entry separated from internal processing.\u0026rdquo; However, this decoupling brings requirements. Routing, health checks, failover, name resolution, and reachability between edge and backend must be operated unambiguously. A hidden backend is not automatically available or correctly segmented.\u003c/p\u003e\n\u003cp\u003eObservability must also reflect the two perspectives: client traffic at the public endpoint and forwarding to the internal target. Traffic and usage statistics at the edge help to separately consider external usage and forwarding behavior. For error analysis, platform teams must additionally include the transition to the backend and the application itself.\u003c/p\u003e\n\u003cp\u003eEconomically, a standard reduces the number of individual integrations and exceptions. This lowers operational effort in the long term because service exposure becomes repeatable. However, the benefit only arises if cloaking is mandatorily integrated into onboarding, approvals, and operational processes. An option that each team must activate themselves remains a special case and does not achieve the impact of a platform standard.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-a-service-across-multiple-clusters\"\u003ePractical Scenario: A Service Across Multiple Clusters\u003c/h2\u003e\n\u003cp\u003eA company operates an API in its own \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n and later migrates it to a cluster of another provider. In both cases, the same public endpoint should remain. Without cloaking, DNS, firewall rules, and client configuration would have to be adjusted to the respective new backend address.\u003c/p\u003e\n\u003cp\u003eWith an edge in front of both compute environments, the public endpoint remains unchanged. The platform swaps out the internal target, checks its availability via health checks, and forwards requests only to a valid backend. For clients, the address does not change; for the platform, the internal topology remains interchangeable. This does not automatically make the migration risk-free, but it removes the direct coupling between service exposure and backend address.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-backend-cloaking-prevent-all-direct-access-to-the-backend\"\u003eDoes Backend Cloaking prevent all direct access to the backend?\u003c/h3\u003e\n\u003cp\u003eNo. Cloaking reduces public visibility. Network rules, authentication, and backend policies must additionally ensure that only intended traffic is accepted.\u003c/p\u003e\n\u003ch3 id=\"is-backend-cloaking-only-relevant-for-kubernetes\"\u003eIs Backend Cloaking only relevant for Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNo. The principle applies to APIs, web applications, and other services. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n facilitates standardization because workloads and service targets are dynamically managed.\u003c/p\u003e\n\u003ch3 id=\"does-a-public-endpoint-have-to-permanently-point-to-the-same-backend\"\u003eDoes a public endpoint have to permanently point to the same backend?\u003c/h3\u003e\n\u003cp\u003eNo. A central edge can change targets or consider multiple backends via health checks and failover, while the public endpoint remains.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking should not be treated as an optional security feature in an internal platform, but as a standard for service exposure. The separation between public endpoint and internal backend reduces visibility, supports segmentation, and facilitates migrations across compute boundaries. The ayedo Edge Cloud implements this separation as part of its edge functionality—regardless of whether the backend is operated in ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, its own, or a third-party Kubernetes cluster.\u003c/p\u003e\n",
      "summary": "\nTL;DR Backend Cloaking separates the public service endpoint from the actual backend addresses. As a platform standard, it reduces the visible attack surface, facilitates network segmentation, and decouples service publication from internal infrastructure details. The ayedo Edge Cloud implements this separation at the edge—even for Kubernetes clusters outside of ayedo Managed Kubernetes.\nIntroduction A public service should not automatically reveal the address of its backend. However, in evolving platforms, direct dependencies often arise: DNS entries point to ingress addresses, firewall rules allow publicly accessible backend networks, or teams publish services with individual exceptions. This complicates rotation, migration, and incident response. Backend Cloaking sets a clear boundary here: Clients reach a public endpoint at the edge, while internal backend addresses remain outside the public visibility range. For an internal platform, it is crucial to establish this separation not as an optional special configuration but as a standard for service exposure.\n",
      "image": "https://ayedo.de/backend-cloaking-als-plattformstandard-fur-services.png",
      "date_published": "2026-09-07T13:49:18Z",
      "date_modified": "2026-09-07T13:49:18Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","security","cloud-native","digital-sovereignty"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/",
      "url": "https://ayedo.de/en/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/",
      "title": "Digital Sovereignty Through Separate Edge Responsibility",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/digitale-souveranitat-durch-getrennte-edge-verantwortung/digitale-souveranitat-durch-getrennte-edge-verantwortung.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDigital sovereignty is not achieved by avoiding cloud or platform providers, but through controllable architectural boundaries. By separating public access, routing, and security functions from the compute infrastructure, \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n can be operated more independently, providers can be switched, and security decisions can be enforced centrally. The ayedo Edge Cloud supports this model in front of own or external clusters.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n should not automatically assume responsibility for its public access. When DNS, TLS, DDoS protection, WAF, and traffic distribution are tightly coupled to a single cluster or cloud provider, switching platforms becomes technically and organizationally challenging. The issue does not lie with Kubernetes itself but with a mixed responsibility: compute, network access, and security functions are operated as a single unit. A separate edge responsibility creates a verifiable architectural boundary. It defines which components control public traffic and which infrastructure runs the applications. Digital sovereignty thus becomes a question of dependencies, operational processes, and technical portability.\u003c/p\u003e\n\u003ch2 id=\"1-digital-sovereignty-begins-at-the-public-interface\"\u003e1. Digital Sovereignty Begins at the Public Interface\u003c/h2\u003e\n\u003cp\u003eDigital sovereignty is often reduced to the choice of a cloud or infrastructure provider. However, for operating digital services, another question is crucial: who controls the path from the internet to the backend? This includes DNS resolution, IP addressing, TLS termination, routing, load balancing, and the enforcement of security policies.\u003c/p\u003e\n\u003cp\u003eIf this responsibility lies entirely with the compute provider, public endpoints are often closely tied to its network, load balancing, and security services. Changing the cluster may then also require changes to DNS zones, certificate processes, IP addresses, and access controls. This not only increases technical complexity but also complicates audits and standardized operational processes.\u003c/p\u003e\n\u003cp\u003eA more sovereign architecture therefore separates the control points. The edge processes the public traffic, while the compute infrastructure executes applications and workloads. This separation makes responsibilities verifiable: policies for external access are operated independently of internal deployment processes.\u003c/p\u003e\n\u003ch2 id=\"2-edge-and-compute-as-separate-areas-of-responsibility\"\u003e2. Edge and Compute as Separate Areas of Responsibility\u003c/h2\u003e\n\u003cp\u003eEdge and compute fulfill different tasks. The edge cloud receives incoming traffic, distributes it to healthy backends, and protects the downstream infrastructure. This includes, for example, Anycast-based Layer-4 and Layer-7 load balancing, Anycast DNS, multi-provider DNS, WAF, DDoS protection, and TLS termination. The compute infrastructure, on the other hand, provides the services and processes business logic.\u003c/p\u003e\n\u003cp\u003eThis separation changes the architectural boundary of a system. Backends do not need to be directly publicly accessible if backend cloaking concentrates public access on the edge. Health checks and failover can assess the availability of applications without shifting the entire traffic entry into the cluster. Proxy Protocol can pass relevant connection information to downstream systems if required for application or evaluation.\u003c/p\u003e\n\u003cp\u003eOperationally, a clearer responsibility model emerges: edge policies can be adjusted centrally, while teams deploy their clusters independently. This reduces coupling but does not completely replace it. Routing, backend accessibility, and security rules must be documented, tested, and coordinated among those responsible.\u003c/p\u003e\n\u003ch2 id=\"3-provider-independence-requires-technical-portability\"\u003e3. Provider Independence Requires Technical Portability\u003c/h2\u003e\n\u003cp\u003eA separate edge is particularly relevant when \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n should not be tied to a single operator. A cluster can be operated with ayedo Managed Kubernetes, in its own infrastructure, or with another provider. The public access remains anchored at the same edge layer instead of being redesigned with each cluster change.\u003c/p\u003e\n\u003cp\u003eThis is more than a deployment issue. A standardized edge entry can simplify migration paths: a new cluster is integrated as a backend, its accessibility is checked via health checks, and traffic is then controlled and switched. The application does not necessarily have to change its public identity. BYOIP can also be relevant if IP address spaces are part of governance, allowlisting, or organizational requirements.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud is not limited to Managed Kubernetes for this use. Its Kubernetes-native integration can also be used with clusters operated on their own or with other providers. Thus, provider independence becomes a concrete operational option, not an abstract contractual clause.\u003c/p\u003e\n\u003ch2 id=\"4-control-must-be-verifiable-in-operation\"\u003e4. Control Must Be Verifiable in Operation\u003c/h2\u003e\n\u003cp\u003eArchitecture diagrams alone do not prove digital sovereignty. What matters is whether a company can control responsibilities, changes, and failures in operation. This includes defined procedures for DNS changes, certificate management, backend failover, security rules, and the withdrawal of traffic routes. Also, the question of which systems are publicly visible must be regularly verifiable.\u003c/p\u003e\n\u003cp\u003eAn edge platform with its own network infrastructure and autonomous system creates a clearly defined technical domain for this. The distributed multi-PoP architecture and active-active principle also address the availability of the public access layer. This does not replace a complete resilience strategy: backends, data storage, and dependencies must be evaluated separately.\u003c/p\u003e\n\u003cp\u003eTraffic and usage statistics support operational control because they make changes in incoming traffic visible. For cloud governance, it is important that this information flows into operational processes: who is allowed to change routing? How is a provider change tested? What security requirements apply to each backend? Sovereignty is demonstrated in these verifiable processes.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates a \u003ca href=\"/en/kubernetes/\"\u003eKubernetes cluster\u003c/a\u003e\n with an external provider and plans a second environment in its own infrastructure in parallel. Without a separate edge, DNS, TLS, WAF, and load balancing must be set up and operated differently for both environments. This complicates a controlled switch.\u003c/p\u003e\n\u003cp\u003eWith a pre-positioned ayedo Edge Cloud, public entry and security functions remain centralized. Both clusters are connected as backends, evaluated via health checks, and initially used in parallel for testing. Traffic can then be gradually distributed to the new environment. If a backend fails, the edge can respond to the available environment. Compute providers remain interchangeable; edge responsibility remains as a separate operational layer.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-digital-sovereignty-possible-without-owning-a-cloud\"\u003eIs digital sovereignty possible without owning a cloud?\u003c/h3\u003e\n\u003cp\u003eYes. What matters is not full self-operation but control over critical architectural and operational decisions. A separate edge can reduce dependencies on the compute provider.\u003c/p\u003e\n\u003ch3 id=\"does-the-edge-cloud-replace-the-responsibility-of-the-kubernetes-team\"\u003eDoes the Edge Cloud replace the responsibility of the Kubernetes team?\u003c/h3\u003e\n\u003cp\u003eNo. It assumes public access, routing, and security functions. The Kubernetes team remains responsible for workloads, internal services, and the operational capability of applications.\u003c/p\u003e\n\u003ch3 id=\"what-role-does-byoip-play\"\u003eWhat role does BYOIP play?\u003c/h3\u003e\n\u003cp\u003eBYOIP can help maintain existing IP address spaces independently of the compute environment. This is relevant for allowlisting, governance, and controlled provider changes.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDigital sovereignty through edge means making technical dependencies visible and changeable. The separation of edge and compute creates a robust boundary: public access, routing, and security functions are operated independently of workload execution. The ayedo Edge Cloud supports this model with its own network infrastructure, autonomous system, and provider-independent \u003ca href=\"/en/kubernetes/\"\u003eKubernetes usage\u003c/a\u003e\n. Sovereignty arises not through demarcation but through clear responsibilities and controllable operational processes.\u003c/p\u003e\n",
      "summary": "\nTL;DR Digital sovereignty is not achieved by avoiding cloud or platform providers, but through controllable architectural boundaries. By separating public access, routing, and security functions from the compute infrastructure, Kubernetes clusters can be operated more independently, providers can be switched, and security decisions can be enforced centrally. The ayedo Edge Cloud supports this model in front of own or external clusters.\nIntroduction A Kubernetes cluster should not automatically assume responsibility for its public access. When DNS, TLS, DDoS protection, WAF, and traffic distribution are tightly coupled to a single cluster or cloud provider, switching platforms becomes technically and organizationally challenging. The issue does not lie with Kubernetes itself but with a mixed responsibility: compute, network access, and security functions are operated as a single unit. A separate edge responsibility creates a verifiable architectural boundary. It defines which components control public traffic and which infrastructure runs the applications. Digital sovereignty thus becomes a question of dependencies, operational processes, and technical portability.\n",
      "image": "https://ayedo.de/digitale-souveranitat-durch-getrennte-edge-verantwortung.png",
      "date_published": "2026-09-07T13:49:18Z",
      "date_modified": "2026-09-07T13:49:18Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","digital-sovereignty","security","cloud-native","politics"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/",
      "url": "https://ayedo.de/en/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/",
      "title": "An Edge Layer for Heterogeneous Kubernetes Clusters",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/eine-edge-schicht-fur-heterogene-kubernetes-cluster/eine-edge-schicht-fur-heterogene-kubernetes-cluster.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHeterogeneous \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n increase flexibility but also distribute routing, TLS, security, and failover across multiple implementations. A unified edge layer decouples the public ingress from cluster technologies and compute providers. The ayedo Edge Cloud performs these functions provider-independently, enabling consistent backend cloaking across multi-cluster architectures.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eIn multi-cluster architectures, public traffic is often directed straight to the respective ingress controllers of the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes environments\u003c/a\u003e\n. While this seems straightforward, it ties DNS, TLS, security mechanisms, and failover to specific clusters and providers. If the underlying infrastructure changes, external routing and security configurations must also be adjusted. The central architectural flaw is treating the cluster as the public entry point. A more sensible approach is a separate edge layer: it forms the stable public ingress, while Kubernetes clusters and other workloads operate as interchangeable backends behind it.\u003c/p\u003e\n\u003ch2 id=\"public-ingress-and-compute-must-be-separated\"\u003ePublic Ingress and Compute Must Be Separated\u003c/h2\u003e\n\u003cp\u003eKubernetes orchestrates workloads, services, and internal network paths. However, the public ingress of an application is a cross-infrastructure task. This includes Anycast DNS, routing, TLS termination, DDoS protection, web application firewall, health checks, and distributing requests to available backends.\u003c/p\u003e\n\u003cp\u003eImplementing these functions separately in each cluster creates multiple operational models. Each cluster can use its own ingress rules, certificate processes, security policies, and failover mechanisms. This complicates standards and increases the number of configuration points. Additionally, changing providers quickly becomes a routing migration.\u003c/p\u003e\n\u003cp\u003eA unified edge layer decouples these responsibilities. The ayedo Edge Cloud processes public traffic before it reaches the actual backends. These backends can operate in different Kubernetes environments, with various providers, or outside of Kubernetes. The cluster remains responsible for application execution; the edge controls access to it.\u003c/p\u003e\n\u003ch2 id=\"multi-cluster-without-provider-bound-public-routing\"\u003eMulti-Cluster Without Provider-Bound Public Routing\u003c/h2\u003e\n\u003cp\u003eHeterogeneous Kubernetes clusters arise from different requirements: one cluster may be operated by ayedo Managed Kubernetes, another in-house, or with a different cloud provider. Various Kubernetes versions, network models, and ingress implementations are also possible. For the application, these differences should not automatically lead to different public endpoints.\u003c/p\u003e\n\u003cp\u003eWith a unified Anycast-based Layer 4 and Layer 7 load balancing, the public service can be addressed before the clusters. The edge decides where to forward traffic based on the configured backend structure. Backend health checks allow unavailable targets to be removed from routing. Failover can thus be represented at the edge rather than in each individual cluster implementation.\u003c/p\u003e\n\u003cp\u003eThis reduces dependency on individual ingress controllers and providers. At the same time, internal cluster choice remains an architectural decision: active-active across multiple backends, prioritized failover, or separate distribution by service. The Edge Cloud provides public accessibility but does not require a unified internal cluster technology.\u003c/p\u003e\n\u003ch2 id=\"backend-cloaking-as-a-protection-and-decoupling-principle\"\u003eBackend Cloaking as a Protection and Decoupling Principle\u003c/h2\u003e\n\u003cp\u003eA public application should not necessarily expose the addresses of its Kubernetes services, nodes, or provider networks. Backend cloaking separates the public identity of a service from its actual origin targets. Clients communicate with the edge endpoint, while the backends remain hidden behind the edge.\u003c/p\u003e\n\u003cp\u003eThis has two technical consequences. First, changes to cluster addresses, providers, or internal routing paths do not automatically lead to changes in the public DNS. Second, the attack surface is reduced because the actual backend endpoints do not have to function as regular public entry points. Backend cloaking does not replace access controls within the cluster but prevents the edge architecture from exposing the backend structure externally.\u003c/p\u003e\n\u003cp\u003eFor heterogeneous Kubernetes clusters, this separation is particularly relevant. TLS can be terminated at the edge, while forwarding occurs via defined backend paths. Proxy Protocol can pass information about the original connection to backends, provided the downstream infrastructure supports it. This keeps logging, routing, and security controls between edge and cluster technically aligned.\u003c/p\u003e\n\u003ch2 id=\"unified-operation-instead-of-identical-clusters\"\u003eUnified Operation Instead of Identical Clusters\u003c/h2\u003e\n\u003cp\u003eA unified edge layer does not mean all Kubernetes clusters must be operated identically. Rather, it creates a common control surface for public traffic. DNS, WAF rules, DDoS protection, TLS termination, backend status, and traffic statistics can be centrally organized in front of different compute environments.\u003c/p\u003e\n\u003cp\u003eThis also changes responsibilities. The platform team defines the external service and its accessibility rules. The teams for the respective clusters are responsible for deployment, service discovery, and internal resilience. This allows organizational boundaries to be more clearly represented without each team having to rebuild the complete public routing and protection architecture.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud is not limited to ayedo Managed Kubernetes. It can also be used in front of Kubernetes clusters operated in-house or with other providers. The foundation is its own network infrastructure, its own autonomous system, and a distributed multi-PoP architecture in an active-active principle. The key is not the unification of compute but the decoupling of its public access.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-a-service-across-three-clusters\"\u003ePractical Scenario: A Service Across Three Clusters\u003c/h2\u003e\n\u003cp\u003eA company operates an API in three environments: in an ayedo Managed Kubernetes cluster, in its own Kubernetes cluster, and with another provider. Without a unified edge layer, each environment has its own public endpoint. DNS, TLS, WAF, and failover must be maintained differently depending on the ingress implementation.\u003c/p\u003e\n\u003cp\u003eAlternatively, the API is published via a unified edge endpoint. The ayedo Edge Cloud performs health checks on the three backends and distributes traffic according to a defined active-active or failover model. Clients see neither cluster addresses nor provider changes. If a backend fails, it can be removed from routing without changing the public service address. The clusters remain technically different but fulfill the same backend role towards the edge.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-each-cluster-need-to-use-the-same-ingress-controller\"\u003eDoes each cluster need to use the same ingress controller?\u003c/h3\u003e\n\u003cp\u003eNo. A unified edge layer decouples public routing from the specific ingress implementation. Reachable backends and a consistent target model for health checks and forwarding are important.\u003c/p\u003e\n\u003ch3 id=\"is-backend-cloaking-only-relevant-for-security\"\u003eIs backend cloaking only relevant for security?\u003c/h3\u003e\n\u003cp\u003eNo. It also reduces the coupling between public DNS and internal backend addresses. This allows clusters, providers, and routing paths to change without necessarily rebuilding the external service.\u003c/p\u003e\n\u003ch3 id=\"can-the-edge-also-serve-non-kubernetes-backends\"\u003eCan the edge also serve non-Kubernetes backends?\u003c/h3\u003e\n\u003cp\u003eYes. The Edge Cloud can combine \u003ca href=\"/en/kubernetes/\"\u003eKubernetes backends\u003c/a\u003e\n with other workloads. The key is backend reachability, not the use of a specific compute platform.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eHeterogeneous Kubernetes clusters are not a problem that needs to be solved by identical cluster implementations. The more robust architecture separates public ingress from compute execution. A unified edge layer consolidates routing, protection, TLS, and failover, while clusters and providers remain interchangeable backend environments. The ayedo Edge Cloud supports this model provider-independently, making backend cloaking and multi-cluster routing components of a consistent public infrastructure.\u003c/p\u003e\n",
      "summary": "\nTL;DR Heterogeneous Kubernetes clusters increase flexibility but also distribute routing, TLS, security, and failover across multiple implementations. A unified edge layer decouples the public ingress from cluster technologies and compute providers. The ayedo Edge Cloud performs these functions provider-independently, enabling consistent backend cloaking across multi-cluster architectures.\nIntroduction In multi-cluster architectures, public traffic is often directed straight to the respective ingress controllers of the Kubernetes environments . While this seems straightforward, it ties DNS, TLS, security mechanisms, and failover to specific clusters and providers. If the underlying infrastructure changes, external routing and security configurations must also be adjusted. The central architectural flaw is treating the cluster as the public entry point. A more sensible approach is a separate edge layer: it forms the stable public ingress, while Kubernetes clusters and other workloads operate as interchangeable backends behind it.\n",
      "image": "https://ayedo.de/eine-edge-schicht-fur-heterogene-kubernetes-cluster.png",
      "date_published": "2026-09-07T13:49:17Z",
      "date_modified": "2026-09-07T13:49:17Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","operations","hosting"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/",
      "url": "https://ayedo.de/en/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/",
      "title": "Boundaries of Responsibility Between Platform and Application",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/verantwortungsgrenzen-zwischen-plattform-und-anwendung/verantwortungsgrenzen-zwischen-plattform-und-anwendung.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA resilient operational model for the edge separates core protection and network functions from application-specific configuration. The platform team is responsible for DNS, TLS, DDoS Protection, and technical accessibility. The application team provides business requirements, WAF rules, and robust health check endpoints. Shared responsibility prevents blind spots in accountability.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany disruptions at the edge do not arise from missing functions but from unclear responsibilities. If no one is clearly responsible for DNS entries, certificates, WAF exceptions, or backend health checks, changes are either implemented too slowly or without sufficient review. It is particularly problematic to assume that the platform team must understand every application in detail or that the application team can independently manage network and protection functions. A viable model therefore defines not only responsibilities but also handovers, approvals, and technical interfaces. Platform engineering provides the framework; the application delivers the context.\u003c/p\u003e\n\u003ch2 id=\"1-dns-and-tls-belong-to-central-operational-responsibility\"\u003e1. DNS and TLS Belong to Central Operational Responsibility\u003c/h2\u003e\n\u003cp\u003eDNS and TLS termination are central edge functions impacting accessibility, security, and change processes. The platform team should therefore manage DNS zones, Anycast DNS or multi-provider DNS, certificate provisioning, and TLS parameters. It is also responsible for maintaining technical consistency across multiple applications and environments.\u003c/p\u003e\n\u003cp\u003eHowever, the application team must determine which hostnames are needed, which environments should be accessible, and what business dependencies exist. An application may require additional subdomains or separate endpoints for APIs. These requirements do not belong in the central platform logic.\u003c/p\u003e\n\u003cp\u003eThe separation reduces operational risks: certificate and DNS changes follow standardized processes, while application-specific decisions remain with the responsible team. It is important to have a clear escalation path for expiration, misconfiguration, and rollback. The edge can terminate TLS but cannot decide whether a particular hostname is still needed from a business perspective.\u003c/p\u003e\n\u003ch2 id=\"2-waf-and-ddos-protection-require-different-responsibilities\"\u003e2. WAF and DDoS Protection Require Different Responsibilities\u003c/h2\u003e\n\u003cp\u003eDDoS Protection is a platform-wide protection function. The platform team is responsible for activation, baseline configuration, monitoring, and the technical operation of protection mechanisms at the edge. This responsibility should not lie with individual application teams, as attacks can affect multiple services simultaneously and protection measures must operate independently of the backend.\u003c/p\u003e\n\u003cp\u003eA WAF, on the other hand, requires shared responsibility. The platform team provides the WAF as a central service, maintains baseline rules, and defines the secure framework for changes. The application team knows the specific HTTP and API patterns: allowed methods, special payloads, uploads, or deliberately necessary exceptions. It must document and test these requirements.\u003c/p\u003e\n\u003cp\u003eWAF exceptions should not serve as a permanent shortcut for unclear application errors. Each exception requires a business owner, a justification, and a review of its scope. This keeps protection centrally manageable without indiscriminately blocking legitimate application patterns. DDoS Protection remains infrastructural, while WAF configuration becomes a shared responsibility topic.\u003c/p\u003e\n\u003ch2 id=\"3-health-checks-separate-infrastructure-status-and-application-view\"\u003e3. Health Checks Separate Infrastructure Status and Application View\u003c/h2\u003e\n\u003cp\u003eBackend health checks are only reliable if the platform and application teams answer different questions. The platform team checks whether a backend is technically reachable: Is the service accessible via the expected protocol and port? Does the connection work from the edge\u0026rsquo;s perspective? Are timeouts, status codes, and failover correctly processed?\u003c/p\u003e\n\u003cp\u003eThe application team is responsible for the health check endpoint and its semantics. This endpoint should appropriately reflect the actual state of the application without unnecessarily depending on dependent systems. A process that is running but cannot process requests should not be falsely considered healthy. Conversely, a temporarily unnecessary auxiliary system should not automatically remove the entire backend from routing.\u003c/p\u003e\n\u003cp\u003eThis boundary is operationally crucial. The platform can redistribute traffic or remove backends from the pool in case of faulty checks. However, it cannot assess whether a business state is acceptable. For this, it needs defined criteria from the application team. If these are not agreed upon, unnecessary failovers or traffic to non-functional instances may occur.\u003c/p\u003e\n\u003ch2 id=\"4-backend-accessibility-is-not-solely-a-platform-problem\"\u003e4. Backend Accessibility Is Not Solely a Platform Problem\u003c/h2\u003e\n\u003cp\u003eThe edge can terminate, protect, and distribute traffic to backends. However, actual accessibility depends on several layers: routing, firewall rules, listeners, ports, proxy protocol, name resolution, return paths, and service configuration. The platform team is responsible for the edge-side connection and documents the technical requirements for a backend.\u003c/p\u003e\n\u003cp\u003eThe application team must ensure that the service listens on the agreed interface, processes the expected headers, and accepts connections from the intended network. This also includes consciously configuring specifics like proxy protocol or TLS between edge and backend. Backend cloaking can reduce public access to internal targets but does not replace correct segmentation and functioning return paths.\u003c/p\u003e\n\u003cp\u003eA binding interface is suitable for collaboration: service address, port, protocol, health check, timeout behavior, allowed source information, and responsible party. This turns \u0026ldquo;backend not reachable\u0026rdquo; into a verifiable error chain. The edge cloud can be used with ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n or with \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters of its own or other providers. The boundary of responsibility remains independent of the compute provider.\u003c/p\u003e\n\u003ch2 id=\"operational-scenario-a-new-api-is-published\"\u003eOperational Scenario: A New API Is Published\u003c/h2\u003e\n\u003cp\u003eAn application team wants to publish an API under \u003ccode\u003eapi.example.de\u003c/code\u003e. The platform team creates the DNS entry, provides TLS at the edge, and activates central DDoS Protection. Together, they determine which WAF baseline applies and whether the API requires special methods or payloads.\u003c/p\u003e\n\u003cp\u003eThe application team provides a health check endpoint and documents port, protocol, timeout, and expected behavior. The platform team checks technical accessibility and configures failover. If requests are blocked, the application team first analyzes the API pattern; the platform team evaluates the rule, logic, and scope of the WAF adjustment. No team changes the other\u0026rsquo;s responsibility, but both are responsible for the handover.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"who-should-approve-dns-and-certificate-changes\"\u003eWho should approve DNS and certificate changes?\u003c/h3\u003e\n\u003cp\u003eThe platform team operates DNS and TLS. The application team confirms hostnames, validity requirements, and business impacts. For critical changes, a documented joint approval is recommended.\u003c/p\u003e\n\u003ch3 id=\"who-is-responsible-for-a-waf-exception\"\u003eWho is responsible for a WAF exception?\u003c/h3\u003e\n\u003cp\u003eThe application team justifies the exception and describes the required behavior. The platform team reviews technical implementation, scope, and remaining risk.\u003c/p\u003e\n\u003ch3 id=\"is-a-tcp-health-check-sufficient-for-a-backend\"\u003eIs a TCP health check sufficient for a backend?\u003c/h3\u003e\n\u003cp\u003eOnly for technical accessibility. Whether the application can process requests must be checked by an application-specific health check with clear semantics.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eBoundaries of responsibility between the platform team and application team are a technical interface, not just an organizational issue. Central functions like DNS, TLS termination, and DDoS Protection require consistent platform operation. WAF rules, health check semantics, and backend requirements, on the other hand, need application context. The ayedo Edge Cloud supports this model as an independent edge platform in front of different backends and \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments. A precise shared responsibility agreement remains crucial.\u003c/p\u003e\n",
      "summary": "\nTL;DR A resilient operational model for the edge separates core protection and network functions from application-specific configuration. The platform team is responsible for DNS, TLS, DDoS Protection, and technical accessibility. The application team provides business requirements, WAF rules, and robust health check endpoints. Shared responsibility prevents blind spots in accountability.\nIntroduction Many disruptions at the edge do not arise from missing functions but from unclear responsibilities. If no one is clearly responsible for DNS entries, certificates, WAF exceptions, or backend health checks, changes are either implemented too slowly or without sufficient review. It is particularly problematic to assume that the platform team must understand every application in detail or that the application team can independently manage network and protection functions. A viable model therefore defines not only responsibilities but also handovers, approvals, and technical interfaces. Platform engineering provides the framework; the application delivers the context.\n",
      "image": "https://ayedo.de/verantwortungsgrenzen-zwischen-plattform-und-anwendung.png",
      "date_published": "2026-09-07T13:49:17Z",
      "date_modified": "2026-09-07T13:49:17Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["platform","security","operations","cloud-native","development"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/",
      "url": "https://ayedo.de/en/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/",
      "title": "Provider-Independent Edge Architecture in Platform Operations",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/providerunabhangige-edge-architektur-im-plattformbetrieb/providerunabhangige-edge-architektur-im-plattformbetrieb.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA provider-independent edge is not achieved merely by using multiple cloud providers. The key is who controls public accessibility, routing, protection, and failover. An independent network, \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n and a centrally operated edge platform decouple these functions from individual compute or Kubernetes providers. This makes migration capability and operational responsibility architecturally manageable.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMultiple \u003ca href=\"/en/kubernetes/\"\u003eKubernetes clusters\u003c/a\u003e\n across different providers do not automatically create a provider-independent edge. If DNS, public IP addresses, DDoS protection, TLS termination, and traffic distribution remain tied to a single provider, the critical entry path remains dependent. The typical architectural mistake is diversifying only the compute layer while keeping routing and protection centralized with the provider. A robust provider-independent edge therefore separates two areas of responsibility: the compute infrastructure runs applications, while the edge controls their public access. This separation is not merely an organizational formality but a decision about routing, security boundaries, and the long-term operational viability of a platform.\u003c/p\u003e\n\u003ch2 id=\"1-provider-independence-begins-with-the-network\"\u003e1. Provider Independence Begins with the Network\u003c/h2\u003e\n\u003cp\u003eAn independent \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n and network infrastructure create a standalone technical identity outside of individual cloud or Kubernetes providers. This is relevant because public accessibility is no longer fully tied to a compute provider\u0026rsquo;s network model. IP addressing, routing, and access to backends can be considered a platform responsibility.\u003c/p\u003e\n\u003cp\u003eHaving an autonomous system does not automatically mean independence from all external infrastructure. The edge still requires connectivity and must communicate with the networks where backends are operated. The difference lies in the control over the public entry and its architecture. With Bring Your Own IP, addressing can be aligned with the platform strategy, rather than treating external addresses as a migration issue with each provider change.\u003c/p\u003e\n\u003cp\u003eFor a multi-cloud network, this separation is crucial: providers become potential execution locations for workloads, not owners of the entire traffic path.\u003c/p\u003e\n\u003ch2 id=\"2-routing-and-protection-belong-in-a-unified-edge-layer\"\u003e2. Routing and Protection Belong in a Unified Edge Layer\u003c/h2\u003e\n\u003cp\u003eRouting alone does not solve provider dependency. A new compute provider can be connected as a backend, but without centralized protection and termination functions, different operational models emerge per provider. TLS, WAF rules, DDoS protection, health checks, and failover would then need to be configured and monitored separately.\u003c/p\u003e\n\u003cp\u003eAn edge platform consolidates these functions in front of the backends. The ayedo Edge Cloud processes incoming traffic through Anycast-based Layer 4 and Layer 7 load balancing, can terminate TLS at the edge, and offers WAF and DDoS protection with scrubbing at the edge. Backend cloaking reduces the direct visibility of the origin infrastructure. The specific compute environment remains interchangeable behind the edge without needing to redesign public access for each environment.\u003c/p\u003e\n\u003cp\u003eThis is an architectural decision: routing and protection are operated as independent platform services, not as by-products of a specific Kubernetes cluster.\u003c/p\u003e\n\u003ch2 id=\"3-operational-responsibility-shifts-deliberately\"\u003e3. Operational Responsibility Shifts Deliberately\u003c/h2\u003e\n\u003cp\u003eProvider independence does not automatically reduce operational effort. It shifts responsibility. Defining the edge as its own platform layer requires clear responsibilities for DNS, IP addressing, certificates, routing rules, backend connectivity, and incident response. Without these boundaries, only an additional abstraction with unclear ownership is created.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud supports this separation with Anycast DNS and multi-provider DNS, backend health checks and failover, and a distributed multi-PoP architecture following the active-active principle. Traffic and usage statistics help visualize the impact of routing and operational decisions. \u003ca href=\"/en/kubernetes/\"\u003eKubernetes-native integration\u003c/a\u003e\n enables use with both ayedo Managed Kubernetes and clusters operated independently or with other providers.\u003c/p\u003e\n\u003cp\u003eThis way, the edge is not tied to a specific cluster. Platform responsibility encompasses public traffic entry; compute layer teams continue to manage applications, clusters, and workloads.\u003c/p\u003e\n\u003ch2 id=\"4-vendor-lock-in-becomes-visible-at-interfaces\"\u003e4. Vendor Lock-in Becomes Visible at Interfaces\u003c/h2\u003e\n\u003cp\u003eVendor lock-in rarely appears in a single function. It arises at interfaces: proprietary IP models, provider-bound DNS configurations, tightly integrated load balancers, differing security policies, and lack of backend connectivity portability. The more these functions are implemented separately per cloud, the higher the migration risk and operational effort.\u003c/p\u003e\n\u003cp\u003eA provider-independent edge limits this lock-in by defining stable external interfaces. Applications do not need to know publicly which provider their backend runs on. The edge can distribute traffic based on central rules, check backends, and switch to alternative targets in case of failures. Proxy Protocol can transport relevant connection information for the backend side without relocating the entire edge function into the cluster.\u003c/p\u003e\n\u003cp\u003eTechnical honesty remains important: databases, storage, cluster APIs, or provider-dependent managed services do not automatically become portable. The edge decouples public access and protection functions. It does not replace a strategy for workload portability itself.\u003c/p\u003e\n\u003ch2 id=\"architecture-and-operational-scenario\"\u003eArchitecture and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates an API in two Kubernetes clusters: one cluster runs with ayedo, another with a different provider. Both clusters are connected as backends via the ayedo Edge Cloud. The public DNS entry, TLS termination, WAF rules, and DDoS protection are at the edge. Health checks detect if a backend is available; in case of a failure, traffic can be directed to the remaining target.\u003c/p\u003e\n\u003cp\u003eWhen switching providers, public access remains unchanged. The new backend is connected to the edge and gradually included in the distribution. Application teams migrate their workloads while network and edge responsibilities control external accessibility. This separation reduces the risk that a compute change simultaneously forces a change in the entire security and routing model.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-multi-cloud-automatically-provider-independent\"\u003eIs Multi-Cloud Automatically Provider-Independent?\u003c/h3\u003e\n\u003cp\u003eNo. Multiple compute providers only help if DNS, IP addressing, routing, protection, and failover are not still tied to a single provider.\u003c/p\u003e\n\u003ch3 id=\"what-role-does-the-autonomous-system-play\"\u003eWhat Role Does the Autonomous System Play?\u003c/h3\u003e\n\u003cp\u003eIt forms an independent network identity and supports control over the public traffic path. However, it does not replace a connectivity or portability strategy for backends.\u003c/p\u003e\n\u003ch3 id=\"is-the-edge-only-for-ayedo-managed-kubernetes\"\u003eIs the Edge Only for ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNo. The ayedo Edge Cloud can also be used with independently operated or other provider\u0026rsquo;s Kubernetes clusters.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eProvider-independent edge is an architectural decision about the public traffic path and associated operational responsibility. An independent \u003ca href=\"/en/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n, network infrastructure, and a centrally operated edge layer decouple routing, protection, and failover from individual compute providers. The ayedo Edge Cloud organizes these functions independently of the specific Kubernetes or cloud environment. This does not eliminate every vendor lock-in but creates a clearly defined and portable platform boundary.\u003c/p\u003e\n",
      "summary": "\nTL;DR A provider-independent edge is not achieved merely by using multiple cloud providers. The key is who controls public accessibility, routing, protection, and failover. An independent network, Autonomous System and a centrally operated edge platform decouple these functions from individual compute or Kubernetes providers. This makes migration capability and operational responsibility architecturally manageable.\nIntroduction Multiple Kubernetes clusters across different providers do not automatically create a provider-independent edge. If DNS, public IP addresses, DDoS protection, TLS termination, and traffic distribution remain tied to a single provider, the critical entry path remains dependent. The typical architectural mistake is diversifying only the compute layer while keeping routing and protection centralized with the provider. A robust provider-independent edge therefore separates two areas of responsibility: the compute infrastructure runs applications, while the edge controls their public access. This separation is not merely an organizational formality but a decision about routing, security boundaries, and the long-term operational viability of a platform.\n",
      "image": "https://ayedo.de/providerunabhangige-edge-architektur-im-plattformbetrieb.png",
      "date_published": "2026-09-07T13:49:17Z",
      "date_modified": "2026-09-07T13:49:17Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","operations","hosting"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/",
      "url": "https://ayedo.de/en/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/",
      "title": "Self-Service for DNS and Traffic at the Application Entry Point",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/self-service-fur-dns-und-traffic-am-anwendungseingang/self-service-fur-dns-und-traffic-am-anwendungseingang.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSelf-service DNS should not mean that application teams manage DNS zones, routing, and security decisions entirely on their own. An internal platform should offer standardized building blocks, fixed policies, and traceable approvals. This way, services are published faster while operations, security, and network responsibilities remain centrally manageable.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany platforms still treat the publication of a service as a ticket to network or infrastructure teams. This slows down releases, creates manual errors, and leads to inconsistent DNS and routing configurations. However, the opposite position is equally problematic: fully free changes by application teams merely shift critical responsibility to the wrong place. DNS failures, uncontrolled target changes, or missing protection mechanisms ultimately affect more than just the respective application. A more sensible approach is a self-service model with clear abstractions. Teams request and manage the public application entry through standardized interfaces, while central platform managers control policies, security boundaries, and operational capability.\u003c/p\u003e\n\u003ch2 id=\"1-self-service-begins-with-standardized-service-building-blocks\"\u003e1. Self-Service Begins with Standardized Service Building Blocks\u003c/h2\u003e\n\u003cp\u003eA viable self-service for DNS and traffic management does not provide individual technical parameters but complete, understandable building blocks. An application team should be able to set up a public service with a DNS name, TLS requirement, backend targets, health checks, and a defined routing model. The platform translates these specifications into the required configurations.\u003c/p\u003e\n\u003cp\u003eIt is important to separate user intent from implementation details. The team describes: \u0026ldquo;This service should be accessible under a specific domain and switch to an alternative target if the primary backend fails.\u0026rdquo; They do not need to configure nameservers, anycast routes, or proxy settings themselves.\u003c/p\u003e\n\u003cp\u003eVersioned templates, declarative configurations, and clearly defined service classes are suitable for self-service DNS. A simple class can publish a single service with standard health checks. A higher class can represent multi-provider DNS, failover, or special routing requirements. Each class needs traceable boundaries: allowed domains, target types, scope of changes, and responsibilities.\u003c/p\u003e\n\u003ch2 id=\"2-sensibly-distribute-dns-and-routing-responsibilities\"\u003e2. Sensibly Distribute DNS and Routing Responsibilities\u003c/h2\u003e\n\u003cp\u003eDNS is not just an entry in the zone file. TTLs, delegation, failover behavior, caching, and provider dependencies directly influence the recovery time and changeability of a service. Therefore, application teams should be able to make the necessary technical decisions without owning the entire DNS architecture.\u003c/p\u003e\n\u003cp\u003eAn internal platform can offer profiles for this purpose. A profile might specify whether a service is published via \u003ca href=\"/en/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n, whether multiple DNS providers are used, and what failover logic applies. Teams select the appropriate profile and provide the service-related parameters. The central platform is responsible for provider configuration, consistency, permissions, and monitoring.\u003c/p\u003e\n\u003cp\u003eThe same principle applies to traffic routing. Desired distributions such as primary and secondary backends, geographic distribution, or controlled migrations can be provided as standardized routing models. Free weightings or arbitrary target changes are often too risky. A platform team should verify whether a target is technically reachable, authorized, and secured by health checks. This way, self-service DNS remains fast without dissolving central operational responsibility.\u003c/p\u003e\n\u003ch2 id=\"3-security-boundaries-must-be-part-of-the-self-service\"\u003e3. Security Boundaries Must Be Part of the Self-Service\u003c/h2\u003e\n\u003cp\u003eThe public application entry is a security and operational boundary. Therefore, a platform for DNS and traffic should not only automate accessibility. It must also define which services can be published, which backends are reachable, and which protection functions are mandatory.\u003c/p\u003e\n\u003cp\u003eIn an edge platform like the ayedo Edge Cloud, such building blocks can be combined with \u003ca href=\"/en/kubernetes/\"\u003eAnycast-based Layer-4 and Layer-7 load balancing\u003c/a\u003e\n, TLS termination, web application firewall, DDoS protection, and backend cloaking. The application team requests a service and receives a defined protection profile instead of having to assemble individual security components themselves. Backend cloaking prevents internal target structures from becoming part of the public design.\u003c/p\u003e\n\u003cp\u003ePermissions and changes are also part of the model. Teams should only manage domains and backends within their responsibility. Changes must be traceable, validatable, and as reversible as possible. Additional approvals or time-limited permissions may be required for critical routing changes. Self-service then does not reduce governance but shifts it to verifiable platform rules.\u003c/p\u003e\n\u003ch2 id=\"4-the-platform-must-cover-the-entire-lifecycle\"\u003e4. The Platform Must Cover the Entire Lifecycle\u003c/h2\u003e\n\u003cp\u003eA DNS entry is only successfully provided if the underlying service can also be operated. Therefore, the self-service should cover the lifecycle from publication to decommissioning. This includes ownership information, expiration rules, health check status, change history, and clear assignment to an application or team.\u003c/p\u003e\n\u003cp\u003eFor \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environments, declarative integration is particularly useful. Publication can be initiated from the service or ingress configuration without the cluster itself becoming the public DNS and traffic authority. This applies to both ayedo Managed Kubernetes and self-managed or other provider-operated Kubernetes clusters. The Edge Cloud remains the central platform for the public entry, while compute and workload operations remain separate.\u003c/p\u003e\n\u003cp\u003eOperational data must also be available. Traffic and usage statistics help teams identify misconfigurations and unexpected usage. Platform managers additionally need an overarching view of failover, routing changes, and resource consumption. This separation creates clear responsibilities: teams are responsible for their services, the platform is responsible for the functionality and rules of the public entry.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates multiple Kubernetes clusters with different providers. A team publishes an API service via a self-service portal or a declarative platform definition. It selects a service class with \u003ca href=\"/en/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n, TLS termination, standard health checks, and a primary and secondary backend. The platform checks domain and target permissions, generates the necessary configuration, and binds the service to the specified protection profile.\u003c/p\u003e\n\u003cp\u003eIf the primary backend fails, the defined failover takes effect. The team does not need to configure DNS providers individually or manage public backend addresses. During a migration, routing can be adjusted in a controlled manner. The central platform maintains control over policies, auditability, and security boundaries.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-self-service-dns-fully-open-for-every-team\"\u003eIs self-service DNS fully open for every team?\u003c/h3\u003e\n\u003cp\u003eNo. Teams should be able to manage service-related settings. Domain spaces, routing models, target types, and security profiles must be limited by central policies.\u003c/p\u003e\n\u003ch3 id=\"when-is-multi-provider-dns-useful\"\u003eWhen is multi-provider DNS useful?\u003c/h3\u003e\n\u003cp\u003eWhen DNS availability and provider independence are important requirements. However, the additional complexity in synchronization, testing, and operation must be consciously assumed.\u003c/p\u003e\n\u003ch3 id=\"can-the-edge-cloud-be-used-with-external-kubernetes-clusters\"\u003eCan the Edge Cloud be used with external Kubernetes clusters?\u003c/h3\u003e\n\u003cp\u003eYes. The ayedo Edge Cloud can be used with ayedo Managed Kubernetes as well as with self-managed or other provider-operated Kubernetes clusters.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eGood self-service for DNS and traffic management is a platform product, not free access to infrastructure parameters. Application teams receive standardized ways to publish and change their services. Network, routing, and security responsibilities remain where they belong: with the platform organization. The ayedo Edge Cloud supports this model as a provider-independent public entry with \u003ca href=\"/en/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n, traffic control, and integrated protection functions.\u003c/p\u003e\n",
      "summary": "\nTL;DR Self-service DNS should not mean that application teams manage DNS zones, routing, and security decisions entirely on their own. An internal platform should offer standardized building blocks, fixed policies, and traceable approvals. This way, services are published faster while operations, security, and network responsibilities remain centrally manageable.\nIntroduction Many platforms still treat the publication of a service as a ticket to network or infrastructure teams. This slows down releases, creates manual errors, and leads to inconsistent DNS and routing configurations. However, the opposite position is equally problematic: fully free changes by application teams merely shift critical responsibility to the wrong place. DNS failures, uncontrolled target changes, or missing protection mechanisms ultimately affect more than just the respective application. A more sensible approach is a self-service model with clear abstractions. Teams request and manage the public application entry through standardized interfaces, while central platform managers control policies, security boundaries, and operational capability.\n",
      "image": "https://ayedo.de/self-service-fur-dns-und-traffic-am-anwendungseingang.png",
      "date_published": "2026-09-07T13:49:17Z",
      "date_modified": "2026-09-07T13:49:17Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","software-delivery","operations","kubernetes","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/edge-funktionen-als-produkt-der-internen-plattform/",
      "url": "https://ayedo.de/en/posts/edge-funktionen-als-produkt-der-internen-plattform/",
      "title": "Edge Functions as a Product of the Internal Platform",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-funktionen-als-produkt-der-internen-plattform/edge-funktionen-als-produkt-der-internen-plattform.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAn internal developer platform should not treat edge functions as individual infrastructure tasks. TLS termination, DNS, load balancing, and backend health checks are provided as standardized platform services with clear interfaces, responsibilities, and operational models. This creates a reusable platform product for different application teams and runtime environments.\u003c/p\u003e\n\u003cp\u003eIn many companies, the edge is still operated like a one-time configured infrastructure component: A team sets up DNS, certificates, load balancing, and health checks for an application, documents the configuration, and then hands it over to operations. This model works as long as there are few services with similar requirements. However, as the number of applications grows, individual exceptions, inconsistent operational processes, and unclear responsibilities emerge.\u003c/p\u003e\n\u003cp\u003eThe crucial shift in perspective is: Edge services are not a collection of individual configuration tasks but a platform product. An internal platform provides them through defined interfaces, describes their use in understandable operational models, and delineates responsibilities between platform and application teams. Thus, platform engineering edge becomes a matter of product design, not just network automation.\u003c/p\u003e\n\u003ch2 id=\"1-platform-services-begin-with-clear-user-groups\"\u003e1. Platform Services Begin with Clear User Groups\u003c/h2\u003e\n\u003cp\u003eA platform product first needs a defined target audience. For edge services, these can be teams operating public HTTP or HTTPS applications, API owners, platform teams with \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, or operators of workloads outside the central compute environment. These groups do not necessarily require the same technical depth or operational options.\u003c/p\u003e\n\u003cp\u003eThe internal platform should therefore not primarily offer technical individual parameters but user-oriented services. For example, a team might request a public HTTPS endpoint with TLS termination, an L7 load balancer, and backend health checks. Another might need layer-4 load balancing for a non-HTTP-based service. DNS, backend targets, and failover are described through a consistent interface.\u003c/p\u003e\n\u003cp\u003eIt is important to separate desire from implementation. Application teams do not need to know at which edge location a request is processed or how routing is implemented internally. However, they must know what properties are guaranteed, what inputs are required, and what impact a configuration change has. The platform abstracts complexity without hiding operational consequences.\u003c/p\u003e\n\u003ch2 id=\"2-interfaces-make-edge-functions-reusable\"\u003e2. Interfaces Make Edge Functions Reusable\u003c/h2\u003e\n\u003cp\u003eReusability does not arise solely from automation. It depends on stable interfaces and standardized lifecycles. A platform must define how a service is created, changed, verified, and removed. This includes validations for DNS names, backend targets, TLS configurations, and health check parameters.\u003c/p\u003e\n\u003cp\u003eFor application teams, it is also relevant which parts can be changed independently. A platform can offer a standard class for public HTTPS services and define variants for special requirements. It is crucial that these variants are described as comprehensible products and not as a freely combinable collection of hard-to-understand options.\u003c/p\u003e\n\u003cp\u003eIn the \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n environment, provisioning can be integrated into declarative workflows. This applies not only to ayedo Managed Kubernetes but also to own clusters or Kubernetes environments with other providers. The edge remains an independent area of responsibility: Kubernetes describes the workload and its accessibility, while the edge handles the public entry, TLS termination, routing, and distribution to the backend.\u003c/p\u003e\n\u003ch2 id=\"3-operational-models-define-responsibility-and-risk\"\u003e3. Operational Models Define Responsibility and Risk\u003c/h2\u003e\n\u003cp\u003eA platform product is only robust when its operational model is clear. The application team typically takes responsibility for the accessibility and functionality of its application. The platform team, on the other hand, is responsible for the provided edge services, their interfaces, and the technical implementation of the public entry. Without this separation, disruptions quickly become questions of responsibility.\u003c/p\u003e\n\u003cp\u003eBackend health checks show why this delineation is necessary. A check is not automatically meaningful just because an endpoint is technically reachable. Application teams must determine which dependencies are relevant for accepting traffic. The platform team must ensure that faults are detected and failover mechanisms can be used if necessary. Both sides need common guidelines and visible operational information.\u003c/p\u003e\n\u003cp\u003eSecurity is also part of the product model. TLS termination at the edge shifts a security-relevant processing step from the backend to a centrally operated platform. Additional edge functions like WAF, DDoS protection, or backend cloaking can be categorized as defined service variants. The question is not whether every application receives all functions, but which protection and operational profiles are offered.\u003c/p\u003e\n\u003ch2 id=\"4-a-platform-product-needs-measurable-quality\"\u003e4. A Platform Product Needs Measurable Quality\u003c/h2\u003e\n\u003cp\u003eThe quality of an internal platform is not only evident in whether a new endpoint is quickly created. What matters is whether teams can reliably understand, use, and operate the service. This includes documented interfaces, comprehensible states, clear change processes, and traffic and usage statistics for the affected services.\u003c/p\u003e\n\u003cp\u003eFor the platform organization, this means treating edge services like an internal product. User feedback, recurring operational problems, and change requests flow into further development. At the same time, standards must be consistent enough so that the platform does not become a collection of individual exceptions. Each new option increases the complexity of the interface and operations.\u003c/p\u003e\n\u003cp\u003eArchitecturally, the ayedo Edge Cloud is relevant as a cohesive platform: It combines Anycast-based layer-4 and layer-7 load balancing, Anycast DNS or multi-provider DNS, TLS termination, and backend health checks. The underlying own network infrastructure, the autonomous system, and the active-active architecture are not product details for application teams but important foundations for the operational model of the platform organization.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eA company operates several \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters with different providers as well as individual legacy applications outside of Kubernetes. Without a platform product, each team configures DNS, certificates, and load balancing in its own way. In case of disruptions, it is unclear which health checks are active and who is responsible for failover decisions.\u003c/p\u003e\n\u003cp\u003eAs a counter-model, the internal platform offers three standardized profiles: HTTPS service with TLS termination and L7 routing, TCP service with L4 load balancing, and a service with extended protection functions. All profiles use the same basic interfaces for DNS, backends, and health checks. Application teams remain responsible for their backends; the platform operates the public entry. ayedo Edge Cloud can be used as an edge layer independent of the respective Kubernetes or cloud provider.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-the-edge-then-just-a-kubernetes-service\"\u003eIs the edge then just a Kubernetes service?\u003c/h3\u003e\n\u003cp\u003eNo. Kubernetes can integrate provisioning but is not a prerequisite. The Edge Cloud can also be deployed in front of own clusters, cross-provider environments, and non-containerized backends.\u003c/p\u003e\n\u003ch3 id=\"what-interfaces-should-an-edge-platform-product-offer\"\u003eWhat interfaces should an edge platform product offer?\u003c/h3\u003e\n\u003cp\u003eAt a minimum, service profile, DNS names, TLS requirements, backend targets, health check behavior, change process, and responsibilities. The key is understandable semantics, not the number of technical options.\u003c/p\u003e\n\u003ch3 id=\"does-every-application-team-have-to-manage-edge-configurations-themselves\"\u003eDoes every application team have to manage edge configurations themselves?\u003c/h3\u003e\n\u003cp\u003eNot necessarily. Teams can submit declarative requirements while the platform handles implementation and operations. Self-management is sensible when approvals, validations, and responsibilities are clearly defined.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eEdge services become a platform product when they are available to defined user groups through stable interfaces with clear operational models. TLS termination, DNS, load balancing, and health checks are then no longer individual tickets but reusable building blocks of the internal developer platform. The ayedo Edge Cloud supports this model as an independent edge layer in front of applications and APIs—regardless of where the compute workloads are operated.\u003c/p\u003e\n",
      "summary": "\nTL;DR An internal developer platform should not treat edge functions as individual infrastructure tasks. TLS termination, DNS, load balancing, and backend health checks are provided as standardized platform services with clear interfaces, responsibilities, and operational models. This creates a reusable platform product for different application teams and runtime environments.\nIn many companies, the edge is still operated like a one-time configured infrastructure component: A team sets up DNS, certificates, load balancing, and health checks for an application, documents the configuration, and then hands it over to operations. This model works as long as there are few services with similar requirements. However, as the number of applications grows, individual exceptions, inconsistent operational processes, and unclear responsibilities emerge.\n",
      "image": "https://ayedo.de/edge-funktionen-als-produkt-der-internen-plattform.png",
      "date_published": "2026-09-07T13:49:16Z",
      "date_modified": "2026-09-07T13:49:16Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","platform","cloud-native","development"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/",
      "url": "https://ayedo.de/en/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/",
      "title": "Kubernetes and Edge Cloud as a Unified Platform Boundary",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eA unified deployment of multiple \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters doesn\u0026rsquo;t start with Ingress resources, but with a clear platform boundary. Kubernetes manages workloads and internal services; the provider-independent edge handles public traffic, protection, TLS, routing, and failover. This creates a unified Kubernetes Edge Integration for managed and external clusters.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany Kubernetes architectures treat each cluster as a complete deployment unit: its own Ingress, public IPs, DNS, and separate protection mechanisms. This works as long as an application is operated in only one environment. However, with ayedo Managed Kubernetes, own clusters, or clusters across multiple providers, duplicate entry points and different operational models emerge. The central architectural flaw is equating the Ingress layer with the public edge. A robust platform therefore separates two areas of responsibility: Kubernetes publishes services within its operational boundaries, while a common edge layer coordinates provider-independent access in front of multiple clusters.\u003c/p\u003e\n\u003ch2 id=\"1-the-platform-boundary-between-cluster-and-edge\"\u003e1. The Platform Boundary Between Cluster and Edge\u003c/h2\u003e\n\u003cp\u003eKubernetes is responsible for running and orchestrating workloads. This includes deployments, services, pods, internal service discovery, and regulating how traffic reaches a destination within a cluster. An Ingress or gateway can additionally map HTTP routes and terminate TLS connections. However, these functions initially pertain to a single cluster and its network model.\u003c/p\u003e\n\u003cp\u003eThe Edge Cloud lies one level ahead. It forms the public entry point for applications and APIs, receives traffic via Anycast, and distributes it to defined backends. It can combine Layer-4 and Layer-7 load balancing, TLS termination, WAF, DDoS protection, and backend health checks. The edge does not decide which pod within a cluster processes the request. It decides which cluster or backend receives the request.\u003c/p\u003e\n\u003cp\u003eThis separation is crucial for a Kubernetes platform. It prevents public accessibility, application protection, and failover from needing to be modeled separately in each cluster. At the same time, cluster-internal mechanisms remain where they belong: within the responsibility of the respective Kubernetes team.\u003c/p\u003e\n\u003ch2 id=\"2-unified-routing-across-multiple-clusters\"\u003e2. Unified Routing Across Multiple Clusters\u003c/h2\u003e\n\u003cp\u003eCross-cluster routing requires a routing model that does not depend on the identity of a single provider. A hostname or API endpoint can point to multiple backends: for example, to a cluster at ayedo, to an own Kubernetes environment, or to a cluster of another cloud provider. The edge evaluates the reachability of these backends and can distribute traffic accordingly or redirect it in case of failures.\u003c/p\u003e\n\u003cp\u003eIt is important to distinguish between global and local routing. The edge determines the broad target environment. The Ingress in the target cluster then takes over the specific forwarding to services and workloads. A request can thus first reach the edge via Anycast, then be forwarded to a healthy cluster and delivered there to a service via Ingress rules.\u003c/p\u003e\n\u003cp\u003eFor this chain to function stably, responsibilities and identities must be clearly defined. Hostnames, paths, TLS states, and health check criteria should not be modeled contradictorily across multiple levels. Backend cloaking can also prevent the direct addresses of the clusters from becoming publicly visible. This reduces the coupling between external routing and the specific network topology.\u003c/p\u003e\n\u003ch2 id=\"3-common-security-and-operational-functions\"\u003e3. Common Security and Operational Functions\u003c/h2\u003e\n\u003cp\u003eWithout a central edge, security and operational differences often arise between clusters. One cluster uses its own TLS rules, another a different WAF approach; DDoS protection and logging are configured multiple times. Technically, this is possible, but organizationally it increases the number of control points and complicates consistent change.\u003c/p\u003e\n\u003cp\u003eA common edge layer bundles functions that should be executed before entering Kubernetes. These include TLS termination, web application firewall, and DDoS protection. The backends can be monitored via health checks, while failover rules control the transition to an alternative environment. Traffic and usage statistics provide a common view of external usage, regardless of which cluster the application runs in.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud is designed for this approach as a distributed multi-PoP platform with its own network infrastructure and autonomous system. The active-active principle affects edge availability, not the automatic high availability of every Kubernetes workload. Applications, databases, and state models must still be planned at the cluster and application level.\u003c/p\u003e\n\u003ch2 id=\"4-kubernetes-native-integration-without-provider-lock-in\"\u003e4. Kubernetes-Native Integration Without Provider Lock-In\u003c/h2\u003e\n\u003cp\u003eA Kubernetes-native integration does not mean that the edge can only be connected to ayedo Managed Kubernetes. What matters is that teams can consistently describe and operate the deployment from their Kubernetes processes without implementing the public entry layer itself as cluster-local infrastructure.\u003c/p\u003e\n\u003cp\u003eThis is especially important in heterogeneous environments. A company can use Managed Kubernetes for certain workloads, operate its own clusters, or combine environments with different providers. The edge remains the common platform boundary, while each cluster retains its own lifecycle, network, and release model. The \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Edge Integration does not need to completely eliminate provider differences; it encapsulates external access and reduces the number of publicly operated entry points.\u003c/p\u003e\n\u003cp\u003eFor platform engineers, the task shifts from maintaining individual Ingress stacks to defining a standardized deployment model. This includes clarifying ownership, naming conventions, health check behavior, certificate processes, and which routes apply globally or cluster-locally. This standardization is more important than the most comprehensive abstraction possible.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-one-api-endpoint-three-clusters\"\u003ePractical Scenario: One API Endpoint, Three Clusters\u003c/h2\u003e\n\u003cp\u003eA company operates an API in three environments: production in ayedo Managed Kubernetes, as a fallback environment in its own cluster, and for certain regions with another provider. All three clusters have a local Ingress. However, only \u003ccode\u003eapi.example.com\u003c/code\u003e points to the edge publicly.\u003c/p\u003e\n\u003cp\u003eThe edge terminates TLS, inspects the traffic, and uses health checks to identify reachable backends. In normal operation, the main share is directed to the Managed Kubernetes cluster. If this fails, the defined fallback environment takes over. In the target cluster, the local Ingress decides on the service and version. This way, deployments and internal routing rules remain cluster-dependent, while DNS, protection functions, and global failover are not operated separately three times.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"does-the-edge-replace-the-kubernetes-ingress\"\u003eDoes the edge replace the Kubernetes Ingress?\u003c/h3\u003e\n\u003cp\u003eNo. The edge selects the backend or target cluster. The Ingress in the cluster then routes to services and workloads and remains responsible for cluster-internal rules.\u003c/p\u003e\n\u003ch3 id=\"does-the-integration-only-work-with-ayedo-managed-kubernetes\"\u003eDoes the integration only work with ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNo. The Edge Cloud can also be used with own Kubernetes clusters and with clusters at other providers. The key is the reachable and verified backend connection.\u003c/p\u003e\n\u003ch3 id=\"does-this-automatically-solve-multi-cluster-deployment\"\u003eDoes this automatically solve multi-cluster deployment?\u003c/h3\u003e\n\u003cp\u003eNo. The edge solves public access, routing, and failover. Deployment synchronization, data consistency, and application state remain tasks for the platform and application teams.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA robust \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n platform does not end at the cluster boundary, but it also does not begin with another Ingress controller. The clear separation between cluster-internal delivery and provider-independent public entry reduces operational effort and makes multi-cluster architectures more manageable. The ayedo Edge Cloud supports this model as a common edge layer for Managed Kubernetes and external clusters—with central routing, protection, and failover, without dissolving responsibilities within the cluster.\u003c/p\u003e\n",
      "summary": "\nTL;DR A unified deployment of multiple Kubernetes clusters doesn\u0026rsquo;t start with Ingress resources, but with a clear platform boundary. Kubernetes manages workloads and internal services; the provider-independent edge handles public traffic, protection, TLS, routing, and failover. This creates a unified Kubernetes Edge Integration for managed and external clusters.\nIntroduction Many Kubernetes architectures treat each cluster as a complete deployment unit: its own Ingress, public IPs, DNS, and separate protection mechanisms. This works as long as an application is operated in only one environment. However, with ayedo Managed Kubernetes, own clusters, or clusters across multiple providers, duplicate entry points and different operational models emerge. The central architectural flaw is equating the Ingress layer with the public edge. A robust platform therefore separates two areas of responsibility: Kubernetes publishes services within its operational boundaries, while a common edge layer coordinates provider-independent access in front of multiple clusters.\n",
      "image": "https://ayedo.de/kubernetes-und-edge-cloud-als-gemeinsame-plattformgrenze.png",
      "date_published": "2026-09-07T13:49:16Z",
      "date_modified": "2026-09-07T13:49:16Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","platform","cloud-native","software-delivery","development"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/",
      "url": "https://ayedo.de/en/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/",
      "title": "Standardized Load Balancing in Developer Platforms",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/standardisiertes-loadbalancing-in-entwicklerplattformen/standardisiertes-loadbalancing-in-entwicklerplattformen.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eStandardized load balancing separates central network and security decisions from team-specific service parameters. Layer-4 and Layer-7 load balancing can be integrated into internal platforms when policies, defaults, and responsibilities are clearly defined. The ayedo Edge Cloud provides a provider-independent edge layer for applications and APIs.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eMany developer platforms treat load balancing as a local configuration of a single service. This works as long as there are few applications. However, as the number of teams grows, different routing rules, inconsistent TLS requirements, incomplete health checks, and hard-to-track exceptions arise. The central trade-off is not \u0026ldquo;central or flexible,\u0026rdquo; but rather: Which decisions should be platform standards, and which can teams make themselves? A robust architecture standardizes the public entry, protection mechanisms, and operational foundations without unnecessarily slowing down the deployment of new services.\u003c/p\u003e\n\u003ch2 id=\"1-central-standards-instead-of-individual-network-decisions\"\u003e1. Central Standards Instead of Individual Network Decisions\u003c/h2\u003e\n\u003cp\u003eAn internal platform team should define the invariant properties of load balancing. These include allowed protocols, TLS termination, minimum health check requirements, backend cloaking, and handling unreachable backends. These guidelines reduce the number of decisions application teams need to make with each deployment.\u003c/p\u003e\n\u003cp\u003eLayer-4 load balancing is suitable for TCP- or UDP-based services where the platform should distribute traffic at the backend level. Layer-7 load balancing adds application-related criteria such as hostnames, paths, or HTTP behavior. Both variants require different standards and operational models. A blanket \u0026ldquo;load balancing enabled\u0026rdquo; is not sufficient.\u003c/p\u003e\n\u003cp\u003eCentralization also improves security and auditability. Protection functions like a Web Application Firewall or DDoS Protection are not dependent on whether a team has configured them correctly. At the same time, it must be documented which parameters are mandatory and which remain optional. Otherwise, standardization becomes merely a hard-to-understand central special logic.\u003c/p\u003e\n\u003ch2 id=\"2-team-specific-configuration-with-limited-freedom\"\u003e2. Team-Specific Configuration with Limited Freedom\u003c/h2\u003e\n\u003cp\u003eAn internal platform becomes unusable if every new routing detail triggers a manual process at the network team. Therefore, teams should be able to specify within a controlled framework which service should be accessible, which backends are included, and whether Layer 4 or Layer 7 is required. The platform validates these specifications and implements them in the central edge configuration.\u003c/p\u003e\n\u003cp\u003eIt is important to separate intent from implementation. For example, a team describes that an HTTPS service should be accessible under a specific domain. They do not need to decide which routing structure, protection rule, or failover procedure is technically used for this. Such decisions remain with the platform.\u003c/p\u003e\n\u003cp\u003eThis approach also prevents overextension of team autonomy. Free configuration of TLS, redirects, or backend targets can undermine security and operational standards. Defined profiles are better: for example, a standard profile for public HTTP/HTTPS services and a separate profile for non-HTTP-based protocols. Exceptions require a comprehensible justification and a responsible operator.\u003c/p\u003e\n\u003ch2 id=\"3-layer-4-and-layer-7-as-different-platform-paths\"\u003e3. Layer 4 and Layer 7 as Different Platform Paths\u003c/h2\u003e\n\u003cp\u003eThe distinction between Layer 4 and Layer 7 should remain visible in the deployment process. In Layer 4, the transport connection is the focus. The platform can distribute TCP connections and perform backend health checks without interpreting the content of the application communication. This is relevant for protocols that are not HTTP-based or where the application layer should be processed outside the edge.\u003c/p\u003e\n\u003cp\u003eLayer 7, on the other hand, allows routing and security-related decisions at the HTTP level. TLS can be terminated at the edge, traffic can be distributed based on host or path, and a Web Application Firewall can be placed in front. For this, header behavior, redirects, and backend reachability must be clearly standardized. Proxy Protocol can support the forwarding of connection information to backends, provided the target systems are designed for it.\u003c/p\u003e\n\u003cp\u003eFor the internal platform, this means: The choice of profile is team-specific, the effects remain centrally controlled. The ayedo Edge Cloud can provide both Layer-4 and Layer-7 load balancing as a public entry point for applications and APIs. The actual workloads can run in ayedo Managed \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n or in self-managed or other provider-operated \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n clusters.\u003c/p\u003e\n\u003ch2 id=\"4-operational-model-ownership-and-exceptions\"\u003e4. Operational Model, Ownership, and Exceptions\u003c/h2\u003e\n\u003cp\u003eStandardized load balancing is primarily a matter of clear responsibilities. The platform team is responsible for edge standards, central protection mechanisms, failover logic, and the technical consistency of deployment. Application teams are responsible for their backends, their health endpoints, and the functional significance of routing rules. Without this division, errors are passed between the network and application layers.\u003c/p\u003e\n\u003cp\u003eFor operations, observable states are crucial. Traffic and usage statistics show whether a service is actually being reached and how its usage is developing. Health checks and failover must be defined to meaningfully reflect the state of the application, rather than merely testing an open port. Otherwise, the edge may send traffic to a formally reachable but functionally non-operational backend.\u003c/p\u003e\n\u003cp\u003eThe ayedo Edge Cloud organizes these tasks into a distributed, active-active edge platform with its own network infrastructure and autonomous system. This places the public traffic entry outside individual clusters. It facilitates provider-independent use but does not replace the responsibility of teams for correct backends and meaningful health checks.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn internal platform provides two profiles: a Layer-7 profile for public HTTPS APIs and a Layer-4 profile for a non-HTTP-based service. The team only selects the appropriate profile, names the backend service and target address, and provides the health endpoint if necessary. TLS termination, WAF basic protection, backend cloaking, and failover follow the central guidelines.\u003c/p\u003e\n\u003cp\u003eWith an individually configured load balancer, the team would have to assemble routing, certificate behavior, and protection rules themselves. The deployment may initially seem flexible but creates different operational standards. In the standardized model, team-specific configuration is retained while security and network-relevant decisions are reproducibly rolled out.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"when-is-layer-4-load-balancing-the-better-choice\"\u003eWhen is Layer-4 load balancing the better choice?\u003c/h3\u003e\n\u003cp\u003eWhen the service is not HTTP-based or the edge does not require application-specific interpretation. For TCP and UDP services, the transport layer is sufficient.\u003c/p\u003e\n\u003ch3 id=\"does-every-team-need-to-understand-the-edge-configuration\"\u003eDoes every team need to understand the edge configuration?\u003c/h3\u003e\n\u003cp\u003eNo. Teams need an understanding of the available profiles and their impacts. The specific routing and protection implementation should be standardized by the platform.\u003c/p\u003e\n\u003ch3 id=\"does-the-approach-only-work-with-ayedo-managed-kubernetes\"\u003eDoes the approach only work with ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNo. The \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-native integration of the ayedo Edge Cloud can also be used with self-managed or other provider-operated Kubernetes clusters.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eStandardized load balancing is not achieved through maximum centralization nor through complete team autonomy. The key is a clear boundary: The internal platform defines network, security, and operational standards, while teams deploy services within these guidelines. Layer-4 and Layer-7 profiles make this framework practically usable. The ayedo Edge Cloud can be used as an independent edge layer in front of different \u003ca href=\"/en/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n and backend environments.\u003c/p\u003e\n",
      "summary": "\nTL;DR Standardized load balancing separates central network and security decisions from team-specific service parameters. Layer-4 and Layer-7 load balancing can be integrated into internal platforms when policies, defaults, and responsibilities are clearly defined. The ayedo Edge Cloud provides a provider-independent edge layer for applications and APIs.\nIntroduction Many developer platforms treat load balancing as a local configuration of a single service. This works as long as there are few applications. However, as the number of teams grows, different routing rules, inconsistent TLS requirements, incomplete health checks, and hard-to-track exceptions arise. The central trade-off is not \u0026ldquo;central or flexible,\u0026rdquo; but rather: Which decisions should be platform standards, and which can teams make themselves? A robust architecture standardizes the public entry, protection mechanisms, and operational foundations without unnecessarily slowing down the deployment of new services.\n",
      "image": "https://ayedo.de/standardisiertes-loadbalancing-in-entwicklerplattformen.png",
      "date_published": "2026-09-07T13:49:16Z",
      "date_modified": "2026-09-07T13:49:16Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","development","kubernetes","hosting","cloud-native"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/",
      "url": "https://ayedo.de/en/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/",
      "title": "Runbooks for Failover and Recovery at the Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/runbooks-fur-failover-und-wiederanlauf-an-der-edge/runbooks-fur-failover-und-wiederanlauf-an-der-edge.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eRunbooks for edge failover must include more than just a list of technical commands. Clear symptoms, responsibilities, verification sequences, and abort criteria are crucial. Only when health checks, failover status, backend condition, and return to normal operations are evaluated together can incident response remain manageable under time pressure.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA failover at the edge is not automatically a successful operation. A failed backend can be removed from traffic, while at the same time, a faulty target system, incorrect health check, or incomplete state change can prolong the incident. This is why runbooks for edge failover must map the entire decision chain: from the first symptom through technical assessment to controlled return to normal operations. A robust runbook not only reduces response time but also prevents multiple teams from making contradictory changes in parallel or a still unstable backend from receiving traffic too early.\u003c/p\u003e\n\u003ch2 id=\"1-clearly-describe-symptoms-and-responsibilities\"\u003e1. Clearly Describe Symptoms and Responsibilities\u003c/h2\u003e\n\u003cp\u003eThe first part of a runbook must clarify how an edge incident is recognized. Relevant symptoms can include increased error rates, timeouts, failed TLS connections, DNS anomalies, or the failure of individual backends. The key is assignment: an HTTP error pattern points to different checks than an unreachable health-check endpoint or a problem at a single PoP.\u003c/p\u003e\n\u003cp\u003eFor each symptom, the runbook needs a defined initial assessment and escalation logic. Who handles incident response? Who can make failover decisions? Who assesses the application in the backend? Who informs dependent teams and documents the timeline? These roles must be known even outside regular working hours.\u003c/p\u003e\n\u003cp\u003eIt is also sensible to have fixed details about the start of the incident, affected services, timestamps, communication channels, and approvals. This turns a collection of technical hints into an operational process. Especially in a distributed active-active architecture, this structure prevents a local symptom from being prematurely interpreted as a global failure.\u003c/p\u003e\n\u003ch2 id=\"2-do-not-confuse-health-checks-with-application-health\"\u003e2. Do Not Confuse Health Checks with Application Health\u003c/h2\u003e\n\u003cp\u003eHealth checks provide a technical signal but not a complete statement about an application\u0026rsquo;s operational capability. An endpoint can be reachable even if database accesses fail, dependencies are unavailable, or only part of the requests can be processed. Conversely, a too strictly configured check can unnecessarily remove a functional backend from traffic.\u003c/p\u003e\n\u003cp\u003eThe runbook should therefore specify which health-check results trigger which actions. This includes checks of status, response time, reachability, affected backends, and possibly multiple regions or infrastructure segments. Timing is also important: a single failure requires a different response than a confirmed outage over multiple check intervals.\u003c/p\u003e\n\u003cp\u003eBefore a failover, the incident team must check whether the signal actually matches the error pattern. After a failover, it is not enough to only consider the \u0026ldquo;healthy\u0026rdquo; status. Traffic distribution, error rates, and the application\u0026rsquo;s functional capability are also crucial. The edge cloud can control public reachability with backend health checks and failover mechanisms; however, the assessment of the application remains a joint task of edge and backend stakeholders.\u003c/p\u003e\n\u003ch2 id=\"3-document-failover-status-and-backend-assessment\"\u003e3. Document Failover Status and Backend Assessment\u003c/h2\u003e\n\u003cp\u003eA runbook needs an explicit status for each phase: normal operation, degraded operation, failover initiated, failover active, backend under review, and recovery. Without these states, ambiguities arise. One team might assume traffic has already been switched, while another is still considering a preparatory measure.\u003c/p\u003e\n\u003cp\u003eFor each affected backend, status, cause, last successful check, and current reachability should be documented. Equally important is whether a target system is merely unreachable or genuinely not load-bearing. A backend that accepts connections but does not reliably process requests should not be reactivated solely based on a successful network check.\u003c/p\u003e\n\u003cp\u003eThe runbook should also define when a failover is considered complete. This includes confirmed traffic redirection, stable health checks at the target, and the review of relevant application signals. In an anycast-based, distributed edge, these criteria must be considered across the affected traffic paths. A local success does not necessarily suffice as proof of stable overall operation.\u003c/p\u003e\n\u003ch2 id=\"4-manage-recovery-and-return-to-normal-operations\"\u003e4. Manage Recovery and Return to Normal Operations\u003c/h2\u003e\n\u003cp\u003eRecovery is not just undoing the last step but a separate operational process. First, the cause of the failure must be sufficiently understood or at least narrowed down. Then the backend is prepared in a controlled manner: dependencies, resources, configuration, and health-check behavior are reviewed. A service may be technically reachable but still react unstably under real load.\u003c/p\u003e\n\u003cp\u003eThe runbook should provide for a phased return. This includes a defined observation phase, clear abort criteria, and a responsible person for approval. If traffic is returned too early, the incident may recur or spread to other components. If operations remain in failover permanently, capacity and operational risks arise at the remaining target.\u003c/p\u003e\n\u003cp\u003eAfter the return, failover status, monitoring, routing, and communication must be reset to normal operations. Only then is the incident concluded. A brief post-mortem should check whether symptoms, responsibilities, and verification steps in the runbook are still correct. Operational processes become more resilient when real deviations systematically flow into the next version.\u003c/p\u003e\n\u003ch2 id=\"practical-and-operational-scenario\"\u003ePractical and Operational Scenario\u003c/h2\u003e\n\u003cp\u003eAn API backend increasingly responds with timeouts in an infrastructure segment. The edge detects a deterioration through health checks and removes the target from distribution according to failover logic. The runbook obliges the team to first confirm the affected traffic paths and failover status. In parallel, the backend team evaluates database connections and resource consumption.\u003c/p\u003e\n\u003cp\u003eAfter stabilization, the health check reports success again. However, the team does not immediately fully activate the backend but first checks functional requests and observes the error rate. Only after documented approval is normal operation restored. This separation of edge decision and backend assessment prevents a formally reachable but practically unstable system from receiving traffic again.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"what-information-must-be-kept-current-in-the-runbook\"\u003eWhat information must be kept current in the runbook?\u003c/h3\u003e\n\u003cp\u003eResponsibilities, escalation paths, health-check criteria, failover states, approvals, and abort criteria. Technical details should be regularly checked against the actual operating configuration.\u003c/p\u003e\n\u003ch3 id=\"who-decides-on-the-return-to-normal-operations\"\u003eWho decides on the return to normal operations?\u003c/h3\u003e\n\u003cp\u003eThe decision should be made by a designated role after edge and backend signals have been jointly evaluated. Technical reachability alone is not a sufficient approval criterion.\u003c/p\u003e\n\u003ch3 id=\"how-often-should-edge-runbooks-be-tested\"\u003eHow often should edge runbooks be tested?\u003c/h3\u003e\n\u003cp\u003eNot just after an incident. Planned reviews, tabletop exercises, and controlled tests show whether responsibilities, verification steps, and communication paths work under time pressure.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eA good runbook for edge failover not only describes what technical action is possible. It defines when it is justified, who executes it, and how success or abort is recognized. This separation of symptom, decision, backend assessment, and recovery reduces mismanagement in incidents. An edge platform like the ayedo Edge Cloud provides the technical framework of distributed operations, health checks, and failover. However, operational stability only arises through standardized processes, clear responsibilities, and verifiable approvals.\u003c/p\u003e\n",
      "summary": "\nTL;DR Runbooks for edge failover must include more than just a list of technical commands. Clear symptoms, responsibilities, verification sequences, and abort criteria are crucial. Only when health checks, failover status, backend condition, and return to normal operations are evaluated together can incident response remain manageable under time pressure.\nIntroduction A failover at the edge is not automatically a successful operation. A failed backend can be removed from traffic, while at the same time, a faulty target system, incorrect health check, or incomplete state change can prolong the incident. This is why runbooks for edge failover must map the entire decision chain: from the first symptom through technical assessment to controlled return to normal operations. A robust runbook not only reduces response time but also prevents multiple teams from making contradictory changes in parallel or a still unstable backend from receiving traffic too early.\n",
      "image": "https://ayedo.de/runbooks-fur-failover-und-wiederanlauf-an-der-edge.png",
      "date_published": "2026-09-07T13:44:06Z",
      "date_modified": "2026-09-07T13:44:06Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","operations","kubernetes","digital-sovereignty","software-delivery"],
      "language": "en"
    },{
      "id": "https://ayedo.de/en/posts/ddos-ereignisse-im-sre-betrieb-an-der-edge-operativ-bewerten/",
      "url": "https://ayedo.de/en/posts/ddos-ereignisse-im-sre-betrieb-an-der-edge-operativ-bewerten/",
      "title": "Operational Assessment of DDoS Events in SRE Operations at the Edge",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ddos-ereignisse-im-sre-betrieb-an-der-edge-operativ-bewerten/ddos-ereignisse-im-sre-betrieb-an-der-edge-operativ-bewerten.png\" alt=\"Post Image\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDDoS Protection does not automatically resolve an incident. For SRE teams, the real operational task begins with classification: Is traffic being dropped at the edge, are requests still reaching the backends, and what risks remain for availability, costs, and downstream dependencies? Clear signals, escalation paths, and a reliable assessment of backend impacts are crucial.\u003c/p\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eA DDoS event in SRE operations is not just a security incident but a distributed operational event. The central question is not solely whether the edge detects and filters attacks. Equally important is whether backends, network connections, databases, or downstream services continue to be burdened and whether legitimate users are affected. Edge-proximate DDoS Protection with scrubbing can reduce harmful traffic before it reaches applications. However, it does not replace observability or incident management. Teams need to understand what is happening at the edge, which signals are relevant for escalation, and when a seemingly thwarted attack continues to pose operational risks.\u003c/p\u003e\n\u003ch2 id=\"1-recognizing-ddos-as-a-multi-stage-operational-event\"\u003e1. Recognizing DDoS as a Multi-Stage Operational Event\u003c/h2\u003e\n\u003cp\u003eThe first operational task is to distinguish an unusual traffic surge from a relevant DDoS event. Individual metrics are rarely sufficient for this. High request rates can result from legitimate campaigns, faulty clients, or an internal retry storm. The assessment becomes more meaningful when edge statistics, response behavior, error rates, and backend metrics are considered together.\u003c/p\u003e\n\u003cp\u003eDDoS Protection and scrubbing at the edge change the perspective on the event. A large portion of incoming traffic can already be processed or discarded before reaching the backends. The application may not see a proportionally increasing load, while the edge continues to register unusual activity. Conversely, an attack on the protocol or application level can allow relevant requests to pass through to the application despite filtering.\u003c/p\u003e\n\u003cp\u003eFor SRE teams, this means: The absence of a backend failure is not proof of the absence of an incident. Similarly, high edge traffic alone is not evidence of a concrete impairment. The operational assessment must integrate both levels.\u003c/p\u003e\n\u003ch2 id=\"2-aligning-escalation-and-communication-with-clear-signals\"\u003e2. Aligning Escalation and Communication with Clear Signals\u003c/h2\u003e\n\u003cp\u003eIncident management requires clear thresholds for DDoS events. These include, for example, sustained deviations from the normal traffic profile, increasing error rates, deteriorating response times, or noticeable impacts on backend resources. It is important to distinguish between technical observation and escalation decision: Not every detected event requires the same immediate response.\u003c/p\u003e\n\u003cp\u003eThe edge cloud can take over the public traffic ingress as an upstream protection and distribution layer. However, for communication, it must be clear what statement is reliable: Is traffic being scrubbed at the edge? Are the backends reachable? Are there impacts on specific services, regions, or customer groups? Without this separation, contradictory status messages can easily arise between security, SRE, network operations, and product managers.\u003c/p\u003e\n\u003cp\u003eA sensible incident process therefore documents not only start time and traffic volume but also the observed filtering effects, backend symptoms, routing or failover decisions made, and open risks. This ensures that after the event, it is traceable whether the protective measure was effective or merely shifted the visible cause of the error.\u003c/p\u003e\n\u003ch2 id=\"3-examining-backend-impacts-despite-scrubbing\"\u003e3. Examining Backend Impacts Despite Scrubbing\u003c/h2\u003e\n\u003cp\u003eDDoS scrubbing reduces the load on the actual applications but does not automatically eliminate every risk behind the edge. Depending on the attack pattern, connections, TLS processing, HTTP requests, or expensive application paths may still be affected. Even an attack with lower volume can become problematic if it targets resource-intensive endpoints.\u003c/p\u003e\n\u003cp\u003eThe examination should therefore cover multiple levels: Do suspicious requests reach the backends? Are connection counts, CPU, memory, or queue utilization changing? Are timeouts and retries increasing? Are databases or external dependencies more heavily loaded? Health checks and failover help with availability management but are no substitute for root cause analysis. A backend can be formally reachable and still suffer from degraded performance.\u003c/p\u003e\n\u003cp\u003eBackend cloaking reduces the direct attack surface because the actual origin addresses do not have to serve as a public entry point. However, this does not protect against every load delivered via the regular edge path. SRE teams must therefore check whether scaling, rate controls, application logic, and dependencies can handle the remaining traffic.\u003c/p\u003e\n\u003ch2 id=\"4-assessing-remaining-risks-after-the-event\"\u003e4. Assessing Remaining Risks After the Event\u003c/h2\u003e\n\u003cp\u003eAfter traffic eases, operational work does not end. The key question is which risks were reduced by the protective measure and which were only temporarily concealed. These include possible overload of individual backends, unexpected failover states, delayed queues, or error patterns that were masked by edge activity during the attack.\u003c/p\u003e\n\u003cp\u003eA multi-PoP architecture with active-active operation can reduce dependency on a single location. An own autonomous system and network infrastructure create an independent technical control area for public traffic ingress. These features do not replace capacity planning or robust runbooks but influence the assessment of failure and dependency scenarios.\u003c/p\u003e\n\u003cp\u003eFor post-event analysis, teams should separately evaluate protective effect and operational impact: Was harmful traffic sufficiently reduced? Did legitimate users remain reachable? Which backends were still critical? Were manual interventions necessary? The answers feed into thresholds, communication templates, and architectural decisions. Thus, DDoS Protection becomes a verifiable component of SRE operations rather than just a reactive security feature.\u003c/p\u003e\n\u003ch2 id=\"practical-scenario-same-traffic-different-operational-consequences\"\u003ePractical Scenario: Same Traffic, Different Operational Consequences\u003c/h2\u003e\n\u003cp\u003eA public API suddenly receives multiple times its usual requests. The edge recognizes the pattern, filters a significant portion, and distributes the remaining traffic across multiple active entry points. The backend metrics initially show stable CPU values but increasing database connections and longer response times.\u003c/p\u003e\n\u003cp\u003eA team that only looks at availability ends the incident too early. An SRE team, on the other hand, correlates edge statistics, HTTP errors, connection counts, and database state. It continues to classify the event as active, informs the responsible parties, and checks whether individual endpoints or dependencies need targeted protection. After the subsiding, it documents not only the filtering but also the remaining backend load.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"is-a-ddos-incident-over-if-the-backends-remain-reachable\"\u003eIs a DDoS incident over if the backends remain reachable?\u003c/h3\u003e\n\u003cp\u003eNo. Reachability does not exclude performance losses, increasing costs, resource exhaustion, or restrictions for individual user groups.\u003c/p\u003e\n\u003ch3 id=\"what-signals-should-sre-teams-consider-together\"\u003eWhat signals should SRE teams consider together?\u003c/h3\u003e\n\u003cp\u003eEdge traffic, discarded requests, error rates, response times, connections, backend resources, and dependencies must be evaluated in temporal context.\u003c/p\u003e\n\u003ch3 id=\"what-role-does-the-edge-play-in-incident-management\"\u003eWhat role does the edge play in incident management?\u003c/h3\u003e\n\u003cp\u003eIt provides a central control and observation point for public traffic. Escalation, backend analysis, and communication remain tasks of the operational model.\u003c/p\u003e\n\u003ch2 id=\"conclusion\"\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eDDoS Protection in SRE operations is successful when it not only defends against traffic but is embedded in a traceable incident process. Edge signals, backend telemetry, escalation rules, and post-event analysis must fit together. The ayedo Edge Cloud combines edge-proximate DDoS Protection and scrubbing with Anycast-based distribution, health checks, and failover. However, the operational assessment remains crucial: Protective effect and remaining backend risk must be considered separately.\u003c/p\u003e\n",
      "summary": "\nTL;DR DDoS Protection does not automatically resolve an incident. For SRE teams, the real operational task begins with classification: Is traffic being dropped at the edge, are requests still reaching the backends, and what risks remain for availability, costs, and downstream dependencies? Clear signals, escalation paths, and a reliable assessment of backend impacts are crucial.\nIntroduction A DDoS event in SRE operations is not just a security incident but a distributed operational event. The central question is not solely whether the edge detects and filters attacks. Equally important is whether backends, network connections, databases, or downstream services continue to be burdened and whether legitimate users are affected. Edge-proximate DDoS Protection with scrubbing can reduce harmful traffic before it reaches applications. However, it does not replace observability or incident management. Teams need to understand what is happening at the edge, which signals are relevant for escalation, and when a seemingly thwarted attack continues to pose operational risks.\n",
      "image": "https://ayedo.de/ddos-ereignisse-im-sre-betrieb-an-der-edge-operativ-bewerten.png",
      "date_published": "2026-09-07T13:44:05Z",
      "date_modified": "2026-09-07T13:44:05Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","security","cloud-native","kubernetes","digital-sovereignty"],
      "language": "en"
    },
  ]
}