Amazon EKS Production Architecture: Cluster, Nodes, Networking, Security and Operations

How I think about EKS

EKS gives a managed Kubernetes control plane. It does not remove responsibility for:

worker capacity
networking
ingress
IAM
pod security
upgrades
observability
autoscaling
cost
application readiness

A simplified production topology:

Route53
  |
ALB / Ingress
  |
EKS Service
  |
Pods across AZs
  |
Managed Node Groups
  |
private subnets

Databases and managed services remain outside the cluster when appropriate.

Multi-AZ worker capacity

I spread worker nodes across availability zones.

AZ-A node group
AZ-B node group
AZ-C node group

Applications use topology spread/anti-affinity for critical replicas.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: booking

Ingress

AWS Load Balancer Controller can create ALBs from Kubernetes ingress resources.

I separate public and internal ingress classes/security groups.

Not every service needs a public load balancer.

IRSA / workload identity

A pod that needs S3 should not receive the entire node IAM role.

I use service-account identity:

Kubernetes ServiceAccount
        |
        v
IAM Role
        |
only required AWS permissions

This reduces credential blast radius.

Node groups

Different workloads may need different capacity:

general on-demand
memory optimized
spot workers
GPU nodes

I use taints/tolerations to keep special workloads on intended nodes.

Cluster autoscaler / Karpenter-style capacity

HPA adds pods.

If pods cannot schedule, cluster/node autoscaling adds capacity.

These are separate loops.

traffic increases
 -> HPA requests more pods
 -> no node capacity
 -> node autoscaler provisions node
 -> pods schedule

I monitor pending-pod time because autoscaling is not instantaneous.

Upgrades

Kubernetes/EKS versions have support windows.

Upgrade plan:

API deprecation scan
addon compatibility
test non-prod
control plane upgrade
node group rollout
workload validation

I do not discover removed APIs during production upgrade.

Network/security

I combine:

• private worker subnets;
• security groups;
• NetworkPolicy where enforced;
• restricted pod security;
• non-root images;
• secrets integration;
• IRSA;
• controlled egress.

Observability

Cluster signals:

node pressure
pending pods
OOMKilled
CPU throttling
pod restarts
API server errors
ingress 4xx/5xx
HPA desired/current
node provisioning time

Application signals remain separate.

Cost

Important EKS cost drivers:

• underutilized nodes;
• over-requested CPU/memory;
• NAT gateway egress;
• one ALB per service;
• large log retention;
• cross-AZ traffic;
• idle environments.

I review requests vs actual usage.

Production checklist

• Multi-AZ.
• Private workers.
• Managed node groups/controlled provisioning.
• IRSA.
• Ingress separation.
• Resource requests/limits.
• Pod disruption budget.
• Topology spread.
• Network/security policy.
• Cluster + app observability.
• Upgrade calendar.
• Capacity/cost review.

FAQ

EKS vs ECS Fargate?

EKS provides Kubernetes ecosystem and flexibility; ECS Fargate reduces platform operational complexity.

Should databases run inside EKS?

They can, but I usually prefer mature managed database services for enterprise transactional data unless there is a strong reason otherwise.

Is managed control plane enough for HA?

No. Workload replicas, nodes, zones, ingress and dependencies still require HA design.

Related architecture guides

• Kubernetes Primitives

• Kubernetes Production Readiness

  Architect's final take

  EKS removes control-plane operations, not architecture responsibility. The production work is still in workload isolation, networking, identity, capacity and observability.