All Services

Containers

Amazon Elastic Kubernetes Service

EKS provides managed Kubernetes control planes for teams that need Kubernetes APIs and ecosystem compatibility.

Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with Amazon Elastic Kubernetes Service.

Amazon Elastic Kubernetes Service pricing and cost programs

Pricing model: Cluster and selected compute usage

On-Demand
Service-specific
Reserved Instances or reserved capacity
Service-specific
Savings Plans
Service-specific
Spot
Service-specific

Billing dimensions: Cluster hours and support tier · Worker compute · Hybrid nodes · Capabilities

Programs and modes: Standard and extended support · EC2 nodes · Fargate · EKS Auto Mode

The EKS cluster fee is separate from worker compute; node purchase options depend on the chosen compute mode.

Free Tier: Service-specific — verify current offers

Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.

Official AWS pricing

Official AWS sources reviewed 2026-07-21.

Why implement Amazon Elastic Kubernetes Service?

  • Provides an AWS-managed, highly available Kubernetes control plane with upstream-compatible Kubernetes APIs and tooling.
  • Preserves Kubernetes portability and ecosystem access while integrating clusters with IAM, VPC networking, load balancing, storage, and AWS observability.
  • Offers several data-plane choices, including managed node groups, Fargate, and EKS Auto Mode, so teams can choose their operational boundary.

How to implement Amazon Elastic Kubernetes Service

  1. Design cluster VPC, subnet, endpoint, identity, and access requirements, then create the cluster and select a data-plane mode.
  2. Configure cluster access, workload identity, VPC CNI, DNS, storage and load-balancing add-ons, image repositories, secrets, and network policies.
  3. Deploy workloads with declarative manifests or a GitOps pipeline and add autoscaling, logging, metrics, audit visibility, backups, and a tested version-upgrade process.

Amazon Elastic Kubernetes Service best practices

  • Use least-privilege cluster access and workload identities, restrict the API endpoint, segment workloads, and apply pod, network, image, and runtime security controls.
  • Run production capacity across Availability Zones, use disruption budgets and topology rules, and monitor control-plane, node, pod, and application health.
  • Keep Kubernetes versions and managed add-ons current, rehearse upgrades, validate quotas and IP capacity, and follow the EKS guides for reliability, networking, scaling, and cost.

Amazon Elastic Kubernetes Service use cases and server impact

  • Kubernetes-standardized application platforms
  • Portable multi-service systems
  • Advanced networking, operators, and Kubernetes ecosystem workloads

Replaces Kubernetes control-plane operations. Node management remains with the customer unless a managed mode such as Fargate or EKS Auto Mode takes on more of the data plane.

Official implementation resources

How Amazon Elastic Kubernetes Service works with other AWS services

Arrows show the documented technical direction. Reciprocal navigation does not imply a reverse technical dependency.

Official AWS sources reviewed 2026-07-25.

Elastic Load Balancing → Amazon Elastic Kubernetes Service

Elastic Load Balancing routes requests to Amazon Elastic Kubernetes Service

The AWS Load Balancer Controller provisions and configures Elastic Load Balancing resources from Kubernetes Service or Ingress resources in EKS.

Why teams use it
Teams retain Kubernetes-native routing declarations while using managed AWS load balancers.
Permissions and networking
Install and authorize the controller, tag or discover subnets correctly, and choose instance or IP targets intentionally.
Pricing and security caveats
The controller, Kubernetes objects, and load balancer have separate lifecycles; deleting or misconfiguring one can interrupt routing and load balancer charges continue while provisioned.

Amazon Virtual Private Cloud → Amazon Elastic Kubernetes Service

Amazon Virtual Private Cloud provides network boundaries for Amazon Elastic Kubernetes Service

EKS cluster and pod networking use VPC subnets, routes, security groups, and elastic network interfaces.

Why teams use it
The integration gives Kubernetes workloads native reachability to AWS resources and familiar network controls.
Permissions and networking
Size pod address capacity, separate public and private access deliberately, and restrict both cluster endpoint and workload security groups.
Pricing and security caveats
Private networking can add NAT or endpoint charges, and Kubernetes network policy is a separate control from VPC security groups.

AWS Identity and Access Management → Amazon Elastic Kubernetes Service

AWS Identity and Access Management authorizes Amazon Elastic Kubernetes Service

EKS workloads can use IAM roles associated with Kubernetes service accounts or pod identities to receive scoped AWS credentials.

Why teams use it
The pairing avoids node-wide credentials and maps application identity to specific cloud permissions.
Permissions and networking
Bind roles to the intended cluster, namespace, and service account, restrict role trust, and keep Kubernetes RBAC separate from AWS API authorization.
Pricing and security caveats
IAM and Kubernetes authorization are independent layers; a permissive policy can expose resources even when cluster RBAC is strict.

Amazon Elastic Kubernetes Service → Amazon CloudWatch

Amazon Elastic Kubernetes Service sends cluster telemetry to Amazon CloudWatch

CloudWatch Container Insights can collect metrics and logs from EKS clusters, nodes, pods, and containers.

Why teams use it
The integration gives platform teams AWS-native dashboards and alarms for Kubernetes workload health.
Permissions and networking
Deploy and authorize the observability components, set log retention, scrub sensitive fields, and account for Fargate versus node collection differences.
Pricing and security caveats
Logs and enhanced metrics are separately billed; observability agents consume workload resources and do not replace Kubernetes-native health checks.

Planning guides that use Amazon Elastic Kubernetes Service

  • Amazon EMR planning guide — Run EMR on EKS to share an existing Kubernetes cluster instead of maintaining a separate EMR cluster.