Amazon EKS: Kubernetes Architecture, Scaling, and Hybrid Deployment – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon Elastic Kubernetes Service (Amazon EKS) is AWS’s managed Kubernetes service. It is designed for teams that need Kubernetes for deploying, scaling, and managing containerized applications while reducing the operational effort required to run the Kubernetes control plane.

EKS can support workloads in AWS, on premises, and on customer-managed infrastructure through options such as EKS Distro and EKS Anywhere. The core exam theme is choosing EKS when Kubernetes compatibility and portability are more important than using an AWS-native container orchestrator such as Amazon ECS.

Key Concepts

What Amazon EKS Provides

Kubernetes is an open-source platform for container orchestration. It organizes containers into pods, which are the smallest deployable units in Kubernetes. A pod can contain one or more closely related containers that share networking and storage context.

An EKS environment includes:

A managed Kubernetes control plane operated by AWS.
Worker capacity running on Amazon EC2, AWS Fargate, or AWS Outposts, depending on the deployment model.
Kubernetes applications distributed across Availability Zones for high availability.
Integration with AWS load-balancing services.
Kubernetes APIs and ecosystem tooling for deployments, jobs, scaling, and operations.

EKS is particularly useful when an organization needs a consistent Kubernetes platform across multiple environments or wants to use Kubernetes-native tooling and APIs.

EKS Deployment Environments

EKS supports several infrastructure patterns:

AWS Regions: Run Kubernetes workloads using EC2 worker nodes or AWS Fargate.
AWS Outposts: Extend AWS infrastructure into an on-premises location for supported workloads.
EKS Distro: Use the same core Kubernetes dependencies as EKS to create and operate Kubernetes clusters independently.
EKS Anywhere: Run EKS on customer-managed infrastructure, including bare-metal servers and VMware vSphere environments, with AWS support options.

The EKS control plane is managed by AWS in the standard AWS deployment model. Worker capacity and Kubernetes workload configuration remain part of the customer’s design and operational responsibilities.

Workload Autoscaling

Kubernetes provides multiple layers of scaling. These mechanisms solve different problems and should not be treated as interchangeable.

#### Vertical Pod Autoscaler

The Vertical Pod Autoscaler (VPA) adjusts the CPU and memory requests or reservations assigned to pods. This helps right-size workloads whose resource requirements vary over time.

VPA changes the resource allocation of existing workloads rather than increasing the number of replicas. It is therefore a workload-sizing mechanism, not a replacement for horizontal scaling.

#### Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) changes the number of pod replicas in a deployment, replica set, or similar Kubernetes workload. It commonly scales based on CPU utilization, although Kubernetes configurations can use other metrics.

HPA is appropriate when an application can handle increased demand by running more pod instances.

#### Cluster Autoscaler

The Kubernetes Cluster Autoscaler adds or removes worker nodes when existing capacity cannot schedule pods or when nodes become underutilized. In AWS, it commonly works with EC2 Auto Scaling groups.

Cluster autoscaling operates at the infrastructure-capacity layer. It does not directly change the number of application pods.

#### Karpenter

Karpenter is an open-source node provisioning and autoscaling project that can provision EC2 capacity directly based on pending pod requirements. Unlike the traditional Cluster Autoscaler model, Karpenter does not need to depend exclusively on predefined Auto Scaling groups.

The distinction is important:

HPA changes the number of pods.
VPA changes pod resource sizing.
Cluster Autoscaler changes node-group capacity.
Karpenter provisions suitable EC2 capacity for unscheduled pods.

Load Balancing with EKS

EKS integrates with AWS load balancers through the AWS Load Balancer Controller. The controller can be installed using Helm or Kubernetes manifests and translates Kubernetes resources into AWS load-balancing resources.

Typical mappings include:

A Kubernetes Ingress can result in an Application Load Balancer (ALB).
A Kubernetes Service with type LoadBalancer can result in a Network Load Balancer (NLB).
Classic Load Balancers may also be encountered in older or legacy Kubernetes integrations.

The load balancer controller supports routing traffic to Kubernetes workloads using instance targets or, where configured and supported, IP targets. IP targeting can route directly to pod IP addresses rather than requiring traffic to pass through node-level targets.

EKS Distro

EKS Distro is a distribution of Kubernetes that uses the same core Kubernetes dependencies as Amazon EKS. It includes tested versions of components such as:

Kubernetes binaries and containers.
etcd.
Networking plugins.
Storage plugins.

EKS Distro is useful for organizations that need to run Kubernetes outside the standard managed EKS control plane while maintaining consistency with EKS-tested dependencies. Releases are available through open-source channels and AWS distribution mechanisms such as Amazon S3 and Amazon ECR.

The main operational value is version consistency. Teams do not need to independently track every Kubernetes dependency and determine whether the components are compatible.

EKS Anywhere

Amazon EKS Anywhere allows customers to run Kubernetes clusters on infrastructure they manage themselves. Supported deployment environments described in this lesson include:

Bare-metal servers.
VMware vSphere.
Other customer-managed infrastructure patterns supported by the product.

EKS Anywhere is distinct from standard EKS in AWS. With standard EKS, AWS manages the Kubernetes control plane as an AWS service. With EKS Anywhere, the customer operates the underlying infrastructure and cluster environment, while AWS provides the EKS Anywhere distribution and support model.

Batch and Machine Learning Workloads

Kubernetes Jobs can run sequential or parallel batch workloads. EKS can also support machine learning workflows, including distributed training and GPU-enabled workloads. Tools such as Kubeflow can be used to coordinate machine learning pipelines and training jobs on Kubernetes.

These use cases are examples of why an organization might choose Kubernetes for a broader platform rather than only for stateless web containers.

Exam-Relevant Takeaways

Amazon EKS is managed Kubernetes, not a separate AWS-native orchestration API.
Use EKS when Kubernetes compatibility, portability, or a common platform across environments is a primary requirement.
EKS worker capacity can use EC2, Fargate, or supported Outposts deployments.
Kubernetes workloads are packaged into pods.
VPA adjusts pod resource sizing; HPA adjusts pod replica count.
Cluster Autoscaler generally works with EC2 Auto Scaling groups, while Karpenter provisions EC2 capacity more directly based on pending workload requirements.
The AWS Load Balancer Controller maps Kubernetes Ingress resources to ALBs and Service objects of type LoadBalancer to NLBs.
EKS Distro provides EKS-aligned Kubernetes components for clusters operated outside standard managed EKS.
EKS Anywhere supports EKS-based Kubernetes on customer-managed infrastructure such as bare metal and VMware vSphere.
EKS can span multiple Availability Zones to improve application availability, but the application and worker-node architecture must still be designed for failure.

Architecture Decision Guide

Requirement	Appropriate EKS capability or design
Run Kubernetes without operating the control plane in AWS	Standard Amazon EKS
Run pods with serverless compute where supported	EKS with AWS Fargate
Use dedicated, configurable worker capacity	EKS with EC2 worker nodes
Increase application capacity by adding replicas	Kubernetes Horizontal Pod Autoscaler
Right-size CPU and memory allocations for pods	Kubernetes Vertical Pod Autoscaler
Add or remove nodes managed through Auto Scaling groups	Kubernetes Cluster Autoscaler
Provision EC2 capacity based directly on pending pods	Karpenter
Expose HTTP/HTTPS applications with Layer 7 routing	AWS Load Balancer Controller with an ALB-backed Ingress
Expose services using Layer 4 networking	AWS Load Balancer Controller with an NLB-backed Service
Maintain Kubernetes consistency across AWS and external environments	EKS Distro
Run an EKS-based cluster on customer-owned infrastructure	EKS Anywhere
Run parallel or sequential Kubernetes batch jobs	Kubernetes Jobs API on EKS

Common Exam Traps

Confusing EKS with ECS: EKS is Kubernetes-based. ECS uses AWS’s own container orchestration model. A requirement for Kubernetes APIs, Kubernetes portability, or existing Kubernetes expertise strongly favors EKS.
Treating HPA as node autoscaling: HPA adds or removes pods. It does not automatically provide more EC2 worker capacity unless a node autoscaler also responds to pending pods.
Treating VPA as replica scaling: VPA changes pod resource requests. It does not increase the replica count like HPA.
Assuming standard EKS means AWS manages everything: AWS manages the EKS control plane, but customers still design and manage workloads, permissions, networking, worker capacity, and application resilience.
Confusing EKS Distro and EKS Anywhere: EKS Distro is the Kubernetes distribution and its tested dependencies. EKS Anywhere is a supported way to run EKS-based clusters on customer-managed infrastructure.
Using the wrong load balancer mapping: Kubernetes Ingress is commonly associated with an ALB through the AWS Load Balancer Controller, while a LoadBalancer Service commonly provisions an NLB.
Ignoring Availability Zone placement: A multi-AZ control plane or cluster does not automatically make a workload resilient. Pods, worker nodes, and load-balancing paths must be distributed appropriately.
Assuming Karpenter is simply another Auto Scaling group: Karpenter provisions EC2 capacity directly according to pod requirements, while Cluster Autoscaler commonly adjusts node groups backed by Auto Scaling groups.

Real-World Engineer Notes

Select the scaling layer deliberately. A sudden increase in traffic may require HPA to add pods and Cluster Autoscaler or Karpenter to add worker capacity.
Define realistic CPU and memory requests. Kubernetes scheduling and many autoscaling decisions depend on resource requests, not only actual utilization.
Spread replicas and worker nodes across Availability Zones where the application requires high availability.
Use the AWS Load Balancer Controller when Kubernetes resources should drive AWS load-balancer provisioning and lifecycle management.
Standardize Kubernetes versions and dependencies across teams when operating clusters in multiple locations. EKS Distro can reduce compatibility-management effort.
For on-premises Kubernetes, distinguish the desired operational model: standard EKS in AWS, EKS on Outposts, or customer-managed EKS Anywhere infrastructure.
GPU-based machine learning workloads require suitable worker infrastructure and scheduling configuration; Kubernetes orchestration alone does not provide GPU capacity.

Quick Reference Summary

EKS: Managed Kubernetes service in AWS.
Pod: Kubernetes unit containing one or more containers.
EC2: Configurable worker-node capacity.
Fargate: Serverless compute option for supported EKS pods.
VPA: Adjusts pod CPU and memory sizing.
HPA: Adjusts the number of pod replicas.
Cluster Autoscaler: Adjusts node-group capacity, commonly through Auto Scaling groups.
Karpenter: Directly provisions suitable EC2 capacity for pending pods.
ALB: Commonly created from Kubernetes Ingress by the AWS Load Balancer Controller.
NLB: Commonly created from a Kubernetes LoadBalancer Service.
EKS Distro: EKS-aligned Kubernetes distribution for independently operated clusters.
EKS Anywhere: Runs EKS on customer-managed infrastructure.

Flashcards

1. What is Amazon EKS?

Amazon EKS is AWS’s managed Kubernetes service for deploying, scaling, and operating containerized applications using Kubernetes APIs and tooling.

2. What is the smallest deployable Kubernetes unit?

A pod. A pod contains one or more containers that share networking and storage context.

3. What does the Horizontal Pod Autoscaler change?

It changes the number of pod replicas based on metrics such as CPU utilization.

4. What does the Vertical Pod Autoscaler change?

It adjusts CPU and memory requests or reservations for pods.

5. What does the Kubernetes Cluster Autoscaler manage?

It adds or removes worker nodes, commonly by modifying capacity in EC2 Auto Scaling groups.

6. How does Karpenter differ from Cluster Autoscaler?

Karpenter provisions EC2 capacity directly based on pending pod requirements instead of relying exclusively on predefined Auto Scaling groups.

7. Which controller integrates Kubernetes resources with AWS load balancers?

The AWS Load Balancer Controller.

8. What AWS load balancer is commonly created from a Kubernetes Ingress?

An Application Load Balancer.

9. What AWS load balancer is commonly created for a Kubernetes Service of type `LoadBalancer`?

A Network Load Balancer.

10. What is EKS Distro used for?

It provides EKS-aligned Kubernetes components and dependencies for operating compatible Kubernetes clusters outside the standard managed EKS control plane.

11. What is EKS Anywhere?

A way to run EKS-based Kubernetes clusters on customer-managed infrastructure, including bare-metal servers and VMware vSphere.

12. Why might an organization choose EKS over ECS?

Because it requires Kubernetes compatibility, Kubernetes-native tooling, portability across environments, or an existing Kubernetes operating model.

Practice Questions

Question 1

A company has an existing Kubernetes platform and wants to move its workloads to AWS while preserving Kubernetes manifests, APIs, and operational tooling. Which service is the best fit?

A. Amazon ECS
B. Amazon EKS
C. AWS Batch only
D. AWS Lambda

Correct answer: B. Amazon EKS

Explanation: EKS provides managed Kubernetes in AWS, allowing the company to continue using Kubernetes APIs and ecosystem tooling. ECS is an AWS-native container orchestrator with a different control model.

Question 2

An EKS application must automatically increase the number of running application instances when average CPU utilization rises. Which Kubernetes feature should be used?

A. Vertical Pod Autoscaler
B. Horizontal Pod Autoscaler
C. Cluster Autoscaler
D. EKS Distro

Correct answer: B. Horizontal Pod Autoscaler

Explanation: HPA changes the number of pod replicas. VPA changes pod resource sizing, and Cluster Autoscaler changes worker-node capacity.

Question 3

Pods cannot be scheduled because the existing EC2 worker nodes lack sufficient capacity. The organization wants EC2 instances to be provisioned based on the requirements of pending pods rather than only adjusting predefined Auto Scaling groups. Which option best fits?

A. Karpenter
B. Vertical Pod Autoscaler
C. ALB Ingress
D. Kubernetes Jobs API

Correct answer: A. Karpenter

Explanation: Karpenter provisions EC2 capacity directly according to pending pod requirements. The Cluster Autoscaler generally adjusts node groups backed by Auto Scaling groups.

Question 4

A team wants Kubernetes Ingress resources to provision and manage an AWS Layer 7 load balancer for HTTP routing. Which combination should it use?

A. AWS Load Balancer Controller and an ALB
B. Karpenter and an NLB
C. Cluster Autoscaler and a Classic Load Balancer
D. EKS Distro and an NLB

Correct answer: A. AWS Load Balancer Controller and an ALB

Explanation: The AWS Load Balancer Controller commonly provisions an Application Load Balancer from a Kubernetes Ingress resource and supports Layer 7 routing.

Question 5

An organization needs to operate EKS-based Kubernetes clusters on its own bare-metal servers and VMware vSphere environments. Which capability is most directly aligned with this requirement?

A. Standard EKS with Fargate
B. EKS Anywhere
C. Kubernetes Horizontal Pod Autoscaler
D. AWS Batch

Correct answer: B. EKS Anywhere

Explanation: EKS Anywhere is designed for running EKS-based clusters on customer-managed infrastructure, including bare metal and VMware vSphere. Standard EKS is the managed AWS service model.

Amazon EKS: Kubernetes Architecture, Scaling, and Hybrid Deployment – SAP-C02 Study Guide