**Help improve this page** To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page. # Organize and monitor cluster resources This chapter includes the following topics to help you manage your cluster. You can also view information about your [Kubernetes resources](view-kubernetes-resources.md) with the AWS Management Console. + The Kubernetes Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage applications running in the cluster and troubleshoot them, as well as manage the cluster itself. For more information, see The [Kubernetes Dashboard](https://github.com/kubernetes/dashboard) GitHub repository. + [View resource usage with the Kubernetes Metrics Server](metrics-server.md) – The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster. It isn’t deployed by default in your cluster, but is used by Kubernetes add-ons, such as the Kubernetes Dashboard and [Scale pod deployments with Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md). In this topic you learn how to install the Metrics Server. + [Deploy applications with Helm on Amazon EKS](helm.md) – The Helm package manager for Kubernetes helps you install and manage applications on your Kubernetes cluster. This topic helps you install and run the Helm binaries so that you can install and manage charts using the Helm CLI on your local computer. + [Organize Amazon EKS resources with tags](eks-using-tags.md) – To help you manage your Amazon EKS resources, you can assign your own metadata to each resource in the form of *tags*. This topic describes tags and shows you how to create them. + [View and manage Amazon EKS and Fargate service quotas](service-quotas.md) – Your AWS account has default quotas, formerly referred to as limits, for each AWS service. Learn about the quotas for Amazon EKS and how to increase them. # Monitor and optimize Amazon EKS cluster costs Cost monitoring is an essential aspect of managing your Kubernetes clusters on Amazon EKS. By gaining visibility into your cluster costs, you can optimize resource utilization, set budgets, and make data-driven decisions about your deployments. Amazon EKS provides two cost monitoring solutions, each with its own unique advantages, to help you track and allocate your costs effectively: ** AWS Billing split cost allocation data for Amazon EKS** — This native feature integrates seamlessly with the AWS Billing Console, allowing you to analyze and allocate costs using the same familiar interface and workflows you use for other AWS services. With split cost allocation, you can gain insights into your Kubernetes costs directly alongside your other AWS spend, making it easier to optimize costs holistically across your AWS environment. You can also leverage existing AWS Billing features like Cost Categories and Cost Anomaly Detection to further enhance your cost management capabilities. For more information, see [Understanding split cost allocation data](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html) in the AWS Billing User Guide. **Kubecost** — Amazon EKS supports Kubecost, a Kubernetes cost monitoring tool. Kubecost offers a feature-rich, Kubernetes-native approach to cost monitoring, providing granular cost breakdowns by Kubernetes resources, cost optimization recommendations, and out-of-the-box dashboards and reports. Kubecost also retrieves accurate pricing data by integrating with the AWS Cost and Usage Report, ensuring you get a precise view of your Amazon EKS costs. Learn how to [Install Kubecost](cost-monitoring-kubecost.md#kubecost-overview). See the [Kubecost](https://aws.amazon.com/marketplace/pp/prodview-asiz4x22pm2n2) AWS Marketplace page for information on getting a free Kubecost subscription. # View costs by Pod in AWS billing with split cost allocation ## Cost monitoring using AWS split cost allocation data for Amazon EKS You can use AWS split cost allocation data for Amazon EKS to get granular cost visibility for your Amazon EKS clusters. This enables you to analyze, optimize, and chargeback cost and usage for your Kubernetes applications. You allocate application costs to individual business units and teams based on Amazon EC2 CPU and memory resources consumed by your Kubernetes application. Split cost allocation data for Amazon EKS gives visibility into cost per Pod, and enables you to aggregate the cost data per Pod using namespace, cluster, and other Kubernetes primitives. The following are examples of Kubernetes primitives that you can use to analyze Amazon EKS cost allocation data. + Cluster name + Deployment + Namespace + Node + Workload Name + Workload Type [User-defined cost allocation tags](https://console.aws.amazon.com/costmanagement/home#/tags) are also supported. For more information about using split cost allocation data, see [Understanding split cost allocation data](https://docs.aws.amazon.com/cur/latest/userguide/split-cost-allocation-data.html) in the AWS Billing User Guide. ## Set up Cost and Usage Reports You can turn on Split Cost Allocation Data for EKS in the Cost Management Console, AWS Command Line Interface, or the AWS SDKs. Use the following for *Split Cost Allocation Data*: 1. Opt in to Split Cost Allocation Data. For more information, see [Enabling split cost allocation data](https://docs.aws.amazon.com/cur/latest/userguide/enabling-split-cost-allocation-data.html) in the AWS Cost and Usage Report User Guide. 1. Include the data in a new or existing report. 1. View the report. You can use the Billing and Cost Management console or view the report files in Amazon Simple Storage Service. # Install Kubecost Amazon EKS supports Kubecost, which you can use to monitor your costs broken down by Kubernetes resources including Pods, nodes, namespaces, and labels. This topic covers installing Kubecost, and accessing the Kubecost dashboard. Amazon EKS provides an AWS optimized bundle of Kubecost for cluster cost visibility. You can use your existing AWS support agreements to obtain support. For more information about the available versions of Kubecost, see [Learn more about Kubecost](cost-monitoring-kubecost-bundles.md). **Note** Kubecost v3 introduces major architectural improvements including dramatically faster performance and enhanced automation capabilities. [Learn more about Kubecost v3. ](cost-monitoring-kubecost-bundles.md#kubecost-v3) Kubecost v2 introduces several major new features. [Learn more about Kubecost v2. ](cost-monitoring-kubecost-bundles.md#kubecost-v2) For more information about Kubecost, see the [Kubecost](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x) documentation and [Frequently asked questions](cost-monitoring-kubecost-bundles.md#cost-monitoring-faq). ## Install Amazon EKS optimized Kubecost bundle You can use one of the following procedures to install the *Amazon EKS optimized Kubecost bundle*: + Before start, it is recommended to review [Kubecost - Architecture Overview](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installations-amazon-eks-integration) to understand how Kubecost works on Amazon EKS. + If you are new to Amazon EKS, we recommend that you use the Amazon EKS add-on for the installation because it simplifies the *Amazon EKS optimized Kubecost bundle* installation. For more information, see [Deploying Kubecost on an Amazon EKS cluster using Amazon EKS add-on](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installations-amazon-eks-integration#ariaid-title3). + To customize the installation, you might configure your *Amazon EKS optimized Kubecost bundle* with Helm. For more information, see [Deploying Kubecost on an Amazon EKS cluster using Helm](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installations-amazon-eks-integration#ariaid-title8) in the *Kubecost documentation*. **Important** For Kubecost v3, the Helm chart location has changed to `public.ecr.aws/kubecost/kubecost`. If you are upgrading from v2, update your Helm repository references accordingly. **Note** For multi-cluster deployments with Kubecost v3, you need S3-compatible object storage (AWS S3 for EKS customers) for metrics storage. This replaces the Prometheus-compatible storage used in v2. For more information, see [Multi-Cluster Installation](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installation-multi-cluster) in the Kubecost documentation. ## Access Kubecost dashboard Once the *Amazon EKS optimized Kubecost bundle* setup done, you should have access to Kubecost dashboard. For more information, see [Access Kubecost Dashboard](cost-monitoring-kubecost-dashboard.md). # Access Kubecost Dashboard ## Prerequisites 1. Make sure the kubecost related Pods' state are "Running". ``` kubectl get pods --namespace kubecost ``` ## Access Kubecost Dashboard 1. On your device, enable port-forwarding to expose the Kubecost dashboard. + If kubecost v3 is installed using helm: ``` kubectl port-forward deployment/kubecost-frontend 9090 --namespace kubecost ``` + If kubecost v1 or v2 is installed using helm: ``` kubectl port-forward deployment/kubecost-cost-analyzer 9090 --namespace kubecost ``` + If kubecost is installed using Amazon EKS add-on: ``` kubectl port-forward deployment/cost-analyzer 9090 --namespace kubecost ``` Alternatively, you can use the [AWS Load Balancer Controller](aws-load-balancer-controller.md) to expose Kubecost and use Amazon Cognito for authentication, authorization, and user management. For more information, see [How to use Application Load Balancer and Amazon Cognito to authenticate users for your Kubernetes web apps](https://aws.amazon.com/blogs/containers/how-to-use-application-load-balancer-and-amazon-cognito-to-authenticate-users-for-your-kubernetes-web-apps). 1. On the same device that you completed the previous step on, open a web browser and enter the following address. ``` http://localhost:9090 ``` You see the Kubecost Overview page in your browser. It might take 5–10 minutes (or more) for Kubecost to gather metrics, depends on your cluster size. You can see your Amazon EKS spend, including cumulative cluster costs, associated Kubernetes asset costs, and monthly aggregated spend. 1. To track costs at a cluster level, tag your Amazon EKS resources for billing. For more information, see [Tagging your resources for billing](eks-using-tags.md#tag-resources-for-billing). + **Cost allocation** – View monthly Amazon EKS costs and cumulative costs for each of your namespaces and other dimensions over the past seven days. This is helpful for understanding which parts of your application are contributing to Amazon EKS spend. + **Assets** – View the costs of the AWS infrastructure assets that are associated with your Amazon EKS resources. # Learn more about Kubecost Amazon EKS provides an AWS optimized bundle of Kubecost for cluster cost visibility. Amazon EKS supports Kubecost, which you can use to monitor your costs broken down by Kubernetes resources including Pods, nodes, namespaces, and labels. This topic covers the available versions of Kubecost, and the differences between the available tiers. EKS supports Kubecost Version 1, Version 2, and Version 3. Each version is available in different tiers. You can use *Amazon EKS optimized Kubecost bundle* for your Amazon EKS clusters at no additional cost. You may be charged for use of associated AWS services, such as Amazon Managed Service for Prometheus. Also, you can use your existing AWS support agreements to obtain support. As a Kubernetes platform administrator and finance leader, you can use Kubecost to visualize a breakdown of Amazon EKS charges, allocate costs, and charge back organizational units such as application teams. You can provide your internal teams and business units with transparent and accurate cost data based on their actual AWS bill. Moreover, you can also get customized recommendations for cost optimization based on their infrastructure environment and usage patterns within their clusters. For more information about Kubecost, see the [Kubecost](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x) documentation. **What is the difference between the custom bundle of Kubecost and the free version of Kubecost (also known as OpenCost)?** AWS and Kubecost collaborated to offer a customized version of Kubecost. This version includes a subset of commercial features at no additional charge. See the tables below for features that are included with in the custom bundle of Kubecost. ## Kubecost v3 **What is the difference between Kubecost v2 and v3?** Kubecost 3.0 is a major architectural upgrade that delivers dramatically faster performance, enhanced scalability, and proactive optimization capabilities. The most significant change is the migration to a ClickHouse database, replacing DuckDB from version 2.8, which provides substantially faster queries and more reliable performance at scale. Kubecost 3.0 also introduces a unified agent that combines Kubecost and Cloudability functionality, eliminating the Prometheus dependency and reducing memory footprint while maintaining OpenCost compatibility. **Important** [Review the Kubecost documentation before upgrading to v3.](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x) Migration from v2 requires careful planning and may impact report availability during transition. The Helm chart location has changed to `public.ecr.aws/kubecost/kubecost`. **Key architectural improvements in v3:** + **ClickHouse Database**: Replaces DuckDB for dramatically faster queries and better scalability + **Unified Agent**: Combines Kubecost and Cloudability functionality, eliminating Prometheus dependency + **S3-Compatible Storage for Multi-Cluster**: For multi-cluster deployments, v3 uses S3-compatible object storage (AWS S3 for EKS customers) instead of Prometheus-compatible storage like Amazon Managed Service for Prometheus. The FinOps agent pulls metrics from the Kubernetes API and pushes to S3-compatible storage, then the Aggregator pulls that data, performs derivation steps, and displays results in the frontend. For more information, see [Multi-Cluster Installation](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installation-multi-cluster) and [Secondary Clusters Guide](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=cluster-secondary-clusters-guide) in the Kubecost documentation. + **Reduced Memory Footprint**: Substantially lower resource requirements while maintaining functionality + **Simplified Architecture**: Single-container pod topology for independent scaling and improved resiliency + **Enhanced Automation**: Automated Container Request Sizing with multi-cluster awareness and custom profiles **Amazon EKS optimized bundle benefits in v3:** The *Amazon EKS optimized Kubecost bundle* continues to be available at no additional charge and is exempt from the new \$1100,000 USD spend limit introduced in Kubecost v3 free tier. EKS users retain full access to all Kubernetes spend functionality regardless of spend levels. **Core features comparison:** | Feature | Kubecost free tier 3.0 | Amazon EKS optimized Kubecost bundle 3.0 | Kubecost Enterprise 3.0 | | --- | --- | --- | --- | | Cluster cost visibility | Unlimited clusters, gated at \$1100k USD spend over 30 days | Unified multi-cluster without spend limits | Unified and unlimited number of clusters across unlimited numbers of environments (i.e. multi-cloud) | | Database backend | ClickHouse (local) | ClickHouse with S3-compatible storage for multi-cluster metrics | ClickHouse with custom database options | | Performance | Substantially faster queries vs v2 | Substantially faster queries vs v2 | Substantially faster queries vs v2 | | Memory footprint | Reduced vs v2 (no Prometheus dependency) | Reduced vs v2 (no Prometheus dependency) | Reduced vs v2 (no Prometheus dependency) | | Automated Container Request Sizing | Available (limited to 250 cores) | Available without core limits | Available without core limits | | Spend limits | \$1100k USD over 30 days | No spend limits | No spend limits | | Multi-cluster automation | Limited | Full multi-cluster awareness with secure messaging | Full multi-cluster awareness with secure messaging | ## Kubecost v2 **What is the difference between Kubecost v1 and v2?** Kubecost 2.0 is a major upgrade from previous versions and includes major new features including a brand new API Backend. Note the [Allocation](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=apis-allocation-api) and [Assets](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=apis-assets-api) APIs are fully backwards compatible. [Please review the Kubecost documentation to ensure a smooth transition.](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=installation-kubecost-v2-installupgrade) For the full list of enhancements, [please see the Kubecost v2.0 announcement](https://github.com/kubecost/cost-analyzer-helm-chart/releases/tag/v2.0.0) and [the full release notes](https://github.com/kubecost/cost-analyzer-helm-chart/releases). **Important** [Review the Kubecost documentation before upgrading.](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x) Upgrading may impact report availability. **Core features comparison:** | Feature | Kubecost free tier 2.0 | Amazon EKS optimized Kubecost bundle 2.0 | Kubecost Enterprise 2.0 | | --- | --- | --- | --- | | Cluster cost visibility | Unlimited clusters up to 250 cores | Unified multi-cluster without core limits when integrated with Amazon Managed Service for Prometheus | Unified and unlimited number of clusters across unlimited numbers of environments (i.e. multi-cloud) | | Deployment | User hosted | User hosted | User hosted, Kubecost hosted (dedicated tenant), SaaS | | Databases supported | Local Prometheus | Amazon Managed Service for Prometheus or Local Prometheus | Any prometheus flavor and custom databases | | Database retention support (raw metrics) | 15 days | Unlimited historical data | Unlimited historical data | | Kubecost API and UI retention (ETL) | 15 days | 15 days | Unlimited | | Hybrid cloud visibility | - | Amazon EKS and Amazon EKS Anywhere clusters | Multi-cloud and hybrid cloud | | Alerts and recurring reports | Only supported on the primary cluster, limited to 250 cores | Efficiency alerts, budget alerts, spend change alerts, and [more supported](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=navigating-kubecost-ui#ariaid-title6) across all clusters | Efficiency alerts, budget alerts, spend change alerts, and [more supported](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=navigating-kubecost-ui#ariaid-title6) across all clusters | | Saved reports | - | Reports using 15 days of metrics | Reports using unlimited historical data and metrics | | Cloud billing integration | Only supported on the primary cluster, limited to 250 cores | Custom pricing support for AWS (including multiple clusters and multiple accounts) | Custom pricing support for any cloud | | Savings recommendations | Only supported on the primary cluster, limited to 250 cores | Primary cluster insights, but there is no 250 core limit | Multi-cluster insights | | Governance: Audits | - | - | Audit historical cost events | | Single sign-on (SSO) support | - | Amazon Cognito supported | Okta, Auth0, PingID, KeyCloak, and anything else custom | | Role-based access control (RBAC) with SAML 2.0 | - | - | Okta, Auth0, PingID, KeyCloak, and anything else custom | | Enterprise training and onboarding | - | - | Full-service training and FinOps onboarding | | Teams | - | - | Yes | **New Features:** The following features have metric limits: + Kubecost Aggregator + Network Monitoring + Kubecost Actions + Collections + Anomaly detection + Container Request Right-Sizing + Kubecost Forecasting + Autocomplete for filtering and aggregation **Metric limits:** | Metric | Kubecost Free Tier 2.0 | Amazon EKS optimized Kubecost bundle 2.0 | Kubecost Enterprise 2.0 | | --- | --- | --- | --- | | Cluster size | Unlimited clusters up to 250 cores | Unlimited | Unlimited | | Metric retention | 15 days | 15 days | Unlimited | | Multi-cluster support | Not available | Available | Available | | Core limits | 250 cores per cluster | No core limits | No core limits | ## Kubecost v1 | Feature | Kubecost free tier | Amazon EKS optimized Kubecost bundle | Kubecost Enterprise | | --- | --- | --- | --- | | **Deployment** | User hosted | User hosted | User hosted or Kubecost hosted (SaaS) | | **Number of clusters supported** | Unlimited | Unlimited | Unlimited | | **Databases supported** | Local Prometheus | Local Prometheus or Amazon Managed Service for Prometheus | Prometheus, Amazon Managed Service for Prometheus, Cortex, or Thanos | | **Database retention support** | 15 days | Unlimited historical data | Unlimited historical data | | **Kubecost API retention (ETL)** | 15 days | 15 days | Unlimited historical data | | **Cluster cost visibility** | Single clusters | Unified multi-cluster | Unified multi-cluster | | **Hybrid cloud visibility** | - | Amazon EKS and Amazon EKS Anywhere clusters | Multi-cloud and hybrid-cloud support | | **Alerts and recurring reports** | - | Efficiency alerts, budget alerts, spend change alerts, and more supported | Efficiency alerts, budget alerts, spend change alerts, and more supported | | **Saved reports** | - | Reports using 15 days data | Reports using unlimited historical data | | **Cloud billing integration** | Required for each individual cluster | Custom pricing support for AWS (including multiple clusters and multiple accounts) | Custom pricing support for AWS (including multiple clusters and multiple accounts) | | **Savings recommendations** | Single cluster insights | Single cluster insights | Multi-cluster insights | | **Governance: Audits** | - | - | Audit historical cost events | | **Single sign-on (SSO) support** | - | Amazon Cognito supported | Okta, Auth0, PingID, KeyCloak | | **Role-based access control (RBAC) with SAML `2.0` ** | - | - | Okta, Auth0, PingID, Keycloak | | **Enterprise training and onboarding** | - | - | Full-service training and FinOps onboarding | ## Frequently asked questions See the following common questions and answers about using Kubecost with Amazon EKS. **What is the Kubecost API retention (ETL) feature?** The Kubecost ETL feature aggregates and organizes metrics to surface cost visibility at various levels of granularity (such as `namespace-level`, `pod-level`, and `deployment-level`). For *Amazon EKS optimized Kubecost bundle*, customers get data and insights from metrics for the last 15 days. **What is the alerts and recurring reports feature? What alerts and reports does it include?** Kubecost alerts allow teams to receive updates on real-time Kubernetes spend as well as cloud spend. Recurring reports enable teams to receive customized views of historical Kubernetes and cloud spend. Both are configurable using the Kubecost UI or Helm values. They support email, Slack, and Microsoft Teams. **What do saved reports include?** Kubecost saved reports are predefined views of cost and efficiency metrics. They include cost by cluster, namespace, label, and more. **What is cloud billing integration?** Integration with AWS billing APIs allows Kubecost to display out-of-cluster costs (such as Amazon S3). Additionally, it allows Kubecost to reconcile Kubecost’s in-cluster predictions with actual billing data to account for spot usage, savings plans, and enterprise discounts. **What do savings recommendations include?** Kubecost provides insights and automation to help users optimize their Kubernetes infrastructure and spend. **Is there a charge for this functionality?** No. You can use *Amazon EKS optimized Kubecost bundle* at no additional charge. If you want additional Kubecost capabilities that aren’t included, you can buy an Enterprise License of Kubecost through the AWS Marketplace, or from Kubecost directly. **Is support available for *Amazon EKS optimized Kubecost bundle*?** Yes, only if you are using the *Amazon EKS optimized Kubecost bundle*. **How do I get support for *Amazon EKS optimized Kubecost bundle*?** You can open a support case with the AWS Support team at [Contact AWS](https://aws.amazon.com/contact-us/). **Do I need a license to use Kubecost features provided by the Amazon EKS integration?** No. **Can I integrate Kubecost with AWS Cost and Usage Report for more accurate reporting?** Yes. You can configure Kubecost to ingest data from AWS Cost and Usage Report to get accurate cost visibility, including discounts, Spot pricing, reserved instance pricing, and others. For more information, see [AWS Cloud Billing Integration](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=integrations-aws-cloud-billing-integration) in the Kubecost documentation. **Does this version support cost management of self-managed Kubernetes clusters on Amazon EC2?** No. *Amazon EKS optimized Kubecost bundle* only compatible with Amazon EKS clusters. **Can Kubecost track costs for Amazon EKS on AWS Fargate?** Kubecost provides best effort to show cluster cost visibility for Amazon EKS on Fargate, but with lower accuracy than with Amazon EKS on Amazon EC2. This is primarily due to the difference in how you’re billed for your usage. With Amazon EKS on Fargate, you’re billed for consumed resources. With Amazon EKS on Amazon EC2 nodes, you’re billed for provisioned resources. Kubecost calculates the cost of an Amazon EC2 node based on the node specification, which includes CPU, RAM, and ephemeral storage. With Fargate, costs are calculated based on the requested resources for the Fargate Pods. **How can I get updates and new versions of Kubecost?** You can upgrade your Kubecost version using standard Helm upgrade procedures. For Kubecost v3, the latest versions are available at the new Helm chart location `public.ecr.aws/kubecost/kubecost`. Previous versions (v1 and v2) remain available in the [Amazon ECR Public Gallery](https://gallery.ecr.aws/kubecost/cost-analyzer). **Important** When upgrading to Kubecost v3, note that the Helm chart location has changed from `public.ecr.aws/kubecost/cost-analyzer` to `public.ecr.aws/kubecost/kubecost`. Update your Helm repository references accordingly. **Is the `kubectl-cost` CLI supported? How do I install it?** Yes. `Kubectl-cost` is an open source tool by Kubecost (Apache 2.0 License) that provides CLI access to Kubernetes cost allocation metrics. To install `kubectl-cost`, see [Installation](https://github.com/kubecost/kubectl-cost#installation) on GitHub. **Is the Kubecost user interface supported? How do I access it?** Kubecost provides a web dashboard that you can access through `kubectl` port forwarding, an ingress, or a load balancer. You can also use the AWS Load Balancer Controller to expose Kubecost and use Amazon Cognito for authentication, authorization, and user management. For more information, see [How to use Application Load Balancer and Amazon Cognito to authenticate users for your Kubernetes web apps](https://aws.amazon.com/blogs/containers/how-to-use-application-load-balancer-and-amazon-cognito-to-authenticate-users-for-your-kubernetes-web-apps) on the AWS blog. **Does the new \$1100k spend limit in Kubecost v3 affect Amazon EKS users?** No. The \$1100,000 USD spend limit over 30 days introduced in Kubecost v3 free tier does not apply to *Amazon EKS optimized Kubecost bundle* users. EKS users retain full access to all Kubernetes spend functionality regardless of spend levels. **What are the main performance improvements in Kubecost v3?** Kubecost v3 introduces substantial performance improvements through its ClickHouse database backend, which provides dramatically faster queries compared to the DuckDB used in v2.8. Additionally, the unified agent architecture eliminates the Prometheus dependency, reducing memory footprint while maintaining full functionality and OpenCost compatibility. **What storage backend does Kubecost v3 use for multi-cluster deployments?** Kubecost v3 uses S3-compatible object storage (AWS S3 for EKS customers) for multi-cluster metrics storage, replacing the Prometheus-compatible storage used in v2. The FinOps agent collects metrics from the Kubernetes API and pushes them to S3-compatible storage. The Aggregator then retrieves this data, performs cost calculations, and displays the results in the frontend. For detailed multi-cluster setup instructions, see [Multi-Cluster Installation](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=installation-multi-cluster) and [Secondary Clusters Guide](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=cluster-secondary-clusters-guide) in the Kubecost documentation. **Can I upgrade directly from Kubecost v1 to v3?** No. Direct upgrade from v1 to v3 is not supported. You must first upgrade to v2, then migrate to v3. Review the Kubecost documentation for detailed migration guidance, as the process requires careful planning and may impact report availability during transition. ## Additional Kubecost Features + The following features are available in Kubecost v1, v2, and v3. + **Export cost metrics** – Amazon EKS optimized cost monitoring is deployed with Kubecost. In v1 and v2, Kubecost integrates with Prometheus for metrics storage and processing. In v3, Kubecost uses a ClickHouse database for dramatically improved performance while maintaining OpenCost compatibility. For multi-cluster deployments in v3, metrics are stored in S3-compatible object storage (AWS S3 for EKS customers) instead of Prometheus-compatible storage. Kubecost reads metrics, performs cost allocation calculations, and provides data through its APIs and user interface. The architecture varies by version but maintains consistent functionality. ![\[Kubecost architecture\]](http://docs.aws.amazon.com/eks/latest/userguide/images/kubecost-architecture.png) You can write queries to ingest Kubecost data into your current business intelligence system for further analysis. You can also use it as a data source for your current [Grafana](https://grafana.com/) dashboard to display Amazon EKS cluster costs that your internal teams are familiar with. To learn more about how to write queries, see the [OpenCost Configuration](https://opencost.io/docs/installation/prometheus/) documentation or use the example Grafana JSON models in the [Kubecost Github repository](https://github.com/kubecost/cost-analyzer-helm-chart/tree/develop/cost-analyzer) as references. + ** AWS Cost and Usage Report integration** – To perform cost allocation calculations for your Amazon EKS cluster, Kubecost retrieves the public pricing information of AWS services and AWS resources from the AWS Price List API. You can also integrate Kubecost with ** AWS Cost and Usage Report** to enhance the accuracy of the pricing information specific to your AWS account. This information includes enterprise discount programs, reserved instance usage, savings plans, and spot usage. To learn more about how the AWS Cost and Usage Report integration works, see [AWS Cloud Billing Integration](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=integrations-aws-cloud-billing-integration) in the Kubecost documentation. # View resource usage with the Kubernetes Metrics Server The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it isn’t deployed by default in Amazon EKS clusters. For more information, see [Kubernetes Metrics Server](https://github.com/kubernetes-sigs/metrics-server) on GitHub. The Metrics Server is commonly used by other Kubernetes add ons, such as the [Scale pod deployments with Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) or the [Kubernetes Dashboard](eks-managing.md). For more information, see [Resource metrics pipeline](https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) in the Kubernetes documentation. This topic explains how to deploy the Kubernetes Metrics Server on your Amazon EKS cluster. **Important** The metrics are meant for point-in-time analysis and aren’t an accurate source for historical analysis. They can’t be used as a monitoring solution or for other non-auto scaling purposes. For information about monitoring tools, see [Monitor your cluster performance and view logs](eks-observe.md). ## Considerations + If manually deploying Kubernetes Metrics Server onto Fargate nodes using the manifest, configure the `metrics-server` deployment to use a port other than its default of `10250`. This port is reserved for Fargate. The Amazon EKS add-on version of Metrics Server is pre-configured to use port `10251`. + Ensure security groups and network ACLs allow port `10250` between the `metrics-server` Pods and all other nodes and Pods. The Kubernetes Metrics Server still uses port `10250` to collect metrics from other endpoints in the cluster. If you deploy on Fargate nodes, allow both the configured alternate Metrics Server port and port `10250`. ## Deploy as community add-on with Amazon EKS Add-ons **New: You can now deploy Metrics Server as a community add-on using the AWS console or Amazon EKS APIs.** ### Deploy with AWS console 1. Open your EKS cluster in the AWS console 1. From the "Add-ons" tab, select **Get More Add-ons**. 1. From the "Community add-ons" section, select **Metrics Server** and then **Next** 1. EKS determines the appropriate version of the add-on for your cluster. You can change the version using the **Version** dropdown menu. 1. Select **Next** and then **Create** to install the add-on. ### Additional resources Learn more about [Community add-ons](community-addons.md). You install or update community add-ons in the same way as other Amazon EKS Add-ons. + [Create an Amazon EKS add-on](creating-an-add-on.md) + [Update an Amazon EKS add-on](updating-an-add-on.md) + [Remove an Amazon EKS add-on from a cluster](removing-an-add-on.md) ## Deploy with manifest **New: You can now deploy Metrics Server as a community add-on using the AWS console or Amazon EKS APIs. These manifest install instructions will be archived.** 1. Deploy the Metrics Server with the following command: ``` kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml ``` If you are using Fargate, you will need to change this file. In the default configuration, the metrics server uses port 10250. This port is reserved on Fargate. Replace references to port 10250 in components.yaml with another port, such as 10251. 1. Verify that the `metrics-server` deployment is running the desired number of Pods with the following command. ``` kubectl get deployment metrics-server -n kube-system ``` An example output is as follows. ``` NAME READY UP-TO-DATE AVAILABLE AGE metrics-server 1/1 1 1 6m ``` 1. Test the metrics server is working by displaying resource (CPU/memory) usage of nodes. ``` kubectl top nodes ``` 1. If you receive the error message `Error from server (Forbidden)`, you need to update your Kubernetes RBAC configuration. Your Kubernetes RBAC identity needs sufficient permissions to read cluster metrics. Review the [minimum required Kubernetes API permissions for reading metrics](https://github.com/kubernetes-sigs/metrics-server/blob/e285375a49e3bf77ddd78c08a05aaa44f2249ebd/manifests/base/rbac.yaml#L5C9-L5C41) on GitHub. Learn how to [grant AWS IAM Identities such as Roles access to Kubernetes APIs](grant-k8s-access.md#authentication-modes). # Deploy applications with Helm on Amazon EKS The Helm package manager for Kubernetes helps you install and manage applications on your Kubernetes cluster. For more information, see the [Helm documentation](https://docs.helm.sh/). This topic helps you install and run the Helm binaries so that you can install and manage charts using the Helm CLI on your local system. **Important** Before you can install Helm charts on your Amazon EKS cluster, you must configure `kubectl` to work for Amazon EKS. If you have not already done this, see [Connect kubectl to an EKS cluster by creating a kubeconfig file](create-kubeconfig.md) before proceeding. If the following command succeeds for your cluster, you’re properly configured. ``` kubectl get svc ``` 1. Run the appropriate command for your client operating system. + If you’re using macOS with [Homebrew](https://brew.sh/), install the binaries with the following command. ``` brew install helm ``` + For more installation options, see [Installing Helm](https://helm.sh/docs/intro/install/) in the Helm Docs. **Note** If you get a message that `openssl` must first be installed, you can install it with the following command. ``` sudo yum install openssl ``` 1. To pick up the new binary in your `PATH`, Close your current terminal window and open a new one. 1. See the version of Helm that you installed. ``` helm version --template='{{ .Version }}{{ "\n" }}' ``` An example output is as follows. ``` v3.17.2 ``` 1. Make sure the version installed is compatible with your cluster version. Check [Supported Version Skew](https://helm.sh/docs/topics/version_skew/#supported-version-skew) to learn more. For example, if you are running with `3.17.x`, supported Kubernetes version should not out of the range of `1.29.x` \$1 `1.32.x`. 1. At this point, you can run any Helm commands (such as `helm install chart-name `) to install, modify, delete, or query Helm charts in your cluster. If you’re new to Helm and don’t have a specific chart to install, you can: + Experiment by installing an example chart. See [Install an example chart](https://helm.sh/docs/intro/quickstart#install-an-example-chart) in the Helm [Quickstart guide](https://helm.sh/docs/intro/quickstart/). + Create an example chart and push it to Amazon ECR. For more information, see [Pushing a Helm chart](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) in the *Amazon Elastic Container Registry User Guide*. + Install an Amazon EKS chart from the [eks-charts](https://github.com/aws/eks-charts#eks-charts)GitHub repo or from [ArtifactHub](https://artifacthub.io/packages/search?page=1&repo=aws). # Organize Amazon EKS resources with tags You can use *tags* to help you manage your Amazon EKS resources. This topic provides an overview of the tags function and shows how you can create tags. **Topics** + [ ## Tag basics ](#tag-basics) + [ ## Tagging your resources ](#tag-resources) + [ ## Tag restrictions ](#tag-restrictions) + [ ## Tagging your resources for billing ](#tag-resources-for-billing) + [ ## Working with tags using the console ](#tag-resources-console) + [ ## Working with tags using the CLI, API, or `eksctl` ](#tag-resources-api-sdk) **Note** Tags are a type of metadata that’s separate from Kubernetes labels and annotations. For more information about these other metadata types, see the following sections in the Kubernetes documentation: [Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) ## Tag basics A tag is a label that you assign to an AWS resource. Each tag consists of a *key* and an optional *value*. With tags, you can categorize your AWS resources. For example, you can categorize resources by purpose, owner, or environment. When you have many resources of the same type, you can use the tags that you assigned to a specific resource to quickly identify that resource. For example, you can define a set of tags for your Amazon EKS clusters to help you track each cluster’s owner and stack level. We recommend that you devise a consistent set of tag keys for each resource type. You can then search and filter the resources based on the tags that you add. After you add a tag, you can edit tag keys and values or remove tags from a resource at any time. If you delete a resource, any tags for the resource are also deleted. Tags don’t have any semantic meaning to Amazon EKS and are interpreted strictly as a string of characters. You can set the value of a tag to an empty string. However, you can’t set the value of a tag to null. If you add a tag that has the same key as an existing tag on that resource, the new value overwrites the earlier value. If you use AWS Identity and Access Management (IAM), you can control which users in your AWS account have permission to manage tags. ## Tagging your resources The following Amazon EKS resources support tags: + clusters + managed node groups + Fargate profiles You can tag these resources using the following: + If you’re using the Amazon EKS console, you can apply tags to new or existing resources at any time. You can do this by using the **Tags** tab on the relevant resource page. For more information, see [Working with tags using the console](#tag-resources-console). + If you’re using `eksctl`, you can apply tags to resources when they’re created using the `--tags` option. + If you’re using the AWS CLI, the Amazon EKS API, or an AWS SDK, you can apply tags to new resources using the `tags` parameter on the relevant API action. You can apply tags to existing resources using the `TagResource` API action. For more information, see [TagResource](https://docs.aws.amazon.com/eks/latest/APIReference/API_TagResource.html). When you use some resource-creating actions, you can also specify tags for the resource at the same time that you create it. If tags can’t be applied while the resource is being created, the resource fails to be created. This mechanism ensures that resources that you intend to tag are either created with the tags that you specify or not created at all. If you tag resources when you create them, you don’t need to run custom tagging scripts after you create the resource. Tags don’t propagate to other resources that are associated with the resource that you create. For example, Fargate profile tags don’t propagate to other resources that are associated with the Fargate profile, such as the Pods that are scheduled with it. ## Tag restrictions The following restrictions apply to tags: + A maximum of 50 tags can be associated with a resource. + Tag keys can’t be repeated for one resource. Each tag key must be unique, and can only have one value. + Keys can be up to 128 characters long in UTF-8. + Values can be up to 256 characters long in UTF-8. + If multiple AWS services and resources use your tagging schema, limit the types of characters you use. Some services might have restrictions on allowed characters. Generally, allowed characters are letters, numbers, spaces, and the following characters: `+` `-` `=` `.` `_` `:` `/` `@`. + Tag keys and values are case sensitive. + Don’t use `aws:`, ` AWS:`, or any upper or lowercase combination of such as a prefix for either keys or values. These are reserved only for AWS use. You can’t edit or delete tag keys or values with this prefix. Tags with this prefix don’t count against your tags-per-resource limit. ## Tagging your resources for billing When you apply tags to Amazon EKS clusters, you can use them for cost allocation in your **Cost & Usage Reports**. The metering data in your **Cost & Usage Reports** shows usage across all of your Amazon EKS clusters. For more information, see [AWS cost and usage report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage.html) in the * AWS Billing User Guide*. The AWS generated cost allocation tag, specifically `aws:eks:cluster-name`, lets you break down Amazon EC2 instance costs by individual Amazon EKS cluster in **Cost Explorer**. However, this tag doesn’t capture the control plane expenses. The tag is automatically added to Amazon EC2 instances that participate in an Amazon EKS cluster. This behavior happens regardless of whether the instances are provisioned using Amazon EKS managed node groups, Karpenter, or directly with Amazon EC2. This specific tag doesn’t count towards the 50 tags limit. To use the tag, the account owner must activate it in the AWS Billing console or by using the API. When an AWS Organizations management account owner activates the tag, it’s also activated for all organization member accounts. You can also organize your billing information based on resources that have the same tag key values. For example, you can tag several resources with a specific application name, and then organize your billing information. That way, you can see the total cost of that application across several services. For more information about setting up a cost allocation report with tags, see [The Monthly Cost Allocation Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html) in the * AWS Billing User Guide*. **Note** If you just enabled reporting, data for the current month is available for viewing after 24 hours. **Cost Explorer** is a reporting tool that’s available as part of the AWS Free Tier. You can use **Cost Explorer** to view charts of your Amazon EKS resources from the last 13 months. You can also forecast how much you’re likely to spend for the next three months. You can see patterns in how much you spend on AWS resources over time. For example, you can use it to identify areas that need further inquiry and see trends that you can use to understand your costs. You also can specify time ranges for the data, and view time data by day or by month. ## Working with tags using the console Using the Amazon EKS console, you can manage the tags that are associated with new or existing clusters and managed node groups. When you select a resource-specific page in the Amazon EKS console, the page displays a list of those resources. For example, if you select **Clusters** from the left navigation pane, the console displays a list of Amazon EKS clusters. When you select a resource from one of these lists (for example, a specific cluster) that supports tags, you can view and manage its tags on the **Tags** tab. You can also use **Tag Editor** in the AWS Management Console, which provides a unified way to manage your tags. For more information, see [Tagging your AWS resources with Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) in the * AWS Tag Editor User Guide*. ### Adding tags on a resource on creation You can add tags to Amazon EKS clusters, managed node groups, and Fargate profiles when you create them. For more information, see [Create an Amazon EKS cluster](create-cluster.md). ### Adding and deleting tags on a resource You can add or delete the tags that are associated with your clusters directly from the resource’s page. 1. Open the [Amazon EKS console](https://console.aws.amazon.com/eks/home#/clusters). 1. On the navigation bar, select the AWS Region to use. 1. In the left navigation pane, choose **Clusters**. 1. Choose a specific cluster. 1. Choose the **Tags** tab, and then choose **Manage tags**. 1. On the **Manage tags** page, add or delete your tags as necessary. + To add a tag, choose **Add tag**. Then specify the key and value for each tag. + To delete a tag, choose **Remove tag**. 1. Repeat this process for each tag that you want to add or delete. 1. Choose **Update** to finish. ## Working with tags using the CLI, API, or `eksctl` Use the following AWS CLI commands or Amazon EKS API operations to add, update, list, and delete the tags for your resources. You can only use `eksctl` to add tags while simultaneously creating the new resources with one command. | Task | AWS CLI | AWS Tools for Windows PowerShell | API action | | --- | --- | --- | --- | | Add or overwrite one or more tags. | [tag-resource](https://docs.aws.amazon.com/cli/latest/reference/eks/tag-resource.html) | [Add-EKSResourceTag](https://docs.aws.amazon.com/powershell/latest/reference/items/Add-EKSResourceTag.html) | [TagResource](https://docs.aws.amazon.com/eks/latest/APIReference/API_TagResource.html) | | Delete one or more tags. | [untag-resource](https://docs.aws.amazon.com/cli/latest/reference/eks/untag-resource.html) | [Remove-EKSResourceTag](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EKSResourceTag.html) | [UntagResource](https://docs.aws.amazon.com/eks/latest/APIReference/API_UntagResource.html) | The following examples show how to tag or untag resources using the AWS CLI. **Example 1: Tag an existing cluster** The following command tags an existing cluster. ``` aws eks tag-resource --resource-arn resource_ARN --tags team=devs ``` **Example 2: Untag an existing cluster** The following command deletes a tag from an existing cluster. ``` aws eks untag-resource --resource-arn resource_ARN --tag-keys tag_key ``` **Example 3: List tags for a resource** The following command lists the tags that are associated with an existing resource. ``` aws eks list-tags-for-resource --resource-arn resource_ARN ``` When you use some resource-creating actions, you can specify tags at the same time that you create the resource. The following actions support specifying a tag when you create a resource. | Task | AWS CLI | AWS Tools for Windows PowerShell | API action | eksctl | | --- | --- | --- | --- | --- | | Create a cluster | [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html) | [New-EKSCluster](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EKSCluster.html) | [CreateCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html) | `create cluster` | | Create a managed node group\$1 | [create-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html) | [New-EKSNodegroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EKSNodegroup.html) | [CreateNodegroup](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateNodegroup.html) | `create nodegroup` | | Create a Fargate profile | [create-fargate-profile](https://docs.aws.amazon.com/cli/latest/reference/eks/create-fargate-profile.html) | [New-EKSFargateProfile](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EKSFargateProfile.html) | [CreateFargateProfile.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateFargateProfile.html) | `create fargateprofile` | + If you want to also tag the Amazon EC2 instances when you create a managed node group, create the managed node group using a launch template. For more information, see [Tagging Amazon EC2 instances](launch-templates.md#launch-template-tagging). If your instances already exist, you can manually tag the instances. For more information, see [Tagging your resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-resources) in the Amazon EC2 User Guide. # View and manage Amazon EKS and Fargate service quotas Amazon EKS has integrated with Service Quotas, an AWS service that you can use to view and manage your quotas from a central location. For more information, see [What Is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) in the *Service Quotas User Guide*. With Service Quotas integration, you can quickly look up the value of your Amazon EKS and AWS Fargate service quotas using the AWS Management Console and AWS CLI. ## View EKS service quotas in the AWS Management Console 1. Open the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home/services/eks/quotas). 1. In the left navigation pane, choose ** AWS services**. 1. From the ** AWS services** list, search for and select **Amazon Elastic Kubernetes Service (Amazon EKS)** or ** AWS Fargate**. In the **Service quotas** list, you can see the service quota name, applied value (if it’s available), AWS default quota, and whether the quota value is adjustable. 1. To view additional information about a service quota, such as the description, choose the quota name. 1. (Optional) To request a quota increase, select the quota that you want to increase, select **Request quota increase**, enter or select the required information, and select **Request**. To work more with service quotas using the AWS Management Console, see the [Service Quotas User Guide](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html). To request a quota increase, see [Requesting a Quota Increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*. ## View EKS service quotas with the AWS CLI Run the following command to view your Amazon EKS quotas. ``` aws service-quotas list-aws-default-service-quotas \ --query 'Quotas[*].{Adjustable:Adjustable,Name:QuotaName,Value:Value,Code:QuotaCode}' \ --service-code eks \ --output table ``` Run the following command to view your Fargate quotas. ``` aws service-quotas list-aws-default-service-quotas \ --query 'Quotas[*].{Adjustable:Adjustable,Name:QuotaName,Value:Value,Code:QuotaCode}' \ --service-code fargate \ --output table ``` **Note** The quota returned is the number of Amazon ECS tasks or Amazon EKS Pods that can run concurrently on Fargate in this account in the current AWS Region. To work more with service quotas using the AWS CLI, see [service-quotas](https://docs.aws.amazon.com/cli/latest/reference/service-quotas/index.html) in the * AWS CLI Command Reference*. To request a quota increase, see the [request-service-quota-increase](https://docs.aws.amazon.com/cli/latest/reference/service-quotas/request-service-quota-increase.html) command in the * AWS CLI Command Reference*. ## Amazon EKS service quotas AWS recommends using the AWS Management Console to view your current quotas. For more information, see [View EKS service quotas in the AWS Management Console](#service-quotas-console). To view the default EKS service quotas, see [Amazon Elastic Kubernetes Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html#limits_eks) in the * AWS General Reference*. These service quotas are listed under **Amazon Elastic Kubernetes Service (Amazon EKS)** in the Service Quotas console. To request a quota increase for values that are shown as adjustable, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*. **Note** Adjustments to the following components are **not** supported in Service Quotas: \$1 Pod Identity associations per cluster. For limits, see [Learn how EKS Pod Identity grants pods access to AWS services](pod-identities.md). \$1 CIDRs for Remote Node Networks or Remote Pod Networks for hybrid nodes. For limits, see [Amazon EKS Hybrid Nodes overview](hybrid-nodes-overview.md). ## AWS Fargate service quotas The ** AWS Fargate** service in the Service Quotas console lists several service quotas. You can configure alarms that alert you when your usage approaches a service quota. For more information, see [Creating a CloudWatch alarm to monitor Fargate resource usage metrics](monitoring-fargate-usage.md#service-quota-alarm). New AWS accounts might have lower initial quotas that can increase over time. Fargate constantly monitors the account usage within each AWS Region, and then automatically increases the quotas based on the usage. You can also request a quota increase for values that are shown as adjustable. For more information, see [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*. AWS recommends using the AWS Management Console to view your current quotas. For more information, see [View EKS service quotas in the AWS Management Console](#service-quotas-console). To view default AWS Fargate on EKS service quotas, see [Fargate service quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html#service-quotas-eks-fargate) in the * AWS General Reference*. **Note** Fargate additionally enforces Amazon ECS tasks and Amazon EKS Pods launch rate quotas. For more information, see [AWS Fargate throttling quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/throttling.html) in the *Amazon ECS guide*.