Amazon EKS Deployment Tips for Reliable Application Launches

Start with the workload, not the cluster

Most failed launches on Amazon EKS are not cluster problems. They come from workloads that Kubernetes cannot manage well: Pods that report ready before they can serve traffic, containers without resource requests, or deployments that take every replica down at once. The settings below are standard Kubernetes, and they matter more on EKS than anywhere else because nodes come and go through autoscaling, upgrades and Spot interruptions.

Health probes that tell the truth

Kubernetes uses three probes, and each answers a different question:

• Readiness probe: can this Pod receive traffic now? Failing it removes the Pod from Service endpoints without restarting it.
• Liveness probe: is this container stuck? Failing it restarts the container. Keep it simple and do not check downstream dependencies, or one slow database can restart your whole fleet.
• Startup probe: has the application finished starting? Liveness and readiness checks wait until it succeeds, which protects slow-starting applications from being killed during startup.

containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/api:1.4.2
    ports:
      - containerPort: 8080
    startupProbe:
      httpGet: { path: /healthz, port: 8080 }
      failureThreshold: 30
      periodSeconds: 5
    readinessProbe:
      httpGet: { path: /ready, port: 8080 }
      periodSeconds: 5
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 10

Resource requests and limits

The scheduler places Pods based on their requests, and node autoscalers decide how many nodes to add based on them too. Pods without requests get packed onto nodes that cannot actually run them. Set CPU and memory requests from observed usage, set a memory limit to contain leaks, and be careful with CPU limits, which throttle a container even when the node has spare capacity.

    resources:
      requests:
        cpu: 250m
        memory: 512Mi
      limits:
        memory: 512Mi

Setting the memory request equal to the memory limit makes out-of-memory behavior predictable. A LimitRange per namespace can supply defaults for teams that forget.

Rolling updates and graceful shutdown

A Deployment’s rolling update strategy controls how many Pods can be added or removed during a release:

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

With maxUnavailable: 0, Kubernetes only removes an old Pod after a new one passes its readiness probe. Pair this with graceful shutdown: your application should handle SIGTERM by finishing in-flight requests, and terminationGracePeriodSeconds (30 seconds by default) must be long enough for that. If you use the AWS Load Balancer Controller with IP targets, a short preStop sleep gives the load balancer time to deregister the Pod before it stops accepting connections.

PodDisruptionBudgets

Rolling updates protect you during your own deployments. A PodDisruptionBudget (PDB) protects you during everyone else’s: node drains for managed node group updates, Karpenter consolidation, EKS Auto Mode node replacement and cluster upgrades all use the Eviction API, which respects PDBs.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

Do not set a PDB that allows zero disruptions (for example, minAvailable equal to the replica count). It blocks node drains, and managed node group updates fail with a PodEvictionFailure error when Pods cannot be evicted. Spread replicas across Availability Zones with topologySpreadConstraints so that one zone failure does not take out every replica.

Secrets: keep them out of ConfigMaps

ConfigMaps are for non-sensitive configuration. Secrets belong in a secret store, delivered to Pods with workload identity rather than long-lived keys. Two common patterns on EKS:

• AWS Secrets and Configuration Provider (ASCP) for the Secrets Store CSI Driver. Pods mount secrets from AWS Secrets Manager or parameters from AWS Systems Manager Parameter Store as files, using EKS Pod Identity or IAM roles for service accounts to authorize access. See Use AWS Secrets Manager secrets in Amazon EKS.
• External Secrets Operator. An open source controller that reads from Secrets Manager or Parameter Store and creates native Kubernetes Secrets, which suits applications that expect environment variables.

Kubernetes Secrets themselves are envelope encrypted with AWS KMS on EKS clusters running Kubernetes 1.28 or later, as described in default envelope encryption. Encryption at rest does not replace RBAC, though: restrict who can read Secrets in each namespace.

Pod Security Admission, not Pod Security Policies

PodSecurityPolicy was removed from Kubernetes in version 1.25. Its replacement is the built-in Pod Security Admission controller, which applies the Pod Security Standards (privileged, baseline, restricted) per namespace with labels:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Start with warn and audit to find violations, then switch on enforce. For rules beyond the Pod Security Standards, such as allowed registries or required labels, use a policy engine like Kyverno or OPA Gatekeeper.

Autoscaling at two levels

Pods and nodes scale separately:

• Horizontal Pod Autoscaler (HPA) changes the replica count based on CPU, memory or custom metrics. It needs the Kubernetes Metrics Server for resource metrics, and it only works well when requests are set correctly.
• Karpenter watches for unschedulable Pods and launches right-sized EC2 instances for them, then consolidates underused nodes. EKS Auto Mode includes Karpenter-based autoscaling as a managed component.
• Cluster Autoscaler scales existing Auto Scaling groups, such as managed node groups, up and down. It remains a valid choice when you want fixed, predefined node groups.

Test scale-out before launch day. Load tests reveal limits such as subnet IP exhaustion, EC2 service quotas and slow image pulls long before real users do.

Progressive delivery

A rolling update sends every user to the new version once Pods are ready. For higher-risk releases, progressive delivery shifts traffic gradually and checks metrics before going further. Argo Rollouts and Flagger are open source controllers that implement canary and blue/green strategies on Kubernetes, with automated rollback when error rates or latency cross a threshold. Combine them with GitOps tools such as Argo CD or Flux so every release is a reviewed change in Git and a rollback is a revert.

A pre-launch checklist

• Probes defined and tested, with liveness kept separate from dependency checks.
• Requests set from real measurements; memory limits in place.
• Rolling update settings and graceful shutdown verified under load.
• PDBs and topology spread constraints on every multi-replica workload.
• Secrets in Secrets Manager or Parameter Store, accessed through Pod Identity or IRSA.
• Pod Security Admission labels on every application namespace.
• HPA and node autoscaling tested with a realistic load test.
• Observability in place: logs, metrics and alarms for error rates and latency.

9Acts is an AWS Advanced Tier Services Partner and holds the AWS DevOps Competency. If you are preparing a production launch on Amazon EKS, see our DevOps services or contact us.