Minimalist EKS: The Easy Way

Amazon EKS manages the Kubernetes control plane, but you remain responsible for provisioning the underlying AWS infrastructure, including networking, security groups, IAM roles, and worker nodes. The eksctl command-line tool automates this entire process. Using a clean, declarative syntax, it handles the complex multi-step orchestration across different AWS services that would normally require extensive manual configuration. In this guide, we will use `eksctl` to deploy both the VPC and EKS layers simultaneously, establishing a complete testing sandbox with a single command.  ### About eksctl > “_**eksctl** is a command-line utility tool that automates and simplifies the process of creating, managing, and operating Amazon **Elastic Kubernetes Service** (**Amazon EKS**) clusters. Written in Go, eksctl provides a declarative syntax through YAML configurations and CLI commands to handle complex EKS cluster operations that would otherwise require multiple manual steps across different AWS services._” (source [What is Eksctl?](https://docs.aws.amazon.com/eks/latest/eksctl/what-is-eksctl.html)) ## Tools  These are the tools used in this article. * [AWS CLI](https://aws.amazon.com/cli/) [`aws`]: Interact with AWS services. * [kubectl](https://kubernetes.io/docs/reference/kubectl/) [`kubectl`]: Manage Kubernetes clusters and workloads. * [eksctl](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html) [`eksctl`]: Provision Amazon EKS clusters and supporting infrastructure. Optional: * [helm](https://helm.sh/) [`helm`]: Install and manage Kubernetes applications. ### Verifying Tool Versions This guide has been tested with these tools: ```yaml aws: 2.35.7 kubectl: v1.36.2 helm: v4.2.0 eksctl: 0.227.0 ``` You can verify your versions using a [POSIX Shell](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html), such as [bash](https://www.gnu.org/software/bash/) or [zsh](https://www.zsh.org/): ```bash printf "aws: %s\nkubectl: %s\nhelm: %s\neksctl: %s\n" \ "$(aws --version 2>&1 | awk -F'[/ ]' '{print $2}')" \ "$(kubectl version --client | awk '/Client Version:/ {print $3}')" \ "$(helm version --short | cut -d+ -f1)" \ "$(eksctl version | cut -d- -f1)" ``` ## Prerequisite: AWS Profile Before running the deployment script, you need an AWS CLI profile configured for an IAM identity with sufficient administrative permissions to provision EKS, IAM roles, and VPC infrastructure. **NEVER use your AWS root account for local development**. > 📓 **NOTE**: Recent versions of the AWS CLI (v2.32.0+) support `aws login`, which uses your AWS Management Console credentials to obtain temporary credentials. This eliminates the need to store long-lived static access keys on your machine.. (see [Sign in through the AWS Command Line Interface](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html)) ### 1. Configure the Profile Setting Run the following below to create a config profile block dynamically: ```bash # Define your local variables MY_ACCOUNT_ID="123456789012" # Replace with your real AWS Account ID MY_REGION="us-east-2" mkdir -p ~/.aws # Append the login profile structure to your AWS config file cat <<EOF >> ~/.aws/config [profile myuser] login_session = arn:aws:iam::$ACCOUNT_ID:user/myuser region = $MY_REGION EOF ``` ### 2. Authenticate and Activate Trigger the browser-based authentication handshake: ```bash aws login --profile myuser ``` A browser window will open automatically, prompting you to complete your standard console sign-in. Once authorized, activate the profile in your active shell: ```bash export AWS_PROFILE=myuser ``` ### 3. Verify Your Active Session Confirm that your terminal is actively communicating with AWS using your temporary token: ```bash aws sts get-caller-identity ``` Upon successful connection, the AWS CLI will output your active identity details: ```json { "UserId": "AIDA0123456789EXAMPLE", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/myuser" } ``` If the command returns your metadata, your authentication profile is active and ready to spin up your testing sandbox. ## The Minimalist One-Command EKS Cluster If you want the absolute fastest path to an operational Kubernetes sandbox, you can rely on the native CLI defaults of **`eksctl`**. The following snippet isolates your configuration file, provisions a default public/private network topology, and configures the control plane using a single baseline execution: This is the least amount of steps to create a Kubernetes cluster. ```bash # Set your active profile and environment targets export AWS_PROFILE="myuser" export MY_CLUSTER_NAME="mycluster" export MY_REGION="$(aws configure get region)" # Direct your Kubernetes context to an isolated configuration file mkdir -p $HOME/.kube/aws/ export KUBECONFIG="$HOME/.kube/aws/$MY_REGION.$MY_CLUSTER_NAME.yaml" # Spin up the infrastructure stack eksctl create cluster \ --name $MY_CLUSTER_NAME \ --region $MY_REGION \ --version 1.36 ``` > 🚨 **IMPORTANT SECURITY NOTE**: While this simple deployment is perfect for rapid testing, it relies on legacy permissions mapping. By default, it attaches the broad AWS VPC CNI network policy directly to the underlying worker node’s shared IAM Instance Profile role. This means any standard application pod running on the cluster technically inherits those raw EC2 network management capabilities at the hardware layer. Once the creation process finishes, logging into your AWS Management Console will reveal your newly active cluster topology, complete with healthy control plane paths and managed compute node resources:  To verify the core system components running on your cluster, query all namespaces: ```bash kubectl get all --all-namespaces ``` Running this command displays the baseline networking, metrics, and DNS workloads initialized on the cluster:  ## Deploying a Demo Nginx Application With your cluster up and running, you can verify external traffic routing by deploying a simple Nginx application and exposing it via an AWS Classic Load Balancer (ELBv1): ```bash # Create the Nginx deployment kubectl create deployment demo-lb-app --image=nginx:alpine # Expose the deployment as a Kubernetes LoadBalancer Service kubectl expose deployment demo-lb-app --port=80 --type=LoadBalancer ``` To find the public AWS DNS name assigned to your load balancer, check the status of your services: ```bash kubectl get services ``` This will display the external hostname provisioning in your AWS account:  Copy the address from the `EXTERNAL-IP` field and paste it into a web browser to verify connectivity:  Alternatively, you can query the endpoint directly from your terminal using curl: ```bash # Capture the hostname dynamically DEMO_ADDR=$(kubectl get service demo-lb-app \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' ) # Send an HTTP request to the load balancer curl -i $DEMO_ADDR ``` The command returns the raw HTTP response headers and HTML body from the container:  ## Addendum: Free-Tier EKS Cluster If you are strictly working within the AWS Free Tier, you can provision a minimal single-node cluster using t3.micro instances. > 📓 **NOTE**: The t3.micro instances have severe memory and IP assignment limitations. To make a single micro node usable without running out of pod capacity instantly, you should pass the --zones flag to restrict network placement to two availability zones instead of three (saving NAT gateway overhead costs), and explicitly drop the node count to one: ```bash # Set your environment variables export AWS_PROFILE="myuser" export MY_CLUSTER_NAME="mycluster" export MY_REGION="$(aws configure get region)" # Isolate your Kubernetes configuration file mkdir -p $HOME/.kube/aws/ export KUBECONFIG="$HOME/.kube/aws/$MY_REGION.$MY_CLUSTER_NAME.yaml" # Create a minimal, single-node free tier cluster eksctl create cluster \ --name $MY_CLUSTER_NAME \ --region $MY_REGION \ --zones "${MY_REGION}a,${MY_REGION}b" \ --nodes 1 \ --node-type "t3.micro" ``` > ⚠️ **WARNING**: This configuration is strictly for basic CLI testing and experimentation. Because a t3.micro only supports a maximum of 4 pods per network interface, default system components (like coredns, kube-proxy, and vpc-cni) will consume almost the entire available capacity, leaving minimal room to run custom applications. ## Addendum: Robust Minimalist Cluster For development or short-lived playground clusters, running standard `eksctl create cluster` command line defaults is perfectly adequate. However, for formal test and staging environments, you will want an infrastructure profile that is more robust, secure, and production-like: * **Strict Isolation via Pod Identity**: Only the explicit vpc-cni driver is permitted to modify network configurations, locking out malicious or unprivileged application pods from tampering with AWS routing infrastructure. * **High Availability Architecture**: Three managed worker nodes are automatically calculated and balanced across three distinct Availability Zones (AZs) to prevent single-datacenter outages from dropping your services. * **Native Persistent Storage**: The AWS EBS CSI driver is packaged directly into the cluster lifecycle to easily back stateful application requirements. * **Modern Cost Optimization**: Upgrades compute selections to the modern m6i.large general-purpose instance family (saving on price-per-performance relative to the older m5.large defaults). Instead of managing an endless string of CLI arguments, you can capture these configurations cleanly inside a version-controlled file. Below is a one-touch command that dynamically interpolates your local environment variables into a `ClusterConfig` layout and pipes it directly into the `eksctl` builder: ```bash export AWS_PROFILE="myuser" export MY_CLUSTER_NAME="mycluster" export MY_REGION="$(aws configure get region)" export MY_EKS_VERSION="1.36" eksctl create cluster --config-file /dev/stdin <<EOF apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: $MY_CLUSTER_NAME region: $MY_REGION version: $MY_EKS_VERSION managedNodeGroups: - name: ng-1 instanceType: m6i.large desiredCapacity: 3 minSize: 3 maxSize: 3 labels: alpha.eksctl.io/cluster-name: $MY_CLUSTER_NAME alpha.eksctl.io/nodegroup-name: ng-1 tags: alpha.eksctl.io/nodegroup-name: ng-1 alpha.eksctl.io/nodegroup-type: managed iam: withOIDC: true addonsConfig: autoApplyPodIdentityAssociations: true addons: - name: vpc-cni useDefaultPodIdentityAssociations: true - name: aws-ebs-csi-driver useDefaultPodIdentityAssociations: true - name: eks-pod-identity-agent EOF ``` ## Addendum: Optional Enhancements The default minimalist cluster is sufficient for basic experimentation. If you choose not to use the automated `ClusterConfig` heredoc template from the earlier addendum, you can manually install these individual components via the CLI to support real-world application workloads: ### 1. IAM OIDC Provider If your specific testing tools require legacy IAM Roles for Service Accounts (IRSA) rather than the modern EKS Pod Identity agent, you must manually associate an OpenID Connect (OIDC) identity provider with your cluster: ```bash eksctl utils associate-iam-oidc-provider \ --cluster $MY_CLUSTER_NAME \ --region $MY_REGION \ --approve ``` ### 2. Pod Identity Agent Addon The Pod Identity Agent enables Kubernetes service accounts to access AWS resources using EKS Pod Identity. ```bash eksctl create addon \ --cluster $MY_CLUSTER_NAME \ --region $MY_REGION \ --name eks-pod-identity-agent ``` ### 3. Amazon EBS CSI Driver Addon The EBS CSI Driver allows your cluster to dynamically provision and manage lifecycle storage volumes backed by Amazon EBS. ```bash eksctl create addon \ --cluster $MY_CLUSTER_NAME \ --region $MY_REGION \ --name aws-ebs-csi-driver ``` ## Cleanup To avoid recurring AWS charges after you finish experimenting with your sandbox, delete all provisioned resources using the following command: ```bash eksctl delete cluster --name $MY_CLUSTER_NAME --region $MY_REGION ``` This single command automatically tears down both the EKS compute resources and the underlying VPC network stack.