TL;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.
Introduction
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.
1. DNS and TLS Belong to Central Operational Responsibility
DNS 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.
However, 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.
The 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.
2. WAF and DDoS Protection Require Different Responsibilities
DDoS 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.
A 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.
WAF 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.
3. Health Checks Separate Infrastructure Status and Application View
Backend 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's perspective? Are timeouts, status codes, and failover correctly processed?
The 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.
This 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.
4. Backend Accessibility Is Not Solely a Platform Problem
The 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.
The 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.
A binding interface is suitable for collaboration: service address, port, protocol, health check, timeout behavior, allowed source information, and responsible party. This turns "backend not reachable" into a verifiable error chain. The edge cloud can be used with ayedo Managed Kubernetes or with Kubernetes clusters of its own or other providers. The boundary of responsibility remains independent of the compute provider.
Operational Scenario: A New API Is Published
An application team wants to publish an API under api.example.de. 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.
The 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's responsibility, but both are responsible for the handover.
FAQ
Who should approve DNS and certificate changes?
The 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.
Who is responsible for a WAF exception?
The application team justifies the exception and describes the required behavior. The platform team reviews technical implementation, scope, and remaining risk.
Is a TCP health check sufficient for a backend?
Only for technical accessibility. Whether the application can process requests must be checked by an application-specific health check with clear semantics.
Conclusion
Boundaries 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 Kubernetes environments. A precise shared responsibility agreement remains crucial.