Billing model
Aether bills different things different ways depending on what you’re running. This page describes the model and structure. For your own invoices and the prices as they stand today, see the Billing page in the portal.
All prices are in EUR and exclude VAT — the VAT treatment that applies to your organization is shown on the invoice. Charges are invoiced monthly, and a billing month runs in UTC.
The control plane is free
Section titled “The control plane is free”Your cluster’s Kubernetes control plane costs nothing. Aether runs and manages the API server, controller manager, scheduler, and the cluster’s datastore, and none of it appears as a charge. There is no control-plane fee: on a custom cluster, the only flat charge that belongs to the cluster itself is the public API endpoint IPv4 — every cluster has one, and it is mandatory — described under Other charges. A package cluster bills the package’s flat price per cluster as well.
Packages and custom clusters
Section titled “Packages and custom clusters”A cluster is billed one of two ways, chosen when you create it and fixed for the cluster’s lifetime. There is no field to switch a cluster between them afterwards — to change, create another cluster.
- From a package — you pick one of the packages below, and the cluster bills that package’s flat monthly price. The price covers an included allowance of vCPUs, memory, and node disk for the whole cluster. Anything beyond that allowance is charged on top, per resource, as a separate overage line.
- Custom — you pick no package, and every fixed pool is priced per resource from the rate card: €8 per vCPU, €3.50 per GB of memory and €0.12 per GB of node disk, per month.
A cluster is billed one way or the other — never as a package and as a custom cluster.
The packages
Section titled “The packages”| Package | Price | Included allowance (whole cluster) | Shown in the portal as |
|---|---|---|---|
| Dev | €29 / month | 1 node · 2 vCPU · 8 GB · 50 GB disk | 1 × 2 vCPU / 8 GB / 50 GB |
| Starter | €79 / month | 2 nodes · 8 vCPU · 32 GB · 200 GB disk | 2 × 4 vCPU / 16 GB / 100 GB |
| Growth | €179 / month | 3 nodes · 24 vCPU · 96 GB · 600 GB disk | 3 × 8 vCPU / 32 GB / 200 GB |
| Scale | €279 / month | 5 nodes · 40 vCPU · 160 GB · 2500 GB disk | 5 × 8 vCPU / 32 GB / 500 GB |
The allowance is a whole-cluster budget of vCPUs, memory and node disk, not a per-pool one and not a node count — you are free to spend it across pools in whatever shape you like. The per-node shape in the last column is how the portal illustrates the same totals; it is not a constraint on how you spend them.
The package fee’s terms
Section titled “The package fee’s terms”The package price is a flat monthly fee on the same terms as a fixed pool: billed for the full calendar month, not prorated, and not refunded if you delete the cluster. The amount is locked when its grace period expires, for the month in which the grace period expires; in every later month it is locked the first time the cluster is seen in that month. The 15-minute grace period applies through the cluster — the fee is not charged if the cluster is removed within 15 minutes of its first node appearing in the cluster’s node list.
Overage
Section titled “Overage”Your fixed pools consume the allowance first. Per dimension, anything above the allowance is an overage line at the per-resource rates — €8 per vCPU, €3.50 per GB of memory, €0.12 per GB of node disk.
Each dimension stands on its own: unused memory does not offset extra vCPUs, and unused allowance is not credited back. The overage amount is locked at the first observation in the month that sees post-grace nodes over the allowance, on the same monthly terms as the package fee, and node count is not priced — only the three dimensions are.
Newly created nodes do not trigger package overage during their initial 15-minute grace period. If removal is requested within that period, no overage is charged for that node.
If we detect repeated creation and removal intended to exploit this grace period, we may defer removal until the node is at least 16 minutes old. The grace-period exemption then no longer applies, and the applicable package overage charges become payable. This enforcement delay is separate from ordinary node draining, which does not extend billable lifetime.
How much. Worked through, on a Starter cluster (allowance 8 vCPU / 32 GB / 200 GB) whose fixed pools total 12 vCPU, 32 GB and 300 GB:
| Dimension | Used | Allowance | Over by | Overage |
|---|---|---|---|---|
| vCPU | 12 | 8 | 4 | 4 × €8 = €32.00 |
| Memory | 32 GB | 32 GB | 0 | — |
| Node disk | 300 GB | 200 GB | 100 GB | 100 × €0.12 = €12.00 |
That month bills €127.00 — €79.00 for the package, €44.00 of overage, and the mandatory €4 public API endpoint. The memory dimension sits exactly on its allowance, so it contributes nothing — and it would contribute nothing if it were under the allowance either.
When. An overage line that first appears mid-month is charged for that month. There is no overage line at all until the cluster’s fixed pools exceed the allowance, counting only nodes whose grace period has expired, so the first observation that sees an overage is the one that locks it — unlike a fixed pool’s own fee, which is already locked by then. Growing a package cluster that was sitting inside its allowance therefore costs you in the month you grow it — once the node that takes it over the allowance is past its 15-minute grace period. A node whose removal is requested within that period creates no overage line (unless an enforcement delay applies, as described above).
Take the same Starter cluster sitting exactly on its allowance — 2 × (4 vCPU / 16 GB / 100 GB) — and add a third node of the same shape on day 10. It is now over on all three dimensions, memory included, which is what makes it dearer than the table above: 4 vCPU, 16 GB and 100 GB over, so an overage line of 4 × €8 + 16 × €3.50 + 100 × €0.12 = €100.00 is charged for that month, on top of the package fee and the mandatory €4 public API endpoint. Once the line exists, further growth does not reprice it until the next month.
Autoscaling nodes on a package cluster
Section titled “Autoscaling nodes on a package cluster”Any allowance still left after the fixed pools covers autoscaling nodes, in the order they come up: a node whose shape fits entirely inside what remains is covered by the package and accrues no hourly charge, and once the allowance runs out the next node bills by the hour like any other autoscaling node. A node keeps the treatment it got when it came up.
Node disk — €0.12 per GB per month. This is the worker VM’s own disk, sized per node pool. It is part of the node’s price and follows the pool’s billing mode — flat monthly for a fixed pool, per started node-hour for an autoscaling pool. It is not a persistent volume; those are billed separately under Storage and registry.
The 15-minute grace period
Section titled “The 15-minute grace period”Every node has a 15-minute grace period, measured from the moment it first
appears in the cluster’s node list, whether or not it becomes Ready. It applies
to every node in a fixed or an autoscaling pool — the pool’s first nodes, nodes
added later, and replacement nodes alike.
- A node removed within its grace period carries no node charge. A node counts as removed when its removal is requested — you delete it, scale the pool down, or delete the pool or the cluster. The time it then spends draining does not count against the grace period and is never billed.
- Fixed pools bill per pool, not per node, so the grace period works through the pool: the pool’s monthly fee is not charged if the pool is removed within 15 minutes of its first node appearing in the cluster’s node list. The amount is locked when the grace period expires, for the month in which it expires; in every later month it is locked the first time the pool — or, for a package, the cluster — is seen in that month. No proration, and deleting the pool later in a month does not refund the locked amount.
- Autoscaling pools bill per node: after its grace period a node bills per started node-hour (its monthly price ÷ 730, each started hour rounded up), counted from the moment the node first appears in the cluster’s node list — the same event the grace period starts from — and the grace period is not deducted.
- Aether records every node and pool from the moment it exists — that record is what the portal’s usage views and your invoice are computed from. A payable charge is locked only when the grace period passes: for a fixed pool or a package, its month; for an autoscaling node, its first started hour — which is counted from the node’s first appearance, not from the end of the grace period.
Worked through, for a fixed pool: a pool created at 12:00 whose first node appears in the node list at 12:08 and whose removal is requested at 12:20 has run for 12 minutes: no charge.
The grace period covers the node, and nothing else it shares a cluster with:
- The public API endpoint and load balancers (Other charges) lock a whole month the first time the billing sampler observes the address. The sampler runs every few minutes, so that first observation is a distinct event from the moment the address is created — there is no hourly accrual and no proration for them.
- Persistent volumes and registry storage (Storage and registry) are charged per hourly observation instead, so a volume or an image that is created and deleted between two observations costs nothing — not because a grace period covered it, but because nothing ever observed it.
The API reports each node’s created_at and age_seconds on a pool’s
machines endpoint, so you can see how old a node is. There is no countdown timer
in the portal.
Anti-abuse exception
Section titled “Anti-abuse exception”The grace period exists so that provisioning mistakes, failed nodes, and genuine short experiments don’t cost you anything. Where an account creates and destroys nodes in a pattern that exploits the grace period, Aether may defer a removal past the window and charge for the node — the same rule the Terms of Service state.
This is an exception applied to abuse, not the ordinary course, and there is no setting or API field that controls it. It is also distinct from an ordinary drain: a drain delays when a node disappears, never when its billing stops.
Flat monthly: fixed pools
Section titled “Flat monthly: fixed pools”Fixed pools — the ones whose CPU/memory budget permits no scaling (minimum and maximum total vCPUs equal, and the same for total memory), so the pool holds a constant number of nodes — bill a flat monthly fee once the pool is past its 15-minute grace period:
- Billed for the full calendar month — there is no proration.
- The amount — including the pool’s node count — is locked when its grace period expires, for the month in which the grace period expires; in every later month it is locked the first time the pool — or, for a package, the cluster — is seen in that month.
- Deleting the pool later in a month does not refund the locked amount.
So a fixed pool removed inside its 15-minute grace period costs nothing, and a fixed pool kept past its grace period is billed for the whole month even if you delete it the same day. This makes the cost of steady-state infrastructure predictable.
Changing a fixed pool
Section titled “Changing a fixed pool”- Decreasing the node count mid-month does not reduce the locked amount. The next month locks at the new size.
- Increasing the node count behaves differently on a custom cluster and on a
package cluster:
- On a custom cluster the increase is reflected from next month’s amount. No additional charge is added within the month you make the change.
- On a package cluster, growth that pushes the cluster past its allowance for the first time in that month creates an overage line, and that line is charged for the month it first appears in — there is no overage until the cluster’s fixed pools exceed the allowance, counting only nodes whose grace period has expired, so the first observation that sees one is also the one that locks it. If an enforcement delay applies (see Anti-abuse exception), the grace-period exemption no longer applies to that node and the overage becomes payable. An overage line that already exists is not repriced by further growth until next month.
- Changing a fixed pool’s per-node vCPU, memory or disk after creation is not supported today. To change node size, create a new pool with the new shape and drain the old one. The new pool has its own 15-minute grace period and its own monthly charge, and the old pool’s locked month stays payable.
- Deleting a pool and creating another — even with the same name, in the same month — creates a new pool with its own grace period and its own monthly charge. The old pool’s locked month stays payable.
Month boundaries
Section titled “Month boundaries”A fixed pool’s or a package’s month becomes payable only when its grace period expires, and it is charged for the month in which the grace period expires; after that it is charged for every calendar month in which it exists.
For example: a pool whose first node appears at 23:55 UTC on 30 September has a grace period that ends at 00:10 UTC on 1 October. September is not charged, and October becomes payable if the pool is still there when the grace period ends — October’s amount locking at that moment, and each later month’s the first time the pool — or, for a package, the cluster — is seen in it.
On a package cluster, fixed pools don’t produce their own charges — they consume the package’s included allowance, and only the excess shows up, as the package’s overage line.
Hourly per node: autoscaling pools
Section titled “Hourly per node: autoscaling pools”Autoscaling pools — the ones whose CPU/memory budget permits scaling (its maximum exceeds its minimum on total vCPUs or on total memory) — bill hourly, per node, because their size changes with demand. A pool’s node count never decides this: an autoscaling pool sitting at one node still bills hourly.
- A node that outlives its 15-minute grace period bills per started node-hour at the monthly rate divided by 730, with each started hour rounded up. Started hours are counted from the moment the node first appears in the cluster’s node list — the same event the grace period starts from — and cover the node’s whole lifetime from that moment, rounded up to the next hour: the grace period is not deducted first.
- A node-hour bills in the UTC month in which that hour starts, so a node running across a month boundary splits its hours between the two months.
Worked through, for a node of 4 vCPU / 16 GB / 100 GB disk. Its monthly price is 4 × €8 + 16 × €3.50 + 100 × €0.12 = €100.00, so an hour costs €100.00 ÷ 730 = €0.1370:
| Node lifetime | Charge |
|---|---|
| Removed after 10 minutes | Nothing — the removal fell inside the 15-minute grace period. |
| 40 minutes | 1 hour → €0.14 |
| 70 minutes | 2 hours — the second hour started → €0.27 |
On a package cluster, an autoscaling node that still fits inside the package’s unused allowance is covered by the package price and doesn’t accrue hourly at all. Hourly billing starts with the first node that no longer fits.
Deletion and the billing cutoff
Section titled “Deletion and the billing cutoff”Billing for a node ends when its removal is requested, before the drain runs. For example: you scale a pool down at minute 12 and the node drains until minute 21. Its lifetime for billing is 12 minutes — inside the grace period — so it carries no charge.
The rest of the cutoff, in one place:
- Deleting a fixed pool or a package cluster after its grace period does not refund the locked month.
- Deleting a cluster does not refund the €4 endpoint month, or any load-balancer month already locked.
- Hourly nodes stop accruing when the deletion is requested.
- Storage stops at the next hourly observation that no longer sees the volumes.
- Registry storage is metered per organization and is unaffected by deleting a cluster.
- Deleting a cluster destroys its workloads, volumes and data. Aether keeps no copy.
Other charges
Section titled “Other charges”These are billed independently of node pools, and none of them is covered by the node grace period. The public API endpoint and load balancers below lock their month the first time the billing sampler observes the address — the sampler runs every few minutes, so that is a distinct event from the moment the address is created. Persistent volumes and registry storage are not locked at all: once per clock hour the sampler observes what exists and charges that hour, so a volume or an image created and deleted between two observations costs nothing (see Storage and registry).
Public API endpoint IPv4 — €4 per cluster per month. Every cluster has a public Kubernetes API endpoint, and its IPv4 address carries this flat charge. It is billed for the full calendar month, with no proration, and the amount is locked the first time the billing sampler observes the address in that month. There is no configuration that removes the endpoint or its charge.
Load balancers — €8 per load balancer per month. Same monthly terms as the endpoint: full month, no proration, locked the first time the billing sampler observes the address. The price includes the public IP the Service answers on; that address is never billed again as a separate public-IP charge. The charge is keyed on that address: a Service recreated within the month on the same address is charged once, and a new address is a new charge.
Container registry — €0.15 per started GiB per month, metered at the organization level rather than per cluster. Trivy vulnerability scanning is included at no extra charge.
Volume snapshots — €0.05 per GB per month. This rate is priced in the rate card, but snapshots are not yet available to tenant clusters and are not currently metered, so they do not appear on your invoice today.
No egress, bandwidth, or API-call fees. Aether does not charge for network traffic in or out of your clusters, and does not charge per Kubernetes or Aether API request.
Storage and registry
Section titled “Storage and registry”Persistent volumes and registry storage are measured in GiB (1 GiB = 1024³ bytes — the unit Kubernetes and the registry themselves report). Node disk is the size you type per node in GB, and it is part of the node’s price rather than a persistent volume. Snapshot pricing is per GB, but snapshots are unavailable and unmetered.
| What | Billed on | Rate |
|---|---|---|
aether-block (ReadWriteOnce) |
Provisioned size | €0.15 per GiB per month |
aether-shared (ReadWriteMany) |
Used bytes | €0.18 per GiB per month |
| Container registry | Repository storage, per organization | €0.15 per started GiB per month |
- Block storage: charged for the provisioned capacity, regardless of how much data is stored.
- Shared storage: charged for actual usage observed at billing measurement time, because capacity is not hard-quota limited.
How it is measured
Section titled “How it is measured”Once every clock hour (UTC), at the same minute of each hour (which changes if the metering service restarts), Aether observes what exists and charges that hour at the monthly rate ÷ 730. Because the observation happens at a point inside the hour rather than across it, a volume that exists for part of an hour is billed for that hour only if the observation saw it. There is no monthly maximum and no monthly average: the month’s charge is the sum of its hourly observations. So a volume that exists for the whole of a 31-day month costs 744/730 of the monthly rate — about 1.9 % more — and one that exists for a day costs about a thirtieth of it. A 30-day month is 720 hours (about 1.4 % less); February is 672 hours (696 in a leap year), about 7.9 % less. The first observation for an hour is the one that counts.
- Block (
aether-block) — each volume’s provisioned size, rounded up to a whole GiB per volume, then summed. Expanding a PVC bills the new size from the next hourly observation. - Shared (
aether-shared) — the used bytes of all shared volumes in the cluster, summed and rounded up once per cluster per hour. Deleting data lowers the next observation. - Registry — the storage the registry reports for your organization’s repositories, summed and rounded up to a whole GiB per hour. An empty registry costs nothing; deleting images lowers the next observation once the registry’s garbage collection has reclaimed the space.
A volume or an image deleted at 10:40 is last billed for the hour whose observation still saw it.
Worked examples
Section titled “Worked examples”- A 100 GiB block volume created at 09:10 and deleted at 15:50 the same day. The sampler observes once per clock hour, at the same minute of each hour (which changes if the metering service restarts), so depending on where that minute falls the volume is seen either six or seven times. Seven observations: 7 × 100 GiB × €0.15 ÷ 730 = €0.14. Six: 6 × 100 GiB × €0.15 ÷ 730 = €0.12.
- A 100 GiB block volume expanded to 200 GiB after 15 days of a 31-day month. (360 h × 100 + 384 h × 200) × €0.15 ÷ 730 = €23.18.
- A shared volume holding 50 GiB for 400 hours, then 10 GiB after a cleanup for the month’s remaining 344 hours. (400 × 50 + 344 × 10) × €0.18 ÷ 730 = €5.78.
- A registry holding 3.2 GiB of images (billed as 4 started GiB) for 500 hours, then 0.8 GiB (billed as 1) after a cleanup for 244 hours. (500 × 4 + 244 × 1) × €0.15 ÷ 730 = €0.46.
Evaluating Aether
Section titled “Evaluating Aether”You can try the platform without committing to a month of node charges: create a cluster and remove it within the 15-minute grace period, and there is no node charge.
Two things to keep in mind while evaluating:
- Every cluster has a mandatory €4 public API endpoint. Its charge is locked the first time the billing sampler observes the address, and is not covered by the node grace period.
- Storage and registry usage is billed as described above, whatever the cluster’s lifetime.
Aether publishes no free trials, promotional credits, discounts, or refunds — the grace period above is the whole of it.
Budgets and usage alerts
Section titled “Budgets and usage alerts”You can set a soft monthly budget for your organization: a euro limit plus
one or more percentage thresholds (for example 50%, 80%, 100%). When your
month-to-date spend crosses a threshold, Aether fires a one-time usage.alert
webhook to the endpoints your organization has registered.
Budgets are advisory. Crossing one alerts you; it never blocks provisioning, stops a cluster, or caps your spend.
Invoices
Section titled “Invoices”At the close of each calendar month, Aether issues an invoice for every organization with charges in that month. The invoice freezes what you were charged: your billing details, the itemized lines, and the totals as they stood at close — later changes to your organization don’t rewrite past invoices. The VAT treatment applied to your organization is stated on the invoice itself.
Invoices are listed on the portal’s Billing page and each one can be downloaded as a PDF.
How the portal presents it
Section titled “How the portal presents it”The portal’s Billing page separates the pieces clearly:
- Monthly Subscriptions — the flat monthly charges: packages, fixed pools, and add-ons.
- Autoscaling Usage — the hourly, per-node charges from your autoscaling pools.
- Invoices — your billed history, with PDF download.