{"id":2105,"date":"2026-02-25T07:47:19","date_gmt":"2026-02-25T07:47:19","guid":{"rendered":"https:\/\/www.rajeshkumar.xyz\/blog\/?p=2105"},"modified":"2026-02-25T08:16:25","modified_gmt":"2026-02-25T08:16:25","slug":"evaluation-of-amazon-eks-auto-mode-compute-options-for-high-availability-and-operational-ownership","status":"publish","type":"post","link":"https:\/\/www.rajeshkumar.xyz\/blog\/evaluation-of-amazon-eks-auto-mode-compute-options-for-high-availability-and-operational-ownership\/","title":{"rendered":"Evaluation of Amazon EKS Auto Mode Compute Options for High Availability and Operational Ownership"},"content":{"rendered":"\n
Area<\/th>1) EKS-provided NodeClass + EKS built-in NodePools<\/strong> (system<\/code>, general-purpose<\/code>)<\/th>2) EKS-provided NodeClass + Custom NodePool(s)<\/strong><\/th>3) Custom NodeClass + Custom NodePool(s)<\/strong><\/th><\/tr><\/thead>
What you get (big wins)<\/strong><\/td>Fastest + simplest<\/strong> \u201cproduction-ready baseline.\u201d Built-ins give you: system<\/code> pool isolation for critical add-ons (CriticalAddonsOnly taint) and a general-purpose pool. (AWS Documentation<\/a>)<\/td>Compute control without touching networking:<\/strong> you can tune AZs\/arch\/Spot vs On-Demand\/instance categories, set CPU+memory limits, and define disruption policies using NodePool. (AWS Documentation<\/a>)<\/td>Full infra policy control<\/strong> (within Auto Mode): customize networking placement, SG selection, SNAT policy, network policy defaults, event logging, pod subnet isolation, plus storage\/tagging knobs via NodeClass. (AWS Documentation<\/a>)<\/td><\/tr>
What you lose \/ constraints<\/strong><\/td>Least flexibility: built-ins are fixed. Both built-ins are On-Demand only<\/strong>, C\/M\/R families<\/strong>, gen\u22655<\/strong>, and general-purpose<\/code> is amd64-only<\/strong>. (AWS Documentation<\/a>)<\/td>You still inherit default NodeClass networking choices. If you need custom subnets\/SGs\/pod-subnet isolation, you can\u2019t do it here. (AWS Documentation<\/a>)<\/td>Highest complexity. More chances to misconfigure (subnet tags\/AZ mismatch, SG selection, IAM\/access-entry gaps). Also, still cannot choose AMI (AWS-managed). (AWS Documentation<\/a>)<\/td><\/tr>
NodeClass availability \/ dependency<\/strong><\/td>Default NodeClass is automatically provisioned when built-ins are enabled. (AWS Documentation<\/a>)<\/td>Important:<\/strong> Default NodeClass exists only if at least one built-in pool is enabled. Practically, most teams keep system<\/code> enabled. (AWS Documentation<\/a>)<\/td>If you disable all built-ins, you must<\/strong> create your NodeClass + NodePool. Also, AWS says do not<\/strong> name your custom NodeClass default<\/code>. (AWS Documentation<\/a>)<\/td><\/tr>
HA posture (cluster add-ons)<\/strong><\/td>Strong default: system<\/code> NodePool is designed to isolate critical add-ons using CriticalAddonsOnly<\/code> taint; many add-ons tolerate it. (AWS Documentation<\/a>)<\/td>You can keep the same HA posture by leaving system<\/code> enabled and moving apps to custom pools. (Common \u201cbest of both worlds.\u201d) (AWS Documentation<\/a>)<\/td>If you disable built-ins, you must recreate the \u201csystem isolation\u201d pattern yourself (taints\/tolerations + capacity plan). Otherwise cluster add-ons and apps compete for the same pool. (AWS Documentation<\/a>)<\/td><\/tr>
Networking\/security control (big differentiator)<\/strong><\/td>Minimal (defaults).<\/td>Minimal (still defaults).<\/td>Maximum<\/strong> (within Auto Mode): NodeClass can select node SGs, node subnets, SNAT policy, network policy defaults\/logging, and pod subnet isolation. (AWS Documentation<\/a>)<\/td><\/tr>
Compute\/cost tuning<\/strong><\/td>Limited to AWS defaults (On-Demand only, fixed family\/arch constraints). (AWS Documentation<\/a>)<\/td>Strong: NodePool lets you constrain instance types\/categories, AZs, arch, Spot\/On-Demand, and set CPU\/memory limits. (AWS Documentation<\/a>)<\/td>Strongest overall: same as option 2 plus the ability to align networking\/security posture to cost\/scale requirements (e.g., pod subnet isolation for IP exhaustion scenarios). (AWS Documentation<\/a>)<\/td><\/tr>
Upgrades & maintenance (who does what)<\/strong><\/td>AWS patches nodes + rolls AMIs; you mainly ensure workloads tolerate disruption (PDBs\/topology spread). (AWS Documentation<\/a>)<\/td>Same AWS responsibility for patching; you<\/strong> additionally manage NodePool policies (limits, consolidation timing, disruption budgets) to control upgrade impact. (AWS Documentation<\/a>)<\/td>Same AWS patching; you<\/strong> also own NodeClass lifecycle (network\/storage\/tagging changes) + any required IAM\/access-entry work for custom roles. (AWS Documentation<\/a>)<\/td><\/tr>
DevOps workload (ongoing)<\/strong><\/td>Low<\/strong>: mostly app HA policies + observing events\/node health. Node health monitoring\/auto-repair capabilities exist and the monitoring agent is included for Auto Mode clusters. (AWS Documentation<\/a>)<\/td>Medium<\/strong>: everything in option 1 plus managing one or more NodePools (requirements, limits, disruption windows\/budgets) and avoiding over-constraint. (AWS Documentation<\/a>)<\/td>High<\/strong>: everything in option 2 plus NodeClass governance (subnets\/SG\/SNAT\/pod-subnet isolation, storage\/KMS\/tagging) and IAM\/access-entry associations for node roles. (AWS Documentation<\/a>)<\/td><\/tr>
Typical fit<\/strong><\/td>Teams optimizing for simplicity<\/strong>, fastest time-to-production, and standard workloads.<\/td>Most common \u201centerprise sweet spot\u201d: keep AWS defaults for networking, but add NodePools for HA + cost + workload segmentation<\/strong>.<\/td>Regulated \/ complex networking environments: explicit subnet\/SG policy<\/strong>, IP management requirements, pod subnet isolation, stricter infra governance. (AWS Documentation<\/a>)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Below is the built-in NodePool comparison<\/strong> you get with \u201cfull\u201d EKS Auto Mode: system<\/code><\/strong> and general-purpose<\/code><\/strong>.<\/p>\n\n\n\n

Topic<\/th>system<\/code> (built-in)<\/th>general-purpose<\/code> (built-in)<\/th><\/tr><\/thead>
Primary purpose<\/strong><\/td>Dedicated capacity for cluster-critical add-ons<\/strong> to improve stability\/isolation. (AWS Documentation<\/a>)<\/td>Default pool for general workloads<\/strong> (microservices, web apps, etc.) with \u201creasonable defaults.\u201d (AWS Documentation<\/a>)<\/td><\/tr>
How pods get scheduled onto it<\/strong><\/td>Nodes have a CriticalAddonsOnly<\/code> taint<\/strong> \u2192 pods must have a matching toleration<\/strong> (and typically select the pool) to run here. Example uses nodeSelector: karpenter.sh\/nodepool: system<\/code> + toleration. (AWS Documentation<\/a>)<\/td>Typical workloads just target Auto Mode nodes with eks.amazonaws.com\/compute-type: auto<\/code>; unless you explicitly target another pool, this is the \u201cdefault\u201d place most apps land. (AWS Documentation<\/a>)<\/td><\/tr>
Who should run here (allowed use)<\/strong><\/td>CoreDNS and other critical add-ons that tolerate CriticalAddonsOnly<\/code>, plus any custom critical components<\/strong> you want isolated (monitoring\/ingress controllers, etc.)\u2014if they can tolerate the taint. (AWS Documentation<\/a>)<\/td>Application workloads and services that don\u2019t need \u201csystem-only\u201d isolation. (AWS Documentation<\/a>)<\/td><\/tr>
Main limitation (behavioral)<\/strong><\/td>Regular app pods won\u2019t schedule here<\/strong> unless you add the toleration (by design). (AWS Documentation<\/a>)<\/td>No built-in isolation; system add-ons and apps can compete unless you keep system<\/code> enabled and schedule critical add-ons there. (AWS Documentation<\/a>)<\/td><\/tr>
CPU architecture support<\/strong><\/td>amd64 + arm64<\/strong> (AWS Documentation<\/a>)<\/td>amd64 only<\/strong> (AWS Documentation<\/a>)<\/td><\/tr>
Capacity type<\/strong><\/td>On-Demand only<\/strong> (AWS Documentation<\/a>)<\/td>On-Demand only<\/strong> (AWS Documentation<\/a>)<\/td><\/tr>
Instance families & generations<\/strong><\/td>C\/M\/R families<\/strong>, gen 5+<\/strong> (AWS Documentation<\/a>)<\/td>C\/M\/R families<\/strong>, gen 5+<\/strong> (AWS Documentation<\/a>)<\/td><\/tr>
NodeClass used<\/strong><\/td>Uses the default EKS NodeClass<\/strong> (AWS Documentation<\/a>)<\/td>Uses the default EKS NodeClass<\/strong> (AWS Documentation<\/a>)<\/td><\/tr>
Can you edit\/customize it?<\/strong><\/td>No<\/strong> (you can only enable\/disable). For customization you must create your own NodePool(s). (AWS Documentation<\/a>)<\/td>No<\/strong> (you can only enable\/disable). For customization you must create your own NodePool(s). (AWS Documentation<\/a>)<\/td><\/tr>
Operational dependency note<\/strong><\/td>If you disable all<\/strong> built-in pools, EKS won\u2019t automatically provision the default<\/code> NodeClass<\/strong>\u2014you must create a custom NodeClass + NodePool. (AWS Documentation<\/a>)<\/td>Same dependency note. (AWS Documentation<\/a>)<\/td><\/tr><\/tbody><\/table><\/figure>\n","protected":false},"excerpt":{"rendered":"

Area 1) EKS-provided NodeClass + EKS built-in NodePools (system, general-purpose) 2) EKS-provided NodeClass + Custom NodePool(s) 3) Custom NodeClass + […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2105","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/2105","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/comments?post=2105"}],"version-history":[{"count":2,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/2105\/revisions"}],"predecessor-version":[{"id":2107,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/2105\/revisions\/2107"}],"wp:attachment":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/media?parent=2105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/categories?post=2105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/tags?post=2105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}