ACKF logoACKF
Containers

Amazon EKS

View on GitHub

Amazon EKS

A managed Kubernetes service that provides an AWS-operated control plane for running Kubernetes clusters. It operates by offering a regional, highly available control plane while customers run workloads on compute they select (Amazon EC2, managed node groups, or AWS Fargate). It fits into AWS architectures as the Kubernetes orchestration layer that integrates with VPC networking, IAM, container registries, and AWS storage and monitoring services.

🗂 Resource Category

Containers • Compute

🧠 Exam Memory Hook

Think: "Managed Kubernetes control plane + customer worker nodes or Fargate + VPC networking = Amazon EKS"

📖 Ownership

Classification: Shared Responsibility Service

AWS responsibilities: AWS operates, secures, maintains, and patches the Amazon EKS control plane and the AWS-owned physical infrastructure and hypervisor; AWS provides the Kubernetes API endpoints, etcd, and control-plane components and is responsible for their availability and scaling. AWS also provides integrations and managed compute options such as AWS Fargate where AWS manages the underlying compute runtime. AWS does not operate or patch customer-managed worker node guest operating systems or container images unless those compute options are explicitly managed by AWS (for example, Fargate).

Customer responsibilities: The customer configures cluster resources, Kubernetes manifests, RBAC, network policies, IAM roles, and Kubernetes-level security; the customer provisions, configures, and secures worker nodes when using Amazon EC2 or managed node groups and is responsible for container images, runtime configuration, application code, and access control. The customer monitors cluster and application health, configures logging and metrics collection (for example with Amazon CloudWatch), and automates lifecycle operations such as node upgrades or image refresh as required.

Patching responsibilities: AWS patches the physical infrastructure, hypervisor, and the EKS-managed control plane components. When using AWS Fargate, AWS patches the underlying compute runtime and infrastructure. When using Amazon EC2 worker nodes (self-managed or as managed node groups), the customer is responsible for guest operating system patches, installed runtimes, libraries, container images, and application dependencies; managed node groups simplify provisioning and replacement but OS-level patching requires node image updates or replacements initiated by the customer.

🏗 Typical Architecture

💡 Top 5 Features

  • Provides an AWS-managed Kubernetes control plane with high availability and API endpoints.
  • Supports multiple compute models including Amazon EC2 worker nodes, managed node groups, and AWS Fargate.
  • Integrates with AWS Identity and Access Management for authentication and with IAM Roles for Service Accounts for fine-grained pod permissions.
  • Native integration points for pulling container images from Amazon ECR and using Amazon VPC for pod networking.
  • Supports Windows and Linux worker nodes and can use AWS storage services (EBS, EFS) for persistent volumes.

✅ Top 5 Use Cases

  • Running production containerized microservices with Kubernetes orchestration while offloading control-plane operations to AWS.
  • Migrating on-premises Kubernetes clusters to a managed control plane to reduce operational overhead of control-plane management.
  • Implementing a multi-tenant platform team model where teams deploy namespaces and workloads to centrally managed EKS clusters.
  • Running ephemeral or on-demand workloads using AWS Fargate to avoid managing EC2 instances for certain pods.
  • Hosting stateful services that use Kubernetes for orchestration while storing persistent data on Amazon EBS, Amazon EFS, or external databases such as Amazon RDS.

🏗 Architecture Placement

Amazon EKS provides the Kubernetes orchestration layer with an AWS-managed control plane that is regional; the control plane exposes API endpoints to the account and region while worker nodes run in the customer VPC. External traffic is typically routed via a load balancer or ingress to pods, and EKS clusters commonly pull container images from Amazon ECR and send logs and metrics to Amazon CloudWatch. Placement and networking depend on VPC configuration, subnets, and load-balancer choices.

🎯 Commonly Used With

- Amazon EC2
- AWS Fargate
- Amazon ECR
- Amazon VPC
- AWS Identity and Access Management

🌍 5 Real-World Examples

  • A financial services team runs containerized trade-processing microservices on EKS to use Kubernetes-native deployment patterns while integrating with Amazon RDS for transactional storage.
  • A media company uses EKS with Amazon ECR to orchestrate transcoding workloads and scales worker nodes to meet variable processing demand.
  • A retail platform operates shopping-cart and catalog microservices on EKS, using ALB ingress for HTTP traffic and Amazon EBS for per-pod volumes.
  • A healthcare analytics team runs batch data-processing jobs on EKS using Fargate for isolated, short-lived tasks to reduce node management overhead.
  • A telecommunications operations team deploys network management tooling on EKS to standardize tooling across environments and integrate with AWS monitoring and logging.

🎓 AWS Exam Clues

  • Choose EKS when you need Kubernetes API compatibility and want AWS to manage the control plane while retaining Kubernetes features.
  • Consider AWS Fargate with EKS when you want serverless compute for pods and to avoid managing EC2 instances.
  • Use managed node groups or self-managed EC2 when you need specific instance types, OS control, or specialized drivers that Fargate does not support.
  • EKS clusters run in a VPC and require careful VPC, subnet, and security group design for pod networking and load balancer integration.
  • Authentication and authorization typically combine AWS IAM, IAM Roles for Service Accounts, and Kubernetes RBAC, so design identity controls accordingly.

📝 Quick Revision

Amazon EKS is a managed Kubernetes control plane that lets you run Kubernetes clusters on AWS using EC2, managed node groups, or Fargate; use it when you need upstream Kubernetes compatibility with AWS integrations. Key considerations include who manages node patching and OS lifecycle, VPC and networking design for pod traffic, and integration with IAM, Amazon ECR, and monitoring services.

🏷 Keywords

Kubernetes control plane • worker nodes • managed node groups • AWS Fargate • Amazon ECR • IAM Roles for Service Accounts • VPC CNI • pod networking • persistent volumes • cluster autoscaling • kubeconfig • node lifecycle