Amazon EKS in Production: Control Plane, Compute, IAM, Networking, and Upgrades

Amazon Elastic Kubernetes Service operates a dedicated Kubernetes control plane for each cluster. AWS places API server and etcd capacity across Availability Zones and replaces failed control-plane instances. That removes control-plane installation and patching, not responsibility for workload configuration, access policy, network design, data protection, or most compute choices.

Compute models

Managed node groups automate EC2 provisioning and lifecycle through Auto Scaling groups. Self-managed nodes expose more control. Fargate supplies pod-oriented serverless compute. EKS Auto Mode and Karpenter can automate broader data-plane decisions. Each model changes patching, instance selection, daemon support, interruption handling, and cost; “managed” does not mean identical responsibility.

Identity and networking

AWS IAM authenticates access to EKS and grants workloads AWS API permissions through supported pod-identity mechanisms; Kubernetes RBAC still authorizes Kubernetes actions. Nodes and pods live in VPC networking governed by subnets, route tables, security groups, the VPC CNI, load balancers, and DNS. Plan IP capacity before scale creates an outage.

Upgrades, resilience, and observability

Control plane, nodes, add-ons, and application APIs have related but separate upgrade paths. Test version skew and deprecated APIs, then update nodes with disruption budgets and spare capacity. Spread workloads across zones, but remember that zonal EBS volumes constrain rescheduling. Collect control-plane logs, CloudWatch metrics, Kubernetes events, application telemetry, and node signals.

Cost and shared responsibility

Costs include the cluster control plane, EC2 or Fargate compute, EBS, load balancers, NAT, data transfer, logging, and add-ons. AWS secures and operates the managed service; customers still secure identities, workloads, images, secrets, network exposure, and timely node/add-on upgrades. Choose EKS when Kubernetes APIs and ecosystem portability justify that operational surface.

Access has two distinct decisions

An AWS principal first authenticates to the EKS API endpoint; Kubernetes authorization then decides which API operations it may perform. EKS access entries provide an AWS API-managed way to associate IAM principals with Kubernetes permissions, while Kubernetes RBAC remains available for granular in-cluster policy. Do not hand every platform operator cluster-admin. Separate emergency administration, platform automation, read-only investigation, and application deployment roles, and test each role with impersonation-aware audit evidence.

Workload access to AWS services is another path. EKS Pod Identity or IAM roles for service accounts associate a Kubernetes service account with AWS permissions so a pod does not inherit the node role. Scope policies to the required resources, use a distinct service account per trust boundary, and prevent untrusted workloads from reaching credentials that belong to another component. Kubernetes Secrets are not a substitute for IAM federation and require their own encryption, RBAC, backup, and rotation controls.

Add-ons and version lifecycle

The managed control plane, kubelet nodes, VPC CNI, CoreDNS, kube-proxy, CSI drivers, admission webhooks, and third-party controllers evolve separately. Before an upgrade, inventory APIs with deprecation tooling, verify supported version skew, review add-on compatibility, and test admission and networking behavior in a representative environment. Upgrade the control plane and data plane through a documented sequence rather than assuming a node-group update changes every component.

For node replacement, create surge capacity before draining. Pod disruption budgets constrain voluntary eviction but cannot create missing replicas or override impossible topology constraints. Confirm that workloads tolerate cordon and drain, daemon sets are compatible with the new image, and zonal volumes have a viable placement path. Keep a recovery procedure for a broken CNI or DNS add-on because ordinary application rollbacks cannot repair cluster networking.

Network capacity is a reliability budget

The Amazon VPC CNI assigns VPC addresses to pods in its common operating mode, so subnet space, instance ENI limits, prefix delegation choices, and warm-address settings affect scale. Track available addresses and allocation failures before a rollout. Private API endpoints, public endpoint CIDR restrictions, security groups, network policies, load-balancer controllers, and DNS each solve different parts of exposure; enabling one does not implicitly configure the others.

Map north-south and east-west flows explicitly. A private node may still need controlled paths to ECR, STS, CloudWatch, S3, or other AWS APIs. VPC endpoints can cover supported services, while external dependencies may require inspected egress. NetworkPolicy enforcement depends on the installed networking implementation, so prove policy with connection tests instead of accepting YAML as evidence.

Backup, detection, and recovery

Source-controlled manifests and Helm values help reconstruct desired state, but they do not back up persistent application data or every runtime object. Define backups for databases and volumes, protect encryption keys, and periodically restore into an isolated environment. Avoid treating an etcd snapshot as a customer-operated mechanism: AWS manages EKS control-plane etcd, while customers recover workloads and data through supported application and Kubernetes tooling.

Enable the control-plane log types needed for audit and diagnosis, then correlate them with CloudTrail, node telemetry, Kubernetes events, workload logs, and traces. High-value alerts include failed authentication, privileged RBAC changes, admission failures, unschedulable pods, node pressure, CNI address errors, DNS latency, and prolonged rollouts. A quarterly game day should prove loss of a node group, an Availability Zone dependency, and a critical add-on without relying on undocumented console actions.

Keep cluster creation reproducible as infrastructure code, including endpoint access, logging, encryption, add-on versions, node configuration, and access entries. A console-created exception should either be codified after review or removed. Periodically compare deployed configuration with the approved definition and investigate drift before it becomes the undocumented prerequisite for the next upgrade.

Record quota assumptions as well: control-plane requests, pod density, load balancers, volumes, addresses, and AWS API throttles can each become the first scaling boundary.

Related:

Sources: