Deployments, services and config

Running workloads on EKS uses the same Kubernetes objects you learned in the DevOps Foundation — Deployments, Services, ConfigMaps, Secrets. This lesson does not re-teach those; it focuses on what is different when those workloads run on EKS: how config and secrets integrate with AWS, how pods get AWS permissions, and the few AWS-specific choices that come up. If the Foundation's Kubernetes module is fresh, this lesson slots straight on top of it.

The workloads themselves are unchanged

First, the reassuring part: a Deployment, Service, ConfigMap or Secret you write for EKS is identical to one you would write for any Kubernetes cluster. kubectl apply -f deployment.yaml works the same, desired-state reconciliation works the same, self-healing works the same. EKS is real Kubernetes, so all your Foundation knowledge transfers directly — you declare the state you want and Kubernetes maintains it. What follows is only the AWS-specific additions to that.

Pods getting AWS permissions: IRSA

The most important EKS-specific pattern is giving your pods AWS permissions without keys — the machine- access problem from the foundations module, solved for Kubernetes. A pod often needs to call AWS services (read from S3, a queue, Secrets Manager), and it must do so with least privilege and no stored credentials.

IAM Roles for Service Accounts (IRSA) (and its newer sibling, EKS Pod Identity) solves this: you map a Kubernetes service account to an IAM role, and any pod using that service account automatically gets temporary AWS credentials for that role — no access keys anywhere.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/app-s3-read   # the IAM role this SA assumes
---
# a pod using serviceAccountName: app gets that role's temporary AWS credentials automatically

The pod's AWS SDK picks up the temporary credentials with no configuration. This is the Kubernetes equivalent of an EC2 instance role, and it is how you give each workload exactly the AWS permissions it needs (least privilege — the IAM lesson) with zero long-lived secrets. Getting IRSA right is a defining EKS skill: it is how your containerised apps talk to AWS securely.

Config and secrets: Kubernetes plus AWS options

Config and secrets work as in the Foundation — ConfigMaps for non-sensitive config, Secrets for sensitive values, injected as environment variables — but EKS gives you AWS-integrated options worth knowing:

ConfigMaps and Kubernetes Secrets work exactly as taught; on EKS you can also encrypt Kubernetes Secrets at rest using a KMS key (envelope encryption), closing the "Secrets are only base64-encoded" gap from the Foundation.
AWS Secrets Manager / Parameter Store integration. Rather than storing real secret values as Kubernetes Secrets, many teams keep them in AWS Secrets Manager or SSM Parameter Store (the pipelines module's secrets lesson) and pull them into pods via the Secrets Store CSI driver or External Secrets Operator. The real secret lives in a managed secrets store; the cluster fetches it at runtime. This is the "values live in a secrets manager, references live in your config" principle (the DevOps Foundation) realised on EKS.

So on EKS you have a choice: plain Kubernetes Secrets (encrypted with KMS), or sourcing secrets from AWS's managed stores. For anything sensitive in production, sourcing from a managed store (with IRSA controlling access to it) is the stronger pattern.

Storage and networking touches

Two more AWS-specific integrations you will meet when running real workloads:

Storage. A pod needing persistent storage uses a PersistentVolumeClaim (standard Kubernetes), and on EKS the EBS CSI driver provisions a real AWS EBS volume to back it (or the EFS CSI driver for shared storage). So Kubernetes persistence maps onto AWS block/file storage automatically — you request a volume, AWS provides one.
Pod networking. Because of the VPC CNI (the previous lesson), pods have real VPC IP addresses and are subject to VPC routing and (optionally) security groups. This means your Kubernetes workloads participate in the AWS network you designed (private subnets, endpoints) rather than a separate overlay — the networking module's design applies to your pods directly.

Check your work

Workloads are unchanged: Deployments/Services/ConfigMaps/Secrets on EKS are identical to any Kubernetes; all Foundation knowledge (apply, desired-state, self-healing) transfers. Only the AWS additions differ.

IRSA (the key EKS pattern): map a Kubernetes service account → an IAM role (via the eks.amazonaws.com/role-arn annotation); pods using it get temporary AWS credentials automatically — least privilege, no stored keys. The Kubernetes equivalent of an instance role; how your apps call AWS securely.

Config/secrets: ConfigMaps/Secrets as taught, plus EKS options — encrypt Kubernetes Secrets at rest with KMS, or source real secrets from AWS Secrets Manager / Parameter Store via the Secrets Store CSI driver / External Secrets Operator (values in the managed store, references in config; access controlled by IRSA). Prefer the managed store for production secrets.

Storage/networking: a PVC is backed by a real EBS volume via the EBS CSI driver (EFS for shared); the VPC CNI gives pods real VPC IPs, so workloads participate in your designed AWS network directly.

Practice

Explain why a Deployment written for EKS is identical to one for any Kubernetes cluster.
Explain IRSA: how a pod gets AWS permissions with no keys, and what you annotate.
Write a ServiceAccount annotated for an IAM role and explain how a pod uses it.
Compare storing secrets as Kubernetes Secrets versus sourcing them from AWS Secrets Manager on EKS.
Explain how a PersistentVolumeClaim maps onto AWS storage on EKS.
Explain how the VPC CNI makes your pods part of the AWS network you designed.

Official documentation

AWS — IAM roles for service accounts (IRSA) — Giving pods AWS permissions without keys.
AWS — EKS and Secrets Manager (CSI driver) — Sourcing secrets from a managed store.
AWS — EBS CSI driver — Persistent storage for pods on EKS.

Next: ingress, load balancers and TLS.