EKS Cluster Architecture: Control Plane, Node Groups, and Endpoint Access Modes

What AWS manages and what you manage

EKS is a managed Kubernetes service, but "managed" applies narrowly to the control plane — the API server, etcd, scheduler, and controller manager. AWS runs these across multiple AZs in an AWS-owned account. You cannot access the control plane nodes directly.

The data plane — the worker nodes that run your actual workloads — runs in your VPC, in your account. You manage it, or you use Fargate to have AWS manage the underlying instances (but you still manage pods, deployments, and resource configurations).

Node group types

Managed node groups (recommended for most workloads): AWS provisions and manages EC2 instances using an EKS-optimized AMI and an ASG. Node upgrades (new AMI for K8s version bump) happen via a managed rolling update — nodes are cordoned, drained, terminated, and replaced. You specify instance type, capacity, and labels/taints; AWS handles the rest.

Self-managed node groups: you manage the EC2 instances directly using your own launch templates. Required if you need custom AMIs, specific boot configurations, or instance types not supported by managed node groups. More operational overhead.

Fargate profiles: workloads matching specific namespace/label selectors run on Fargate instead of EC2 nodes. No node management. Each pod gets dedicated compute. No DaemonSets, no hostPath volumes, and only coredns and some other system pods can run on Fargate (not all EKS add-ons support it).

resource "aws_eks_node_group" "main" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "main"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = aws_subnet.private[*].id

  instance_types = ["m6i.xlarge"]

  scaling_config {
    desired_size = 3
    max_size     = 10
    min_size     = 1
  }

  update_config {
    max_unavailable = 1  # rolling update: 1 node unavailable at a time
  }

  labels = {
    role = "general"
  }

  # Use launch template for custom configurations
  launch_template {
    id      = aws_launch_template.eks_node.id
    version = aws_launch_template.eks_node.latest_version
  }
}

Cluster endpoint access modes

The EKS cluster API endpoint can be public, private, or both. This controls who can reach the Kubernetes API server:

Public (default): the API endpoint is accessible from the internet. Your kubectl commands, CI/CD pipelines, and applications can reach it from anywhere with valid credentials. Convenient, but the API server is internet-exposed.

Private: the API endpoint is only accessible from within your VPC (or peered networks). All kubectl access must go through a bastion host, VPN, or AWS Direct Connect. Required for strict network isolation requirements.

Public and private (recommended): external clients (developers, CI/CD) use the public endpoint; in-cluster nodes use the private endpoint (within VPC, no internet roundtrip). This is the practical default — developer convenience without routing all node-to-control-plane traffic over the internet.

resource "aws_eks_cluster" "main" {
  name     = "production"
  role_arn = aws_iam_role.cluster.arn
  version  = "1.29"

  vpc_config {
    subnet_ids              = concat(aws_subnet.private[*].id, aws_subnet.public[*].id)
    endpoint_private_access = true
    endpoint_public_access  = true
    public_access_cidrs     = ["10.0.0.0/8", "203.0.113.0/24"]  # restrict public endpoint to known CIDRs
  }

  # Enable control plane logging
  enabled_cluster_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"]
}

public_access_cidrs restricts which IP ranges can reach the public API endpoint — your office IPs, CI/CD runner IPs, VPN exit nodes. This significantly reduces the attack surface of the public endpoint.

# List available add-ons for your cluster version
aws eks describe-addon-versions --kubernetes-version 1.29

# Install/update an add-on
aws eks create-addon \
  --cluster-name production \
  --addon-name aws-vpc-cni \
  --addon-version v1.18.0-eksbuild.1 \
  --resolve-conflicts OVERWRITE

IAM access to the cluster

EKS uses two mechanisms to grant IAM principals access to the Kubernetes API:

aws-auth ConfigMap (legacy): maps IAM roles and users to Kubernetes RBAC groups. The creator of the cluster gets automatic system:masters access; everyone else must be added to aws-auth.

EKS Access Entries (recommended, EKS 1.28+): manage IAM-to-Kubernetes access via the EKS API rather than a ConfigMap. Less error-prone — a misconfigured aws-auth ConfigMap can lock you out of your cluster.

# Add access entry (new API)
aws eks create-access-entry \
  --cluster-name production \
  --principal-arn arn:aws:iam::123456789012:role/DeveloperRole \
  --type STANDARD

aws eks associate-access-policy \
  --cluster-name production \
  --principal-arn arn:aws:iam::123456789012:role/DeveloperRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=namespace,namespaces=default,staging