What EKS is and what AWS does for you
Amazon EKS is the managed Kubernetes control plane on AWS. AWS runs the API servers and etcd across availability zones, patches them and exposes a standard Kubernetes endpoint. Everything else, including worker nodes, networking add-ons, ingress, storage drivers and your workloads, runs in your account and is yours to operate. That boundary is the single most useful thing to understand before an EKS consulting engagement, because most of the real work sits on your side of it.
For the platform concepts themselves (scheduling, RBAC, probes, disruption budgets), see our Kubernetes page. This page covers what is specific to AWS.
Architecture decisions that are hard to reverse
VPC and pod networking
By default the Amazon VPC CNI gives every pod a real VPC IP address. That makes pods first-class citizens for security groups and VPC flow logs, but it also means pod count is bounded by subnet size and instance network interfaces. We size subnets generously, consider a secondary CIDR range for pods, and enable prefix delegation where density matters. Choosing a /24 for a cluster that later needs a few thousand pods is the classic mistake, and fixing it means rebuilding. See our EKS cluster architecture design deliverable.
Compute model
You have four options: managed node groups, Karpenter, Fargate, or EKS Auto Mode. Our default for general workloads is a small managed node group for system components plus Karpenter for everything else. Fargate suits isolated, low-ops workloads but has constraints (no DaemonSets, no privileged pods). Auto Mode hands node lifecycle to AWS, which is attractive for small teams that value simplicity over tuning.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: general
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
Pair this with sensible PodDisruptionBudgets so consolidation does not surprise your services. Our Karpenter and cluster autoscaler guide goes deeper.
Identity and security on AWS
Identity is where EKS differs most from AKS and GKE, because two IAM systems meet.
- Human and CI access: EKS access entries map IAM principals to Kubernetes permissions through the EKS API, replacing the older aws-auth ConfigMap for new clusters. Avoid sharing the cluster-creator identity.
- Pod access to AWS: use IRSA or EKS Pod Identity so each service account assumes a scoped IAM role. Never let pods inherit the node role. Our IRSA least-privilege work audits exactly this.
- Secrets: enable KMS envelope encryption and pull application secrets from AWS Secrets Manager or Parameter Store (details).
- Network: keep the API endpoint private where you can, apply security groups for pods selectively, and add Kubernetes network policies (EKS network policies and security groups).
- Detection: turn on control plane audit logging and consider GuardDuty EKS protection.
Cost and capacity
EKS cost is rarely the cluster fee. The usual drivers are over-requested pods, idle nodes, NAT gateway data processing, cross-zone traffic and verbose logging. Our order of attack is: measure by namespace, fix requests, enable Karpenter consolidation, move tolerant workloads to spot, then tackle network and storage. A worked list is in 12 ways to cut EKS cost, and our cost analysis and optimisation service applies it to your account. Use the EKS cost calculator to size a baseline.
Day-2 operations
Upgrades
EKS upgrades the control plane in place, one minor version at a time, and you cannot downgrade. Then add-ons (CoreDNS, kube-proxy, VPC CNI, EBS CSI) must match, and nodes must be replaced. Karpenter drift or managed node group updates handle the last step. Each version has a standard support window, followed by a paid extended period, so we keep a calendar. Our EKS upgrade runbook is the artefact we hand over.
Observability and delivery
CloudWatch covers control plane logs, but application metrics and alerting are better served by Prometheus and Grafana (EKS monitoring setup). Deliver workloads through GitOps; our Argo CD on EKS tutorial shows a working pattern.
Ingress and traffic
The AWS Load Balancer Controller provisions ALBs for Ingress and NLBs for Services of type LoadBalancer. Use IngressGroups to share one ALB across many services instead of paying for one per team, and terminate TLS with ACM certificates so renewal is not your problem. Keep external DNS automated, and run at least two replicas of the controller with a disruption budget, because a stalled controller silently stops reconciling load balancers.
Backup and recovery
Nothing in EKS backs up your persistent volumes or custom resources for you. We pair EBS snapshot policies or a Kubernetes-aware backup tool with Git as the source of truth for manifests, then rehearse a restore into a fresh cluster. That rehearsal also proves your Terraform can rebuild the platform, which is the real disaster recovery test. See our backup and disaster recovery service.
Common EKS failure modes
- IP exhaustion: small subnets plus the default CNI settings.
- Node role over-permission: every pod can reach whatever the instance can.
- Stale add-ons: a control plane upgrade that leaves CoreDNS or the CNI unsupported.
- Load balancer sprawl: one ALB per Ingress, each billed hourly.
- Spot without budgets: interruptions take out all replicas together.
When to choose something else
If you run a few stateless services and nobody on the team knows Kubernetes, ECS on Fargate is a fair answer and cheaper to own. If you already live in Azure or Google Cloud, use AKS or GKE. If you are weighing EKS against something else or planning a cloud migration, book a consultation and we will give you a candid recommendation.
Official documentation: docs.aws.amazon.com/eks