Amazon Web Services Review for Running Kubernetes Clusters and Containerized Microservices

The research in brief

Amazon Web Services is a strong fit for a US DevOps or platform engineering team running managed Kubernetes container orchestration hosting, provided the team has real AWS platform expertise and accepts multi-part billing. Six of the seven included platforms named AWS during ranking discovery, and all seven rated it a strong fit. The strongest reason to consider it is Amazon EKS: a managed control plane plus a choice of managed node groups, EKS Auto Mode, Fargate, or self-managed Karpenter, with native VPC, IAM, load balancing, and Amazon ECR integration. The main limitation is cost and operational complexity: a per-cluster control-plane fee, separately metered networking and storage, and reduced node control or visibility under EKS Auto Mode.

Research Snapshot

Why Amazon Web Services Qualified for This Study

Questions explored

• Is Amazon Web Services a good choice for managed Kubernetes container orchestration hosting?
• How many platforms named Amazon Web Services for managed Kubernetes container orchestration hosting?

AWS qualified because six of the seven included platforms named it during ranking discovery, and every platform that produced a fit assessment rated it strong for this use case. The ranking-stage mentions came from Anthropic, DeepSeek, Google, Kimi, OpenAI, and Perplexity; Grok did not name AWS in the ranking stage but still returned a strong fit verdict. Listed ranks ranged from 1 (Perplexity) to 4 (Kimi), producing an average listed rank of 2.17 and a best listed rank of 1.

The platforms converged on the same product: Amazon Elastic Kubernetes Service (EKS), AWS's managed Kubernetes service, which manages the Kubernetes control plane and integrates with AWS services and Regions ^[8]. AWS documents EKS as a fully managed service that removes the need to install or operate your own control plane ^[3], with a control plane that scales and is highly available ^[3] and deploys control plane instances across multiple Availability Zones with automatic detection and replacement of unhealthy instances ^[3].

This review covers AWS only for managed Kubernetes container orchestration hosting. It is not a broad assessment of AWS as a company, and it does not evaluate AWS services outside the Kubernetes hosting path. For the wider field, see the managed Kubernetes container orchestration hosting consensus index.

The hosting offering in focus

Questions explored

• Which Amazon Web Services product should a buyer choose for managed Kubernetes container orchestration hosting?
• Is Amazon EKS with managed node groups or EKS Auto Mode better for a team that wants less node management work?

The most relevant AWS offering is Amazon Elastic Kubernetes Service (EKS), and the default configuration the platforms describe is EKS with managed node groups. OpenAI recommended EKS with managed node groups while flagging EKS Auto Mode for lower node-management overhead and self-managed Karpenter for greater provisioning control. Perplexity described the same default and the same two alternatives. Anthropic, DeepSeek, Google, Grok, and Kimi all named EKS, with Kimi explicitly listing EKS Auto Mode, managed node groups, and Fargate profiles as the relevant options.

EKS supports several compute models inside one service. AWS documents managed node groups, EKS Auto Mode managed nodes, self-managed nodes, AWS Fargate, and hybrid nodes as compute options ^[19]. Managed node groups automate EC2 node provisioning, updates, termination, draining, and optional node auto repair, and AWS states they carry no separate management fee beyond the underlying AWS resources ^[22]. Independent coverage describes the same automation of provisioning and lifecycle management ^[39] and notes that EKS makes it easier to apply bug fixes, security patches, and Kubernetes version updates to nodes ^[44].

EKS Auto Mode is the lower-operations alternative. AWS documents Auto Mode as automating cluster infrastructure and using a Karpenter-based system for pod-driven scaling and consolidation ^[15]. Perplexity reported that Auto Mode manages worker node operations and allows mixing Auto Mode managed nodes with self-managed nodes in the same cluster ^[11]. Independent coverage describes Auto Mode as automating infrastructure provisioning and scaling ^[47] and as eliminating the need to manage EC2 nodes ^[47]. One independent source states Auto Mode reached general availability on December 1, 2024 ^[31]; that date is platform-reported and should be confirmed against AWS announcements.

Self-managed Karpenter is the third path. Karpenter is an open-source node provisioning and autoscaling tool designed for EKS clusters ^[45] that provisions EC2 instances directly through the AWS API without Auto Scaling Groups ^[34], reads pod requirements when a pod goes pending, selects an instance type, and calls RunInstances ^[34]. One independent source reports nodes ready in 45–60 seconds under typical conditions ^[34], and another describes Karpenter as significantly faster than the native EKS Cluster Autoscaler ^[43]. AWS states that self-managed Karpenter must be installed and operated by the customer and has no AWS SLA ^[16].

What the AI Platforms Agreed About

Questions explored

• What do AI platforms agree on about Amazon Web Services for managed Kubernetes container orchestration hosting?
• Does Amazon EKS integrate with a container registry and AWS networking for microservices?

Agreement was unanimous on fit and strong on the reasons. All seven platforms rated AWS a strong fit for this use case, and the shared reasoning clustered around four points.

First, the managed control plane. Platforms agreed EKS removes control-plane operations while leaving workload and platform ownership with the buyer. AWS states EKS manages the Kubernetes control plane and integrates with AWS services and Regions ^[8], and independent coverage describes a fully managed, certified Kubernetes-compatible control plane that scales across multiple Availability Zones and handles upgrades, patching, and security configuration ^[48].

Second, container registry integration. Amazon ECR is AWS's managed container image registry ^[6] and is deeply integrated with EKS, so deploying containerized applications requires specifying the ECR repository in the pod definition ^[42]. Independent coverage describes ECR as tightly integrated with Amazon ECS, EKS, Fargate, Lambda, and developer tools ^[33]. AWS states that data transfer out to AWS services such as EKS within the same Region is free, while repository storage and applicable internet or cross-Region transfer are billed separately ^[33].

Third, networking. EKS uses the Amazon VPC CNI for pod networking on AWS infrastructure ^[20], and clusters require a VPC with at least two subnets in different Availability Zones ^[23]. Independent coverage notes deep VPC CNI integration and native support for IAM Roles for Service Accounts to grant fine-grained permissions ^[40].

Fourth, node autoscaling. Platforms agreed EKS offers multiple scaling paths rather than one. AWS documents scaling cluster compute with Karpenter and Cluster Autoscaler, including creating new nodes when pods cannot fit ^[16], and describes Auto Mode as including fully managed Karpenter functionality ^[28]. Perplexity reported that AWS says EKS Auto Mode and Karpenter node pools support EFA and placement groups in all Regions where EKS is available ^[1].

Where the AI Platforms Disagreed or Were Uncertain

Questions explored

• Is Amazon EKS Auto Mode pricing clear enough for a buyer to budget confidently?
• Does Amazon EKS include a managed service mesh, or must the buyer operate one separately?

The platforms disagreed on Auto Mode pricing and were uncertain about service mesh. These are the two areas where a buyer should not rely on any single platform's answer.

On Auto Mode cost, the conflict is direct. Anthropic cited independent sources stating Auto Mode applies an approximately 10–12% surcharge on top of EC2 On-Demand instance pricing per node-hour ^[48] and that this surcharge is not covered by Compute Savings Plans or Reserved Instances ^[35]. Google cited an independent source describing an Auto Mode surcharge of roughly 12% on top of EC2 node spend ^[32]. Kimi reported the opposite framing: that Auto Mode infrastructure is included in the standard structure with no separate pricing detailed in available sources ^[9]. OpenAI and Perplexity both noted that Auto Mode and other EKS capabilities have separate pricing without itemizing it ^[10]. The exact calculation per instance type was not documented in the official AWS pages reviewed, so the surcharge figure should be treated as platform-reported and verified.

On service mesh, the platforms were limited rather than contradictory. OpenAI stated that the reviewed AWS sources did not establish a single bundled, first-party service-mesh product or service-mesh pricing model for EKS. Perplexity stated that service mesh specifics were not confirmed in the checked material. DeepSeek cited AWS documentation covering service mesh options in relation to EKS and Kubernetes networking but described service mesh as possible rather than a single turnkey EKS-managed capability ^[24]. Kimi reported that Istio is available with EKS Auto Mode, unlike Fargate, but did not verify Linkerd or Consul. Google reported that Fargate does not support DaemonSets, which blocks some service meshes and eBPF tooling without workarounds ^[40].

Other unresolved items: whether extended support enrollment is automatic or opt-in was described inconsistently across sources; EKS Hybrid Nodes pricing tiers were described as complex and not thoroughly compared against EC2 On-Demand; and the exact Auto Mode general availability date rests on one independent source ^[31].

Features for this workload

Questions explored

• Does Amazon EKS support node autoscaling, container registry integration, and service mesh for microservices?
• What node customization does Amazon EKS Auto Mode prevent?

EKS covers the five criteria in this study's scope, with one partial gap on service mesh.

Managed Kubernetes offering. EKS provides a managed control plane with a choice of compute models in the same service ^[19]. AWS documents EKS add-ons and operational guidance for cluster components ^[18].

Container registry integration. Amazon ECR is a fully managed registry for storing and deploying container images and artifacts ^[7]. Same-Region transfer from ECR to AWS compute is described by AWS as free, with storage and cross-Region or internet transfer billed separately ^[7].

Autoscaling of nodes. Managed node groups automate provisioning and lifecycle management ^[39]. Karpenter provisions right-sized EC2 capacity directly through the AWS API ^[34]. Auto Mode provides managed Karpenter-based provisioning and consolidation ^[15]. AWS documents Karpenter and Cluster Autoscaler support for scaling cluster compute ^[16].

Networking and service mesh support. EKS uses the Amazon VPC CNI for native VPC pod networking with IPv4 or IPv6 support ^[20]. The VPC CNI supports Kubernetes network policies, but AWS documents limitations: applicability primarily to EC2 Linux nodes, with behavior depending on address family and pod architecture ^[17]. EKS also supports third-party policy tools such as Calico ^[21]. Auto Mode integrates managed load balancing and block storage ^[15], and AWS documents Auto Mode VPC CNI integration and pod networking ^[4]. Service mesh is possible but not a single AWS-managed EKS feature ^[24].

Pricing per node or cluster. EKS charges per cluster-hour, with separate charges for compute, storage, networking, and data transfer ^[10].

Two capability limits matter for microservices teams. EKS Auto Mode does not support Windows containers and has placement differences versus managed node groups ^[19]. Auto Mode also restricts direct access to managed instances and limits OS, AMI, and customization choices ^[14], and manages several components outside the customer cluster, reducing visibility into their logs and troubleshooting details ^[11]. Independent coverage confirms that custom AMIs are not supported in Auto Mode ^[41] and that Auto Mode restricts SSH/SSM node access by design ^[9]. Managed node groups, by contrast, support EC2 launch templates and custom AMIs ^[3].

Pricing, renewal terms, and ongoing costs

Questions explored

• How much does Amazon EKS cost per month, and are there setup or cancellation fees?
• What happens to the Amazon EKS control-plane price if a cluster is not upgraded within the standard support window?

EKS uses usage-based billing with no minimum fees or upfront commitments for the core service, but total cost depends on many separately metered resources. The control-plane fee is the only predictable line item.

Independent sources translate the standard control-plane fee to roughly $72 per cluster per month ^[46] and the extended-support fee to roughly $438 per cluster per month ^[36]. AWS states that managed node groups have no minimum fees, no upfront commitments, and no separate node-group management fee ^[22], and that On-Demand instances are billed by the second with no long-term commitments ^[10]. AWS's general pricing page describes a pay-as-you-go approach with no long-term contracts or termination fees for the vast majority of services (official:C2), and Savings Plans offer lower prices in exchange for a one- or three-year commitment (official:C3).

Additional fees the platforms flagged include NAT gateways, VPC endpoints, Elastic Load Balancing, CloudWatch or other observability services, public IPv4 addresses, cross-AZ traffic, cross-Region traffic, EBS storage, and AWS Support plans ^[10]. Independent sources cite NAT gateway charges of $0.045 per hour per gateway plus $0.045 per GB processed, cross-AZ transfer at $0.01 per GB, and internet egress at $0.09 per GB ^[32]. One independent source cites publicly routable IPv4 addresses at $3.65 per month ^[48]. These figures are platform-reported and should be confirmed against current AWS pricing pages.

The extended-support mechanism is the most consequential cost trap the platforms identified. AWS lists $0.60 per cluster-hour for Kubernetes versions in extended support ^[10], and independent sources describe extended support as automatically triggered after a 14-month standard support window, producing a sixfold increase ^[48]. Whether enrollment is automatic or opt-in was not consistently described across sources and should be verified.

Exact monthly cost cannot be determined from the supplied evidence. It depends on cluster count, Kubernetes version, node mix, utilization, Regions, traffic, storage, observability, and purchasing commitments (ChatGPT, Claude). Enterprise agreement pricing, AWS Support charges, discounts, and account-specific contractual terms were not verified.

Best Suited For

Questions explored

• Who is Amazon Web Services best suited for in managed Kubernetes container orchestration hosting?
• Is Amazon EKS a good fit for a team already standardized on AWS IAM, VPC, and ECR?

AWS is best suited to teams already invested in AWS and staffed to operate it. The platforms converged on this profile.

Teams already standardized on AWS IAM, VPC networking, ECR, CloudWatch, and AWS security and governance tooling are the clearest fit (DeepSeek, Kimi). Organizations building or migrating microservices to AWS infrastructure, and those running high-traffic production deployments that need multi-AZ availability with automatic control-plane management, also fit well (Claude). Platform engineering teams that want upstream Kubernetes APIs with an AWS-managed control plane, and organizations that need multiple node provisioning models in one Kubernetes platform, are a strong match (DeepSeek, ChatGPT).

Specific capability fits the platforms named: workloads benefiting from tight ECR integration and native AWS service access (Claude); deployments needing GPU, Graviton, or other specialized compute instances (Claude, Kimi); teams wanting rapid node scaling with Karpenter over Cluster Autoscaler (Claude); teams using Fargate for burstable or event-driven workloads (Claude); and teams wanting GitOps through Argo CD, AWS resource management through ACK, or custom API abstractions through KRO (Kimi). Teams that want to reduce node-management overhead while retaining full Kubernetes conformance fit EKS Auto Mode (Kimi, Perplexity).

Probably Not Best Suited For

Questions explored

• Who should not choose Amazon Web Services for managed Kubernetes container orchestration hosting?
• Is Amazon EKS a poor fit for a small team that wants a simple, flat Kubernetes bill?

AWS is probably not the best fit for buyers who want simplicity, low fixed costs, or portability. The platforms were consistent on this.

Small teams seeking the simplest Kubernetes experience with minimal AWS-specific configuration are a poor fit (ChatGPT, DeepSeek). Buyers optimizing primarily for lowest cost or the simplest pricing model should look elsewhere (DeepSeek, Perplexity). Organizations that want to avoid AWS-specific operational patterns and prefer maximum portability, or that require multi-cloud neutrality, should not choose EKS as their primary platform (DeepSeek, Grok, Kimi).

Buyers requiring full node OS, SSH, AMI, or low-level infrastructure control while also wanting AWS to manage the complete node lifecycle will find the combination unavailable: Auto Mode restricts those controls, and managed node groups return them at the cost of more operational work (ChatGPT, Claude). Workloads needing Windows containers, AWS Local Zones, or extensive node customization are not appropriate for EKS Auto Mode (ChatGPT, Claude). Teams requiring SSH or SSM access to worker nodes for debugging should avoid Auto Mode (Kimi). Workloads in China Regions cannot use EKS Auto Mode as of early 2026 (Kimi). Very small clusters or experimental deployments where the per-cluster control-plane fee is not cost-justified are also a poor fit (Claude).

When Another Option May Be Better

Questions explored

• What is a better alternative to Amazon Web Services for a buyer who needs simpler managed Kubernetes pricing?
• When should a buyer choose a non-AWS managed Kubernetes provider over Amazon EKS?

Another option may be better in five situations the platforms identified.

When the team wants the simplest possible managed Kubernetes pricing and operations with fewer AWS-specific moving parts, simpler providers are a better match (Perplexity, Kimi). Kimi specifically named DigitalOcean Kubernetes for simplicity, transparent pricing, and small-to-medium scale, and Civo for lowest entry cost with a free control plane ^[27]. These are platform-reported comparisons from provider-owned pages and should be verified independently.

When multi-cloud strategy is mandatory and AWS lock-in must be avoided, GKE, AKS, or self-hosted Kubernetes may be better (Claude, DeepSeek, Grok). When the team requires highly customized node environments such as specialized kernel modules, security tooling, or legacy OS requirements, self-managed or bare-metal Kubernetes may be better (Claude). When strict compliance policies prohibit cloud provider access to node internals, Auto Mode restrictions may not align and fully self-managed Kubernetes may be required (Claude). When cost predictability matters more than flexibility, providers with free or differently structured control planes may offer better predictability (Claude). When the workload is primarily hosted outside AWS and minimizing cross-cloud networking or identity integration matters more than AWS service breadth, another cloud provider may be better (ChatGPT).

Questions to ask before choosing a provider

Questions explored

• What should a buyer confirm with Amazon Web Services before signing a contract for managed Kubernetes hosting?
• Which Amazon EKS node model should a buyer choose for their workload profile?

The platforms produced overlapping verification lists. The consolidated items below are the ones that materially change cost or feasibility.

Confirm the node model first: managed node groups, EKS Auto Mode, self-managed Karpenter, Fargate, or a combination, and the reason for the choice (ChatGPT, Claude). Confirm whether the workload requires Windows containers, Local Zones, custom AMIs, SSH or SSM access, privileged agents, or GPUs, since these are incompatible with Auto Mode (ChatGPT, Claude, Kimi).

Confirm the full monthly cost including EC2, EBS, load balancers, NAT gateways, VPC endpoints, cross-AZ traffic, CloudWatch, ECR, public IPv4, and support (ChatGPT, Claude, Perplexity). Confirm the expected number of clusters, since the control-plane fee applies per cluster regardless of size (Claude). Confirm the Kubernetes version plan, upgrade cadence, and how extended-support charges will be avoided (ChatGPT, Claude, Gemini).

Confirm which service mesh is required, who operates it, and whether it supports the selected compute types, networking mode, and observability stack (ChatGPT, DeepSeek, Kimi). Confirm whether required network policies are supported for all node types, address families, standalone pods, and additional network interfaces (ChatGPT). Confirm ECR retention, replication, vulnerability scanning, signing, and cross-Region transfer policies (ChatGPT). Confirm AWS account, organization, IAM, private-endpoint, audit-log, and data-residency controls (ChatGPT). For self-managed Karpenter, confirm who owns controller upgrades, security, availability, disruption policies, Spot interruption handling, and incident response (ChatGPT). Confirm the support plan and response-time commitments and whether they are included in the AWS commercial agreement (ChatGPT, DeepSeek, Grok).

The consensus assessment

AWS is a strong fit for managed Kubernetes container orchestration hosting for a US DevOps or platform engineering team adopting microservices, with unanimous strong-fit ratings across all seven included platforms and ranking-stage mentions from six of seven. The consensus recommendation is Amazon EKS with managed node groups as the default, EKS Auto Mode when minimizing node operations matters more than node-level control, and self-managed Karpenter when flexible provisioning justifies additional operational ownership.

The consensus is not unqualified. The platforms agreed that AWS architecture and billing are complex, that many dependencies are separately metered, that EKS does not remove application operations, observability, security configuration, VPC design, or workload management, and that Auto Mode trades control and visibility for reduced operations. Auto Mode pricing was disputed between platforms, service mesh support was not verified as a turnkey AWS capability, and exact monthly cost cannot be determined without cluster count, version, node mix, utilization, Regions, traffic, storage, observability, and purchasing commitments. Buyers should verify current pricing, SLA terms, and the correct node model for their workload before committing.

How This Review Was Produced

This review was produced from seven AI platform responses to a single research prompt describing a platform engineering team moving to containerized microservices and seeking mature managed Kubernetes support with integrated container registries, reliable node autoscaling, networking and service mesh capabilities, and transparent node- or cluster-based pricing. The research date is 2026-10-03.

Six of the seven platforms named AWS during ranking discovery: Anthropic, DeepSeek, Google, Kimi, OpenAI, and Perplexity. Grok did not name AWS in the ranking stage but returned a fit assessment. All seven platforms rated AWS a strong fit for this use case. Listed ranks were Anthropic 2, DeepSeek 2, Google 2, Kimi 4, OpenAI 2, and Perplexity 1.

Platform responses were synthesized into the sections above. Where platforms agreed, the agreement is described as unanimous, strong, majority, mixed, or limited based on the supplied responses. Where platforms conflicted, the conflict is stated rather than resolved. No personal testing, customer experience, or independent verification was performed. For the broader category, see the vps cloud and dedicated server hosting directory.

Research limitations

Several limitations apply to this review.

Citations are platform-reported evidence, not independently verified facts. The supplied URLs were collected from platform responses and were not independently validated. Company-owned citations materially outnumber independent citations in the supplied evidence, so company claims should not be read as independently verified.

Platform-reported research dates differ from the authoritative run date. DeepSeek reported a research date of 2026-06-01; the other six platforms reported 2026-10-03. Platform-reported dates are provenance metadata and do not independently prove freshness.

DeepSeek reported that search was not enabled for its response, so its claims rest on model knowledge rather than retrieved sources and require explicit verification before being described as current facts.

Platform mentions in the ranking stage count only platforms that named the entity during ranking discovery, not all platforms that produced a fit assessment. Grok produced a fit assessment without a ranking-stage mention.

Conflicting product names, pricing, and capabilities were not resolved by guessing. The Auto Mode surcharge conflict, the service mesh uncertainty, and the extended-support enrollment question are described as conflicts and flagged for buyer verification.

Actual monthly cost cannot be determined from the supplied evidence. Enterprise agreement pricing, AWS Support charges, discounts, and account-specific contractual terms were not verified. AWS documentation and pricing can change, and the assessment reflects sources checked on 2026-10-03.

See the broader Running Kubernetes Clusters and Containerized Microservices consensus index for comparisons across qualified options.

Sources

Company-Owned Sources

1. Amazon EKS now supports EFA and placement groups on EKS Auto Mode and Karpenter node pools: https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-eks-efa-placement-groups/
2. Faster nodes, smarter scaling: What’s new inside Amazon EKS Auto Mode: https://aws.amazon.com/blogs/containers/faster-nodes-smarter-scaling-whats-new-inside-amazon-elastic-kubernetes-service-amazon-eks-auto-mode/
3. Introducing launch template and custom AMI support in Amazon EKS Managed Node Groups: https://aws.amazon.com/blogs/containers/introducing-launch-template-and-custom-ami-support-in-amazon-eks-managed-node-groups/
4. Navigating enterprise networking challenges with Amazon EKS Auto Mode | Containers: https://aws.amazon.com/blogs/containers/navigating-enterprise-networking-challenges-with-amazon-eks-auto-mode/
5. AWS Elastic Container Registry Documentation: https://aws.amazon.com/documentation-overview/ecr
6. Amazon Elastic Container Registry (ECR: https://aws.amazon.com/ecr/
7. Amazon ECR Pricing: https://aws.amazon.com/ecr/pricing/
8. Amazon Elastic Kubernetes Service (EKS: https://aws.amazon.com/eks/
9. Managed Kubernetes Service - Amazon EKS FAQs - Amazon Web Services: https://aws.amazon.com/eks/faqs/
10. Amazon EKS Pricing: https://aws.amazon.com/eks/pricing/
11. EKS Auto Mode - Best Practices Guide: https://docs.aws.amazon.com/eks/latest/best-practices/automode.html
12. EKS Auto Mode - AWS Documentation: https://docs.aws.amazon.com/eks/latest/best-practices/eks-auto-mode.html
13. Automate cluster infrastructure with EKS Auto Mode - AWS Documentation: https://docs.aws.amazon.com/eks/latest/userguide/automating-infrastructure.html
14. Learn about Amazon EKS Auto Mode Managed instances: https://docs.aws.amazon.com/eks/latest/userguide/automode-learn-instances.html
15. Automate cluster infrastructure with EKS Auto Mode: https://docs.aws.amazon.com/eks/latest/userguide/automode.html
16. Scale cluster compute with Karpenter and Cluster Autoscaler: https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html
17. Limit Pod traffic with Kubernetes network policies: https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html
18. Amazon EKS add-ons: https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
19. Manage compute resources by using nodes: https://docs.aws.amazon.com/eks/latest/userguide/eks-compute.html
20. Configure networking for Amazon EKS clusters: https://docs.aws.amazon.com/eks/latest/userguide/eks-networking.html
21. Infrastructure security in Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/infrastructure-security.html
22. Simplify node lifecycle with managed node groups: https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html
23. View Amazon EKS networking requirements for VPC and subnets: https://docs.aws.amazon.com/eks/latest/userguide/network-reqs.html
24. Service meshes on Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/service-mesh.html
25. Managed Kubernetes - Full API & custom CLI | Civo: https://www.civo.com/public-cloud/kubernetes
26. Kubernetes Pricing | DigitalOcean: https://www.digitalocean.com/pricing/kubernetes
27. Comparing Managed Kubernetes: DigitalOcean Kubernetes vs AWS EKS | DigitalOcean: https://www.digitalocean.com/resources/articles/kubernetes-digitalocean-vs-aws
28. Autoscaling with EKS Auto Mode: https://www.eksworkshop.com/docs/fastpaths/operator/karpenter/
29. Official pricing and terms source: https://aws.amazon.com/pricing/?nc2=h_pr_hub
30. Official pricing and terms source: https://aws.amazon.com/savingsplans/?nc2=h_pr_sp

Independent Sources

31. EKS Auto Mode Pricing, vs Managed Node Groups & Karpenter: https://alexandre-vazquez.com/eks-auto-mode/
32. AWS EKS Pricing 2026: Every Line Item Explained - Atmosly: https://atmosly.com/blog/aws-eks-pricing/
33. Amazon ECR: Secure Container Image Registry for AWS: https://awsglossary.org/terms/ecr
34. Deploy Karpenter on EKS: Node Auto-Scaling Guide (2026: https://cast.ai/blog/deploy-karpenter-eks-node-autoscaling/
35. EKS Cost Optimization: The Engineer's Guide for 2026: https://cast.ai/blog/eks-cost-optimization/
36. EKS Pricing in 2026: The $438/Month Trap and How to Avoid It | CloudBurn: https://cloudburn.io/blog/eks-pricing-trap/
37. EKS Pricing Explained: Understanding the Variables Impacting Kubernetes Costs: https://cloudchipr.com/blog/eks-pricing
38. Understanding EKS Compute Options: Self-Managed, Managed Node Groups, Fargate, and Karpenter - DEV Community: https://dev.to/aws-builders/understanding-eks-compute-options-self-managed-managed-node-groups-fargate-and-karpenter-31g9
39. 10 AWS EKS Features You Need & Ought to Know: https://logz.io/blog/aws-eks-features/
40. EKS, Karpenter and Fargate | Blake Romano - Medium: https://medium.com/@blakeromano/eks-karpenter-and-fargate-4f7f6d491cba
41. Simplify Kubernetes Management with Amazon EKS Auto Mode: https://medium.com/@gajaoncloud/simplify-kubernetes-management-with-amazon-eks-auto-mode-d26650bfc239
42. Amazon Elastic Container Registry (ECR): Simplifying Container Image Management: https://medium.com/@mudasirhaji/amazon-elastic-container-registry-ecr-simplifying-container-image-management-64da472ffaff
43. The Karpenter - K8s Node Scaler: https://medium.com/@vgprash24/the-karpenter-k8s-node-scaler-b3d54f231630
44. What is a EKS Nodegroup in AWS?: https://overmind.tech/types/eks-nodegroup
45. A Guide to Autoscaling in EKS: https://sedai.io/blog/autoscaling-in-eks
46. Kubernetes Pricing 2026: EKS vs AKS vs GKE Comparison Guide: https://sedai.io/blog/kubernetes-cost-eks-vs-aks-vs-gke
47. EKS Auto Mode: Simplify Kubernetes Operations: https://spacelift.io/blog/eks-auto-mode
48. EKS Pricing And Cost Optimization (2026 Guide: https://www.cloudzero.com/blog/eks-pricing/
49. Using Karpenter With EKS Fargate To Cut Costs On EKS Infrastructure - CloudZero: https://www.cloudzero.com/blog/karpenter-eks-fargate/
50. AWS EKS Kubernetes Pricing & Cost-Optimization Guide 2026 - Sedai: https://www.sedai.io/blog/aws-eks-kubernetes-pricing-cost-optimization-guide

Other Sources

51. Karpenter: https://karpenter.sh/