Why Amazon’s Kubernetes service is a compliance lever, not just duplication

This article is part of the Azure Kubernetes Chronicles: Multi-Cluster Edition.
Read the series introduction here.

Whenever companies discuss Kubernetes in Azure, AKS naturally comes up because it’s the go-to managed service for those within Microsoft’s ecosystem. However, across Europe, another name is gaining attention: Amazon Elastic Kubernetes Service, or EKS. For many organizations, EKS isn’t just another option; it’s become a vital part of their strategic planning.

At first glance, operating both AKS and EKS may seem redundant. Why would an enterprise support two distinct Kubernetes services, each with its own costs, governance, and operational challenges? The reasons are regulation, resilience, and strategic advantage. In key industries such as banking and telecommunications, European regulators are increasingly discouraging reliance on a single cloud provider. Frameworks like DORA require organizations to demonstrate they can recover from third-party service failures, which typically means being able to switch to an alternative provider. For a financial institution running core workloads on AKS, this often involves maintaining a backup cluster on EKS.

Geography introduces an additional layer. Although Azure and AWS both have strong footprints across Europe, their presence isn’t identical. AWS’s well-established operations in Frankfurt, a crucial regulatory hub for Germany, make it an appealing option for companies that need to meet national standards. Additionally, AWS provides specific services such as SageMaker and Bedrock for AI/ML, and Kinesis for streaming, that can be seamlessly integrated with containerized applications. Opting for EKS in these situations is not about redundancy but about optimization: it ensures workloads are matched with the regions and features that best support them.

But adopting EKS does not come without challenges. The most immediate issue is identity. AKS connects directly with Entra ID, while EKS depends on IAM. Aligning these models is seldom straightforward. Enterprises often end up duplicating roles and policies, which creates inefficiency and increases risk. Policy enforcement also varies. In AKS, teams can rely on Azure Policy for Kubernetes. In EKS, the equivalent must be built with OPA or Kyverno. Keeping consistency across these two systems requires discipline and often leads to drift.

Networking remains a weak point. Azure’s VNets and AWS’s VPCs do not naturally align, making hybrid network design a complex process. Service discovery across providers is rarely seamless, and while service meshes provide one solution, they also increase overhead and skills requirements. Observability follows a similar pattern. Azure Monitor cannot understand CloudWatch, and CloudWatch cannot view resources in AKS. Some companies use neutral platforms like Prometheus and Grafana, but this adds another operational layer.

Then there is the cost. On paper, AKS appears to be cheaper because its control plane is free, whereas EKS charges a flat monthly fee per cluster. At more minor scales, this difference is noticeable. At an enterprise level, the cost of the control plane is less significant than something less obvious: the need for duplicate skills. Running both AKS and EKS requires training teams on two identity models, two policy frameworks, and two monitoring stacks. The financial impact extends beyond infrastructure to include people, time, and processes.

Despite these obstacles, EKS holds a crucial strategic position. It serves as a compliance facilitator, enabling enterprises to showcase multi-cloud resilience to regulators. It also acts as a legacy anchor for organizations that developed within AWS and are hesitant to leave. Additionally, it offers a competitive advantage for workloads that leverage AWS’s AI and data ecosystem. Most importantly, it provides CIOs with a bargaining chip: the power to negotiate with Microsoft confidently by demonstrating the ability to shift workloads to other platforms if necessary.

Imagine a large European logistics company. Its central platform operates on AKS in Amsterdam, but due to German regulations, it also needs a secondary cluster in Frankfurt, which EKS handles. Meanwhile, their distribution centers use k3s clusters for local IoT processing. This creates a diverse setup: AKS for essential tasks, EKS for compliance needs, and k3s for local edge processing. Without a unifying solution like Azure Arc, this setup can feel scattered; policies need to be duplicated, observability is isolated, and identity management is fragmented. However, choosing EKS isn’t just a preference; it’s a requirement for compliance and is made more appealing by AWS’s robust ecosystem.

EKS is not mere duplication; it is a strategic choice reflecting the reality that enterprises often cannot rely on a single cloud. This is driven by factors such as regulatory compliance, resilience, or competitive pressures. For architects, the real challenge isn’t whether to include EKS; it’s already part of the landscape. Instead, the challenge is how to incorporate it into a governance model that also manages AKS and edge clusters.

In the next episode of the Azure Kubernetes Chronicles, we’ll pause from hyperscale providers and focus on the edge. We will examine how lightweight Kubernetes distributions, such as k3s, are revolutionizing sectors like retail, manufacturing, healthcare, and telecommunications by extending cloud-native capabilities to the most remote parts of the enterprise.

Previous: Azure Kubernetes Chronicles 8: Fleet in Focus
Next up: Azure Kubernetes Chronicles 10: Kubernetes at the Edge with k3s