Amazon EKS — Introduction — Practice Exercises

4 minute read

Chapter 1 — Practice Exercises

Test your understanding of EKS fundamentals with these 5 exercises. Try to answer each question before expanding the solution.

Exercise 1: EKS Shared Responsibility

Question: List 5 components that AWS manages in EKS and 5 components that you manage. Explain why this division exists.

Show Solution

AWS manages (Control Plane):

  1. API Server — Entry point for all Kubernetes operations
  2. etcd — Cluster state database (replicated across 3 AZs)
  3. Scheduler — Decides which node runs each pod
  4. Controller Manager — Runs reconciliation loops
  5. Control plane patching and upgrades — Security fixes applied automatically

You manage (Data Plane + Config):

  1. Worker nodes — EC2 instances or Fargate profiles
  2. Application deployments — Your containerized apps
  3. IAM roles and policies — Authentication and authorization
  4. VPC networking — Subnets, security groups, NACLs
  5. Kubernetes RBAC — Who can do what in the cluster

Why this division? The control plane is the hardest part to run reliably. By letting AWS manage it, you get 99.95% SLA and automatic patching without any operational burden. You keep control of the parts that are unique to your business — your apps, your permissions, your network design.

Exercise 2: Cost Estimation

Question: Calculate the monthly cost for a development EKS cluster with: 1 EKS cluster, 2 t3.medium nodes (On-Demand), 1 NAT Gateway, and 50 GB of EBS gp3 storage. Assume us-east-1 pricing.

Show Solution 
Cost Breakdown:
├── EKS cluster fee:     $0.10/hr × 730 hrs = $73.00
├── 2× t3.medium:       $0.0416/hr × 2 × 730 hrs = $60.74
├── NAT Gateway:         $0.045/hr × 730 hrs = $32.85
│                        (+ data processing, assume minimal)
├── EBS gp3 (50 GB):    $0.08/GB × 50 GB = $4.00
└── TOTAL:              ~$170.59/month

Cost optimization tips:

  • Use Spot instances for non-critical dev workloads (save ~$36/month)
  • Delete the cluster after work hours (save ~65% = $111/month)
  • Use a single NAT Gateway (acceptable for dev)

Exercise 3: EKS vs ECS Decision

Question: Your startup has 5 microservices, a team of 3 developers (none with Kubernetes experience), and needs to deploy to AWS only. Should you use ECS or EKS? Justify your answer.

Show Solution

Recommendation: Amazon ECS

Reasons:

  1. Team expertise — No Kubernetes experience means weeks of learning before being productive with EKS
  2. Service count — 5 microservices is well within ECS’s sweet spot
  3. No multi-cloud need — AWS-only means K8s portability isn’t valuable
  4. Cost — No $73/month cluster fee
  5. Simplicity — ECS + Fargate requires learning Task Definitions (simpler than K8s manifests)

When to reconsider:

  • If you grow to 20+ services and need K8s features (Helm, operators, CRDs)
  • If team hires engineers with K8s experience
  • If multi-cloud becomes a requirement

When EKS would be better:

  • If even one team member is a K8s expert who can train others
  • If your services need complex scheduling (affinity, taints)
  • If you plan to grow to 20+ services within a year

Exercise 4: Architecture Diagram

Question: Draw (or describe) the network flow when a user hits your application running on EKS via an ALB. Include: Internet, ALB, worker node, pod, and the control plane.

Show Solution 
User Request Flow:

Internet
    │
    ▼
┌──────────┐  Public Subnet
│   ALB    │  (receives HTTP/HTTPS traffic)
└────┬─────┘
     │ Target Group
     ▼
┌──────────────────────┐  Private Subnet
│    Worker Node       │
│    ┌──────────┐      │
│    │   Pod    │      │
│    │ (your   │      │
│    │  app)   │      │
│    │ 10.0.x.y│ ◄─── Pod has real VPC IP (VPC CNI)
│    └──────────┘      │
└──────────────────────┘

Meanwhile (separate from user traffic):
┌──────────────────────┐
│  EKS Control Plane   │ Manages scheduling,
│  (AWS-managed)       │ desired state, etc.
│       │              │ via ENIs in your VPC
│       └──── ENI ─────┤
└──────────────────────┘

Key points:

  1. User traffic flows: Internet → ALB → Pod (never touches control plane)
  2. Control plane manages the cluster state (scheduling, reconciliation)
  3. The pod has a real VPC IP address, so ALB can route directly to it
  4. Control plane communicates with nodes through ENIs in your private subnets

Exercise 5: Kubernetes Version Strategy

Question: Your EKS cluster is running Kubernetes 1.27. AWS has announced that 1.27 is moving to extended support in 2 months. What should you do, and what’s the cost impact of doing nothing?

Show Solution

What you should do:

  1. Immediately plan an upgrade to at least K8s 1.28 (or the latest version)
  2. Test your applications on the new version in a staging cluster
  3. Review the Kubernetes changelog for breaking changes
  4. Upgrade add-ons first (VPC CNI, CoreDNS, kube-proxy), then the control plane, then node groups
  5. Upgrade within the 2-month window before extended support kicks in

Cost impact of doing nothing:

Standard support: $0.10/hr = $73/month per cluster
Extended support: $0.60/hr = $438/month per cluster
────────────────────────────────────
Extra cost:       $0.50/hr = $365/month per cluster

That’s a 500% price increase — $365/month extra per cluster just because you didn’t upgrade. For 5 clusters, that’s $1,825/month wasted.

Lesson: Always keep EKS clusters on a version within the standard support window. Set calendar reminders for EKS version support dates.

What’s Next?

Great job completing Chapter 1! You now understand what EKS is, how it compares to alternatives, and how much it costs.

Next up: Chapter 2 — Prerequisites & Setup where we install all the tools you need.

You may also enjoy