Here’s a clean, console-only workflow to spin up a current Amazon EKS cluster (Kubernetes 1.33 as of today) and verify it end-to-end. I’ll also point out the 2026-specific gotchas (AL2 deprecation, default add-ons, Pod Identity). Citations sit right after each section.

0) Prereqs (one-time)

• Permissions: You’ll need IAM rights to create EKS clusters, roles, VPC resources, and EC2 node groups.
• Network: Have a VPC with at least 2 subnets in different AZs (3 private + 3 public is the common pattern). EKS requires subnets in ≥2 AZs and recommends using private subnets for nodes. (AWS Documentation)
• Kubernetes version: EKS supports up to v1.33 now (note: v1.32 was the last to support AL2). From 1.33 onward use AL2023 or Bottlerocket for node AMIs. (AWS Documentation)

1) Create the two IAM roles (cluster + node) in the IAM console

A. Cluster role (eksClusterRole)
IAM → Roles → Create role → AWS Service → EKS → EKS – Cluster → Next → name it eksClusterRole → Create. This attaches AmazonEKSClusterPolicy and sets the correct trust policy for eks.amazonaws.com. (AWS Documentation)

B. Node role (AmazonEKSNodeRole)
IAM → Roles → Create role → AWS Service → EC2 → Next → attach:

• AmazonEKSWorkerNodePolicy
• AmazonEC2ContainerRegistryPullOnly (newer name; replaces old ReadOnly in many guides)

Don’t attach AmazonEKS_CNI_Policy here unless you’re intentionally not using IRSA/Pod Identity for the VPC CNI. AWS recommends giving the CNI its own role via IRSA/Pod Identity.
Name it AmazonEKSNodeRole → Create. (AWS Documentation)

2) Create the cluster in the EKS console

EKS console → Clusters → Create cluster:

1. Name: e.g., prod-eks-133
2. Kubernetes version: 1.33 (default/recommended). (AWS Documentation)
3. Cluster service role: eksClusterRole (from step 1A). (AWS Documentation)
4. Secrets encryption (recommended): pick a KMS key for etcd secrets encryption.
5. Networking: choose your VPC and select at least 2 private subnets (add public subnets if you plan internet-facing LBs). EKS requires ≥6 free IPs per subnet (16+ recommended). (AWS Documentation)
6. Cluster endpoint access: “Public and private” (restrict public CIDRs) or “Private only” if you have reachability.
7. Control plane logs (recommended): enable api, audit, authenticator, controllerManager, scheduler.
8. Add-ons: When you create via console, EKS auto-adds VPC CNI, CoreDNS, kube-proxy as EKS add-ons (managed). You can adjust versions post-create. EBS CSI driver is optional here; you can add it later. Create. (AWS Documentation)

Provisioning the control plane takes a few minutes. The doc’s “Create a cluster” page captures the flow and AZ capacity note. (AWS Documentation)

3) Add compute: Managed node group (console)

Cluster → Compute tab → Add node group:

1. Name: mng-al2023
2. Node IAM role: AmazonEKSNodeRole (from step 1B). (AWS Documentation)
3. AMI family: Amazon Linux 2023 (or Bottlerocket) — do not use AL2 on 1.33. (AWS Documentation)
4. Instance type: start with t3.large (adjust to your workloads).
5. Size: min/desired/max (e.g., 2/3/6).
6. Subnets: select the private subnets.
7. Remote access: optional; leave off unless you need SSH.
8. Create and wait for nodes to register.

4) Verify add-ons (console)

Cluster → Add-ons tab:

• Confirm Amazon VPC CNI, kube-proxy, and CoreDNS are Installed.
• Click each and select the Recommended version if an update is suggested.
• (Optional but strongly recommended) Install EBS CSI driver add-on for dynamic PersistentVolumes. (AWS Documentation)

If you’ll publish Services publicly via Ingress/ALB, plan to install the AWS Load Balancer Controller (Helm) and ensure subnets are tagged (kubernetes.io/role/elb=1 for public, …/internal-elb=1 for private). This part is not built-in to EKS by default. (AWS Documentation)

5) (Modern auth) EKS Pod Identity (optional but preferred over classic IRSA)

• Enable the EKS Pod Identity Agent add-on (Cluster → Add-ons → Get more add-ons → EKS Pod Identity Agent → Install).
• Then create Pod Identity associations to map a service account to an IAM role per workload. This is the current recommended path for pods to access AWS APIs, and it simplifies policy reuse. (AWS Documentation)

6) “Check” the cluster (fastest via AWS CloudShell from the console)

From the AWS console header, open CloudShell in the same Region:

# 1) Merge kubeconfig for your cluster
aws eks update-kubeconfig --region <REGION> --name <CLUSTER_NAME>

# 2) See nodes & system pods
kubectl get nodes -o wide
kubectl get pods -A

# 3) Smoke test: run nginx and expose it
kubectl create deploy hello-nginx --image=nginx
kubectl expose deploy hello-nginx --port=80 --type=ClusterIP
kubectl port-forward deploy/hello-nginx 8080:80
# Then in CloudShell "Preview" or curl http://127.0.0.1:8080
Code language: PHP (php)

The update-kubeconfig step and kubectl connectivity are the official flow. (AWS Documentation)

Optional (Service LoadBalancer test):
If you didn’t install the AWS Load Balancer Controller and just want an external IP fast, you can kubectl expose with type=LoadBalancer (this provisions an AWS load balancer via the legacy provider). For production Ingress/ALB, install the AWS Load Balancer Controller and use Ingress resources. (AWS Documentation)

2026 tips & gotchas (read this!)

• Kubernetes 1.33: pick AL2023 or Bottlerocket for nodes (AL2 is not released for 1.33). (AWS Documentation)
• Default add-ons: when created via console, VPC CNI + CoreDNS + kube-proxy are installed as EKS add-ons (managed). Keep them on Recommended versions. (AWS Documentation)
• Subnet tags for ALB: If/when you install the AWS Load Balancer Controller, tag subnets (kubernetes.io/role/elb=1 for public, …/internal-elb=1 for private) or specify subnets on the Ingress annotation. (kubernetes-sigs.github.io)
• Pod to AWS access: Prefer EKS Pod Identity over older IRSA flow for new clusters; install the Pod Identity Agent and create associations per service account. (AWS Documentation)
• Node role policies: Use AmazonEKSWorkerNodePolicy + AmazonEC2ContainerRegistryPullOnly; attach CNI policy via the CNI’s own service account role (IRSA/Pod Identity), not to the node role, unless you intentionally choose otherwise. (AWS Documentation)

Clean up (to avoid costs)

• Delete test resources: kubectl delete deploy/hello-nginx svc/hello-nginx.
• Compute tab → delete Node group(s).
• Cluster → Delete (after node groups are gone).
  General flow and constraints are in the create/cleanup docs. (AWS Documentation)

Jami Raj

MotoShare.in is your go-to platform for adventure and exploration. Rent premium bikes for epic journeys or simple scooters for your daily errands—all with the MotoShare.in advantage of affordability and ease.