We 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.
The 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.
It controls a crucial part of the infrastructure: the path from the public internet to the actual application.
Before a request reaches the first pod in the Kubernetes cluster, 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.
Whoever operates these components controls a significant part of the access to the application.
Therefore, we didn't start with a single product feature for our Edge Cloud. We built the underlying infrastructure.
An Autonomous System as the Foundation
The technical basis of our Edge Cloud is our own Autonomous System.
An 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.
For our Edge, this means: We operate the network layer through which our locations announce their routes on the internet.
To 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.
One IP Address, Multiple Locations
Anycast is a central component of this architecture.
The 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.
BGP determines, based on available routes, through which PoP the connection reaches the Edge.
This 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.
Redundancy thus begins not at the server but already in the routing.
DNS Also Runs Over the Edge
In most cases, DNS precedes the actual connection. Therefore, this layer is also part of the Edge Cloud.
DNS zones are provided via our Edge infrastructure with Anycast. Thus, name resolution is not tied to a single location.
At 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.
This is particularly important for platform teams: Infrastructure remains reproducible and can be managed with the same processes as the rest of the stack.
The Public IP Doesn't Have to Belong to Us
Another component is Bring Your Own IP, or BYOIP.
Companies can bring their own IP prefixes, which we announce and route via our Edge infrastructure.
This initially sounds like a detail for network administrators. However, it is relevant for the independence of an infrastructure.
Public 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.
With BYOIP, the addresses remain with the company. The public address space and the underlying compute infrastructure are separated.
Edge and Compute Are Two Different Decisions
This separation runs through the entire architecture.
The application behind our Edge does not have to run in the ayedo Compute Cloud. It can be operated there, in a Kubernetes cluster with another provider, or in its own infrastructure.
The Edge takes over public access and forwards traffic to the defined backend.
This decouples two things that often coincide in cloud platforms: Where does my application run – and through whose infrastructure is it accessible?
This enables hybrid and multi-provider architectures without having to build a completely separate public access layer for each compute location.
From the Internet to the Kubernetes Pod
In Kubernetes, this path can be traced very concretely:
Client → ayedo Edge / Load Balancer → Node → Ingress Controller or Gateway Proxy → Service → Pod
The Edge load balancer holds the public virtual IP, checks the availability of the backends, and forwards or terminates TCP or HTTP traffic.
Within 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.
For existing Kubernetes architectures, we support NGINX Ingress with Ingress and IngressClass.
For new architectures, Envoy Gateway with the Kubernetes Gateway API and resources like Gateway, HTTPRoute, and TLSRoute is available.
This is an important architectural principle for us: The transition from our infrastructure to the Kubernetes cluster is based on established cloud-native standards and not on proprietary ayedo routing logic.
Security Belongs in Front of the Application
The protection mechanisms sit on the same level.
Therefore, the Edge Cloud includes Layer-4 and Layer-7 load balancing, TLS, web application firewall, DDoS protection, and health checks.
The 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.
This is an important distinction: A reachable server is not necessarily a functioning service.
Edge infrastructure must therefore consider routing, availability, and security together.
A European Alternative Must Convince Technically
Cloudflare 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.
A European alternative cannot consist of simply labeling the same concept with an EU tag.
It needs its own infrastructure.
Its own Autonomous System. Its own routing. Multiple active PoPs. Anycast. DNS. Load balancing. WAF and DDoS protection. Open interfaces to Kubernetes. The ability to choose compute independently. And with BYOIP, even the ability to retain one's own public address space.
This is exactly the infrastructure we are building with the ayedo Edge Cloud.
Because European cloud infrastructure is only a real alternative when it not only differs regulatorily but also technically regains control over the critical layers.