> For the complete documentation index, see [llms.txt](https://docs.finout.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.finout.io/kubernetes-integrations/kubernetes/finout-eks-kubernetes-agent/eks-kubernetes-agent-faqs.md). # EKS Kubernetes Agent FAQs **Availability:** Generally available for EKS. If you need additional assistance, contact Finout at . *** #### Does the Central Collector support horizontal scaling? No. The Central Collector runs as a single replica by design, backed by a `PersistentVolumeClaim`. Based on load testing at scale, a single replica is sufficient for large clusters. *** #### What happens to data if the Central Collector pod restarts or is rescheduled? The agent is designed to survive restarts with minimal data loss: * **Rotated metric files** persist on the PVC and survive pod restarts, rescheduling, and node failures. Once a file is rotated, it remains on disk until the uploader confirms delivery to S3. * **Node Collectors** buffer and retry while the Central Collector is temporarily unavailable, so metrics continue to flow without manual intervention. * **In-flight data** — the batch held in memory at the moment of a crash — may be lost. With a 30-second scrape interval, this is typically 1–2 scrape windows and is negligible for cost allocation purposes. *** #### Is traffic between Node Collectors and the Central Collector availability-zone-aware? No. Because the Central Collector runs as a single replica, there is no AZ topology awareness. Cross-AZ traffic between Node Collectors and the Central Collector may incur standard inter-AZ data transfer costs from your cloud provider. *** #### Does the agent require any inbound network access or open ports? No. The agent requires outbound HTTPS only — no inbound ports are opened. All communication originates from within the cluster. *** #### How does the agent authenticate uploads to S3? The agent fetches short-lived presigned URLs from `app.finout.io` and uses them to upload metric files directly to S3. Each presigned URL is scoped to a single upload operation and expires automatically — no static S3 credentials are stored in the cluster *** #### How can I avoid NAT Gateway charges for metric uploads? If your Kubernetes worker nodes are in private subnets and reach S3 via an AWS NAT Gateway, metric uploads may incur NAT Gateway data processing fees. To avoid this, configure an [S3 Gateway VPC Endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html) in the VPC that hosts your cluster. When configuring the endpoint: * **Endpoint type:** Gateway Endpoint for S3 (`com.amazonaws..s3`) * **Route tables:** Associate with the route tables used by your Kubernetes worker nodes * **Endpoint policy (if restrictive):** Ensure it permits `s3:PutObject` to Finout's ingestion bucket Contact Finout Support to obtain the Finout bucket details. *** #### How do I uninstall the agent? See the [Install the Finout EKS Kubernetes Agent](#how-do-i-uninstall-the-agent) guide for uninstall instructions. *** #### **How do I migrate from an existing Kubernetes integration to the Kubernetes Agent?** Migration from an existing Kubernetes integration ([Prometheus](/kubernetes-integrations/kubernetes/prometheus.md) or [Datadog](/kubernetes-integrations/kubernetes/datadog.md)) to the agent is **handled by the Finout team** — you don't need to manage the cutover yourself. After the agent is installed successfully on all your clusters, the Finout team will stop your existing Prometheus/Datadog enrichment and replace it with the agent Cost Center, ensuring no overlap between the two data sources on the same cluster. Any overlap would cause duplicated metrics and compromised costs. {% hint style="danger" %} Do not stop the Finout Prometheus/Datadog integration until the Finout team confirms the migration has completed successfully. {% endhint %} **Why do my costs look slightly different after migrating to the agent?** Minor differences are expected and normal. A few reasons: * **Scrape frequency and timing** — the agent runs on its own schedule, independent of Prometheus/Datadog collection intervals * **Broader metric coverage** — the agent scrapes all available metrics and labels by default, whereas a customer's existing monitoring stack may not expose all of them. This typically results in lower idle cost and more accurate allocation on the agent side. * **More accurate network cost allocation** — the agent excludes network metrics for pods running with `hostNetwork: true` configuration, by default. Pods with this configuration share the node's network namespace, causing a report of full node-level traffic per pod — inflating their network costs. The agent corrects this automatically by filtering out these pods’ network metrics. * Customers migrating from the **CronJob** will see lower network costs for those workloads and a slight increase in idle — total cluster cost stays the same, the attribution is just more accurate. * Customers migrating from **Datadog** won't see this difference, as Datadog already excludes `hostNetwork` pods from network metrics on their end. *** #### **Can I use the Finout Kubernetes agent and the Prometheus CronJob in the same environment** Yes. You can run the agent on some clusters and the CronJob on others, for example the agent on dev EKS and the CronJob on prod EKS. Each cluster must be covered by only one integration. Please contact Finout Support to set up this combination. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.finout.io/kubernetes-integrations/kubernetes/finout-eks-kubernetes-agent/eks-kubernetes-agent-faqs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.