Best AWS EC2 Instance for Kubernetes Worker Nodes
For Kubernetes worker nodes in production, **m7g.large** at $0.0816/hr (~$59/mo) hits the sweet spot of price, density, and architectural fit. Two vCPUs and 8GB of RAM is a good balance — enough capacity for kubelet's overhead (typically 0.5-1 GB of RAM) plus a meaningful number of application pods, while small enough that you can run a node pool of several instances for blast-radius isolation. Graviton3 (the "g" in m7g) gives you 20-30% better price/performance than the equivalent Intel m7i.
The most important "don't" with Kubernetes workers: don't use t-series burstable instances for production. It's tempting because they're cheap, but kubelet, kube-proxy, the CNI plugin (Calico, Cilium, AWS VPC CNI), and the container runtime all consume CPU continuously even when your pods are idle. You will burn through CPU credits faster than you earn them, and the resulting throttling shows up as mysterious latency spikes across every pod on the affected node. Use t-series for dev clusters where short-lived load is the norm and the credit budget recovers between deploys.
Graviton requires a small commitment from your workloads: every container image needs to be multi-arch (or have a separate arm64 build), and you need to verify any compiled binaries or platform-specific dependencies. The good news is that the major orchestration tools (kubectl, helm, istio, argo, all CNI plugins) ship arm64 builds today. The harder part is your own application stack — Java works fine, Go cross-compiles trivially, Node.js has full arm64 support, but Python wheels with C extensions or Rust crates with specific architecture targets need verification.
For mixed workloads, the right architecture is multiple node groups: an m-series node group for typical application pods, and a c-series node group for CPU-intensive batch jobs or build pods. Use taints and tolerations to schedule onto the right node group, and let the cluster autoscaler (or Karpenter, if you've adopted it) right-size each group independently. The "one node type fits all" pattern wastes money on under-utilized capacity in one dimension.
Alternatives by tier
Things to consider
- Never use t-series for Kubernetes production workers — kubelet, kube-proxy, and CNI plugins consume CPU continuously and burn through credits
- Graviton works for K8s but requires a node group dedicated to ARM64 — most workloads support multi-arch images, but verify yours do
- For mixed workloads, run two node groups: m-series for application pods, c-series for any CPU-intensive batch or build pods
- EKS managed node groups simplify the lifecycle dramatically — strongly prefer them over Karpenter unless you have a specific reason