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.
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:
- Run the commands in the cheat sheet and write down the region, AZs and VPC CIDRs.
- For each row of the networking table, find the matching resource in the console (VPC → Subnets, Route tables, NAT gateways, Endpoints).
- If a cluster exists, run
aws eks describe-clusterand 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.