Amazon EKS: Managed Kubernetes, Scaling, Load Balancing, and Anywhere Deployments

Purpose of This Lesson

Amazon Elastic Kubernetes Service (EKS) is AWS’s managed implementation of Kubernetes. This lesson focuses on when to select EKS, how its control plane and worker capacity are organized, how Kubernetes workloads and clusters scale, how AWS load balancers are provisioned, and how EKS can be used across AWS, on-premises environments, and other customer-managed infrastructure.

For SOA-C03 preparation, the important skill is recognizing the requirement and selecting the appropriate EKS feature, scaling mechanism, or deployment model.

Key Concepts

• Kubernetes: An open-source system for automating deployment, scaling, and management of containerized applications.
• Amazon EKS: A managed Kubernetes implementation that can run in AWS and support on-premises and customer-managed deployment models through related offerings.
• Cluster: Includes an EKS-managed control plane and worker capacity. Worker capacity can run on Amazon EC2, AWS Fargate, or AWS Outposts.
• Pod: A group of containers managed as a unit by Kubernetes.
• Multi-AZ operation: An EKS cluster can span multiple Availability Zones to support highly available applications.
• Workload autoscaling: Changes pod resource reservations or the number of running pods.
• Cluster autoscaling: Adds or removes the underlying compute capacity needed by pods.
• AWS Load Balancer Controller: Connects Kubernetes resources to AWS Elastic Load Balancing resources.
• EKS Distro: A distribution of Kubernetes and its dependencies that is tested for compatibility with Amazon EKS and can be run manually in different environments.
• ECS Anywhere and EKS Anywhere: AWS-supported options for running ECS or EKS on customer-managed infrastructure, including bare metal and VMware vSphere.

EKS Architecture and Deployment Context

EKS provides a managed Kubernetes control plane while applications run on worker capacity. The worker environment may use:

• Amazon EC2 instances
• AWS Fargate
• AWS Outposts

A cluster can span multiple Availability Zones. This supports highly available application designs and is particularly relevant for web applications that must continue operating if an individual Availability Zone becomes unavailable.

EKS is useful when an organization wants standardized Kubernetes-based container orchestration across environments. The broader EKS ecosystem supports hybrid deployments, allowing teams to manage Kubernetes clusters and applications across AWS and on-premises environments.

Typical workload categories mentioned in this lesson include:

• Web applications: Applications that may need highly available, elastic capacity across multiple Availability Zones.
• Batch processing: Sequential or parallel workloads using the Kubernetes Jobs API.
• Machine learning: Kubeflow can be used to model machine-learning workflows and run distributed training jobs on GPU-powered instances.

EKS also integrates with AWS load-balancing services, including Application Load Balancer (ALB), Network Load Balancer (NLB), and the older Classic Load Balancer (CLB).

Scaling in EKS

EKS scaling occurs at different layers. Selecting the wrong layer can leave an application under-provisioned or cause unnecessary infrastructure changes.

Vertical Pod Autoscaler

The Vertical Pod Autoscaler (VPA) adjusts the CPU and memory reservations of pods. Its purpose is to right-size individual workloads rather than primarily changing the number of pod replicas.

Use VPA when the main issue is that individual pods need different CPU or memory reservations.

Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) changes the number of pods in a deployment, replication controller, or replica set based on resource utilization such as CPU utilization.

Use HPA when the application needs more or fewer pod replicas to respond to changing demand.

Cluster Autoscaling

Cluster autoscaling changes the underlying compute capacity available to the cluster. The lesson identifies two options:

• Kubernetes Cluster Autoscaler: Uses AWS Auto Scaling groups to add or remove worker capacity.
• Karpenter: An open-source autoscaling project that works directly with the Amazon EC2 fleet.

The distinction is important: HPA and VPA operate at the workload or pod level, while Cluster Autoscaler and Karpenter address the infrastructure capacity required to schedule those pods.

Load Balancing with EKS

The AWS Load Balancer Controller manages Elastic Load Balancing resources for a Kubernetes cluster. It can be installed with Helm v3 or by applying a Kubernetes manifest.

The Kubernetes resource determines the AWS load balancer type:

Kubernetes resource	AWS resource provisioned
Kubernetes Ingress	Application Load Balancer
Kubernetes Service with type LoadBalancer	Network Load Balancer

EKS supports ALB, NLB, and CLB, but the controller-based integration described in this lesson focuses on provisioning ALBs and NLBs from Kubernetes resources.

Historically, Kubernetes NLB behavior used instance targets, while the load balancer controller supported IP targets. The lecture also notes that newer controller versions support creating NLBs with an IP target type. When evaluating a design, verify the controller version and target-mode requirements rather than assuming older behavior still applies.

EKS Distro and Hybrid Kubernetes Operations

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

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

EKS Distro releases are available as open source through GitHub and through AWS via Amazon S3 and Amazon ECR. Its purpose is to reduce the operational burden of tracking updates, determining component compatibility, and standardizing Kubernetes versions across distributed teams.

Teams can create EKS Distro clusters in AWS on EC2 or on their own on-premises hardware using the tooling of their choice. EKS Distro therefore supports a consistent Kubernetes foundation without requiring every cluster to be an Amazon-managed EKS cluster.

ECS Anywhere and EKS Anywhere

ECS Anywhere and EKS Anywhere allow customers to run Amazon ECS or Amazon EKS on customer-managed infrastructure with AWS support.

Supported infrastructure examples from the lesson include:

• On-premises bare-metal servers
• VMware vSphere environments

Choose EKS Anywhere when the workload requires Kubernetes on customer-managed infrastructure. Choose ECS Anywhere when the workload uses Amazon ECS rather than Kubernetes. These offerings address where the container platform runs; they do not change the distinction between Kubernetes workload scaling and cluster capacity scaling.

Exam- or Assessment-Relevant Takeaways

• EKS is the managed Kubernetes service; Kubernetes itself is the open-source orchestration platform.
• For a requirement involving Kubernetes across AWS and on-premises environments, consider EKS hybrid capabilities, EKS Distro, or EKS Anywhere based on how much of the environment is customer-managed.
• VPA changes CPU and memory reservations for pods.
• HPA changes the number of pod replicas based on utilization.
• Cluster Autoscaler uses AWS Auto Scaling groups, while Karpenter works directly with the Amazon EC2 fleet.
• An EKS Ingress causes the AWS Load Balancer Controller to provision an ALB.
• A Kubernetes Service with type LoadBalancer causes the controller to provision an NLB.
• EKS can use EC2, Fargate, and Outposts for worker capacity.
• EKS Distro is useful for maintaining compatible Kubernetes components and versions across distributed environments.
• EKS Anywhere runs EKS on customer-managed infrastructure such as bare metal or VMware vSphere.

Tool / Feature Decision Guide

Requirement	Appropriate choice	Decisive reason
Right-size CPU and memory assigned to existing pods	VPA	Adjusts pod resource reservations.
Increase or decrease the number of application pods	HPA	Scales pod replicas based on utilization.
Add or remove worker capacity managed through AWS Auto Scaling groups	Kubernetes Cluster Autoscaler	Uses AWS scaling groups.
Provision EC2 capacity directly for pending Kubernetes workloads	Karpenter	Works directly with the EC2 fleet.
Expose Kubernetes Ingress through an AWS HTTP/HTTPS load balancer	AWS Load Balancer Controller with Ingress	Provisions an ALB.
Expose a Kubernetes service through an AWS network load balancer	AWS Load Balancer Controller with Service type LoadBalancer	Provisions an NLB.
Run compatible Kubernetes components outside standard managed EKS	EKS Distro	Provides tested Kubernetes binaries, containers, and dependencies.
Run Kubernetes on customer-managed bare metal or VMware vSphere	EKS Anywhere	Provides AWS-supported EKS on customer infrastructure.
Run ECS on customer-managed infrastructure	ECS Anywhere	Extends ECS to customer-managed environments.

Common Traps / Misconceptions

• Confusing HPA with cluster autoscaling: HPA adds or removes pods; it does not directly add EC2 worker capacity.
• Confusing VPA with HPA: VPA changes pod CPU and memory reservations, while HPA changes the number of replicas.
• Assuming all EKS scaling uses Auto Scaling groups: Cluster Autoscaler uses AWS Auto Scaling groups, but Karpenter works directly with the EC2 fleet.
• Mapping every Kubernetes service to an ALB: In the described controller behavior, Ingress provisions an ALB, while a Service of type LoadBalancer provisions an NLB.
• Treating EKS Distro as identical to the managed EKS control plane: EKS Distro supplies compatible Kubernetes components for manually operated clusters; it is not simply another name for the AWS-managed control plane.
• Assuming hybrid support means all infrastructure is AWS-managed: EKS Anywhere and EKS Distro address customer-managed or on-premises environments, where the operational responsibility differs from managed EKS.
• Ignoring version and target-mode details for NLBs: Older and newer AWS Load Balancer Controller behavior may differ, especially around IP targets. Check the relevant controller version and configuration.
• Equating Fargate with a complete replacement for cluster design: Fargate is a worker-capacity option; workload scaling, networking, availability, and load-balancer choices still need to be addressed.

Real-World Engineer / Analyst Notes

• Start troubleshooting autoscaling by identifying the layer where the shortage occurs: pod resources, pod count, or worker capacity.
• When a pod cannot be scheduled, increasing HPA replicas may make the capacity problem worse unless cluster capacity can also expand.
• For hybrid operations, define which team owns cluster upgrades, networking, storage plugins, and compatibility testing. EKS Distro reduces version-tracking effort but does not eliminate operational ownership.
• Multi-AZ placement improves resilience, but applications and their supporting dependencies must also be designed to use the available zones effectively.
• Treat the Kubernetes resource type as a key design input when selecting ALB versus NLB behavior.
• Before relying on a particular NLB target mode, verify the AWS Load Balancer Controller version and configuration used by the cluster.
• For batch workloads, the Kubernetes Jobs API is the relevant mechanism identified in this lesson; for distributed machine-learning workflows, Kubeflow and GPU-powered instances are the highlighted options.

Quick Reference Summary

• EKS: Managed Kubernetes implementation from AWS.
• Worker capacity: EC2, Fargate, or Outposts.
• Availability: Clusters can span multiple Availability Zones.
• VPA: Adjusts pod CPU and memory reservations.
• HPA: Adjusts the number of pod replicas.
• Cluster Autoscaler: Uses AWS Auto Scaling groups.
• Karpenter: Works directly with the EC2 fleet.
• Ingress + AWS Load Balancer Controller: Creates an ALB.
• Service type LoadBalancer + controller: Creates an NLB.
• EKS Distro: Compatible Kubernetes distribution for manually managed clusters across environments.
• EKS Anywhere: EKS on customer-managed infrastructure.
• ECS Anywhere: ECS on customer-managed infrastructure.
• Batch: Kubernetes Jobs API.
• Machine learning: Kubeflow and GPU-powered instances.

Flashcards

Q: A workload’s pods need more accurate CPU and memory reservations, but the desired number of replicas should not change. Which autoscaling feature fits this requirement?

A: Use the Vertical Pod Autoscaler (VPA), because it adjusts pod CPU and memory reservations rather than primarily changing replica count.

Q: A web application must add more pod replicas as CPU utilization rises. Which feature should be selected?

A: Use the Horizontal Pod Autoscaler (HPA), which scales the number of pods in a deployment, replication controller, or replica set based on utilization.

Q: What is the key difference between HPA and Cluster Autoscaler?

A: HPA changes the number of application pods. Cluster Autoscaler changes the underlying worker capacity so pods have compute resources on which to run.

Q: Which cluster autoscaling option uses AWS Auto Scaling groups?

A: The Kubernetes Cluster Autoscaler uses AWS Auto Scaling groups. Karpenter is the alternative described as working directly with the Amazon EC2 fleet.

Q: When would Karpenter be considered instead of the Kubernetes Cluster Autoscaler?

A: Consider Karpenter when the design calls for an open-source autoscaler that works directly with the EC2 fleet rather than through AWS Auto Scaling groups.

Q: An administrator creates a Kubernetes Ingress and wants an AWS application load balancer. Which component provides this integration?

A: The AWS Load Balancer Controller provisions an ALB for a Kubernetes Ingress.

Q: What AWS load balancer does the AWS Load Balancer Controller provision for a Kubernetes Service of type LoadBalancer?

A: It provisions a Network Load Balancer (NLB), according to the behavior covered in this lesson.

Q: How can the AWS Load Balancer Controller be installed?

A: It can be installed with Helm v3 or by applying a Kubernetes manifest.

Q: Which worker-capacity environments are identified for EKS?

A: EKS can run worker capacity on Amazon EC2, AWS Fargate, and AWS Outposts.

Q: What problem does EKS Distro help solve for distributed teams?

A: It provides compatible Kubernetes binaries, containers, and dependencies, reducing the need to track updates, determine compatibility, and standardize versions independently across teams.

Q: When is EKS Anywhere more appropriate than standard managed EKS?

A: Use EKS Anywhere when Kubernetes must run on customer-managed infrastructure, such as on-premises bare-metal servers or VMware vSphere.

Q: How do EKS Anywhere and ECS Anywhere differ?

A: EKS Anywhere extends EKS/Kubernetes to customer-managed infrastructure, while ECS Anywhere extends Amazon ECS to that infrastructure.

Q: Which Kubernetes mechanism is highlighted for sequential or parallel batch workloads?

A: The Kubernetes Jobs API is used for the batch-processing workloads described in the lesson.

Practice Questions

Question 1

A team runs an EKS application whose CPU utilization varies significantly during the day. The application needs more replicas during high demand, while each pod’s resource reservations are already appropriate. Which option best fits?

A. Vertical Pod Autoscaler
B. Horizontal Pod Autoscaler
C. EKS Distro
D. AWS Load Balancer Controller

Correct answer: B. Horizontal Pod Autoscaler

Explanation: HPA changes the number of pod replicas based on utilization. VPA changes CPU and memory reservations instead.

Question 2

A Kubernetes administrator creates an Ingress resource and wants AWS to provision an application load balancer for it. What should the administrator use?

A. Kubernetes Cluster Autoscaler
B. AWS Load Balancer Controller
C. Karpenter
D. EKS Distro

Correct answer: B. AWS Load Balancer Controller

Explanation: The controller provisions an ALB when a Kubernetes Ingress is created.

Question 3

An organization wants to run Kubernetes clusters on its own bare-metal servers while using a Kubernetes distribution with dependencies tested for compatibility with Amazon EKS. Which option is the best match?

A. AWS Fargate
B. EKS Distro
C. ECS Anywhere
D. Classic Load Balancer

Correct answer: B. EKS Distro

Explanation: EKS Distro provides compatible Kubernetes components for manually operated clusters and can be used on on-premises hardware. ECS Anywhere is for ECS rather than Kubernetes.

Question 4

Pods cannot be scheduled because the cluster lacks worker capacity. The organization uses AWS Auto Scaling groups for its worker nodes. Which scaling component addresses the infrastructure shortage?

A. Horizontal Pod Autoscaler
B. Vertical Pod Autoscaler
C. Kubernetes Cluster Autoscaler
D. Kubeflow

Correct answer: C. Kubernetes Cluster Autoscaler

Explanation: Cluster Autoscaler adds or removes worker capacity through AWS Auto Scaling groups. HPA changes pod count but does not directly provide worker infrastructure.

WordPress Metadata

Suggested Slug:
amazon-eks-managed-kubernetes-scaling-load-balancing

Meta Description:
Study Amazon EKS architecture, workload and cluster autoscaling, AWS load balancer integration, EKS Distro, and ECS or EKS Anywhere deployment options for the SOA-C03 exam.

Tags:
Amazon EKS, Kubernetes, AWS CloudOps, EKS autoscaling, Karpenter, AWS Load Balancer Controller, EKS Distro, EKS Anywhere, ECS Anywhere, container orchestration, AWS Outposts