Why We Built the ayedo Edge Cloud
An application can be fully operated in Germany and still rely on US infrastructure for every single access.
Because 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.
This layer is exactly what we call the Edge.
And this is precisely where the question begins for us: who actually has technical control over an application?
It Starts Not with the Server, but with the Routing
The 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.
At 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.
This is a significant difference from an architecture where a service is bound to a specific location and its IP address.
With 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.
Availability is thus achieved at the network level.
DNS Is Part of the Infrastructure
Almost every connection is preceded by a DNS query. Therefore, we do not treat DNS as an external add-on service.
DNS 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.
But it is also crucial how DNS is operated.
The 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.
This is practical for developers. For companies, it is above all traceable and reproducible.
The Public IP Does Not Have to Belong to the Cloud Provider
An often underestimated lock-in occurs with IP addresses.
If 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.
Therefore, the Edge Cloud supports Bring Your Own IP.
Companies can use their own IP prefixes. We announce and route these through our Edge infrastructure.
This 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.
This is a very concrete difference between "we can theoretically change the provider" and "our architecture is actually prepared for it."
Edge and Compute Are Deliberately Separated
The Edge Cloud is not tied to the ayedo Compute Cloud.
The application can run in our Compute Cloud, in another Kubernetes cluster, with another provider, or on-premises. DNS and traffic can still be provided via the Edge.
This fundamentally changes the architecture.
The public entry point and the location where compute takes place become two separate decisions.
A 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.
This decoupling precisely reduces dependencies.
The Path from the Internet to the Pod Is Clearly Defined
Technically, the path of a request for Kubernetes workloads looks like this:
Client → ayedo Edge / Loadbalancer → Node → Ingress Controller or Gateway Proxy → Service → Pod.
The individual layers have different tasks.
The 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.
For existing Kubernetes workloads, we support NGINX Ingress with the established Ingress and IngressClass resources.
For new architectures, Envoy Gateway with the Kubernetes Gateway API is available. Routing is described there using resources like Gateway, HTTPRoute, and TLSRoute.
This is deliberately not a proprietary ayedo routing API that technically binds applications to our platform.
Protection Occurs Before Traffic Reaches the Application
Therefore, the Edge also includes the security functions that take effect before the actual workload.
The ayedo Edge Cloud bundles DNS, TLS, Layer-4 and Layer-7 load balancing, Web Application Firewall, DDoS protection, and health checks.
The 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.
Health 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.
Network, routing, application health, and protection mechanisms thus belong together.
A European Cloud Needs a European Network Layer
Cloudflare has shown how valuable it is to combine DNS, routing, load balancing, and security at a global Edge.
The problem is not this technical model. On the contrary: It is very good.
The problem arises when we operate applications, databases, and Kubernetes clusters in Europe under European conditions, but let the entire public access be permanently controlled by infrastructure operated outside of Europe.
That's why we are building this layer ourselves.
With 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.
Because the crucial question is not only, where an application runs.
But who controls DNS, IP addresses, routing, and the path to this application.