Skip to main content
< All Topics

AWS Elastic Kubernetes Service Architect Program

Posted
Updated
Author -Rajkumar Aute
Views1

Before beginning your AWS Elastic Kubernetes Service (EKS) journey, please complete the AWS Essentials and Kubernetes Architect programs to gain deep insights into the AWS Cloud and Kubernetes. These notes will focus primarily on AWS EKS.

Now that you have mastered the nitty-gritty of AWS Cloud and Kubernetes. let’s begin our deep dive into AWS EKS.

AWS EKS – The Enterprise Standard

EKS Architecture and Provisioning EKS Clusters

EKS Architecture read more

The Core Framework

  • The Concept: EKS is a managed service where AWS handles the Control Plane (the “Brain”) while you manage the Data Plane (the “Muscle”).
  • AWS Responsibility: AWS ensures high availability by running the API Server, Scheduler, and etcd across multiple AZs with automated healing and backups.
  • User Responsibility: You are responsible for Worker Nodes, networking (VPC/Subnets), IAM security, and the lifecycle of your applications.

Compute Options (Where Pods Live)

  • EKS Auto Mode: The most hands-off option where AWS dynamically provisions and scales compute, networking, and storage based on real-time demand.
  • Managed Node Groups: AWS automates EC2 provisioning and patching, but you still manage the underlying instances and instance types.
  • AWS Fargate: A serverless approach where you pay per Pod based on CPU/RAM, eliminating the need to manage servers entirely.

Provisioning EKS Clusters read more

EKS Provisioning Methods

  • eksctl (The “Fast-Track”): The official CLI tool that abstracts complex CloudFormation stacks into simple YAML commands
  • Terraform / OpenTofu (The “Industry Standard”): Powerful, vendor-neutral tools that manage the entire ecosystem VPC, IAM, and Security Groups in a single, version-controlled codebase.
  • CDK (Cloud Development Kit): For those who prefer “Infrastructure as Software,” allowing you to define your EKS cluster using familiar languages like Python, TypeScript, or Go.

Why IaC is Mandatory

  • Disaster Recovery: If a region goes down, you can re-provision your entire EKS infrastructure in minutes using your existing code.
  • Repeatability: Easily recreate identical environments for Development, Staging, and Production without manual errors.
  • Version Control: Every infrastructure change is tracked in Git, allowing for peer reviews and instant rollbacks if something breaks.

AWS Identity & Access Management (IAM)

AWS Cloud to EKS Authentication & Access Control read more

The “Who are you?” (Authentication)

  • IAM as Identity: AWS IAM acts as the external “ID Card” issuer for the cluster.
  • STS Tokens: kubectl uses the AWS CLI to swap your IAM credentials for a short-lived (15-min) cryptographic STS token.
  • The Handshake: The EKS Control Plane sends your token back to AWS STS to verify your identity before letting you in.

The “Bridge” (Identity Mapping)

  • Legacy (aws-auth): A brittle Kubernetes ConfigMap that manually maps IAM ARNs to K8s usernames—prone to syntax errors and lockouts.
  • Modern (Access Entries): An AWS-native API that links IAM principals to K8s identities directly, managed outside the cluster via IaC.

The “What can you do?” (Authorization)

  • RBAC is King: Once inside, AWS IAM has no power; Kubernetes RBAC (Roles/Bindings) decides which Pods or Namespaces you can touch.
  • Decoupled Logic: IAM gets you to the front door; RBAC determines which room keys you hold.

The “Workload Identity” (Pod-to-AWS)

  • Modern (Pod Identity): A simplified agent-based system that lets Pods grab AWS credentials without managing OIDC providers or complex JSON strings.
  • Legacy (IRSA): Uses OIDC federation and complex trust policies to give Pods specific IAM roles.

Contents
Scroll to Top