Managed Kubernetes Comparison: EKS vs AKS

#Managed Kubernetes Service

Kubernetes, despite its popularity, is a complicated technology. Businesses of all sizes are driven by business logic, and developers tend to be better at developing business logic than they are at maintaining the operations of the running cluster or creating production clusters from scratch.

A fully managed Kubernetes platform can help by allowing you to focus on your application while letting the cloud provider manage your resources’ availability, security, and deployment. The provider makes sure the resources are deployed at your desired geolocation and adds additional compute resources for the deployment. You can simply focus on your business logic and your application’s deployment and not on the underlying operations necessary to keep serving your application to users.

#Kubernetes Versions and Runtime

Contrary to popular belief, the latest version from Kubernetes isn’t supported by the provider as soon as it’s released. If you compare AKS and EKS, you’ll see that both are unsupportive of the latest upstream and each has a default cluster version a couple of months older than the upstream.

As of November 2021, these are the versions supported by them:

AKS supports the rapid stream with older versions deprecated, whereas EKS supports a broader range of older versions.

#Container Runtime

Docker was deprecated from upstream Kubernetes 1.20. EKS still supports Docker as the only container runtime, whereas AKS has come a long way to support containerd from version 1.19. You can track the development of containerd here for EKS.

#Quotas on Providers

Quotas are essential in deciding whether your workloads will be a good fit in the cloud environment. Below, we examine some of the more popular factors that will help you determine the best fit.

#Maximum Number of Clusters per Region

EKS’s maximum number of clusters per region is one hundred, though this can be increased by contacting the vendor. Meanwhile, AKS doesn’t have a specific limit on clusters per region, but it sets one thousand as the maximum number of clusters for a user account.

#Maximum Nodes per Cluster

For EKS, there is a limit of four hundred and fifty nodes per Node Group, and you can have up to thirty Node Groups. That adds up to a max of 13500 nodes. AKS, on the other hand, has a limit of one thousand across all node pools.

#Maximum Node Pools

Nodes of similar configurations are grouped as node pools to lessen the need to group nodes with similar hardware, that is, you don’t need different clusters with different hardware. AKS has recently started to support up to ten node pools. Meanwhile, EKS has been supporting node pools for four years now, up to a maximum of thirty.

#Maximum Number of Pods

The maximum number of pods per node supported by Kubernetes v1.22 is 110, but the managed Kubernetes offerings show different stats.

AKS supports a maximum of 250 pods per node; each node is allocated a subnet of 254 hosts (/24) with 250 IP addresses for the 250 pods and an additional four spare IPs.

EKS has a complicated structure for supported pods per node, and it depends on the Elastic Network Interfaces (ENIs). The number of pods is strictly 110 if the version of AWS-CNI is earlier than 1.9.0 or if you’re using Cilium, Calico, Weave Net, or Antrea instead of AWS-CNI.

If these two conditions aren’t met, then your number of pods is dependent on your ENIs allowance. You can read more about the numbers in this file from AWS and calculate it using the following formula:

Mapping is calculated from AWS EC2 API using the following formula:
 * First IP on each ENI is not used for pods
 * +2 for the pods that use host-networking (AWS CNI and kube-proxy)

  # of ENI * (# of IPv4 per ENI - 1) + 2

#Monthly Cost and Cost Prediction

There are two components of pricing: the control plane and the hardware (virtual machines’ bandwidth, storage). AKS doesn’t charge for the control plane and EKS has a cost of ten cents per hour per control plane, which adds up to $144 extra per month for a cluster. For AKS, there’s an availability of Uptime SLA, which costs ten cents per hour per cluster.

Pricing for bandwidth and storage depends upon the region and the specifications.

Pricing for virtual machines depends on specifications for the machine supporting your infrastructure. You can follow these links to learn more about the pricing for AWS EC2 Instances and [Azure VMs] (https://azure.microsoft.com/en-in/pricing/details/virtual-machines/windows/#pricing). Also, AKS requires nodes to use VMs of sizes with more than two CPUs for sufficient compute resources. Therefore, the following sizes aren’t suitable:

• Standard_D1
• Standard_D1_v2
• Standard_DS1
• Standard_DS1_v2
• Standard_F1
• Standard_F1s
• Standard_B1ls
• Standard_B1s
• Standard_B1ms
• Standard_A0
• Standard_A1
• Standard_A1_v2
• Standard_A2

#Cluster and Worker Node Upgrades

Both AKS and EKS support manual as well as automatic upgrades to your Kubernetes cluster. Azure upgrades are straightforward, but EKS’s aren’t as simple, with a couple of command-line instructions needed to complete the task.

#Host OS

There are many operating systems to choose from, but while using managed solutions, you’re limited in the choice of them. AKS supports Ubuntu 18.04 and Windows Server for node creation. Meanwhile, EKS supports Amazon Linux 2, Ubuntu, Bottlerocket, and Windows for the same. Bottlerocket is a Kubernetes-focused operating system used for better optimization on EKS.

#Support for GPUs

Both providers support GPUs. Additionally, clusters from Azure have been used to train large models like GPT-3, CLIP, and DALL·E from OpenAI.

#Auto-Repair Nodes

The auto-repair nodes feature ensures that your nodes in a cluster are running and healthy. This feature automatically scans and repairs unhealthy nodes but is currently supported only by Azure AKS and not EKS.

#Bare Metal

Bare metal clusters are installed on a cloud architecture with no virtualization layer or hypervisor. This decreases the virtualization overhead and provides more computing resources to your application. Neither Azure nor AWS currently supports bare metal. Many sources claim that AWS supports bare metal instances, but this is not the case, according to the official documentations.

#Availability

Highly Available applications are a major reason for the widespread adoption of cloud providers. SLAs (service-level agreements) set users’ expectations and ensure an application has a specific uptime during a given period. Both offerings are highly available. EKS offers SLAs of 99.00% uptime, which assures customers that only 3.65 days of downtime per year at max can occur. AKS offers 99.9% SLA (max downtime of 8.77 hours/year) with 99.95% SLA (max downtime of 4.38 hours/year) in these ten Azure regions:

1. Central US
2. East US 2
3. East US
4. West US 2
5. Central Japan
6. East-North Europe
7. Southeast Asia
8. UK
9. South-West Europe
10. France

#Autoscaling

Cloud providers make sure that they can manage demand as it arises. Similarly, your workloads running on AKS/EKS are supported by Cluster Autoscaling with configurable autoscaling profiles. A notable exception on Azure is that it doesn’t support vertical pod autoscaling as of now. However, autoscaling pods to different configurations (instead of the normal horizontal scaling) seem to be much less common.

#Security and Compliance

Cloud providers transfer the security burden from the consumer to themselves, which makes them the ideal choice in most situations. AKS and EKS are both great with security, supporting Secrets, RBAC (Role-based access control), and configurable IPs for the clusters. AKS goes a step further to support confidential containers, which can run applications in secured and isolated containers with attestation.

However, an important consideration about AKS is their failure to deliver important security patch updates for several years at times, which has created CVEs like Azurescape, affecting users. The updated commitments don’t reflect the previous mishaps.

AKS and EKS are both industry-grade services and are fully updated with compliances like HIPAA, SOC, ISO, and PCI DSS. You won’t face any issues with either of them regarding compliance.

#Monitoring/Observability

Monitoring health is critical to mission-essential applications. EKS supports AWS App Mesh as well as Istio. App Mesh isn’t a good choice if you’re planning to avoid vendor lock-in, but it’s very prevalent with production applications running on AWS as it takes significantly less effort to deploy and configure.

Meanwhile, Azure supports all the popular service meshes like Istio, Linkerd, and Consul. One limitation of the Microsoft-owned cloud platform is its inability to provide L7 load balancing, which EKS provides. Both providers do offer basic support for L4 load balancing.

To monitor resources on EKS, you need to deploy Prometheus manually. Azure, on the other hand, has Azure Monitor, which does the same work for you without running commands to deploy. Furthermore, Container Insights from Azure is a good way to watch resource-level details.

#Community and Documentation

The best way to start anything is to begin with documentation and sustained growth within the community. Azure has the upper hand over AWS with very simple and extensive documentation in the form of a learning path that helps you get started and fix problems. The Azure community is very engaged and jumps in to help whenever you face issues.

AWS has excellent community support, but its documentation is not well structured and tends to be a bit detailed, burying the important information in paragraphs of text.

#Summary of EKS and AKS Considerations

As you can see, both offerings are mature and are leaders in the market. They contain all the main features that a production-grade Kubernetes cluster should have, with many users and companies using them for their day-to-day operations. Deciding between the two requires careful consideration and depends upon your specific use case and architecture.

For example, one crucial factor in evaluating the options is the platform where most of your workloads are. If you have experience with AWS, EKS would be an ideal choice as most of your team is already trained to work in the AWS ecosystem. Migrating to some other service would be neither efficient nor cost-effective, even after factoring in the $144 savings for the EKS control plane.

The same could be said about AKS, the offering from Azure. AKS is widely used by most of the big corporations because their business workloads are either hosted on Azure or require a Windows server, which is offered only by AKS.

Another factor could be your organization’s perception of upgrades. If your organization is agile and wants to benefit from all the new features and versions as soon as they’re released, then AKS is definitely the best choice. On the other hand, EKS is preferable if you need support for previous versions of Kubernetes. Another essential factor to consider is whether your cloud provider is in proximity to your user, as closer proximity improves performance.

Finally, you can evaluate the pricing factor in your decision using the calculators from Azure and AWS.

---

This article is part of the "Managed Kubernetes Comparison" series.

• AWS EKS vs GKE (Google Kubernetes Engine)
• AWS EKS vs DigitalOcean Kubernetes
• AWS EKS vs AKS (Microsoft Azure Kubernetes Service)
• AWS EKS vs Scaleway Kubernetes Kapsule