Warrior, now we move from local Kubernetes → production cloud Kubernetes.
You already know:
Docker → Image → Deployment → Pod → Service → IngressNow we'll see how the same concepts work on AWS EKS (Elastic Kubernetes Service).
Amazon Web Services EKS is AWS's managed Kubernetes service.
In simple words:
AWS runs the Kubernetes control plane for you, while you run/manage the workloads and worker capacity.
Instead of manually building:
Kubernetes API Server
etcd
Scheduler
Controller ManagerAWS manages the Kubernetes control-plane infrastructure for an EKS cluster.
Your responsibility is still to understand and operate:
Deployments
Pods
Services
Ingress
ConfigMaps
Secrets
RBAC
Networking
Scaling
MonitoringPreviously:
Your PC
↓
Docker Desktop
↓
KubernetesWith EKS:
AWS Cloud
↓
EKS Cluster
↓
Worker Capacity
↓
PodsA simplified production architecture:
AWS
│
┌──────┴──────┐
│ │
EKS Control VPC
Plane │
│
┌───────┴───────┐
↓ ↓
Node Node
│ │
Pods PodsA major EKS benefit is the managed Kubernetes control plane.
Conceptually:
AWS manages
────────────────────
API Server
etcd
Scheduler
Controller Manager
Control-plane availability
Control-plane infrastructureYou manage or configure:
────────────────────────
Worker nodes / node groups
Pods
Deployments
Services
Ingress
Applications
Resources
RBAC
Network policies
Application configurationThe exact responsibility boundary varies with the EKS compute model and AWS-managed features you're using.
A simplified architecture:
Internet
│
↓
AWS Load Balancer
│
↓
EKS Cluster
│
┌─────────┴─────────┐
│ │
Worker Node Worker Node
│ │
┌────┴────┐ ┌────┴────┐
↓ ↓ ↓ ↓
Pod Pod Pod PodBehind this is AWS networking:
VPC
│
├── Subnet A
│ └── Node
│
├── Subnet B
│ └── Node
│
└── Subnet C
└── NodeOne of the most important AWS concepts is:
EKS runs inside an AWS networking environment based on a VPC.
VPC = Virtual Private Cloud.
Think of it as your private AWS network.
Example:
VPC
│
├── Availability Zone A
│ ├── Public Subnet
│ └── Private Subnet
│
├── Availability Zone B
│ ├── Public Subnet
│ └── Private Subnet
│
└── Availability Zone C
├── Public Subnet
└── Private SubnetFor production workloads, worker nodes are commonly placed in private subnets.
AWS regions contain multiple Availability Zones (AZs).
For example:
Region
│
├── AZ-A
│
├── AZ-B
│
└── AZ-CIf you run all your nodes in one AZ:
AZ-A
├── Node
├── Node
└── Nodean AZ-level failure can affect the entire workload.
Instead:
AZ-A AZ-B AZ-C
│ │ │
Node Node Node
│ │ │
Pods Pods PodsThis improves fault tolerance.
Your Pods need somewhere to run.
Traditionally, EKS worker capacity can be provided by EC2 instances.
Example:
EC2 Node 1
│
├── Pod
├── Pod
└── Pod
EC2 Node 2
│
├── Pod
└── PodEKS commonly uses managed node groups to simplify EC2 worker-node lifecycle management.
A managed node group is a group of EC2 instances that AWS helps manage as EKS worker capacity.
You specify things such as:
Instance type
Minimum nodes
Maximum nodes
Desired nodes
Subnets
AMI / node configurationExample:
Node Group
min = 2
desired = 3
max = 6Initially:
Node 1
Node 2
Node 3If capacity needs to increase:
Node 1
Node 2
Node 3
Node 4
Node 5You should know that EKS is not limited to one worker model.
Common options include:
AWS-managed EC2 worker nodes.
EKS
↓
Managed Node Group
↓
EC2
↓
PodsYou manage more of the node lifecycle yourself.
Pods can run on serverless compute without you managing traditional worker nodes.
Conceptually:
EKS
↓
Fargate
↓
PodAWS also provides a more automated operating model where AWS manages more of the compute infrastructure and scaling decisions.
For learning Kubernetes fundamentals, however, managed node groups are an excellent model to understand first.
You need somewhere to store Docker images.
AWS provides:
Amazon ECR — Elastic Container Registry
Architecture:
Developer
│
↓
docker build
│
↓
Docker Image
│
↓
ECR
│
↓
EKS
│
↓
PodFor example:
ECR Repository
node-api
├── 1.0.0
├── 1.1.0
└── 1.2.0Normally you don't.
Your CI pipeline builds the image:
Git
↓
CI
↓
Docker Build
↓
ECRThen Kubernetes pulls it:
EKS
↓
Pod
↓
ECR
↓
Docker/OCI imageThe container runtime on the node downloads the image.
Suppose you have:
Node.js APIYou make a change.
git pushCI runs:
npm testDocker:
docker build -t node-api:1.5.0 .Push to ECR:
ECR
└── node-api:1.5.0Update Kubernetes:
image: ECR_URL/node-api:1.5.0EKS Deployment starts a rolling update.
v1.4
v1.4
v1.4
↓
v1.4
v1.4
v1.5
↓
v1.4
v1.5
v1.5
↓
v1.5
v1.5
v1.5Earlier you learned:
Internet
↓
Ingress
↓
Service
↓
PodsIn AWS, an Ingress/Service integration can provision or use AWS load-balancing infrastructure depending on the controller and configuration.
A common modern architecture uses the AWS Load Balancer Controller.
Conceptually:
Internet
│
↓
AWS Load Balancer
│
↓
Ingress
│
↓
Service
│
↓
PodsAWS commonly provides:
Layer 7.
Useful for:
HTTP
HTTPS
Host routing
Path routingExample:
example.com
↓
ALB
↓
IngressLayer 4-oriented load balancing.
Useful for:
TCP
TLS
UDP
high-performance networkingThe exact Kubernetes integration depends on the Service/Ingress/controller configuration.
This component watches Kubernetes resources and configures AWS load-balancing resources accordingly.
For example:
kind: Ingresscan lead to AWS infrastructure being configured.
Conceptually:
Kubernetes Ingress
│
↓
AWS Load Balancer Controller
│
↓
AWS ALBThis is an important bridge between:
Kubernetes APIand:
AWS infrastructureRemember Chapter 11?
Kubernetes needs networking between:
Pod → Pod
Pod → Service
Pod → InternetAWS commonly uses the Amazon VPC CNI plugin for EKS networking.
This allows Pods to receive IP addresses associated with the VPC networking model.
Conceptually:
VPC
│
├── Node IP
│
├── Pod IP
├── Pod IP
└── Pod IPThis is different from simply imagining a completely isolated overlay network.
AWS Security Groups operate at the AWS network level.
Think:
Security Group
↓
AWS network trafficWhereas:
NetworkPolicy
↓
Kubernetes Pod network trafficThese are complementary.
For example:
Internet
↓
Security Group
↓
Load Balancer
↓
Kubernetes NetworkPolicy
↓
PodVery important interview question.
| Security Group | NetworkPolicy |
|---|---|
| AWS networking | Kubernetes networking |
| AWS resource/network interfaces | Pods |
| AWS infrastructure level | Kubernetes workload level |
| Controls allowed network traffic | Controls Pod traffic |
| AWS-specific | Kubernetes API abstraction |
Don't think:
"NetworkPolicy replaces Security Groups."
It doesn't.
They operate at different layers.
AWS IAM means:
Identity and Access Management.
It answers:
Who can access AWS resources?For example:
Developer
↓
IAM
↓
Can access EKS?
Can access ECR?
Can access S3?Another very important interview topic.
Controls access to AWS resources.
IAM
↓
EKS
ECR
S3
EC2
RDS
Secrets ManagerControls access to Kubernetes API resources.
RBAC
↓
Pods
Deployments
Services
Secrets
ConfigMapsSo:
AWS IAM
+
Kubernetes RBACare often both involved.
Your application may need AWS permissions.
Suppose:
Node.js Pod
↓
S3 bucketYou should not casually put AWS access keys inside:
ConfigMap
Secret
Dockerfile
source codeModern EKS deployments can use AWS workload identity mechanisms, including EKS Pod Identity and IAM roles for service accounts (IRSA) depending on the setup.
Conceptually:
Pod
↓
Kubernetes ServiceAccount
↓
AWS identity mapping
↓
IAM Role
↓
S3This is much safer than embedding long-lived credentials in the container.
You might have:
DATABASE_PASSWORD
JWT_SECRET
OPENAI_API_KEYDon't put these into:
Dockerfileor:
Git repositoryInstead, you can integrate Kubernetes Secrets with AWS secret-management systems.
A common production pattern:
AWS Secrets Manager
↓
External Secrets / secret integration
↓
Kubernetes Secret
↓
PodOr your application can access Secrets Manager using an appropriate IAM identity.
Very common architecture:
Internet
│
↓
ALB
│
↓
Ingress
│
↓
Node.js Pods
│ │
↓ ↓
Redis RDSNotice:
PostgreSQL doesn't necessarily need to run inside Kubernetes.
You can use:
Amazon RDS PostgreSQL
for managed relational database infrastructure.
This removes much of the database operational burden from Kubernetes.
Similarly, Redis can be provided by:
Amazon ElastiCache
Architecture:
Node.js
│
├── PostgreSQL → RDS
│
└── Redis → ElastiCacheThis can be preferable to running production PostgreSQL/Redis directly inside your application cluster, depending on your operational requirements.
A realistic AWS architecture could look like:
Internet
│
↓
Route 53 / DNS
│
↓
AWS ALB
│
↓
EKS Ingress
│
┌───────────┴───────────┐
↓ ↓
Next.js Service API Service
↓ ↓
Next.js Pods Node.js Pods
│
┌─────────┼─────────┐
↓ ↓ ↓
RDS Redis AWS APIs
Postgres Cache / S3Infrastructure:
AWS Region
│
└── VPC
│
├── Private Subnet
│ ├── EKS Node
│ └── EKS Node
│
├── Private Subnet
│ ├── EKS Node
│ └── EKS Node
│
└── Public/edge networking
└── Load BalancerYou already learned HPA.
The architecture becomes:
Traffic ↑
↓
CPU ↑
↓
Metrics
↓
HPA
↓
Pods increase
↓
Node capacity insufficient
↓
Cluster/node autoscaling
↓
New node capacitySo:
HPA
↓
Podsand:
Node autoscaling
↓
NodesThese are different layers.
Suppose:
Node group:
min = 2
desired = 3
max = 10And:
HPA:
minReplicas = 2
maxReplicas = 20Traffic increases.
HPA wants:
2 Pods → 8 PodsBut existing nodes don't have enough capacity.
Some Pods become:
PendingNode autoscaling can add nodes.
Then:
New nodes
↓
Scheduler
↓
Pending Pods
↓
RunningThis is an important misconception.
Creating an EKS cluster doesn't automatically give you:
Perfect security
Perfect autoscaling
Monitoring
Logging
CI/CD
Backups
Disaster recovery
Cost optimizationYou still need to design these.
EKS provides the Kubernetes managed control-plane foundation.
A production environment needs metrics.
You could use:
Prometheus
Grafana
CloudWatch
AWS Managed PrometheusArchitecture:
EKS
│
├── Node metrics
├── Pod metrics
├── Application metrics
└── Kubernetes metrics
│
↓
Prometheus
│
↓
GrafanaAWS also provides managed observability integrations.
A common architecture:
Pods
│
↓
stdout/stderr
│
↓
Log collector
│
↓
CloudWatch / Loki / ElasticsearchAWS environments often use CloudWatch-based logging, but other centralized logging systems are possible.
EKS isn't simply:
"One Kubernetes server = one price"Your total cost can include:
EKS control-plane/service charges
+
EC2 or other compute
+
Load Balancers
+
EBS storage
+
NAT Gateway
+
Data transfer
+
RDS
+
ElastiCache
+
CloudWatch
+
Other AWS servicesA surprisingly important production skill is understanding the networking bill.
For example:
NAT Gatewaycan become a meaningful cost in some architectures.
There are several ways to create EKS.
For example:
AWS Console
AWS CLI
eksctl
Terraform
CloudFormationFor learning, eksctl is convenient because it abstracts a lot of infrastructure setup.
Conceptually:
eksctl create cluster ...It can create/configure resources such as:
EKS cluster
VPC/networking
Node groups
IAM configurationThe exact command/options should be checked against the current EKS/eksctl documentation before running in a real AWS account because versions and defaults change.
After creating an EKS cluster, your local:
kubectlneeds credentials/configuration to communicate with the cluster.
Conceptually:
Your PC
│
└── kubectl
│
↓
AWS authentication
│
↓
EKS API ServerAWS CLI can update your kubeconfig for an EKS cluster.
Typical command:
aws eks update-kubeconfig \
--region <region> \
--name <cluster-name>Then:
kubectl get nodeskubectl doesn't become AWS-specific#This is a beautiful Kubernetes concept.
Locally:
kubectl get podsEKS:
kubectl get podsGKE:
kubectl get podsAKS:
kubectl get podsThe Kubernetes API is standardized.
Cloud providers provide infrastructure around it.
Suppose ECR contains:
123456789.dkr.ecr.ap-south-1.amazonaws.com/node-api:1.5.0Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: node-api
spec:
replicas: 3
selector:
matchLabels:
app: node-api
template:
metadata:
labels:
app: node-api
spec:
containers:
- name: node-api
image: 123456789.dkr.ecr.ap-south-1.amazonaws.com/node-api:1.5.0
ports:
- containerPort: 3000
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 10Apply:
kubectl apply -f deployment.yamlCheck:
kubectl get podsNow connect everything you've learned:
Developer
│
↓
Git
│
↓
CI
│
┌─────┴─────┐
↓ ↓
Test Build
│
↓
Docker Image
│
↓
ECR
│
↓
EKS
│
Deployment
│
ReplicaSet
│
┌────────┼────────┐
↓ ↓ ↓
Pod Pod Pod
│ │ │
└────────┼────────┘
↓
Service
↓
Ingress
↓
AWS Load Balancer
↓
InternetThat is the architecture you should now be able to explain in an interview.
Amazon EKS is AWS's managed Kubernetes service. AWS manages the Kubernetes control-plane infrastructure while users deploy and operate workloads on supported compute resources.
Kubernetes is the open-source orchestration platform.
EKS is AWS's managed service for running Kubernetes.
Kubernetes = technology
EKS = AWS managed offeringThey are different layers.
EKS
↓
Kubernetes managementwhile:
EC2
↓
Compute instancesEKS can use EC2-based worker capacity.
Amazon Elastic Container Registry.
It stores container images.
Docker image → ECR → EKS PodsA group of EC2 worker nodes whose lifecycle is managed more directly by EKS/AWS.
A Kubernetes controller that integrates Kubernetes resources with AWS load-balancing services.
IAM
↓
AWS permissions
RBAC
↓
Kubernetes API permissionsUse an AWS workload identity mechanism such as EKS Pod Identity or IRSA, depending on your architecture, rather than embedding long-lived AWS access keys inside the Pod.
EKS
↓
Managed Kubernetes on AWS
VPC
↓
AWS private networking
EC2
↓
Worker compute
Managed Node Group
↓
Group of EC2 worker nodes
ECR
↓
Container image registry
ALB/NLB
↓
AWS load balancing
IAM
↓
AWS permissions
RBAC
↓
Kubernetes permissions
RDS
↓
Managed PostgreSQL/MySQL
ElastiCache
↓
Managed Redis/Memcached
HPA
↓
Pod scaling
Node autoscaling
↓
Node capacity scaling AWS
│
┌────┴────┐
│ EKS │
└────┬────┘
│
┌──────┴──────┐
↓ ↓
Node Group Node Group
│ │
Pods Pods
│
↓
Service
│
↓
Ingress
│
↓
AWS Load Balancer
│
↓
InternetAnd the production application stack:
Next.js
↓
Node.js
↓
Redis / RDS
↓
S3 / AWS Servicesall running around an EKS-based platform.
We'll compare:
AWS EKS
GCP GKE
Azure AKSand learn:
Mark it as complete to track your mastery.