Calculating Cloud Costs Accurately: What Does an Application Really Cost?
Compare cloud offerings fairly: total cost of ownership, compute, storage, traffic, operational costs, a worked example and a checklist.
Cloud
Bereitstellung und Nutzung elastischer Infrastruktur- und Plattformdienste.
48 of 210 items
Domains
See instantly if the name is free — and what it costs.
Software operations for the public sector – online services on the ayedo Cloud
Operations for citizen portals, administrative applications, and EfA services in the public sector: sovereign on the ayedo Cloud located in the EU, ISO 27001-certified, with named contacts.
Introduction to OpenTofu Workshop
OpenTofu training, live online: HCL, state encryption, modules and Terraform migration in 3 days. Hands-on in your own cloud lab, max 8 participants.
Introduction to Terraform Workshop
Learn Terraform from scratch in three days: HCL, state management, modules and CI/CD pipelines. Live online in your own cloud environment, max 8 participants.
Building the Edge — Part 8
The beginning of a platform – why every architecture eventually reaches the point where it must rethink the network.
Building the Edge — Part 7
Good platforms are not built by adding more infrastructure – they are built through clearly defined responsibilities.
Building the Edge — Part 6
A connection is not yet an HTTP request – why modern edge platforms begin much earlier than many architecture diagrams suggest.
Building the Edge — Part 5
Compute is not the platform – why modern applications today consist of two platforms.
Building the Edge — Part 4
Why high availability starts in the network today – failures are not an exceptional state, but an architectural principle.
Building the Edge — Part 3
One IP address can exist in three places at once – why Anycast is not a feature, but a property of the internet.
Building the Edge — Part 2
The internet does not know applications – why BGP does not try to find the fastest path.
The 5-Minute Sovereignty Check
How sovereign is your digital infrastructure? Our free sovereignty check is currently only available in German.
ayedo Compute Cloud
ayedo Compute Cloud is the marketplace for sovereign infrastructure – the backbone for Kubernetes and apps at any provider or on-premises, orchestrated by the Software Delivery Platform.
ayedo Edge Cloud
ayedo Edge Cloud delivers highly available anycast load balancing and DNS – multi-homed for secure traffic ingest, low latency and failover. Made in Germany.
ayedo Cloud
ayedo Cloud combines Compute Cloud, Edge Cloud and multi-tenant Platform Services – Identity, Observability, S3, DNS, load balancing, WAF, Argo CD and Harbor under central URLs.
DNS, Routing, Anycast: Why Europe's Cloud Also Needs Its Own Edge
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.
Operating Load Balancers for Kubernetes Independently of Providers
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.
Ingress and Edge Cloud: Clearly Separating Responsibilities
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.
Multi-Cloud Security with Centralized Edge Architecture
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.
Failover Across Multiple Providers with the Edge Cloud
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.
From Cloud Company to Instagram Sensation:
**Cloud infrastructure, Kubernetes, and digital sovereignty are the core business. On Instagram, ayedo shows a completely different side: With humorous office videos, the Schwalbach-based tech company now reaches millions. A single reel garnered over 1.2 million views.**
ayedo Launches European Edge Cloud as a Sovereign Alternative to Cloudflare
**Own network infrastructure, Anycast, DDoS protection, and five active Points of Presence in Germany: With the ayedo Edge Cloud, ayedo expands its cloud platform with a sovereign edge infrastructure for modern applications.**
ayedo Edge-Cloud: The Underestimated Architecture of Modern Applications
When we talk about running an application, we almost automatically think of the data center. Of virtual machines, Kubernetes clusters, databases, containers, or storage systems. Our architecture diagrams often start right there: somewhere within a cloud region, behind a firewall, where compute resources are provisioned and applications are executed.
Sovereign Edge Cloud for Technical Multi-Cloud Operations
A multi-cloud architecture becomes difficult to manage when each provider operates its own public entry points, routing rules, and protection mechanisms. A provider-independent edge cloud consolidates these functions in front of heterogeneous compute environments. It separates public traffic from the backends and creates a central layer for routing, security, TLS, failover, and operations.
Jurisdiction and Technical Control at the Edge
Jurisdiction in the cloud describes legal responsibilities, not automatically the technical control over data flows and infrastructure. To evaluate an edge architecture, routing, traffic processing, TLS termination, backend cloaking, and operational processes must be considered separately. The ayedo Edge Cloud creates technical control points but does not replace legal review.
Operating Kubernetes DNS and Edge Routing Across Provider Boundaries
In a Kubernetes multi-cloud environment, internal service DNS, public DNS zones, and edge routing must share the same lifecycle. Managing records, endpoints, and routing independently leads to outdated targets and unclear failover states. A coordinated model separates responsibilities, centralizes public ingress, and makes changes traceable.
Edge Cloud as a Network Boundary for Distributed Clusters
A distributed Kubernetes landscape requires a clear boundary between public traffic and internal compute infrastructure. An Edge Cloud assumes this boundary, consolidating routing, protection, and failover while keeping backends concealed. Its own Autonomous System and network infrastructure provide an independent foundation for multi-PoP and active-active architectures.
Connecting Kubernetes Gateway Across Providers to the Edge
The Kubernetes Gateway API can form a portable interface between applications and public traffic. When connected to a provider-independent edge layer, routing, TLS, protection, and backend shielding remain separate from the network and cloud stack of the cluster. This simplifies multi-cloud scenarios, enhances resilience, and reduces infrastructure dependencies.
ACME DNS Challenge with the Edge Cloud in Kubernetes
The ACME DNS-01 Challenge enables TLS certificates for Kubernetes services without making the backend accessible from the internet. Key factors include separate DNS permissions, a unique domain assignment, and the question of where TLS is terminated. Behind the ayedo Edge Cloud, this termination point is at the public edge, not necessarily within the cluster.
Provider-Independent Load Balancers for Kubernetes APIs
The Kubernetes API Server is not a typical ingress target but the central control point of a cluster. A Kubernetes API Server Load Balancer must therefore combine accessibility, failover, and access protection. The ayedo Edge Cloud publishes Kubernetes APIs provider-independently via Anycast Layer 4 and protects backend addresses through Backend Cloaking.
Provider-Independent Kubernetes Ingress with the Edge Cloud
A Kubernetes Ingress doesn't need to be directly tied to a cloud provider's load balancer. A central edge layer can connect multiple Kubernetes clusters through unified public IPs, TLS termination, protection functions, and health checks. The ayedo Edge Cloud enables this model for ayedo Managed Kubernetes, private clusters, and Kubernetes environments with other providers.
Utilizing Edge Cloud with Your Own Kubernetes Clusters
A Kubernetes cluster does not need to be operated by the same provider as the edge infrastructure. The ayedo Edge Cloud separates public traffic entry from the compute platform, allowing it to be used with self-managed and provider-hosted Kubernetes clusters. This creates provider independence but changes the requirements for routing, security, and operations.
Automating Ingress with the ayedo Edge Cloud
Automating Kubernetes Ingress involves more than just creating a load balancer via YAML. The key is the connection between declarative resources, edge configuration, and the actual backend. The ayedo Edge Cloud handles public entry, routing, protection, and health checks, while Kubernetes describes the desired publication.
Operating Kubernetes Load Balancers Independently of Providers
A Kubernetes Service of type `LoadBalancer` often ties public entry to the infrastructure of a single cloud provider. In contrast, a central edge entry separates cluster operation from traffic processing. The ayedo Edge Cloud handles routing, protection, and distribution in front of Kubernetes clusters—regardless of the provider they are operated with.
Designing Edge Load Balancing for Multi-Cloud Backends
Multi-cloud load balancing is more than distributing requests across multiple providers. Key aspects include a central routing logic, concealed backends, robust health checks, and operation without dependency on individual cloud networks. An independent edge layer provides a unified control point in front of heterogeneous infrastructures.
Architectural Decisions Between L4 and L7 in Multi-Cloud Operations
Multi-cloud load balancing is not just a matter of distribution. L4 offers transparency and low protocol dependency, while L7 enables application-specific routing, TLS termination, and centralized security functions. The key decision is whether these functions are tied to a provider or operated at an independent edge before the backends.
August 2026
Cloud infrastructure is constantly evolving. That's why we want to provide a monthly overview of what's happening at ayedo—technically, entrepreneurially, and with a focus on digital sovereignty.
The US CLOUD Act Fallacy:
Many medium-sized industrial and service companies are lulled into a false sense of security: Contracts with US hyperscalers specify server locations in Frankfurt or Dublin, and compliance dashboards show green checkmarks. However, due to intensified supply chain security audits and the expansion of regulations like **NIS-2**, operators of critical infrastructures (KRITIS) increasingly demand comprehensive evidence of actual data access rights.
The Dual-Runtime Principle:
In highly regulated industries such as banking and insurance, modern SaaS business models rarely fail due to application logic, but rather due to restrictive hosting requirements of enterprise customers. While agile fintechs aim to scale their platforms in standardized cloud environments, conservative institutions and public entities demand on-premises operations behind the corporate firewall due to data classification and compliance reasons. For software manufacturers, this discrepancy traditionally leads to costly codebase fragmentation and significant friction losses in platform engineering.
The Sovereign Bursting Concept:
In many industrial and manufacturing companies, ambitious AI and data science initiatives face a hard physical barrier: local on-premises clusters regularly hit capacity limits with compute-intensive training and simulation jobs, while acquiring new enterprise accelerators like NVIDIA H100 or B200 involves lead times of many months. The obvious solution—turning to US hyperscalers—fails in practice due to unpredictable data transfer costs, proprietary API silos, and the strict compliance requirements of the European industry.
Weekly Backlog Week 31/2026
This edition primarily focuses on digital sovereignty—from both a technical and political perspective.
Weekly Backlog Week 29/2026
This week had it all: open databases, open GitHub repositories, open questions about data protection – and a surprisingly large number of organizations suddenly discovering that digital dependencies might not be such a good idea after all.
Polycrate Containerization Drives Multi-Cloud Portability
Polycrate-portability-multi-cloud enables containerized workloads across providers and platforms. With OCI-compliant containers, open APIs, and consistent infrastructure definitions, portability becomes planned rather than accidental. Companies gain flexibility, reduce vendor lock-in, enhance recoverability, and secure better options for multi-cloud strategies.
Polycrate Installation System Requirements and Setup
Polycrate installations critically depend on clear system requirements. This checklist outlines minimum and recommended hardware and software dependencies for On-Prem, Cloud, and Hybrid setups, including reference architecture. The goal is to enable planned budgeting, reliable availability, and low-risk scaling—ayedo supports with architectural decisions, reference models, and implementation plans.
Polycrate GitOps as the Single Source of Truth in Cloud Environments
Polycrate GitOps establishes a single source of truth through declarative infrastructure, version control, and auditability. This guide explains the basics, the concept of the single source of truth, rollback capabilities, and how Polycrate functions as a central control layer. Practical architectural decisions help prevent drift and ensure compliance.
Architectural Decisions: Polycrate Platform vs Vendor Lock-in
Polycrate platform approaches promote portability through open standards, container-based orchestration, and multi-cloud strategies. Compared to traditional vendor lock-in models, they enable more flexible migrations, lower switching costs, and long-term cost control. The article compares architectural options, migration requirements, and operational impacts to derive an informed decision—focusing on risk, governance, and economic viability.
Scalable Operations Model: Automation and Observability
A scalable Polycrate operations model leverages clear standards, automation, and comprehensive observability to reliably operate infrastructure and platform services. SLOs, consistent logs, and automated incident response minimize MTTR and costs, while improving management of multi-cloud and edge environments. ayedo supports the architectural definition, implementation, and operationalization of this practice, without marketing jargon.