Practice: AWS and EKS foundations for an ML platform
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: AWS EKS · The lesson is about the identity, networking, compute and storage decisions specific to a managed Kubernetes control plane on AWS, and those can only be practised against a real EKS cluster. · Alternatives: Google GKE and Azure AKS are the managed Kubernetes services of the other two big clouds with their own identity and networking models; self-managed Kubernetes with kubeadm or kOps gives full control of the control plane at the cost of running it; Amazon ECS is simpler but is not Kubernetes; Amazon SageMaker AI hides the cluster behind a managed ML service; kind or minikube run Kubernetes free on a laptop but have no AWS identity, networking or storage integrations.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Sign up for an AWS account and set a small monthly budget alert, since EKS has no free local mode and the control plane bills by the hour.
Every later step needs an account, and a budget alert keeps a forgotten practice cluster from becoming a surprise bill.
Explained in: What is Amazon Elastic Container Registry? - Amazon ECR (docs.aws.amazon.com), checked 2026-10-11
Done when: You can sign in to the AWS console and a budget alert shows in the billing pages.
2. Create an administrator IAM identity for daily work and stop using the root user.
EKS records the identity that creates a cluster, so starting with a proper IAM identity avoids access problems later.
Explained in: What is IAM? - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: The AWS CLI identity check returns your administrator identity and not the root user.
3. Install the AWS CLI, kubectl and eksctl on your laptop, plus kind as a free local cluster for rehearsing the pure Kubernetes parts.
These are the command line tools the getting started guides assume, and a local cluster lets you rehearse manifests without paying for AWS time.
Explained in: Get started with Amazon EKS - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: Each tool prints its version and kubectl can reach the local kind cluster.
Steps
1. Create your first EKS cluster by following one getting started guide end to end; this needs the paid AWS account, so rehearse the kubectl parts on kind first and delete the cluster when you stop for the day.
A first working cluster gives you something real to inspect in every later step. Doing it by the guide shows which resources are created on your behalf.
Explained in: Get started with Amazon EKS - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: kubectl lists nodes in the Ready state and a sample workload is running on the EKS cluster.
2. Query the cluster from the console and from kubectl, and write a two-column list of what you can see and change versus what AWS runs for you.
The split between the managed control plane and your workloads, nodes and integrations is the first subtopic of the lesson. Seeing that you cannot list control plane machines makes the split concrete.
Explained in: What is Amazon EKS? - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a written list that places the API server, etcd, nodes, add-ons and workloads on the AWS side or on your side.
3. Write five review questions for your cluster, one per pillar you care about, taken from the Well-Architected Machine Learning Lens introduction.
The lens is the review framework for the design you are about to build. Writing the questions now gives you a checklist to answer at the end.
Explained in: Machine Learning Lens - AWS Well-Architected Framework - Machine Learning Lens (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a saved list of review questions tied to the ML lifecycle phases the lens describes.
4. Query the EC2 instances behind your nodes and record their instance type, purchase option, attached volumes and security groups.
EKS nodes are ordinary EC2 instances, and ML cost and performance are decided by instance choice. On kind the nodes are containers, so this step needs the real cluster.
Explained in: What is Amazon EC2? - Amazon Elastic Compute Cloud (docs.aws.amazon.com), checked 2026-10-11
Done when: You can match each Kubernetes node name to one EC2 instance and state its type and storage.
5. Create an IAM role with a policy that allows read-only access to a single S3 bucket holding a small sample dataset.
Pods get AWS access through IAM roles, so you need to be fluent with roles, policies and trust before wiring them to Kubernetes. A narrow policy is the habit an ML platform needs.
Explained in: What is IAM? - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: The role exists, and a policy simulation or test call shows read on that bucket is allowed and write is denied.
6. Compare the EKS compute options in a table for three ML workloads: a batch training job, an always-on inference service and a notebook, and choose one option for each.
Node strategy is where ML platforms spend most of their money and operational effort. The comparison table in the documentation lists what each option manages for you.
Explained in: Manage compute resources by using nodes - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a written choice per workload with the reason, including who patches the nodes and how GPU nodes would be handled, even though you do not launch any GPU.
7. Configure a Kubernetes service account to assume the read-only role with EKS Pod Identity, run a pod that lists the bucket, then compare the setup with IRSA.
Identity for pods is a lesson subtopic and the usual cause of access denied errors in ML jobs. Comparing both mechanisms tells you which one to standardise on; kind cannot do this, it needs the real cluster.
Explained in: Grant Kubernetes workloads access to AWS using Kubernetes Service Accounts - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: A pod using the service account lists the bucket, a pod without it is denied, and you can state two differences between Pod Identity and IRSA.
8. Query the network interfaces in the cluster VPC and identify which ones were created by EKS for the control plane and which belong to nodes and pods.
VPC networking for EKS is easiest to understand by looking at the interfaces and subnets it actually uses. Pod IP addresses come out of your subnets, so large ML jobs can exhaust them.
Explained in: Requester-managed network interfaces - Amazon Elastic Compute Cloud (docs.aws.amazon.com), checked 2026-10-11
Done when: You can point to the requester-managed interfaces, name their subnets, and count the free IP addresses left in each node subnet.
9. Create a private ECR repository, package a small CPU-only model server as a container image, push it, and run it on the cluster from that repository.
Every training and serving workload on the platform ships as an image, and ECR is the registry the nodes pull from with IAM. This is the package and register stage of the arc.
Explained in: What is Amazon Elastic Container Registry? - Amazon ECR (docs.aws.amazon.com), checked 2026-10-11
Done when: The image tag appears in the repository and a pod on the cluster pulls it and reaches the Running state.
10. Create a second cluster with EKS Auto Mode from a saved configuration file kept in version control, and update your responsibility list for it; this again needs the paid account.
A cluster defined in a file can be reproduced and reviewed, which is the automation stage. Auto Mode moves node, networking and storage components to the AWS side, so the split changes.
Explained in: Automate cluster infrastructure with EKS Auto Mode - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: Deleting and recreating the cluster from the file gives the same result, and your list shows which duties moved to AWS.
11. Configure the cluster authentication mode to use access entries and grant a second IAM role read-only access to one namespace.
Human and CI access to the Kubernetes API should be declared and repeatable, not tied to whoever created the cluster. This is the access pattern a platform team automates.
Explained in: Grant IAM users and roles access to Kubernetes APIs - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: Assuming the second role lets you list pods in that namespace and denies you everywhere else.
12. Configure a production-like cluster from your file: restricted API endpoint access, control plane logging, a planned version upgrade, and the settings from the earlier steps, then answer your lens review questions against it.
Production clusters are defined by their lifecycle and configuration choices, not by the first create command. Closing with the review questions ties the design back to the Well-Architected Machine Learning Lens.
Explained in: Amazon EKS cluster lifecycle and configuration - Amazon EKS (docs.aws.amazon.com), checked 2026-10-11
Done when: The cluster is recreated from the file with those settings, one version upgrade has completed, every review question has a written answer, and all practice clusters are deleted afterwards.