Summary:
- AWS EKS abstracts Kubernetes control plane management while offering multiple compute options including Auto Mode, Managed Node Groups, Fargate, and hybrid nodes for on-premises workloads.
- This guide walks through cluster creation using eksctl and Terraform, compares pricing across compute modes, and covers Day-2 operations including upgrades, monitoring with Prometheus and CloudWatch, and security hardening.
- Advanced use cases such as ML workloads with GPU scheduling, Windows containers, and hybrid deployments with EKS Anywhere round out the production-ready knowledge you need for 2026.
Running Kubernetes in production without drowning in operational complexity is the promise that draws thousands of engineering teams to managed container orchestration. Amazon Elastic Kubernetes Service, commonly known as AWS EKS, delivers on that promise by handling the undifferentiated heavy lifting of control plane availability, etcd persistence, and Kubernetes API server scaling. The service has evolved dramatically since its 2018 launch. The 2026 landscape introduces EKS Auto Mode, Provisioned Control Plane tiers, and a growing ecosystem of EKS Capabilities that fundamentally change how you architect clusters. This Amazon EKS tutorial provides the architectural grounding, hands-on implementation paths, and cost-aware decision frameworks you need to deploy production-grade Kubernetes on AWS.
What is Amazon EKS and how does it work
Amazon EKS is a managed Kubernetes service that runs the Kubernetes control plane across multiple AWS Availability Zones. This eliminates the need to provision, patch, or scale your own master nodes. The control plane consists of at least two API server instances and three etcd nodes distributed for high availability, all managed entirely by AWS. Your responsibility begins at the data plane, where you choose how to run your containerized workloads across EC2 instances, Fargate serverless compute, or hybrid nodes extending into your own data center.
The service integrates deeply with AWS identity and networking primitives. IAM roles for service accounts (IRSA) allow pods to assume fine-grained AWS permissions without embedding credentials. The VPC CNI plugin assigns routable VPC IP addresses directly to pods, enabling native AWS networking without overlay complexity. These integrations mean your Kubernetes workloads behave as first-class citizens within your broader AWS architecture.
Core components and terminology
Before diving into cluster creation, understanding the EKS vocabulary prevents confusion during implementation. The control plane is the AWS-managed Kubernetes brain handling API requests, scheduling decisions, and cluster state persistence. Node groups represent collections of EC2 instances registered as Kubernetes worker nodes, either self-managed or AWS-managed. Fargate profiles define which pods run on serverless compute based on namespace and label selectors.
Cluster add-ons are pre-packaged Kubernetes operational software managed through the EKS API. These include:
- CoreDNS: Provides cluster-internal DNS resolution for service discovery
- kube-proxy: Maintains network rules for Kubernetes Service abstraction
- VPC CNI: Handles pod IP address allocation from your VPC CIDR ranges
- EBS CSI Driver: Enables persistent volume claims backed by Amazon EBS
With these foundational concepts established, the next step involves preparing your local environment and AWS account for cluster deployment.
Prerequisites and environment setup
Successful EKS deployment requires both local tooling and AWS account configuration. Your local machine needs kubectl for Kubernetes API interaction, the AWS CLI for authentication, and either eksctl or Terraform for infrastructure provisioning. On the AWS side, you need an IAM user or role with permissions to create EKS clusters, EC2 instances, VPCs, and associated networking resources.
Required tools and versions
Install the following tools before proceeding with cluster creation. Version compatibility matters because EKS supports specific Kubernetes versions, and your kubectl client should match or be within one minor version of your cluster.
- AWS CLI v2.15+: Configure with
aws configureusing credentials that have EKS administrative permissions - kubectl 1.33+: Match this to your target EKS Kubernetes version (EKS supports 1.28 through 1.31 as of early 2026)
- eksctl 0.175+: The official CLI for EKS cluster lifecycle management
- Helm 3.14+: Required for installing add-ons and third-party charts
IAM role architecture
EKS requires two distinct IAM role categories. The cluster service role allows the EKS control plane to manage AWS resources on your behalf, including creating elastic network interfaces in your VPC. The node instance role grants worker nodes permission to join the cluster, pull container images from ECR, and write logs to CloudWatch. Setting up IAM roles for EKS cluster operations correctly from the start prevents frustrating permission errors during deployment.
For production environments, implement IAM roles for service accounts (IRSA) to grant pods AWS permissions without node-level credentials. This follows the principle of least privilege by scoping permissions to individual workloads rather than entire node groups.
Consider the following when designing your IAM architecture:
- Cluster role: Attach the
AmazonEKSClusterPolicymanaged policy - Node role: Attach
AmazonEKSWorkerNodePolicy, andAmazonEC2ContainerRegistryReadOnly - Pod roles: Create dedicated roles with trust policies referencing your OIDC provider
After clarifying these IAM requirements, you are ready to explore the multiple paths for creating your first EKS cluster.
Cluster creation methods
AWS provides several approaches to EKS cluster provisioning, each suited to different operational maturity levels and infrastructure-as-code strategies. The eksctl CLI offers the fastest path to a running cluster with sensible defaults. Terraform provides declarative infrastructure management with state tracking and drift detection. The AWS Console works for learning but lacks the repeatability production environments demand.
Creating a cluster with eksctl
The eksctl tool abstracts CloudFormation stack creation behind a simple command-line interface. A basic cluster with managed node groups requires only a few parameters. The following command creates a production-ready cluster with two m6i.large nodes across three availability zones:
eksctl create cluster --name prod-cluster --region us-west-2 --version 1.34 --nodegroup-name standard-workers --node-type m6i.large --nodes 3 --nodes-min 2 --nodes-max 5 --managed --with-oidc
This single command provisions the VPC, subnets, internet gateway, NAT gateways, security groups, IAM roles, the EKS control plane, and a managed node group. For teams learning how to set up an EKS cluster using eksctl, this approach provides immediate results while the underlying CloudFormation templates serve as documentation for what was created.
Infrastructure as code with Terraform
Terraform users benefit from the official terraform-aws-modules/eks module, which encapsulates EKS best practices. This approach integrates cluster provisioning into your broader infrastructure codebase, enabling peer review, version control, and consistent environments across development stages.
The module handles control plane creation, managed node groups, Fargate profiles, and add-on installation through declarative HCL configuration. Senior engineers appreciate Terraform’s state management for tracking infrastructure drift and its plan/apply workflow for safe production changes. The trade-off is increased initial complexity compared to eksctl’s imperative commands.
With your cluster running, the next decision involves selecting the compute mode that best matches your workload characteristics and cost constraints.
EKS Auto Mode and compute options
The 2025 introduction of EKS Auto Mode represents a significant shift in how teams operate Kubernetes on AWS. Auto Mode delegates node provisioning, scaling, and lifecycle management entirely to AWS. This eliminates the need to configure node groups, select instance types, or manage Karpenter provisioners. Understanding what EKS Auto Mode is and when to use it requires comparing it against traditional compute options.
The following diagram shows how Auto Mode differs architecturally from managed node groups and Fargate.
Auto Mode deep dive
EKS Auto Mode uses machine learning models trained on millions of EKS clusters to predict optimal instance types, purchase options (On-Demand vs Spot), and scaling decisions. When pods enter pending state, Auto Mode provisions capacity within seconds using a pre-warmed instance pool. The service automatically consolidates workloads during low-utilization periods, terminating underused nodes to reduce costs.
Auto Mode pricing includes a management fee on top of standard EC2 costs, but many organizations find the operational savings outweigh this premium. Teams without dedicated platform engineers particularly benefit because Auto Mode eliminates the expertise required to tune Karpenter provisioners or design node group strategies.
Compute mode comparison
Selecting the right compute mode depends on workload characteristics, cost sensitivity, and operational capacity. The following table summarizes the trade-offs across all available options.
| Compute mode | Best for | Pricing model | Operational overhead | Limitations |
|---|---|---|---|---|
| EKS Auto Mode | General workloads, teams without platform expertise | EC2 cost + Auto Mode fee | Minimal | Less control over instance selection |
| Managed Node Groups | Predictable workloads, specific instance requirements | EC2 cost only | Medium | Manual scaling configuration required |
| Karpenter | Complex scheduling requirements, cost optimization | EC2 cost only | High | Requires provisioner tuning expertise |
| Fargate | Batch jobs, burstable workloads, security isolation | Per-pod vCPU/memory/second | Low | No DaemonSets, limited storage, higher per-unit cost |
| Hybrid nodes | On-premises integration, data locality requirements | EKS control plane + on-prem infrastructure | High | Network latency, complex troubleshooting |
Consider the following when making your selection. Fargate works well for jobs that run intermittently because you pay only for execution time. Managed Node Groups suit teams with Reserved Instance commitments who want predictable capacity. Auto Mode fits organizations prioritizing operational simplicity over fine-grained control.
With compute architecture decided, understanding the full cost picture helps justify your EKS investment to stakeholders.
Cost analysis and pricing tiers
Amazon EKS pricing consists of multiple components that vary based on your architecture choices. The control plane costs $0.10 per hour ($73 monthly) for standard clusters. The 2025 introduction of Provisioned Control Plane tiers adds options for workloads requiring guaranteed API server capacity, with pricing scaling based on provisioned request units.
Breaking down cluster costs
A realistic production cluster cost analysis must account for control plane fees, compute costs, data transfer, and add-on expenses. How much Amazon EKS costs per cluster depends heavily on your compute mode selection and workload density.
For a cluster running 10 m6i.large On-Demand instances continuously:
- Control plane: $73/month
- EC2 compute: ~$700/month (10 × $0.096/hour × 730 hours)
- NAT Gateway: ~$32/month + data processing fees
- Load balancers: ~$16/month base + LCU charges
Auto Mode vs Fargate pricing
The pricing comparison between Amazon EKS Auto Mode and Fargate reveals important trade-offs. Fargate charges $0.04048 per vCPU-hour and $0.004445 per GB-hour, making it approximately 20-30% more expensive than equivalent EC2 capacity for continuously running workloads. Fargate eliminates node management overhead and provides strong security isolation through dedicated microVMs.
Auto Mode adds a management fee (approximately 10-15% of EC2 costs) but delivers operational savings that often exceed this premium for teams lacking Kubernetes expertise. Run cost projections using the AWS Pricing Calculator with your specific workload patterns before committing to an architecture.
After establishing your cluster and understanding costs, Day-2 operations become the focus of ongoing platform management.
Day-2 operations and cluster management
Production Kubernetes requires continuous attention to upgrades, monitoring, and security posture. EKS simplifies some operational tasks while introducing AWS-specific considerations for others. Best practices for upgrading EKS clusters safely differ from self-managed Kubernetes because AWS controls the control plane upgrade process.
Upgrade strategies
EKS supports Kubernetes versions for approximately 14 months after release, with extended support available for an additional 12 months at increased cost. Planning upgrades proactively avoids forced migrations and extended support fees. The upgrade process follows a specific sequence:
- Review release notes: Check for deprecated APIs and breaking changes in the target version
- Upgrade control plane: Initiate through Console, CLI, or Terraform (takes 20-40 minutes)
- Upgrade node groups: Roll nodes to new AMIs matching the control plane version
- Update add-ons: Ensure CoreDNS, kube-proxy, and VPC CNI versions are compatible
- Validate workloads: Confirm application health and API compatibility
Monitoring and observability
Monitoring EKS with Prometheus and CloudWatch provides complementary visibility into cluster health. CloudWatch Container Insights offers managed metrics collection with minimal configuration, while Prometheus enables custom metrics and longer retention through Amazon Managed Service for Prometheus (AMP).
The following diagram illustrates a comprehensive observability architecture for EKS.
Observability tools for Amazon EKS should cover four pillars. These are metrics (Prometheus/CloudWatch), logs (Fluent Bit to CloudWatch Logs), traces (X-Ray or OpenTelemetry), and events (Kubernetes events forwarded to your SIEM). Implementing all four provides the visibility needed to troubleshoot production incidents effectively.
Security hardening
Securing networking in Amazon EKS involves multiple layers from VPC design through pod-level policies. Start with private cluster endpoints that restrict API server access to your VPC. Implement security groups for pods to apply AWS network ACLs at the pod level. Deploy network policies using Calico or the VPC CNI’s native policy support to control pod-to-pod traffic.
Additional security measures include:
- Pod Security Standards: Enforce restricted or baseline policies at the namespace level
- Secrets management: Integrate with AWS Secrets Manager using the CSI driver
- Image scanning: Enable ECR image scanning and block deployments of vulnerable images
- Audit logging: Stream control plane audit logs to CloudWatch for compliance and forensics
With operational foundations established, advanced use cases extend EKS capabilities to specialized workloads.
Advanced use cases
EKS supports workloads beyond typical web applications, including machine learning training, Windows containers, and hybrid deployments spanning cloud and on-premises infrastructure. These scenarios require additional configuration but leverage the same foundational EKS architecture.
ML workloads and GPU scheduling
Running ML workloads on EKS requires GPU-enabled node groups using P4d, P5, or G5 instance families. Install the NVIDIA device plugin to expose GPU resources to the Kubernetes scheduler. Karpenter or Auto Mode can provision GPU instances on-demand, avoiding the cost of idle accelerators during non-training periods.
For distributed training, deploy the Kubeflow Training Operator or use SageMaker’s integration with EKS for managed training jobs. The AWS Neuron SDK enables workloads on Inferentia and Trainium chips for cost-effective inference and training.
Windows containers and hybrid nodes
Running Windows workloads on EKS requires Windows node groups alongside Linux nodes (core cluster add-ons like CoreDNS and VPC CNI currently require Linux nodes to run). Windows containers support .NET Framework applications that cannot be containerized on Linux, enabling modernization of legacy Windows workloads.
For organizations asking whether EKS can run hybrid or on-premises nodes, EKS Hybrid Nodes and EKS Anywhere provide two approaches. Hybrid Nodes register on-premises servers as worker nodes in a cloud-hosted EKS cluster, useful for data locality requirements. EKS Anywhere deploys the entire EKS stack on-premises using VMware vSphere or bare metal, providing consistent Kubernetes APIs across environments.
Conclusion
AWS EKS has matured into a comprehensive Kubernetes platform that addresses use cases from simple web applications to complex ML training pipelines and hybrid deployments. The introduction of Auto Mode and Provisioned Control Plane tiers in recent releases demonstrates AWS’s commitment to reducing operational burden while providing enterprise-grade reliability. Your architecture decisions around compute modes, networking, and observability will determine both the cost efficiency and operational sustainability of your Kubernetes investment.
Three critical takeaways emerge from this guide. First, match your compute mode to your team’s operational capacity. Use Auto Mode for simplicity, Managed Node Groups for control, and Fargate for serverless isolation. Second, invest in observability from day one because Kubernetes troubleshooting without metrics, logs, and traces becomes exponentially harder as cluster complexity grows. Third, treat upgrades as routine maintenance rather than emergency projects by staying within one version of the latest release.
Looking ahead, expect EKS Capabilities to expand the managed add-on ecosystem, reducing the need for third-party tooling. The convergence of Karpenter’s intelligence into Auto Mode suggests a future where node management becomes entirely invisible. For teams starting their EKS journey today, the platform offers a clear path from initial deployment through production maturity without the operational cliff that characterized earlier Kubernetes adoption.
