What's in this module
TOPIC 1 What is Amazon EKS
Amazon EKS is a managed Kubernetes service. AWS runs the control plane for you — you supply the worker nodes (EC2 or Fargate). The control plane is built on Amazon EKS Distro, the same Kubernetes distribution AWS uses for its own internal workloads, and is patched, scaled, and kept highly available automatically.
Animation · EKS: what each component does
What is Amazon EKS in one sentence?
Amazon EKS is a managed Kubernetes service that creates and operates the Kubernetes control plane on your behalf, so you only manage your own worker nodes (data plane).
What is Amazon EKS Distro?
EKS Distro is the Kubernetes distribution that powers EKS clusters. It is open-source, security-patched, and the same distribution AWS runs internally. You can also run it on-premises.
What are the four pillars of the EKS component set?
1. Amazon EKS — creates K8s clusters (EKS Distro)
2. AWS Fargate — serverless container nodes
3. Amazon EC2 — traditional nodes for your cluster
4. EKS Dashboard (console) — view and explore running K8s apps
2. AWS Fargate — serverless container nodes
3. Amazon EC2 — traditional nodes for your cluster
4. EKS Dashboard (console) — view and explore running K8s apps
What does "managed" actually mean in "managed Kubernetes"?
AWS handles control plane provisioning, scaling, patching, and high availability. You do not SSH into control plane nodes, you do not run etcd backups, you do not manage API server certificates. You just create the cluster; AWS does the rest for the control plane.
TOPIC 2 EKS control plane
The control plane lives in an AWS-managed account, completely separate from your AWS account. It spans multiple Availability Zones and is monitored and automatically repaired. You get the API endpoint; AWS handles everything behind it — etcd, API server, scheduler, controller manager.
Animation · Inside the EKS control plane
AWS manages (control plane)
- kube-apiserver
- etcd (cluster state store)
- kube-scheduler
- kube-controller-manager
- Multi-AZ high availability
- Auto-repair of unhealthy nodes
- Certificate rotation
You manage (data plane)
- Worker nodes (EC2 or Fargate)
- kubelet on each node
- kube-proxy on each node
- Container runtime
- Node OS patching (self-managed)
- Application workloads
Where does the EKS control plane run?
In an AWS-managed AWS account — completely separate from your account. The control-plane EC2 instances are invisible to you. You access the cluster only via the API server endpoint that EKS exposes.
How does EKS maintain high availability for the control plane?
EKS distributes control plane nodes across multiple Availability Zones. It continuously monitors health and automatically replaces unhealthy nodes. Etcd is also replicated across AZs. You never need to perform manual failover.
Who manages etcd availability in an EKS cluster?
Amazon EKS manages etcd completely. You have no SSH access to etcd nodes and no responsibility for backups or replication. This is one of the key managed benefits — losing an etcd node does not require operator intervention.
What is the ENI injection and why does it matter?
EKS injects an Elastic Network Interface (ENI) into your VPC so the control plane can communicate with worker nodes. This means control plane → node traffic never leaves AWS's private backbone, and you control the VPC security groups around it.
What does the EKS pricing model look like?
You pay a per-cluster hourly fee for the managed control plane (~$0.10/hr). Worker nodes are billed separately as standard EC2 or Fargate compute. There is no extra charge for multi-AZ control plane redundancy — that's included.
TOPIC 3 EKS data plane options
EKS always manages the control plane. For the data plane (worker nodes), you choose one of three models: self-managed nodes, managed node groups, or AWS Fargate. Each trades operational control for automation at a different point.
OPTION 1
Self-managed nodes
You launch EC2 instances, register them, patch them, and replace them — full control, full responsibility.
OPTION 2
Managed node groups
EKS provisions, manages, updates, and scales nodes using Auto Scaling Groups. You still choose instance types.
OPTION 3
AWS Fargate
No nodes to manage at all. Each Pod gets its own micro-VM. Fully serverless.
What is the key difference between self-managed nodes and managed node groups?
Self-managed: you launch, register, patch, and replace EC2 instances manually (or via your own automation). Managed node groups: EKS handles provisioning, joining nodes to the cluster, OS patching, rolling upgrades, and scaling — all via the EKS API or console.
Which data plane option gives you zero node management?
AWS Fargate. You never see or manage worker nodes. AWS provisions an isolated micro-VM for each Pod automatically. You only define Fargate profiles to tell EKS which Pods should run on Fargate.
TOPIC 4 Managed node groups
Managed node groups let EKS handle the heavy lifting of node lifecycle while still giving you control over instance types, sizes, and scaling policies. Under the hood, EKS uses an Auto Scaling Group and performs rolling updates that respect Pod Disruption Budgets.
Animation · Managed node group rolling update
What does a managed node group help you with?
5 things MNG manages for you:
1. Provisioning — launches EC2 in an ASG
2. Managing — joins nodes to the cluster
3. Updating — rolling AMI/K8s version upgrades
4. Scaling — min/max/desired count controls
5. eksctl support — first-class CLI integration
1. Provisioning — launches EC2 in an ASG
2. Managing — joins nodes to the cluster
3. Updating — rolling AMI/K8s version upgrades
4. Scaling — min/max/desired count controls
5. eksctl support — first-class CLI integration
How does EKS update a managed node group without downtime?
EKS performs a rolling update: it adds new nodes (new AMI/version), then cordons and drains old nodes one at a time (respecting PodDisruptionBudgets), then terminates the old nodes. Workloads are always available during the upgrade.
What CloudWatch event tells you a managed node group ran out of EC2 capacity?
The event reason
InstanceLimitExceeded. EKS surfaces node group health events in the EKS console and via the DescribeNodegroup API. You should also set CloudWatch alarms on the underlying Auto Scaling Group metrics.What tool provides first-class CLI support for managed node groups?
eksctl — the official CLI for EKS. With a single YAML config file, eksctl create cluster provisions the cluster and managed node group. You can also eksctl upgrade nodegroup to trigger a managed rolling update.TOPIC 5 AWS Fargate & Fargate profiles
With Fargate, there are no nodes to provision or manage. Each Pod gets its own isolated micro-VM, sized exactly to its CPU and memory request. You define Fargate profiles (namespace + labels) to tell EKS which Pods should run on Fargate vs. EC2.
Animation · How Fargate profiles route Pods
What are the five Fargate properties the course lists?
Native — first-class EKS integration
Rightsized — compute matches Pod CPU/memory request
Fast and simple — no node bootstrapping
Transparent — Pods look like K8s Pods; no special code
Optimized — no over-provisioning; pay only for what Pod requests
Rightsized — compute matches Pod CPU/memory request
Fast and simple — no node bootstrapping
Transparent — Pods look like K8s Pods; no special code
Optimized — no over-provisioning; pay only for what Pod requests
What is a Fargate profile and what fields does it contain?
A Fargate profile tells EKS which Pods to schedule on Fargate.
Fields:
•
•
•
•
•
Fields:
•
fargateProfileName•
clusterName•
podExecutionRoleArn — IAM role used by the Fargate runtime•
subnets — private subnets only•
selectors → namespace + optional labels
What subnet type is required for Fargate profiles?
Private subnets only. Fargate Pods cannot run in public subnets — this is a hard requirement. This is also one reason you would choose EC2 node groups instead of Fargate if you need Pods in public subnets.
How does Fargate decide whether to schedule a Pod?
When a Pod is created, EKS checks it against all Fargate profiles in the cluster. If the Pod's namespace and any specified labels match a profile's selector, it is scheduled on Fargate. If no profile matches, EKS schedules it on an EC2 node (if any exist).
What IAM role does a Fargate profile need and why?
The Pod Execution Role — an IAM role that the Fargate infrastructure uses to pull images from ECR and write logs to CloudWatch. It is attached to the profile, not the Pod itself. Without it, the Fargate micro-VM cannot authenticate to AWS services.
TOPIC 6 Fargate vs node groups — decision guide
Neither option is universally better. The course gives you eight concrete signals — four pointing to Fargate, four pointing to node groups. Know these for the exam and for real architecture decisions.
| Use AWS Fargate when… | Use node groups when… |
|---|---|
| You want to reduce scheduling complexity (no affinity/taints to tune) | You need privileged Pods (Fargate does not allow privileged containers) |
| You need compliance / security isolation — 1 Pod per micro-VM | You must deploy nodes in public subnets |
| You want to reduce variable cost (no idle node capacity) | You need fine-grained control over workload disruption during upgrades |
| You want to eliminate infrastructure management | You need faster Pod start times (EC2 nodes are pre-warmed) |
Can Fargate run privileged containers?
No. Fargate does not support privileged containers. If your Pod needs
privileged: true in its security context (e.g., for DaemonSets like FluentD or host-network Pods), you must use EC2 node groups.Why does Fargate improve security compliance?
Each Fargate Pod runs in its own isolated micro-VM (1:1 Pod-to-VM ratio). Pods cannot share the kernel or process namespace with other workloads. This eliminates container-escape concerns that exist when many Pods share an EC2 node.
Why do node groups offer faster Pod start times than Fargate?
On EC2 node groups, nodes are already running — a new Pod just needs to be scheduled and the container image pulled. On Fargate, EKS must provision a new micro-VM for each Pod, which adds cold-start latency (typically 30–60 seconds).
TOPIC 7 Two APIs: Kubernetes API vs Amazon EKS API
EKS exposes two distinct APIs for two distinct jobs. The Kubernetes API manages resources inside a cluster. The Amazon EKS API manages the infrastructure of a cluster. Confusing them is the most common EKS operations mistake.
Animation · kubectl vs eksctl — two different APIs
Kubernetes API
- Pods, Deployments, Services
- Namespaces
- Labels and annotations
- ConfigMaps & Secrets
- Custom Resources (CRDs)
- Tool:
kubectl
Amazon EKS API
- Clusters (create / delete / upgrade)
- Managed node groups
- Fargate profiles
- Add-ons (CoreDNS, VPC CNI, kube-proxy)
- Identity provider config (OIDC)
- Resource tagging
- Tools:
eksctl, AWS Console, AWS CLI
You want to deploy a new version of your app. Which API?
Kubernetes API via
kubectl. You update the Deployment resource inside the cluster. The EKS API is not involved in workload changes — it only manages the cluster infrastructure.You want to add a new node group to your cluster. Which API?
Amazon EKS API via
eksctl create nodegroup or the AWS Console. Node groups are EKS infrastructure constructs, not Kubernetes objects. You'd never create a node group with kubectl.What are EKS "add-ons" and which API manages them?
Add-ons are managed operational components: CoreDNS, kube-proxy, Amazon VPC CNI, and EBS CSI driver. The EKS API manages their installation and version upgrades — you no longer need to maintain them manually with
kubectl apply.What does the EKS API use to authenticate users to the K8s API?
EKS uses IAM for authentication (who you are) and maps IAM identities to Kubernetes RBAC roles for authorization (what you can do). The
aws-auth ConfigMap (or newer access entries) defines those mappings. The Identity Provider Config (OIDC) enables workload identity federation.TOPIC 8 Permissions & access review
The course activity maps four actions to the configuration that enables them. Knowing which mechanism controls which action is essential for both the exam and for debugging "I can't connect to my cluster" problems.
| Action | Mechanism | Notes |
|---|---|---|
| Enforce how applications run in a cluster | Admission Controller | Intercepts API requests; can mutate or reject objects (e.g. PodSecurityAdmission) |
| Add annotations automatically to API objects | MutatingAdmissionWebhook | A special admission controller that calls an external webhook to mutate objects on creation |
| Connect to the Kubernetes API server | kubeconfig file | Contains cluster endpoint, CA cert, and credentials. aws eks update-kubeconfig creates this. |
| Add a node to the cluster | IAM role + kubeconfig | Node needs an IAM role (for AWS API calls) AND a kubeconfig or bootstrap token to join the K8s cluster |
What is an Admission Controller?
A plugin in the Kubernetes API server that intercepts requests after authentication/authorization but before the object is persisted. It can validate (allow/deny) or mutate (modify) the object. Example: enforcing that all Pods set resource limits.
What makes a MutatingAdmissionWebhook different from a regular admission controller?
A MutatingAdmissionWebhook calls an external HTTP endpoint (your webhook server) to modify objects at admission time. This allows injecting sidecars, adding annotations, or patching fields without modifying the original manifests — used by Istio, Linkerd, and tools like
kyverno.How do you generate the kubeconfig for a new EKS cluster?
aws eks update-kubeconfig --region <region> --name <cluster-name>This writes a kubeconfig entry with the cluster endpoint and CA data, using your current AWS IAM credentials to authenticate via the
aws eks get-token exec credential plugin.Why does adding a node to an EKS cluster require both an IAM role AND kubeconfig?
The IAM role allows the node (kubelet) to make AWS API calls — pull images from ECR, write logs to CloudWatch, describe itself. The kubeconfig / bootstrap token allows the kubelet to authenticate to the Kubernetes API server and register as a node object.
TOPIC 9 Knowledge checks (from the course)
These are the official course knowledge-check questions, formatted as flashcards. Try to answer before flipping.
KC 1 — Which component is always managed by Amazon EKS?
A. Control plane B. Data plane C. Container D. Service
A. Control plane B. Data plane C. Container D. Service
✓ A — Kubernetes control plane
EKS always manages the control plane. The data plane (B) is your responsibility (managed node groups, self-managed, or Fargate). Containers (C) and Services (D) are K8s objects you manage.
EKS always manages the control plane. The data plane (B) is your responsibility (managed node groups, self-managed, or Fargate). Containers (C) and Services (D) are K8s objects you manage.
KC 2 — Who is responsible for managing the availability of etcd when using EKS?
A. Amazon EKS B. Kubernetes C. You
A. Amazon EKS B. Kubernetes C. You
✓ A — Amazon EKS
etcd is part of the control plane, which EKS fully manages. It runs replicated across AZs and is automatically repaired. You have no etcd access and no etcd backup responsibility.
etcd is part of the control plane, which EKS fully manages. It runs replicated across AZs and is automatically repaired. You have no etcd access and no etcd backup responsibility.
Which EKS data plane option requires private subnets only?
AWS Fargate. Fargate Pods must run in private subnets — no public subnet support. EC2 managed node groups can run in either public or private subnets.
You need to create a Fargate profile. Which field in the profile JSON specifies the IAM permissions for the Fargate runtime?
podExecutionRoleArn — this IAM role is used by the Fargate infrastructure (not your application code) to pull images from ECR, push logs to CloudWatch, and interact with the VPC.Which tool do you use to manage Kubernetes objects (Pods, Deployments) inside an EKS cluster?
kubectl — it talks to the Kubernetes API. eksctl and the AWS CLI talk to the Amazon EKS API for infrastructure management (clusters, node groups, Fargate profiles, add-ons).