EKS Production Checklist: From Cluster to Deployment

Setting up a basic cluster on Amazon EKS (Elastic Kubernetes Service) takes just a few minutes using eksctl or Terraform. However, architecting a cluster capable of hosting secure, auto-scaling, production workloads requires careful planning.

Below is a production checklist covering security, networking, scaling, and observability.

---

1. Network & Security Isolation

• Private Endpoints: Keep the Kubernetes API server endpoint private. Use a VPN or Bastion host within your VPC to connect to the cluster.
• IAM Roles for Service Accounts (IRSA): Never assign IAM policies to EKS node instance roles. Instead, bind specific IAM roles directly to Kubernetes ServiceAccounts.
• Network Policies: Use the AWS VPC CNI with network policies enabled to restrict pod-to-pod communication.

Here is a Kubernetes YAML manifest showing a network policy that restricts access to a database service to only pods with a specific label:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-only-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: rds-database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend-api
    ports:
    - protocol: TCP
      port: 5432

---

2. Cluster Autoscaling & Right-Sizing

For production, do not use the old Cluster Autoscaler. Instead, adopt Karpenter, the modern, high-performance node provisioning engine for Kubernetes. Karpenter starts nodes in seconds and dynamically aggregates workloads to save costs.

To keep nodes stable, always configure resource limits on your deployments:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"

3. Observability

• Metrics Collection: Install Prometheus and write alerts for pod restarts and pending statuses.
• Log Routing: Deploy Fluentbit as a DaemonSet to ship container stdout logs to Amazon CloudWatch Logs or OpenSearch.
• Tracing: Instrument critical services using AWS X-Ray or OpenTelemetry to map database and microservice latency bottlenecks.