--- title: "Billing options for TIR Kubernetes" description: "How a TIR Kubernetes cluster is billed per node pool, hourly or committed, what happens at the end of a term, and what deleting a pool or cluster costs." content_type: "concept" product: "tir-kubernetes" platform: "TIR" url: "/tir/tir-kubernetes/concepts/billing-options/" --- # Billing options for TIR Kubernetes A TIR Kubernetes cluster is billed per node pool. The control plane is a pool with its own plan, and each worker pool has its own plan. One cluster can therefore mix pools, for example a committed pool for the steady base load and an hourly pool for bursts. Each plan is either **On-Demand**, billed by the hour, or committed for a number of days, shown as ` Days Committed`. The rates are on [E2E's pricing page](https://www.e2enetworks.com/pricing). ## What you pay for You pay for the nodes in each pool, at the pool's plan rate. The pods, Services, and jobs you run on the cluster, and the add-ons the platform installs, are included in that price. A node costs the same whether it is busy or idle. The control plane is billed for its number of nodes from when it is ready until you delete the cluster. That includes the time the cluster shows **Failed** or **Deleting**. You choose its plan, number of nodes, and commitment policy when you create the cluster, and none of them can be changed later. Reserved IPs that you attach to the cluster's LB IP pool are billed as reserved IPs, whether they are attached or detached. See [Reserved IP billing](/tir/tir-reserved-ip/concepts/reserved-ip-billing/). The create form also shows cluster storage, under **Cluster summary**, as **Estimated cost (Usage-based)** per GB per month. ## Hourly pools An **On-Demand** worker pool is billed by the hour for each node, only while that node is up and ready. A node that is starting, joining, failed, not ready, or being removed is free of charge. | What happens to the pool | What happens to its billing | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | You create it | Each node is billed once it is up and ready | | You resize it up, or autoscaling adds nodes | Each new node is billed once it is up and ready | | You resize it down, or autoscaling removes nodes | The removed nodes stop being billed | | You delete it | Billing stops at the moment you ask | | You delete the cluster | Billing stops for every worker pool at the moment you ask | | The cluster ends at **Failed** | The worker pools stop being billed; the control plane stays billed until you delete the cluster | You can resize an hourly pool, or autoscale it where the region offers autoscaling, whenever the pool and the cluster are ready. That makes hourly pools the right choice while you are still learning how much capacity a workload needs. See [Resize or autoscale a worker pool](/tir/tir-kubernetes/how-to/resize-or-autoscale-a-worker-pool/). ## Committed pools A committed pool is paid upfront for a fixed term. The terms on offer depend on the plan you choose. - The whole term is charged upfront, for the pool's number of nodes. - The pool keeps the same number of nodes for the whole term. Only hourly pools can autoscale. - If you delete the pool, or the cluster, before the term ends, the term keeps running. You paid for the whole term upfront, and that money is not returned. - The pool's commitment policy sets what happens when the term ends. When you create a cluster with a committed pool, or add a committed pool to a cluster, **Committed Plans Confirmation** opens first. It lists each committed resource with its **Configuration Details**, **Committed Plan**, **Commitment Policy**, and **Committed Upto** date. Tick the box to confirm that the amount is deducted upfront for the whole term and is not refunded if you delete early. Then select **Proceed**. Size a committed pool for the whole term. If the workload grows, add a separate pool beside it instead of growing the committed pool. A cluster can have as many worker pools as you need. The safest path is to start a pool hourly, learn the size the workload needs, and then move it to a committed plan. ### Move an hourly pool to a committed plan An hourly worker pool that is **Ready** can move to a committed plan in place. An autoscaled pool needs a fixed size first. Moving it charges the whole term upfront, so a prepaid account needs enough credit for it. From then on, the pool keeps its size until the term ends. See [Manage committed plans for worker pools](/tir/tir-kubernetes/how-to/manage-committed-plans/). ## What happens when a term ends Every committed pool has a commitment policy, chosen when you set up the pool: - **Auto-renew the committed plan** is the default. When the term ends, a new term starts if the account has enough credit. If the credit falls short, the pool moves to hourly billing instead. - **Switch to hourly billing** moves the pool to its hourly plan when the term ends, and the pool can then be resized again. ```mermaid flowchart TD A[Committed term ends] --> B{Commitment policy} B -->|Auto-renew the committed plan| C{Enough credit?} C -->|Yes| D[New term starts] C -->|No| E[Pool moves to hourly billing] B -->|Switch to hourly billing| E E --> F[Pool can be resized again] ``` To change a committed worker pool's policy during its term, select **Update Commitment Policy** on the pool's row on the **Node Pool** tab. The change applies only when the current term ends: the term still runs its full length. The control plane's policy is chosen when you create the cluster and stays fixed after that. See [Manage committed plans for worker pools](/tir/tir-kubernetes/how-to/manage-committed-plans/). ## Credit you need on a prepaid account On a prepaid account, TIR checks your credit before it creates anything. Creating a cluster, adding a pool, growing a pool, and moving a pool to a committed plan each need enough credit. If you are short, TIR refuses the request with a message that starts "Insufficient Credits!" and says how many credits to buy. For a committed plan, that is the credit for the whole term. For an hourly plan, it is enough to run the resource for a number of hours. An account still on unverified free credit sees one more confirmation when it creates a cluster. It warns that the cluster is deleted automatically if the account's credits become negative. ## See what a cluster costs Each form shows the estimated cost of what you are adding before you save, and the **Node Pool** tab gives each pool's plan and price. Your usage then lists each of a cluster's pools on its own line, with the cluster name, pool name, plan, and number of nodes. See [Analyse usage](/tir/tir-billing/how-to/analyse-usage/). ## What deleting costs | What you do | Hourly pools | Committed pools | | -------------------- | ----------------------------------- | --------------------------------------------------- | | Delete a worker pool | Billing stops at the moment you ask | The term runs on, and the upfront charge is final | | Resize a pool down | The removed nodes stop being billed | Possible only once the pool moves to hourly billing | | Delete the cluster | Billing stops at the moment you ask | The term runs on, and the upfront charge is final | Deleting the cluster also deletes its storage and volumes. Its attached reserved IPs go back to the project and stay billed as reserved IPs until you delete them. See [Delete a Kubernetes cluster](/tir/tir-kubernetes/how-to/delete-a-cluster/). For short answers on charges, see the [TIR Kubernetes FAQ](/tir/tir-kubernetes/faq/).