Was digging into Kubernetes cost optimization and ended up testing Spot + Karpenter + Graviton together, it turned out more practical than I expected. Would be interested to hear how others are handling stability and trade-offs with similar setups. Here’s what I observed: https://dev.to/muskan_8abedcc7e12/going-to-production-spot-instances-karpenter-and-the-graviton-advantage-4oi5

Hello, @Amanpreet Kaur. This is a good article. I've been using EC2 spot since 2014. People's main excuse for giving up is frustration with low capacity or frequent interruption because they insist on one exact instance type. You mention instance diversification indirectly, but if I were you, I'd include the key words

flexibility

and

diversification

because they appear in all AWS documentation on the subject. Examples: • Using Amazon EC2 Spot Instances with Karpenter • Best practices for Amazon EC2 Spot: Be flexible… Bravo for covering ARM, and multi-architecture builds! CPU architecture can add another degree of freedom, increasing access to spot capacity and reducing interruptions. Why not schedule on both architectures? Last but not least, users who don't want to worry about any of this can just add the FARGATE_SPOT capacity provider on ECS.

@paulm Great feedback, Paul! Really appreciate the specifics here. You're right, I should've explicitly called out the flexibility and diversification parameters in the Karpenter config. I touched on instance diversity conceptually, but naming the actual parameters would've made it much more actionable. Also a great point on multi-architecture. I focused mainly on Graviton's cost/performance, but the expanded Spot capacity across architectures is a big advantage for reducing interruptions. Thanks for sharing the links, the scheduling examples and FARGATE_SPOT callout add very practical depth. I'll likely incorporate these aspects in a follow-up or update.