Production EKS Platform — From Zero to Production›01 · AWS & EKS services and terms

Lesson 01 of 18 · Part 1 — Foundations

AWS & EKS services and terms

The vocabulary every later lesson assumes: the AWS services an EKS platform is built from, and the EKS-specific terms you'll hear in design reviews, each with what it is and why the platform needs it.

Beginner → Practitioner
Key wordsAWS servicesEKS termsVPCIAMEC2ELBEBSEFSECRRoute 53KMSCloudWatchcontrol planedata planeadd-onaccess entryPod Identity

How to use this page

Keep it open while you work through the track. Every later lesson uses these words without explaining them again. The tables answer three questions for each item: what it is, what the EKS platform uses it for, and where it's covered.

Building a platform on AWS is like fitting out a new office building. The building (account, VPC) comes first, then the doors and corridors (subnets, load balancers), the security desk (IAM), the lifts (EKS itself), the storage rooms (EBS, EFS, S3) and the CCTV (CloudWatch). You can't reason about the lifts until you know the words for everything around them.

AWS services an EKS platform uses

Accounts, identity and security

Service / term What it is What EKS uses it for
AWS account The billing and security boundary for resources One account per environment (prod, non-prod) limits blast radius
AWS Organizations, SCP Groups accounts; Service Control Policies set the maximum permissions in an account Org-wide guard-rails (e.g. no regions outside the allowed list)
IAM (users, roles, policies) Identity and access for AWS APIs Cluster role, node role, pod roles, admin and CI roles
IAM Identity Center (SSO) Single sign-on into roles across accounts How people get short-lived credentials to reach the cluster
STS Issues temporary credentials Everything above: nothing on the platform should use long-lived keys
KMS Managed encryption keys Envelope encryption of Kubernetes Secrets, EBS/EFS encryption
Secrets Manager / SSM Parameter Store Stores secrets and configuration App secrets, synced into pods (e.g. External Secrets Operator)
GuardDuty Threat detection EKS audit-log monitoring and runtime monitoring
CloudTrail Audit log of AWS API calls Who changed the cluster, IAM or network, and when

Networking

Service / term What it is What EKS uses it for
Region, Availability Zone (AZ) A geographic area and its isolated data centres Spread nodes across at least 2–3 AZs for resilience
VPC Your private network in a region, with one or more CIDR blocks Nodes and (with the VPC CNI) every pod get IPs from it
Subnet (public / private) A slice of the VPC in one AZ Public: load balancers, NAT. Private: nodes and pods
Route table, Internet Gateway (IGW) Routing rules; the VPC's door to the internet Public subnets route 0.0.0.0/0 to the IGW
NAT gateway Outbound-only internet for private subnets Nodes pulling images and calling external APIs
VPC endpoints (Gateway / Interface) Private access to AWS services without the internet ECR, S3, STS, CloudWatch, EKS API: lower NAT cost, private clusters
Security group (SG) Stateful firewall on network interfaces Cluster SG, node SGs, optionally per-pod SGs
NACL Stateless subnet-level firewall Rarely tuned for EKS; keep defaults unless required
Transit Gateway, VPC peering Connect VPCs and on-prem networks Shared services, hybrid connectivity
Route 53 DNS App hostnames; ExternalDNS writes records from the cluster

Compute, load balancing and containers

Service / term What it is What EKS uses it for
EC2, instance type, AMI Virtual machines, their sizes, their images Worker nodes (EKS-optimised AL2023 or Bottlerocket AMIs)
Launch template Reusable EC2 settings Node group settings: AMI, disk, IMDSv2, user data
Auto Scaling group (ASG) Keeps N instances running Underlies managed node groups
Spot instances Spare capacity at a discount, can be reclaimed Cheap, interruption-tolerant capacity (Karpenter)
Fargate Serverless compute for pods Per-pod isolation without managing nodes, with limits
Elastic Load Balancing: ALB / NLB Layer-7 HTTP(S) / layer-4 TCP-UDP load balancers Exposing Ingresses (ALB) and Services (NLB)
ACM TLS certificates Certificates on ALBs/NLBs
ECR Private container registry Your images; scanning, lifecycle rules, replication

Storage, observability and cost

Service / term What it is What EKS uses it for
EBS (gp3, io2) Block volumes attached to one instance in one AZ ReadWriteOnce persistent volumes via the EBS CSI driver
EFS Managed NFS across AZs ReadWriteMany shared volumes via the EFS CSI driver
S3 Object storage Backups (Velero), logs, app data, Terraform state
CloudWatch (Logs, Metrics, Container Insights) AWS monitoring Control-plane logs, node/pod metrics, alarms
Amazon Managed Service for Prometheus / Managed Grafana Hosted Prometheus-compatible store and Grafana Metrics without running Prometheus storage yourself
Service Quotas Per-account limits vCPU, IP, EKS and ELB limits that block scaling if ignored
Cost Explorer, cost allocation tags Spend analysis Cost per cluster, team or namespace

EKS terms

Term Meaning
Control plane API server, etcd, scheduler and controllers. Run by AWS across AZs, reached through the cluster endpoint
Data plane Where pods run: managed node groups, self-managed nodes, Fargate, Karpenter-launched nodes, or EKS Auto Mode
Cluster endpoint (public / private) The Kubernetes API URL. Public, private, or both, optionally restricted by CIDR
Cluster IAM role Role EKS assumes to manage AWS resources for the control plane
Node IAM role Role on worker instances: join the cluster, pull from ECR, run the CNI. Keep it minimal
Managed node group (MNG) EKS-managed ASG of worker nodes with graceful updates
EKS Auto Mode EKS also manages compute (Karpenter-based), storage and load balancing components for you
Karpenter Open-source node autoscaler that launches right-sized instances directly
Managed add-on Component (VPC CNI, CoreDNS, kube-proxy, EBS/EFS CSI, Pod Identity Agent, metrics-server...) installed and versioned through the EKS API
Amazon VPC CNI Networking plug-in that gives pods real VPC IP addresses
Prefix delegation CNI mode assigning /28 prefixes to nodes so more pods fit per node
Authentication mode How the cluster maps IAM to Kubernetes: API, API_AND_CONFIG_MAP, or legacy CONFIG_MAP (aws-auth)
Access entry, access policy Grants an IAM principal access to the cluster; access policies are AWS-managed Kubernetes permission sets
EKS Pod Identity Associates an IAM role with a namespace/ServiceAccount so pods get AWS credentials
IRSA IAM Roles for Service Accounts: the older OIDC-based way to give pods AWS roles
OIDC issuer The cluster's token issuer URL, trusted by IAM for IRSA
AWS Load Balancer Controller Creates ALBs/NLBs from Ingress and Service objects
EBS / EFS CSI driver Provisions and attaches AWS storage for PersistentVolumeClaims
Standard / extended support Each Kubernetes minor version gets a standard support window, then optional paid extended support
Cluster insights EKS checks that flag upgrade blockers such as deprecated API use
Container Insights CloudWatch feature collecting cluster, node and pod metrics and logs
Security groups for pods Attaching VPC security groups to individual pods

The two identity directions

People mix these up constantly in reviews. Access entries answer "which AWS identity may use the Kubernetes API?". Pod Identity / IRSA answer "which AWS role may a pod use?". Lesson 06 covers both in depth.

Try it: map a real account

In a sandbox account, with the AWS CLI configured:

  1. Run the commands in the cheat sheet and write down the region, AZs and VPC CIDRs.
  2. For each row of the networking table, find the matching resource in the console (VPC → Subnets, Route tables, NAT gateways, Endpoints).
  3. If a cluster exists, run aws eks describe-cluster and find the endpoint access settings, the authentication mode and the OIDC issuer in the output.

Recap

  • An EKS platform is many AWS services: account and IAM, VPC and subnets, EC2 or Fargate, ELB, ECR, EBS/EFS/S3, KMS, CloudWatch.
  • AWS runs the control plane; you own the data plane, add-on configuration and workloads.
  • Learn the EKS terms (access entries, Pod Identity, IRSA, managed add-ons, prefix delegation, Auto Mode); they come up in every design discussion.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.