We run several Node.js microservices in a production Kubernetes cluster on AWS, currently using t3 instances. I'm wondering what instance types other teams use for production and whether it makes sense to stay with t3 or evaluate Graviton or another family. I'm especially interested in the trade-offs around performance, CPU credit behavior, cost, and the effort required to support ARM-based container images.
4 Answers
Moving from amd64 to ARM requires more than changing the worker-node type. Your image builds, CI runners, and deployment process need to produce and test arm64 images. Multi-architecture builds add some setup and build time, so it’s worth doing a small canary or mixed-node rollout first.
Check the CPUCreditBalance metric in CloudWatch over at least a month before changing anything. If the balance stays healthy, t3 may already be the right choice and Graviton becomes mainly a cost-optimization decision. Also verify whether unlimited mode is enabled, since sustained CPU usage can create additional charges.
T3 instances are perfectly reasonable for many production workloads, especially when the services are relatively light and CPU usage is bursty. The important thing is to watch whether you’re running out of memory or hitting the CPU credit limits. If the cluster grows or monitoring and other infrastructure components need more memory, you may eventually need larger or non-burstable instances.
Exactly—t3 is fine until the CPU credit balance starts dropping regularly. When that happens, performance can degrade in ways that aren’t immediately obvious. If CPU usage is sustained, a different family may be a better fit.
Graviton nodes can reduce costs and provide good performance if your container images and dependencies support arm64. Node.js itself generally works well on ARM, but you should verify native modules and any third-party binaries before switching.
The CI environment is easy to overlook. If it builds images for the wrong architecture, builds can become much slower or the containers may fail only after deployment.