Lesson 01 — Amazon EKS Architecture

Learning Objectives

By the end of this lesson, you will be able to:

Explain the architecture of Amazon EKS
Understand the components of a Kubernetes cluster running on AWS
Differentiate between the Kubernetes Control Plane and Worker Nodes
Understand how Amazon EKS manages Kubernetes
Explain the networking architecture of Amazon EKS
Understand EKS node groups and compute options
Design secure enterprise EKS architectures
Understand multi-account and multi-region EKS deployments
Identify AWS services commonly integrated with Amazon EKS
Apply Amazon EKS architecture best practices

Why This Matters

Amazon Elastic Kubernetes Service (Amazon EKS) is one of the most widely adopted managed Kubernetes platforms in the cloud.

Many organisations use Amazon EKS to run:

Enterprise web applications
Banking platforms
Payment systems
AI and Machine Learning workloads
Containerised microservices
DevSecOps pipelines
Security platforms
Large-scale SaaS applications

As a Cloud Security Engineer, understanding Amazon EKS architecture is essential because every security control depends on understanding how the platform is built.

You cannot secure:

Kubernetes API
Worker Nodes
Networking
IAM
Storage
Secrets
Logging
Monitoring

without first understanding how they fit together.

What is Amazon EKS?

Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service provided by AWS.

AWS manages the Kubernetes control plane while customers manage the worker nodes, workloads and Kubernetes resources.

AWS

↓

Managed Kubernetes Control Plane

+

Customer

↓

Applications
Worker Nodes
Networking
Security
Policies

Amazon EKS removes much of the operational burden associated with managing Kubernetes clusters.

High-Level Amazon EKS Architecture

Users

↓

AWS IAM

↓

Amazon EKS API Endpoint

↓

Managed Kubernetes Control Plane

├── API Server
├── Scheduler
├── Controller Manager
└── etcd

↓

Worker Nodes

↓

Pods

↓

Applications

This separation between the managed control plane and customer-managed worker nodes is one of the defining characteristics of Amazon EKS.

Amazon EKS Shared Responsibility

Amazon EKS follows the AWS Shared Responsibility Model.

AWS Responsibilities

AWS manages:

Kubernetes control plane
etcd infrastructure
API Server availability
Scheduler
Controller Manager
Managed service infrastructure
Control plane scaling
Control plane patching
High availability of the managed service

Customer Responsibilities

Customers manage:

Worker Nodes
Managed Node Groups configuration
Self-managed nodes
Kubernetes workloads
RBAC
IAM
Networking
Security Groups
Secrets
Applications
Container Images
Logging
Monitoring
Compliance

AWS
└── Control Plane

Customer
├── Nodes
├── Pods
├── Applications
├── Security
└── Governance

Components of an Amazon EKS Cluster

An Amazon EKS cluster consists of several major components.

Amazon EKS Cluster

├── Managed Control Plane
├── Worker Nodes
├── Kubernetes Pods
├── Services
├── Networking
├── Storage
├── IAM
├── Logging
└── Monitoring

Each component plays an important role.

Amazon EKS Control Plane

The Kubernetes Control Plane is the brain of the cluster.

AWS manages this entire layer.

It includes:

Kubernetes API Server
Scheduler
Controller Manager
etcd
Cloud Controller integration

Applications never interact directly with etcd.

Instead:

kubectl

↓

API Server

↓

etcd

The API Server validates and stores all Kubernetes objects.

Kubernetes API Server

The API Server is the central communication point.

Everything interacts through it.

Examples include:

kubectl
CI/CD pipelines
Controllers
Operators
Admission Controllers
Kubernetes Dashboard
Automation tools

Developer

↓

kubectl

↓

API Server

↓

Cluster

Every request passes through:

Authentication
Authorisation
Admission Controllers
Validation

before being stored.

Kubernetes Scheduler

The Scheduler determines where Pods should run.

It considers:

CPU availability
Memory availability
Resource requests
Node affinity
Taints
Tolerations
Topology constraints
Scheduling policies

New Pod

↓

Scheduler

↓

Best Worker Node

Controller Manager

The Controller Manager maintains the desired cluster state.

Controllers include:

Deployment Controller
ReplicaSet Controller
Node Controller
Job Controller
Endpoint Controller

Example:

Desired replicas:

3 Pods

Current state:

2 Pods

Controller Manager automatically creates:

1 New Pod

etcd

etcd is Kubernetes’ distributed key-value database.

It stores:

Pods
Deployments
Secrets
ConfigMaps
Services
Namespaces
RBAC
Policies

AWS manages etcd within Amazon EKS.

Customers never access etcd directly.

Worker Nodes

Worker Nodes run applications.

They provide:

CPU
Memory
Storage
Network connectivity

Worker Nodes contain:

Worker Node

├── kubelet
├── Container Runtime
├── kube-proxy
└── Pods

kubelet

kubelet communicates with the Kubernetes API Server.

Responsibilities include:

Starting containers
Monitoring Pods
Reporting node status
Running health checks
Managing volumes

API Server

↓

kubelet

↓

Containers

Container Runtime

The Container Runtime executes containers.

Modern Amazon EKS clusters use:

containerd

The runtime:

Pulls images
Starts containers
Stops containers
Reports container status

kube-proxy

kube-proxy manages Kubernetes networking.

Responsibilities include:

Service routing
ClusterIP
NodePort
Load balancing
iptables rules
IPVS rules (where applicable)

It enables Pods to communicate through Kubernetes Services.

Pods

Pods are the smallest deployable Kubernetes object.

A Pod contains:

One or more containers
Shared networking
Shared storage
Shared lifecycle

Example:

Pod

├── Application Container
└── Logging Sidecar

Amazon EKS Networking

Networking is built on Amazon VPC.

Amazon VPC

↓

Subnets

↓

Worker Nodes

↓

Pods

Every Pod receives its own IP address.

Networking components include:

Amazon VPC
Security Groups
Route Tables
Elastic Network Interfaces (ENIs)
Kubernetes Services
Network Policies

VPC CNI

Amazon EKS uses the Amazon VPC CNI plugin.

Benefits include:

Native VPC networking
Pod IP addresses from VPC
Security Group integration
High performance

VPC

↓

ENI

↓

Pod IP

Elastic Network Interfaces (ENIs)

Each Worker Node receives one or more ENIs.

Each ENI provides IP addresses for Pods.

EC2 Instance

↓

ENI

↓

Multiple Pod IPs

The number of Pods depends on:

EC2 instance type
Number of ENIs
Available IP addresses

Kubernetes Services

Services expose applications.

Common types include:

Service Type	Purpose
ClusterIP	Internal communication
NodePort	Exposes through worker nodes
LoadBalancer	AWS Load Balancer
ExternalName	External DNS

Ingress

Ingress manages HTTP and HTTPS routing.

Common implementations include:

AWS Load Balancer Controller
NGINX Ingress Controller

Internet

↓

Application Load Balancer

↓

Ingress

↓

Service

↓

Pods

Amazon EKS Storage

Storage options include:

Amazon EBS
Amazon EFS
FSx
CSI Drivers

Pod

↓

Persistent Volume

↓

Amazon EBS

Storage is dynamically provisioned using StorageClasses.

Identity Architecture

Identity combines AWS IAM and Kubernetes RBAC.

User

↓

AWS IAM

↓

Amazon EKS Authentication

↓

Kubernetes RBAC

↓

Cluster Access

Both layers work together.

Amazon EKS Authentication

Authentication uses AWS IAM.

Examples include:

IAM Users
IAM Roles
IAM Identity Center
Federated identities

Authentication determines:

Who are you?

Kubernetes RBAC

RBAC determines:

What can you do?

Examples:

Create Pods
Delete Deployments
Read Secrets
Manage Nodes

Authentication and Authorisation are separate.

Worker Node Options

Amazon EKS supports multiple compute models.

Option	Description
Managed Node Groups	AWS-managed EC2 worker nodes
Self-managed Nodes	Customer-managed EC2 instances
AWS Fargate	Serverless Pods

Managed Node Groups

AWS manages:

Scaling
Updates
Lifecycle integration

Customers manage:

Instance types
Scaling configuration
Security Groups
IAM roles

Managed Node Groups are recommended for most production workloads.

Self-managed Nodes

Customers manage:

EC2 lifecycle
AMIs
Updates
Scaling
Patching

Provides maximum flexibility but requires greater operational effort.

AWS Fargate

AWS Fargate eliminates worker node management.

Pod

↓

AWS Fargate

↓

Serverless Compute

Suitable for:

Small workloads
Event-driven applications
Operational simplicity

High Availability Architecture

Production EKS clusters span multiple Availability Zones.

Region

├── AZ-A
├── AZ-B
└── AZ-C

↓

Worker Nodes

↓

Pods

This improves:

Availability
Fault tolerance
Disaster resilience

Multi-AZ Deployment

Example:

AZ-1

Worker Nodes

AZ-2

Worker Nodes

AZ-3

Worker Nodes

Applications should run across multiple AZs.

Enterprise Multi-Account Architecture

Large organisations commonly use multiple AWS accounts.

AWS Organizations

├── Security Account
├── Logging Account
├── Shared Services
├── Development
├── Testing
└── Production

Each account may contain one or more EKS clusters.

Multi-Region Architecture

Critical workloads may span Regions.

Primary Region

↓

Amazon EKS

↓

Disaster Recovery Region

↓

Amazon EKS

Benefits include:

Disaster Recovery
Business Continuity
Reduced regional risk

Security Architecture

Amazon EKS security includes:

IAM

↓

RBAC

↓

Pod Security

↓

Network Policies

↓

Security Groups

↓

Encryption

↓

Monitoring

Multiple security layers provide defence in depth.

Logging Architecture

Logging sources include:

API Server
Audit Logs
Authenticator Logs
Scheduler Logs
Controller Manager Logs
Application Logs
Node Logs

Amazon EKS

↓

CloudWatch

↓

SIEM

Monitoring Architecture

Monitoring typically includes:

Amazon CloudWatch
Prometheus
Grafana
Amazon Managed Prometheus
Amazon Managed Grafana

Metrics include:

CPU
Memory
Network
API latency
Pod health

Common AWS Services Integrated with Amazon EKS

AWS Service	Purpose
IAM	Authentication
VPC	Networking
EC2	Worker Nodes
ECR	Container Registry
CloudWatch	Monitoring
CloudTrail	Auditing
KMS	Encryption
Secrets Manager	Secrets
GuardDuty	Threat Detection
Security Hub	Security Findings
Inspector	Vulnerability Scanning

Enterprise Reference Architecture

AWS Organizations

↓

AWS Account

↓

Amazon VPC

↓

Amazon EKS

├── Managed Control Plane
├── Managed Node Groups
├── Ingress
├── Applications
├── Logging
├── Monitoring
├── Security Controls
└── GitOps

Recommendation

Use Managed Node Groups and Infrastructure as Code.

Enterprise Implementation Strategy

Phase 1 — Design

Define business requirements
Select AWS Region
Design VPC
Plan Availability Zones
Choose node model

Phase 2 — Build

Create Amazon EKS cluster
Configure networking
Deploy Managed Node Groups
Configure IAM
Configure RBAC

Phase 3 — Secure

Enable logging
Configure encryption
Deploy admission policies
Configure Pod Security
Configure Network Policies

Phase 4 — Operate

Monitor cluster
Patch worker nodes
Upgrade Kubernetes
Scan images
Review access

Phase 5 — Govern

Continuous compliance
Policy management
Audit logging
Incident response
Security monitoring

Enterprise Best Practices

As a Cloud Security Engineer:

Use Managed Node Groups unless specific requirements justify self-managed nodes.
Deploy worker nodes across multiple Availability Zones.
Protect the Kubernetes API endpoint with least-privilege access.
Use AWS IAM together with Kubernetes RBAC.
Enable Amazon EKS control plane logging.
Integrate Amazon EKS with CloudTrail, GuardDuty and Security Hub.
Store container images in Amazon ECR.
Encrypt sensitive data using AWS KMS.
Use Infrastructure as Code for cluster provisioning.
Continuously monitor cluster health, security posture and compliance.

Real-World Scenario

A multinational financial institution operates more than 300 Amazon EKS clusters across multiple AWS accounts supporting payment systems, customer banking portals and fraud detection services.

To ensure a secure and scalable platform, the organisation adopts a standard Amazon EKS architecture that includes:

AWS Organizations to separate production, development, security and shared services accounts.
Multi-AZ Amazon EKS clusters with Managed Node Groups for high availability.
Private API endpoints with restricted administrative access through AWS IAM Identity Center and MFA.
Amazon VPC CNI for native networking and dedicated node groups for sensitive workloads.
Amazon ECR as the approved container registry with mandatory image scanning and signing.
Pod Security Admission and Kyverno to enforce enterprise security policies.
CloudWatch, CloudTrail, GuardDuty and Security Hub integrated into a central SIEM for continuous monitoring.
GitOps and Infrastructure as Code to provision and manage every cluster consistently across environments.

This standardised architecture enables the organisation to scale securely while maintaining strong governance, operational consistency and regulatory compliance.

Key Takeaways

Amazon EKS is a managed Kubernetes service that separates AWS-managed control plane responsibilities from customer-managed workloads.
The Kubernetes Control Plane consists of the API Server, Scheduler, Controller Manager and etcd.
Worker Nodes run applications and contain kubelet, containerd and kube-proxy.
Amazon VPC provides native networking for Pods using the Amazon VPC CNI.
AWS IAM authenticates users while Kubernetes RBAC authorises actions.
Managed Node Groups are the recommended compute option for most production environments.
Multi-AZ and multi-account architectures improve resilience and governance.
Amazon EKS integrates with many AWS security services such as CloudTrail, GuardDuty, Security Hub, KMS and Inspector.
Enterprise Amazon EKS deployments should follow standardised architectures, Infrastructure as Code and defence-in-depth security principles.

Knowledge Check

1. Which components make up the Amazon EKS managed control plane?

Answer: The Kubernetes API Server, Scheduler, Controller Manager and etcd.

2. What is the primary responsibility of Worker Nodes?

Answer: Worker Nodes provide compute resources and run Kubernetes Pods and containers.

3. Which AWS networking component allows Pods to receive native VPC IP addresses?

Answer: The Amazon VPC CNI plugin.

4. What is the difference between AWS IAM and Kubernetes RBAC?

Answer: AWS IAM authenticates users and workloads to Amazon EKS, while Kubernetes RBAC determines what authenticated identities are authorised to do within the cluster.

5. Why are Multi-AZ deployments recommended for Amazon EKS?

Answer: They improve availability, fault tolerance and resilience by distributing worker nodes across multiple Availability Zones.

What’s Next?

In the next lesson, we will explore Amazon EKS Cluster Design, including production-ready cluster topologies, node group strategies, networking layouts and enterprise deployment patterns.

➡️ Next Lesson: Lesson 02 — Amazon EKS Cluster Design