Home / AWS

AWSHow-toIntermediate

EKS baseline cluster: private endpoint, managed node groups, Pod Identity and add-ons

Build a production EKS cluster with eksctl, private API access, access entries instead of aws-auth, managed node groups across three AZs, EKS Pod Identity, core add-ons and upgrade hygiene.

Deepak Bhardwaj2 min read

Applies toAmazon EKS 1.30+, eksctl, managed node groups or Karpenter

1. Cluster definition

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: eks-prod, region: ap-south-1, version: "1.30" }
vpc:
  id: vpc-0abc
  subnets:
    private:
      ap-south-1a: { id: subnet-a }
      ap-south-1b: { id: subnet-b }
      ap-south-1c: { id: subnet-c }
  clusterEndpoints: { privateAccess: true, publicAccess: false }
accessConfig:
  authenticationMode: API
managedNodeGroups:
  - name: system
    instanceType: m7i.large
    minSize: 3
    maxSize: 6
    privateNetworking: true
    labels: { role: system }
    taints: [{ key: CriticalAddonsOnly, value: "true", effect: NoSchedule }]
addons:
  - { name: vpc-cni }
  - { name: coredns }
  - { name: kube-proxy }
  - { name: eks-pod-identity-agent }
  - { name: aws-ebs-csi-driver }
cloudWatch:
  clusterLogging: { enableTypes: ["api", "audit", "authenticator"] }
eksctl create cluster -f cluster.yaml

Private-only endpoint means kubectl and CI must run from inside the VPC (or via VPN/Direct Connect).

2. Access entries (not aws-auth)

aws eks create-access-entry --cluster-name eks-prod --principal-arn arn:aws:iam::111122223333:role/AWSReservedSSO_Admin_abc
aws eks associate-access-policy --cluster-name eks-prod --principal-arn arn:aws:iam::111122223333:role/AWSReservedSSO_Admin_abc \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster

3. Pod permissions with EKS Pod Identity

aws eks create-pod-identity-association --cluster-name eks-prod --namespace orders \
  --service-account orders-api --role-arn arn:aws:iam::111122223333:role/orders-api-s3

No node-level IAM permissions for apps; no static keys in secrets.

4. Application capacity

  • Managed node groups across 3 AZs, or Karpenter for flexible, faster scaling.
  • AWS Load Balancer Controller for ALB/NLB ingress.
  • Metrics server + HPA; Container Insights or Managed Prometheus.

5. Upgrades

  • EKS supports each Kubernetes version for a limited standard support period; extended support costs more. Plan at least one upgrade a year.
  • Check deprecated APIs and add-on compatibility first (EKS upgrade insights).
aws eks list-insights --cluster-name eks-prod --filter categories=UPGRADE_READINESS
eksctl upgrade cluster --name eks-prod --version 1.31 --approve

6. Single-cluster scope

One cluster across three AZs survives node and AZ failures when apps use multiple replicas spread across zones. A region outage or a failed upgrade needs a second cluster and GitOps (see the EKS HA and AWS DR posts).