Advisory guidance for Amazon EKS architecture and configuration decisions — compute strategy, networking, security, reliability, cost, autoscaling, observability, multi-tenancy, upgrade planning, on-prem/hybrid (EKS Hybrid Nodes, EKS Anywhere, Outposts), and surge readiness for planned traffic peaks. Also answers Terraform questions about terraform-aws-modules/terraform-aws-eks. Use for any EKS planning or architectural judgment call, even when phrased casually. Do NOT use for generating documents or code (eks-design, eks-build), scoring or auditing a live cluster (eks-operation-review, eks-upgrade-check), discovering what is running (eks-recon), MCP tooling setup (eks-mcp-server), developer platforms/IDPs (eks-platform-engineering), GenAI/LLM workloads — GPU vs Trainium/Inferentia, vLLM/Ray serving, distributed training (eks-genai), or compliance hardening and audit prep — HIPAA/PCI/FedRAMP, CIS benchmarks, GuardDuty, image signing (eks-security) or an x86→arm64/Graviton migration (use graviton-migration).
Advisory guidance for Amazon EKS architecture and configuration decisions — compute strategy, networking, security, reliability, cost, autoscaling, observability, multi-tenancy, upgrade planning, on-prem/hybrid (EKS Hybrid Nodes, EKS Anywhere, Outposts), and surge readiness for planned traffic peaks. Also answers Terraform questions about terraform-aws-modules/terraform-aws-eks. Use for any EKS planning or architectural judgment call, even when phrased casually. Do NOT use for generating documents or code (eks-design, eks-build), scoring or auditing a live cluster (eks-operation-review, eks-upgrade-check), discovering what is running (eks-recon), MCP tooling setup (eks-mcp-server), developer platforms/IDPs (eks-platform-engineering), GenAI/LLM workloads — GPU vs Trainium/Inferentia, vLLM/Ray serving, distributed training (eks-genai), or compliance hardening and audit prep — HIPAA/PCI/FedRAMP, CIS benchmarks, GuardDuty, image signing (eks-security) or an x86→arm64/Graviton migration (use graviton-migration).
EKS Best Practices
Comprehensive guidance for designing, deploying, and operating Amazon EKS clusters. Consolidates guidance from the AWS EKS Best Practices Guide, AWS EKS HA/Resiliency Guide, and terraform-aws-modules/terraform-aws-eks examples.
When to Use This Skill
Activate this skill when:
Designing a new EKS cluster architecture
Choosing between EKS compute options (Fargate, MNG, Karpenter, Auto Mode)
Configuring EKS networking (VPC CNI, ingress, service mesh)
Implementing EKS security (IAM, pod security, secrets)
Planning cluster upgrades or migrations
Reviewing EKS architecture decisions
Working with terraform-aws-modules/terraform-aws-eks examples
Optimizing EKS cost or scaling to large clusters
Don't use this skill for:
Generic Kubernetes concepts (Claude knows these)
Provider-specific API reference (link to AWS docs)
Non-EKS container orchestration (ECS, Lambda)
Step-by-step EKS upgrade execution — this skill covers upgrade strategy and architectural decisions, not the per-version procedures themselves.
EKS Architecture Decision Framework
When to Use EKS
Requirement
EKS
ECS
Lambda
Kubernetes ecosystem
✅ Native K8s
❌ AWS-proprietary
❌
Portable across clouds
✅ Standard K8s API
❌ AWS-only
❌ AWS-only
Long-running services
✅
✅
⚠️ 15 min limit
Minimal ops overhead
Medium
Low
Lowest
GPU/ML workloads
✅ Best support
Limited
❌
Complex networking
✅ Full control
Medium
Limited
Team has K8s expertise
Required
Not required
Not required
EKS Deployment Models
Model
Description
Operational Overhead
Use When
EKS Standard
Full control over nodes, add-ons, networking
Medium-High
Need full customization
EKS Auto Mode
AWS manages nodes, add-ons, scaling
Low
Want minimal ops, standard workloads
EKS with Fargate
Serverless pods, per-pod billing
Low
Batch, low-density workloads
EKS Hybrid Nodes
Your on-prem/edge nodes on an AWS-managed control plane
Medium-High
Reliable Region link; AWS-managed control plane on your own hardware
EKS on Outposts
EKS on AWS-owned hardware in your data center
High
Data residency or low latency; local clusters are disconnect-tolerant (not air-gapped)
EKS Anywhere
You run the control plane and nodes on your own infrastructure
Routing: the advisory question "which on-prem/hybrid model should I choose?" stays in this skill; generating a design document or diagram → eks-design; generating a full production cluster Terraform project or an air-gapped build → eks-build (the hybrid cloud/cluster-side Terraform example itself lives in this skill's terraform-examples.md).
Shared Responsibility
Component
AWS Manages
You Manage
Control plane
API server, etcd, HA, patching
RBAC, admission control, audit logging
Data plane (MNG)
AMI updates, node health
Instance type, scaling, pod scheduling
Data plane (Fargate)
Everything
Pod spec, resource requests
Data plane (Auto Mode)
Node lifecycle, OS patching
Workload definitions
Networking
ENI attachment, VPC CNI releases
Subnet design, IP planning, ingress
Security
Control plane auth
IAM, pod security, secrets, network policies
Compute Selection Matrix
Decision Table
Factor
Fargate
MNG
Karpenter
Auto Mode
Self-Managed
Best for
Batch, small scale
Stable, predictable
Dynamic, varied
Minimal ops
Custom AMI/kernel
Scaling
Per-pod
ASG-based
Fast, flexible
AWS-managed
Manual ASG
Spot support
❌
✅
✅ Native
✅
✅
GPU support
❌
✅
✅
✅
✅
DaemonSets
❌
✅
✅
✅
✅
Cost model
Per vCPU/GB/hr
Per EC2 instance
Per EC2 instance
Per EC2 instance
Per EC2 instance
Max pods/node
1
ENI-based
ENI-based
AWS-managed
ENI-based
Node SSH
❌
✅
✅
❌
✅
Operational
Lowest
Low
Low
Lowest
Highest
Quick Decision Guide
Default choice: Karpenter — best balance of flexibility, cost, and automation
Zero ops priority: EKS Auto Mode — AWS manages nodes, add-ons, and scaling via managed Karpenter. Best for teams that want Kubernetes benefits without operational overhead around upgrades, autoscaling, load balancing, and storage
Serverless/batch: Fargate — no nodes to manage, per-pod billing
AWS-owned hardware for data residency or low latency
Critical rule: split by why the site is disconnected. Permanently air-gapped/isolated → EKS Anywhere (the only fully air-gapped model). A connected site that must keep operating through Region outages on AWS-owned hardware (data residency/sovereignty) → Outposts local clusters (Outposts racks only) — disconnect-tolerant, not air-gapped (IAM/IRSA/KMS/EBS-PV/Route 53 are unavailable offline). EKS Hybrid Nodes and Outposts extended clusters both depend on a reliable connection to an AWS Region.
Create PDBs for every production workload with >1 replica:
Workload
Recommended PDB
Stateless (3+ replicas)
minAvailable: "50%"
Stateful quorum (3)
maxUnavailable: 1
Batch/job
maxUnavailable: "50%"
Singleton
No PDB (would block all disruptions)
Health Probe Strategy
Probe
Purpose
Key Rule
Startup
Wait for slow init
Use for apps >10s startup
Readiness
Traffic routing
✅ Check dependencies here
Liveness
Detect deadlocks
❌ Never check dependencies
Critical rule: Liveness probes must NOT check external dependencies. If the database goes down and liveness checks the DB, ALL pods restart — causing cascading failure.
Native in-place rollback to N-1 is supported within 7 days of an in-place upgrade (all regions; Auto Mode rolls back nodes automatically; rollback into an extended-support version requires setting the cluster upgrade policy to EXTENDED first). update-cluster-version supports type VersionRollback, gated by a ROLLBACK_READINESS insight; add-ons/data-plane roll back separately. Blue-green retains independent rationale for post-7-day windows, multi-minor jumps, and data-plane isolation — not "because you can't roll back."
Data Plane with Karpenter
Karpenter automatically replaces nodes via drift detection after control plane upgrade. Control the speed with disruption.budgets:
disruption:budgets:-nodes:"10%"# Max 10% of nodes replaced at a time
For a planned peak — a flash sale, marketing push, product launch, or seasonal event — the arrival is a near-instantaneous step at a known clock time, so favor scheduled pre-scaling (set floors ahead of the trigger) over relying on reactive autoscaling to catch up. Pre-warm all three layers (control plane, nodes, pods) and hold the floor across the whole event window rather than scaling down between peaks.
Critical rule: A load test that passes on request rate can still miss the failure that hits production — if it never reproduces the resource-consumption pattern (memory working-set, connection count) of the event's actual access patterns, especially for new features. Test consumption shapes, not just throughput, and act on findings before the event.
karpenter (MNG for system + Karpenter for workloads)
Minimal ops
eks-auto-mode
Managed nodes
eks-managed-node-group (AL2023 or Bottlerocket)
Full node control
self-managed-node-group
Platform capabilities
eks-capabilities (ArgoCD, ACK, KRO)
Hybrid/edge
eks-hybrid-nodes
Common Deployment Topologies
Private cluster with Karpenter:
VPC (3 AZs, terraform-aws-modules/vpc/aws)
├── Private subnets → EKS nodes (MNG for system, Karpenter for workloads)
├── Public subnets → ALB (internet-facing)
├── Intra subnets → EKS control plane ENIs
└── NAT Gateway → 1 per AZ for production
EKS Capabilities are AWS-managed features installed and updated as part of the EKS platform. They run in AWS-owned infrastructure separate from your clusters, with AWS handling scaling, patching, and upgrading.
Capability
What It Does
When to Use Managed
When to Self-Manage
ArgoCD
GitOps continuous delivery
Multi-account hub-and-spoke, IAM IDC integration, minimal ops
EKS Auto Mode — Auto Mode architecture, managed NodePools/NodeClasses, migration from standard EKS, comparison with self-managed Karpenter, limitations and FAQ
Hybrid & On-Premises Deployments — EKS Hybrid Nodes, EKS Anywhere, and EKS on Outposts: model-selection decision boundary, per-model networking/CIDR/CNI, disconnection behavior, compute & autoscaling support, identity, lifecycle, and a cross-model support matrix
How to use: When you need detailed information on a topic, reference the appropriate guide. Claude will load it on demand.
