The EKS cluster you inherited runs on defaults.

AWS’s own docs say it plainly: “By default, this API server endpoint is public to the internet.” Access is still authenticated — IAM plus RBAC — but the front door of your cluster’s control plane answers to the whole internet, which means credential mistakes, token leaks, and future auth CVEs are internet-exploitable instead of VPC-exploitable. Most teams never revisit it, because the cluster worked on day one and the endpoint setting lives in a console tab nobody opens twice.

# a fresh cluster's endpoint access
endpointPublicAccess  = true◂ the control plane answers the internet
endpointPrivateAccess = false
publicAccessCidrs     = 0.0.0.0/0

“By default, cluster control plane logs aren’t sent to CloudWatch Logs.” All five log types — api, audit, authenticator, controllerManager, scheduler — ship turned off. That means no audit trail of who did what to the cluster, no authenticator record of which IAM identity became which Kubernetes user, and no API-server logs when you’re debugging a webhook that’s rejecting everything. The first time most teams enable audit logging is the day they need last month’s audit log, which is exactly the day it doesn’t exist.

# a fresh cluster's logging config
clusterLogging: api            = off◂ all five types ship OFF
clusterLogging: audit          = off◂ "who deleted it?" — no record
clusterLogging: authenticator  = off
clusterLogging: controllerManager = off
clusterLogging: scheduler      = off

Kubernetes doesn’t require resource requests or limits, so the deployment everyone copies ships without them — and every such pod runs in the BestEffort QoS class. Two consequences, both silent. The scheduler packs blind: with no requests, it can’t know a node is full, so it stacks heavy pods together and lets them fight. And under node memory pressure, BestEffort pods are the first the kubelet evicts — your production service is, by definition, the sacrifice the system makes to save itself. The cluster looks fine until the day one noisy neighbour makes it look haunted.

# the deployment everyone copies
containers:
  - name: api
    resources: {}◂ BestEffort — first against the wall

The VPC CNI’s default mode assigns every pod its own secondary IP address from your subnet, one at a time. Two failure shapes ship with that default. In small subnets — the /24s everyone carves — the subnet exhausts long before the nodes do: CPU sits free while pods hang in ContainerCreating because there is literally no IP to give them. And per AWS’s own docs, the default mode “must make more Amazon EC2 API calls to configure network interfaces and IP addresses,” so exactly when a spiky workload scales, pod launches slow down behind EC2 API throttling. Prefix delegation — the fix — exists, is documented, and is off until you turn it on.

# amazon-vpc-cni defaults
ENABLE_PREFIX_DELEGATION = false◂ one EC2 IP per pod, one at a time
WARM_ENI_TARGET          = 1

Kubernetes ships no PodDisruptionBudgets — they’re opt-in, per workload, and the tutorials skip them. Without one, a voluntary disruption (node drain, managed node-group upgrade, Karpenter consolidation) is allowed to evict every replica of your service at once; three replicas on two draining nodes is an outage the platform considers polite. The cruel part: everything is working as designed, every eviction was “graceful,” and the postmortem finds no failure — just an upgrade that walked through your quorum.

# what protects your 3-replica service during a drain
PodDisruptionBudget: none◂ all replicas evictable simultaneously

A fresh EKS cluster includes no metrics-server, no HorizontalPodAutoscaler targets that can work without it, and no node autoscaler — neither Cluster Autoscaler nor Karpenter comes installed. So the “elastic” cluster everyone inherited is a fixed pool of nodes wearing a Kubernetes costume: HPA objects (if anyone created them) sit broken for lack of metrics, and when load exceeds the node group, pods pend until a human buys capacity. Teams discover this precisely once.

# what a fresh cluster ships for scaling
metrics-server        = not installed◂ HPA has no signal
node autoscaler       = not installed◂ pods pend; nobody buys nodes

Kubernetes networking is default-allow: with no NetworkPolicies, any pod can reach any pod in any namespace — the payments service answers connections from the marketing microsite’s sidecar. Nothing enforces the architecture diagram’s neat arrows; they’re documentation, not policy. One compromised pod is a flat east-west network away from everything else you run, and the cluster you inherited almost certainly has zero policies, because zero is what ships.

# east-west traffic control, out of the box
NetworkPolicy objects = 0◂ default-allow, cluster-wide

EBS volumes are zonal, and a pod bound to an EBS-backed PersistentVolume can only ever run in that volume’s availability zone. Lose the node — or just the AZ’s spare capacity — and the pod sits Pending with “volume node affinity conflict” while its data waits in an AZ that can’t host it. Multi-AZ node groups make this worse, not better: the scheduler happily created the volume wherever the first pod landed, and that accident is now a permanent placement constraint.

# the constraint nobody declared
EBS volume zone = us-east-1a◂ the pod is now zonal, forever
volumeBindingMode: WaitForFirstConsumer   # use this — binds where the pod schedules