EKS Best Practices

A checklist of habits that keep EKS clusters reliable, secure, and cost-effective.

Bringing the whole tutorial together, here are the practices that separate a hobby cluster from a production-ready one.

Reliability

  • Spread nodes across multiple Availability Zones.
  • Set resource requests and limits on every pod so scheduling and autoscaling work.
  • Use PodDisruptionBudgets so upgrades and scale-downs don't take out too many replicas.

Security

  • Use IRSA, restrict the API endpoint, and encrypt secrets with KMS.
  • Keep the cluster and node AMIs patched and on a supported version.

Cost

  • Autoscale nodes (Karpenter or Cluster Autoscaler) and pods (HPA).
  • Use Spot for fault-tolerant workloads; right-size instance types.

Operations

  • Manage clusters as code (eksctl config, Terraform) and keep them in Git.
  • Enable Container Insights and control-plane logging for observability.

Example

Example · yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web
---
# Always set requests and limits on containers
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

When to use it

  • A platform team applies pod disruption budgets to all production Deployments so node drain during upgrades never takes down more than one replica at a time.
  • A cost team sets resource requests and limits on all pods so the Cluster Autoscaler can accurately calculate node capacity and bin-pack workloads efficiently.
  • A security team runs a monthly review using the EKS Best Practices Guide checklist, closing gaps in RBAC scope, network policies, and secret encryption.

More examples

Set a PodDisruptionBudget

Ensures at least 2 api pods remain running during voluntary disruptions like node drains, protecting availability during upgrades.

Example · yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

Resource requests and limits

Sets CPU and memory requests (for scheduling) and limits (for enforcement) on a container — a baseline best practice for every EKS workload.

Example · yaml
containers:
- name: api
  image: my-api:v1.0
  resources:
    requests:
      cpu: "250m"
      memory: "256Mi"
    limits:
      cpu: "500m"
      memory: "512Mi"

Spread pods across AZs

A topology spread constraint that prevents all api pods from landing in one Availability Zone, improving resilience to AZ failures.

Example · yaml
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: api

Related

eks security best practiceseks container insights

Discussion

  • Be the first to comment on this lesson.
EKS Best Practices — Amazon EKS | SoundsCode