DEV Community

Cover image for ☸️ AWS 143: Enterprise Kubernetes - Provisioning a Private Amazon EKS Cluster
Hritik Raj
Hritik Raj

Posted on

☸️ AWS 143: Enterprise Kubernetes - Provisioning a Private Amazon EKS Cluster

#aws #eks #kubernetes #100daysofcloud

🏗️ Production-Ready K8s: Building the xfusion-eks Cluster

Hey Cloud Architects 👋

AWS EKS

Welcome to Day 43 of the #100DaysOfCloud Challenge!
Today, we are tackling one of the most powerful services in the AWS ecosystem: Amazon EKS. The Nautilus DevOps team is preparing for a new microservices deployment, and they need a cluster that is both highly available and secure. Our mission is to provision a cluster using the latest stable version (1.30) while ensuring the control plane remains completely private.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is my go-to for simulating complex infrastructure scenarios.

🎯 Objective

  • Create an IAM Role named eksClusterRole with the necessary trust relationships.
  • Provision an EKS cluster named xfusion-eks using Kubernetes version 1.30.
  • Configure Networking across three Availability Zones (a, b, and c) for High Availability.
  • Restrict access by setting the Cluster Endpoint to Private.

💡 Why Private Endpoints Matter

By default, EKS cluster endpoints are public. By switching to Private Access, the Kubernetes API server is not accessible from the internet. All communication with the cluster must originate from within your VPC or via a connected network (like a VPN or Direct Connect).

🔹 Key Concepts

  • Control Plane: The managed Kubernetes API server and etcd database that AWS handles for you.
  • IAM Cluster Role: A specific role that allows the EKS service to manage resources (like ELBs or EC2 instances) on your behalf.
  • High Availability (HA): Deploying across multiple AZs ensures that even if one data center goes down, your cluster control plane remains operational.

🛠️ Step-by-Step: Infrastructure Workflow

🔹 Phase A: Identity & Access Management (IAM)

Before creating the cluster, we must define the permissions EKS needs to operate.

  • Create Role: Navigate to IAM and create a role named eksClusterRole.
  • Trusted Entity: Select "EKS - Cluster" as the service that will use this role.
  • Policy: Attach the AmazonEKSClusterPolicy.

🔹 Phase B: Cluster Configuration

Now, we move to the EKS console to define the cluster's "brain."

  • Name: xfusion-eks.
  • Version: Select 1.30 (the latest stable version requested).
  • Service Role: Choose the eksClusterRole we created in Phase A.

🔹 Phase C: Networking & Security

This is the most critical phase for meeting the security requirements.

  • VPC: Select the Default VPC.
  • Subnets: Ensure subnets from AZs us-east-1a, us-east-1b, and us-east-1c are selected.

* Cluster Endpoint Access: Change the radio button from "Public" to Private.

🔹 Phase D: Verification

EKS clusters take about 10–15 minutes to provision.

  • Status Check: Wait until the cluster status changes from Creating to Active.
  • Configuration Audit: Click on the "Networking" tab to verify the endpoint access is indeed set to "Private" and that all three AZs are listed.

✅ Verify Success

  • Cluster Identity: The cluster is named xfusion-eks and running K8s version 1.30.
  • Role Association: The cluster successfully assumed the eksClusterRole.
  • Zero Exposure: The API server has no public URL, confirming the private configuration.

📝 Key Takeaways

  • 🚀 Version Stability: Always use the latest stable version supported by EKS for the best security patches.
  • 🛡️ Network Isolation: Private endpoints are the standard for financial and healthcare sectors to meet compliance.
  • 📦 IAM Dependencies: EKS cannot start without its service role. Always verify the trust relationship if the cluster fails to create.

🚫 Common Mistakes

  • Public Access Enabled: Forgetting to toggle the "Private" endpoint setting exposes your API server to the web.
  • Missing AZs: Selecting only one AZ removes the High Availability benefit of a managed service.
  • Role Permissions: Using a standard EC2 role instead of an EKS Service Role will cause the cluster creation to hang.

🌟 Final Thoughts

You've just provisioned a production-grade Kubernetes control plane! While the setup today was done via the console, these same parameters form the basis of automated Infrastructure as Code (IaC) using Terraform or AWS CDK.

🌟 Practice Like a Pro

Sharpen your Kubernetes skills in a real-world sandbox:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

Top comments (0)