Amazon EKS control plane

The Kubernetes control plane managed by Amazon EKS runs inside an EKS-managed VPC. This control plane is single tenant, meaning that for each EKS cluster there is a unique EKS managed VPC and Kubernetes control plane. The EKS control plane comprises the Kubernetes API server nodes and etcd cluster. Kubernetes API server nodes run components such as the API server, scheduler, and kube-controller-manager in an auto-scaling group. EKS runs a minimum of two API server nodes in distinct Availability Zones within an AWS Region. Likewise, for durability, the etcd server nodes also run in an auto-scaling group that spans three Availability Zones. EKS runs a NAT gateway in each Availability Zone, and API servers and etcd servers run in a private subnet. This architecture protects cluster availability so that an event in a single Availability Zone doesn't affect the EKS cluster's availability.

Kubernetes API data

Amazon EKS provides default envelope encryption for Kubernetes API data in EKS Auto Mode clusters. Envelope encryption protects the data you store with the Kubernetes API server. For example, envelope encryption applies to the configuration of your Kubernetes cluster, such as ConfigMaps. Envelope encryption does not apply to data on nodes or Amazon Elastic Block Store (Amazon EBS) volumes. This envelope encryption extends across Kubernetes API data.

This provides a managed, default experience that implements defense-in-depth for your Kubernetes applications and doesn't require action on your part.

Amazon EKS uses AWS Key Management Service (AWS KMS) with Kubernetes KMS provider v2 for this additional layer of security with an AWS owned key and the option for you to bring your own customer managed key (CMK) from AWS KMS.

EKS Auto Mode capabilities

When EKS Auto Mode is enabled for a cluster, an additional set of control plane capabilities are also enabled. In a standard Amazon EKS cluster, the components that perform auto-scaling, manage Elastic Network Interfaces (ENIs) and Amazon EBS devices run as Kubernetes Pods on nodes in the cluster. With Auto Mode, AWS manages these components and runs them outside of the cluster. This shifts the operational responsibility for the health and patching of these components to AWS and moves the components that require sensitive permissions to operate outside of the cluster.

To manage compute, networking, and storage, EKS Auto Mode requires additional permissions beyond those required in a non-Auto Mode cluster. These are normally provided by adding a set of policies to the cluster IAM role. However, there is no requirement to attach these specific policies to the cluster role. Custom policies can be used provided they grant sufficient permissions to Auto Mode components.

The cluster IAM role used by EKS Auto Mode is a service role. A service role is an IAM role that a service assumes to perform actions on your behalf. Service control policies (SCPs) apply to the actions performed by these roles and can be used to further restrict Auto Mode capabilities, such as limiting the instance types that can be launched. This differs from a service-linked role (SLR), which is a type of role that is linked to an AWS service and is not restricted by SCPs. Auto Mode minimizes its use of SLRs so that SCPs are respected when possible.