Interviewers rarely ask "what is EKS". They ask "ECS or EKS for this team, and why", "how does a pod get AWS permissions", "why are your pods stuck Pending with no IPs", "what happens to a message when the consumer crashes". Each has a precise answer tied to a specific AWS feature. On the job, the same features decide the monthly bill (control plane, NAT, extended support), the upgrade plan (support windows, node group rollouts) and whether a traffic spike turns into a queue backlog or a cold-start storm. The resume this site targets lists EKS, ECS, Aurora, ElastiCache and Cloudflare at the edge; this lesson is that list.

Choosing a compute platform

The honest rule: a team of three with five services should not run EKS; ECS on Fargate gives them rolling deploys, load balancing and logs with a tenth of the surface area. A company with 30 services, several teams, Helm charts and operators needs the Kubernetes API and should pay the EKS tax. Lambda is for the edges of a system (webhooks, S3 triggers, scheduled jobs), not for a long-running API at a steady 500 requests per second, where it costs more than a few Fargate tasks.

ECS: enough for most teams

An ECS cluster is a logical group. A task definition is the unit of deployment: one or more containers with image, CPU and memory, ports, environment, secrets (from Secrets Manager or Parameter Store by ARN), the log driver and the task role (the IAM role the application uses) plus the execution role (the role ECS uses to pull the image and fetch secrets). A task is a running copy. A service keeps N tasks running, registers them in a load balancer target group, and replaces failed ones. The launch type is Fargate (AWS runs the hosts, one task per micro VM, you pick a CPU and memory pair such as 1 vCPU with 2 GB) or EC2 (your instances join the cluster through the ECS agent). Images come from ECR; private subnets need the ecr.api, ecr.dkr and S3 gateway endpoints to pull without a NAT, and Fargate tasks logging with awslogs need the CloudWatch Logs endpoint too.

Rolling updates are controlled by minimumHealthyPercent and maximumPercent (defaults 100 and 200 for a replica service), and the deployment circuit breaker stops a deployment whose tasks keep failing and rolls back to the last good revision. Since July 2025, ECS also has a built-in blue/green strategy with lifecycle hooks, so CodeDeploy is no longer required for it. Service Connect gives tasks a service mesh style DNS name and metrics without a sidecar you manage. The week 30 project is exactly this: push an image to ECR, write a task definition, create a service behind an ALB, and watch it roll.

{
  "family": "api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "1024",
  "memory": "2048",
  "taskRoleArn": "arn:aws:iam::123456789012:role/api-task",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecs-exec",
  "containerDefinitions": [{
    "name": "api",
    "image": "123456789012.dkr.ecr.ap-south-1.amazonaws.com/api@sha256:9f1c2e3a4b5c6d7e8f901234567890abcdef1234567890abcdef1234567890ab",
    "portMappings": [{"containerPort": 8080}],
    "secrets": [{"name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-south-1:123456789012:secret:prod/api/db-AbCdEf"}],
    "healthCheck": {"command": ["CMD-SHELL", "curl -sf localhost:8080/healthz || exit 1"], "interval": 30, "retries": 3},
    "logConfiguration": {"logDriver": "awslogs", "options": {"awslogs-group": "/ecs/api", "awslogs-region": "ap-south-1", "awslogs-stream-prefix": "api"}}
  }]
}

EKS as a product

EKS control plane in an AWS-owned account above a customer VPC that holds a managed node group, a Fargate profile, an ALB created by the load balancer controller, and a Pod Identity path from a pod to an IAM role and on to S3 and SQS

Control plane. EKS runs at least two API server instances and three etcd instances across three AZs, in an account AWS owns, and creates two to four network interfaces in your subnets so it can reach kubelets and admission webhooks. Your subnets must span at least two AZs with at least six free IPs each (16 recommended). The control plane costs a flat hourly fee (an assumed 0.10 USD per hour, about 73 USD a month) and the API endpoint can be public, private, or both; production uses private plus a public endpoint restricted to office and CI ranges.

Versions and support. A Kubernetes minor version gets 14 months of standard support on EKS, then 12 months of extended support at a higher hourly price (an assumed 0.60 USD per hour), and a cluster that is still on the version when extended support ends is upgraded automatically with no notice. Extended support is on by default; turn it off if you would rather be forced to upgrade than pay six times the control plane fee. Upgrade order: control plane one minor at a time, then add-ons, then nodes.

Where nodes come from.

Networking: the VPC CNI. Every pod gets a real VPC IP from the node's subnet. A node can only attach so many network interfaces and each interface only so many IPs, so an m6i.xlarge is capped at a few dozen pods and a cluster can run out of subnet addresses long before it runs out of CPU. Prefix delegation fixes both: the CNI attaches /28 blocks (16 addresses) instead of single IPs, so the pod limit per node rises to the managed node group cap of 110 (250 for instances with 30 or more vCPUs). It needs Nitro instances and contiguous free /28 blocks in the subnet, which is why pod subnets are large and separate.

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
kubectl describe node ip-10-20-5-17.ap-south-1.compute.internal | grep -E 'pods|PrivateIPv4Address'

Identity. Humans and CI get into the cluster through access entries: an IAM principal is mapped to a Kubernetes group or to an AWS access policy (AmazonEKSClusterAdminPolicy, AmazonEKSAdminPolicy, AmazonEKSEditPolicy, AmazonEKSViewPolicy), managed through the EKS API and Terraform, with the authentication mode API or API_AND_CONFIG_MAP. This replaces the aws-auth ConfigMap, whose one typo could lock everyone out. Pods get AWS permissions in one of two ways:

• IRSA (IAM Roles for Service Accounts): the cluster has an OIDC issuer; a role's trust policy names that issuer and the service account; the pod gets a projected token that the SDK exchanges for credentials. Works on Fargate and outside EKS, but every new cluster means editing every trust policy.
• Pod Identity: install the eks-pod-identity-agent add-on, create a role whose trust policy names pods.eks.amazonaws.com once, and create an association between the role and a service account. The agent on each node hands out credentials at 169.254.170.23. Simpler, one trust policy for every cluster, but EC2 nodes only.

aws eks create-pod-identity-association --cluster-name prod \
  --namespace payments --service-account api \
  --role-arn arn:aws:iam::123456789012:role/payments-api

Add-ons. vpc-cni, coredns and kube-proxy are installed on every cluster; aws-ebs-csi-driver (PersistentVolumes on EBS, one AZ each), aws-efs-csi-driver (shared ReadWriteMany), eks-pod-identity-agent, amazon-cloudwatch-observability and adot are AWS add-ons you turn on, and metrics-server, cert-manager, external-dns and kube-state-metrics are community add-ons managed the same way. The AWS Load Balancer Controller is installed with Helm (an IAM policy plus Pod Identity for its service account): an Ingress with ingressClassName: alb becomes an ALB, a Service of type LoadBalancer becomes an NLB, and alb.ingress.kubernetes.io/target-type: ip sends traffic straight to pod IPs across any node. Subnets need the tags kubernetes.io/role/elb=1 (public) and kubernetes.io/role/internal-elb=1 (private) for discovery. Karpenter runs on a small managed node group or Fargate (never on nodes it manages) and launches right-sized instances from a NodePool and EC2NodeClass, with consolidation and Spot interruption handling; Auto Mode is Karpenter run by AWS.

Logging and cost. Control plane logs (api, audit, authenticator, controllerManager, scheduler) are off by default; turn on at least audit and authenticator and they land in /aws/eks/<cluster>/cluster. The bill is control plane plus nodes plus the NAT and load balancers around them; the control plane is the smallest line. eksctl creates a working cluster in one command and is fine for a lab; production clusters are Terraform, so the VPC, IAM, access entries and add-ons are reviewed in a pull request.

Kubernetes concept to AWS resource

Lambda and serverless

A Lambda function is code with a handler, a runtime, memory from 128 MB to 10,240 MB (CPU scales with memory; 1,769 MB is one vCPU), a timeout up to 15 minutes, 512 MB of /tmp by default, and an execution role. A cold start is the time to create a new execution environment and run the initialisation code before the first request; it hits the first request after idle and every new concurrent request during a burst. Concurrency is the number of requests in flight at once, equal to requests per second times average duration in seconds; the default account limit is 1,000 per Region, reserved concurrency fences a function off, and provisioned concurrency keeps environments warm for a charge. API Gateway puts an HTTPS endpoint in front (HTTP APIs are cheaper and simpler; REST APIs add usage plans, API keys, WAF, caching and request validation). EventBridge routes events on a schedule or from AWS services to a function or a queue. The week 33 material is this: a function behind API Gateway, one triggered by an S3 upload, one on a schedule, each with its own role.

Messaging: SQS, SNS, and where streams fit

An SQS standard queue gives at-least-once delivery, best-effort ordering and nearly unlimited throughput; a FIFO queue gives exactly-once processing and strict order within a message group at 300 operations per second per API action (3,000 with batching, more in high-throughput mode). A consumer calls ReceiveMessage with WaitTimeSeconds=20 (long polling, fewer empty responses) and gets a receipt handle. The message is then hidden for the visibility timeout (default 30 seconds, maximum 12 hours); if the consumer deletes it in time it is gone, otherwise it reappears and another consumer gets it. Set the visibility timeout to the longest honest processing time, or extend it with ChangeMessageVisibility as a heartbeat. A redrive policy with maxReceiveCount moves a message that keeps coming back to a dead-letter queue (same type, same account and Region, longer retention than the source), where you inspect it and redrive it when the bug is fixed. Because delivery is at-least-once, handlers must be idempotent.

SNS is fan-out: one publish, many subscribers (queues, Lambda, HTTP, email); SNS into several SQS queues is how one event reaches several services. Redis streams (the week 31 project: workers and pushers) fit when the producer and consumers already share a Redis and you want consumer groups with sub-millisecond latency; Kafka (MSK) fits when you need replayable logs, ordering per partition at high volume, and many consumer groups reading the same history. SQS is the default for work queues on AWS because there is nothing to size or patch.

ElastiCache, CloudFront and the edge

ElastiCache runs Valkey, Redis OSS and Memcached, either serverless or as node-based clusters you size. The common pattern is cache-aside: read the cache, on a miss read the database and write the value back with a TTL so stale data expires on its own; put a small random jitter on TTLs so a thousand keys do not expire together and stampede the database. Cluster mode disabled is one shard with up to 5 replicas, one primary endpoint for writes and a reader endpoint; cluster mode enabled shards the key space across up to 500 shards, each with its own replicas, and clients connect through the configuration endpoint with a cluster-aware library. Use it for sessions, rate-limit counters and hot reads; watch evictions, and never make it the only copy of anything.

CloudFront is the CDN: edge locations cache objects from an origin (S3 with origin access control so the bucket stays private, or an ALB) and serve them close to users; objects stay 24 hours by default unless Cache-Control says otherwise. AWS WAF attaches to CloudFront or an ALB with managed rule sets and rate-based rules; Shield absorbs network-layer DDoS. CloudFront Functions run sub-millisecond JavaScript at the edge on viewer requests and responses (header rewrites, redirects, simple auth); Lambda@Edge runs Node.js or Python on origin requests too, with up to 30 seconds and network access. The pattern on the target resume is a CDN or edge worker (Cloudflare Workers do the same job) in front of the origin: TLS, caching, WAF, rate limiting and bot rules happen before a request reaches the ALB, and the origin only accepts traffic from the CDN.

Secrets Manager through the External Secrets Operator

Application code should not call Secrets Manager directly, and Kubernetes Secrets should not be committed to Git. The External Secrets Operator (ESO) runs in the cluster, authenticates to AWS with Pod Identity or IRSA on its own service account, and syncs a SecretStore or ClusterSecretStore into ordinary Kubernetes Secret objects from ExternalSecret resources, refreshing on an interval so rotation in Secrets Manager reaches the pod on the next restart or reload. With Pod Identity, the store has no auth block at all.

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: aws-secrets-manager
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-south-1
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: api-db
  namespace: payments
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: api-db          # the Kubernetes Secret that gets created
    creationPolicy: Owner
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: prod/api/db      # the Secrets Manager secret name
        property: password    # a key inside its JSON value

One service at 500 requests per second, three ways. The service is a stateless API; each request takes 50 ms of CPU-bound work and about 0.5 GB of memory is resident. A load test shows one 1 vCPU task holds 200 requests per second at 70 percent CPU. Every price below is an assumption for the arithmetic, not a quote.

ECS on Fargate. 500 / 200 = 2.5, so 3 tasks, plus one for an AZ loss and deploy headroom: 4 tasks of 1 vCPU and 2 GB. Assumed Fargate prices: 0.0405 USD per vCPU-hour and 0.00445 USD per GB-hour. One task per hour: 0.0405 + 2 x 0.00445 = 0.0494 USD. Four tasks: 0.1976 USD per hour, times 730 hours = 144 USD per month. Add an ALB (assumed 20 USD plus traffic) and the NAT and endpoints shared with everything else. Scaling: ECS service auto scaling adds a task in about a minute; a bad image is stopped by the circuit breaker.

EKS with managed nodes. The same 4 pods need 4 vCPU and 8 GB; with the CNI, kube-proxy, CoreDNS, a log agent and 30 percent headroom, that is three m6i.large nodes (2 vCPU, 8 GiB each, one per AZ) at an assumed 0.096 USD per hour: 3 x 0.096 x 730 = 210 USD. Add the control plane, an assumed 0.10 USD per hour = 73 USD. Total 283 USD, twice the Fargate number for one service, and that is the point: the cluster's fixed cost is only worth it once ten services share those nodes, at which point the per-service cost falls below Fargate's. Scaling: HPA adds pods in seconds; Karpenter adds a node in 1 to 2 minutes.

Lambda. Concurrency = 500 requests per second x 0.05 s = 25, far below the 1,000 default. Requests per month: 500 x 86,400 x 30 = 1,296,000,000, or 1,296 million. At an assumed 0.20 USD per million: 259 USD. Duration: 1,296,000,000 x 0.05 s x 0.5 GB = 32,400,000 GB-seconds, at an assumed 0.0000166667 USD per GB-second: 540 USD. Total about 799 USD per month, five times Fargate, before API Gateway's per-request charge, and with cold starts on every burst.

The flip. If the same service only takes traffic 2 hours a day, Lambda costs 799 / 12 = 67 USD, while Fargate still pays for at least 2 tasks around the clock (2 x 0.0494 x 730 = 72 USD) or 4 tasks for 2 hours and 2 for 22: about 77 USD. At that point they are equal and Lambda wins on operations. Steady load favours containers; idle time favours functions; many services favour a shared cluster.