Your managed entry point appears on the bill in a month it served almost nothing, so what is a rented door's charge shape?

middleshould knowfreq 48%

answer

subscription plus meter
existing is the billable event
idle allocation charged while unattached
consolidation cuts standing, not metered
near-zero meter means waste or standby

basics

~20 s

Two elements: a standing charge for the entry point existing, owed per hour whether or not anyone called, and a metered charge for the work it did, counted in connections, requests or processed capacity. An idle door is never free.

solid answer

~40 s

A rented front door bills like a subscription with a meter attached. The standing element is owed for every hour the entry point exists, and on some platforms it multiplies by how many names or rule sets it serves — that is the part that shows up in a month with no traffic. The metered element follows the work: new connections, concurrent connections, requests, or a composite capacity unit the provider defines. A reserved address you hold usually carries its own charge, often precisely while it is attached to nothing. The bytes moved are billed again under the platform's transfer schedule, which is a separate subject. The practical consequence is a waste pattern: one forgotten entry point per team per environment costs real money while serving nobody, and nothing about it looks broken.

A rented front door bills like a subscription with a meter attached. The **standing element** is owed for every hour the entry point exists, and on some platforms it multiplies by how many names or rule sets it serves — that is the part that shows up in a month with no traffic. The **metered element** follows the work: new connections, concurrent connections, requests, or a composite capacity unit the provider defines. A reserved address you hold usually carries its own charge, often precisely while it is attached to nothing. The bytes moved are billed again under the platform's transfer schedule, which is a separate subject. The practical consequence is a waste pattern: one forgotten entry point per team per environment costs real money while serving nobody, and nothing about it looks broken.

code

pseudocode · 11 lines

pseudocode

// figures are invented units, not any provider's price list
standingUnitsPerHour = 3
hoursInMonth         = 720
meteredUnitsUsed     = 150

standing = standingUnitsPerHour * hoursInMonth   // 2160
metered  = meteredUnitsUsed                      // 150
total    = standing + metered                    // 2310

if meteredUnitsUsed == 0:
    print "a month serving nothing still owes", standing   // 2160

go deeper

for a junior

Recall that a rented entry point is charged for existing, not only for traffic, so an idle one still shows on the bill.

for a middle

Explain the two elements and what multiplies the standing one, and name the reserved address as a third charge that applies while it is idle.

for a senior

Find the waste: doors with a near-zero meter over a month, teardown scripts that remove workloads but not entry points, and allocations held for retired services.

for a principal

Set the standard on consolidation — when a shared door's saving is worth the shared limits, shared certificate scope and shared blast radius.

Two elements, and only one of them follows traffic

Every rented entry point bills on the same shape, whatever the provider's naming: a standing element plus a metered element.

Standing. Charged for each hour the entry point exists, regardless of use. On many platforms it is multiplied by something structural — the number of names it serves, the number of rule sets or listeners configured on it — so a door that fronts several services can carry several standing charges.
Metered. Charged for the work performed: new connections per second, concurrent connections, requests handled, or a composite unit the provider defines that folds several of those together with the bytes processed.

The question in the title is answered by the first element. An entry point that served nothing still existed for every hour of the month, and existing is the billable event.

The idle allocation is its own line

A reserved public address is a third charge, and it behaves unusually: many platforms charge for it precisely while it is attached to nothing, because an address held out of the pool costs the provider the same whether it is in use or not. So the classic tidy-up sequence — delete the entry point, keep the address because someone might want it back — converts one visible charge into a quieter one that nobody reviews.

A worked decomposition

Assume invented units. A door with a standing rate of three units an hour, in a month of seven hundred and twenty hours, owes two thousand one hundred and sixty units before anyone calls it. If it also processed one hundred and fifty metered capacity units, the total is two thousand three hundred and ten, of which the traffic accounts for under seven per cent. Change the traffic to zero and the bill falls by that seven per cent, not to nothing. That ratio is the point: for a low-traffic service, a rented door is effectively a fixed cost.

What consolidation changes, and what it does not

Putting six small services behind one entry point instead of six is a real saving, but it is important to be precise about which element falls:

The standing element falls, because you now hold one door instead of six. This is usually the dominant term for small services.
The metered element does not fall. The same work is still performed; it is merely performed by one door.
The address allocations fall too, if each door had held one.

And what it costs:

One door is a shared failure surface and a shared blast radius for misconfiguration.
Names, certificates and their renewal now span teams that do not share a change window.
The door's own limits — connection counts, rule counts, how many names it may serve — are now shared, and the noisiest service sets the pace.

The waste pattern to look for

Idle entry points are one of the most reliable findings in a cost review, because nothing about them looks wrong:

A door created for a proof of concept that was never deleted with the workload behind it.
A per-developer or per-branch environment whose teardown script removed the workloads but not the door.
A migration's old door, kept for rollback, still standing a year later.
A reserved address held for a service that was retired, charged for being idle.

Each is small; the number of them is not. The detection is the same in every case: look for entry points whose metered element is near zero over a full month, because a door with a standing charge and no work is either waste or a deliberate standby you should be able to name.

What is not on this line

Two things people fold in wrongly. The bytes leaving the platform are charged on the transfer schedule, a separate dimension with its own rules about direction and boundary, and it is a different subject from what the door itself costs. And the certificate the platform issues and renews for the served names is ordinarily part of the service rather than a separate metered fee — so a plan to "save money on certificates" by bringing your own usually saves nothing and buys you renewal work.

The design consequence

Because the standing element is fixed and the metered element follows work, the cost per request of a rented door falls sharply with traffic. A high-traffic service gets excellent value; a low-traffic internal service pays mostly for existing. That is the actual argument for consolidating small services behind a shared door, and the actual argument against giving every ephemeral environment its own.

## Two elements, and only one of them follows traffic Every rented entry point bills on the same shape, whatever the provider's naming: a **standing element** plus a **metered element**. - **Standing.** Charged for each hour the entry point exists, regardless of use. On many platforms it is multiplied by something structural — the number of names it serves, the number of rule sets or listeners configured on it — so a door that fronts several services can carry several standing charges. - **Metered.** Charged for the work performed: new connections per second, concurrent connections, requests handled, or a composite unit the provider defines that folds several of those together with the bytes processed. The question in the title is answered by the first element. An entry point that served nothing still existed for every hour of the month, and existing is the billable event. ## The idle allocation is its own line A reserved public address is a third charge, and it behaves unusually: many platforms charge for it **precisely while it is attached to nothing**, because an address held out of the pool costs the provider the same whether it is in use or not. So the classic tidy-up sequence — delete the entry point, keep the address because someone might want it back — converts one visible charge into a quieter one that nobody reviews. ## A worked decomposition Assume invented units. A door with a standing rate of three units an hour, in a month of seven hundred and twenty hours, owes two thousand one hundred and sixty units before anyone calls it. If it also processed one hundred and fifty metered capacity units, the total is two thousand three hundred and ten, of which **the traffic accounts for under seven per cent**. Change the traffic to zero and the bill falls by that seven per cent, not to nothing. That ratio is the point: for a low-traffic service, a rented door is effectively a fixed cost. ## What consolidation changes, and what it does not Putting six small services behind one entry point instead of six is a real saving, but it is important to be precise about which element falls: - The **standing element** falls, because you now hold one door instead of six. This is usually the dominant term for small services. - The **metered element** does not fall. The same work is still performed; it is merely performed by one door. - The **address allocations** fall too, if each door had held one. And what it costs: - One door is a shared failure surface and a shared blast radius for misconfiguration. - Names, certificates and their renewal now span teams that do not share a change window. - The door's own limits — connection counts, rule counts, how many names it may serve — are now shared, and the noisiest service sets the pace. ## The waste pattern to look for Idle entry points are one of the most reliable findings in a cost review, because nothing about them looks wrong: 1. A door created for a proof of concept that was never deleted with the workload behind it. 2. A per-developer or per-branch environment whose teardown script removed the workloads but not the door. 3. A migration's old door, kept for rollback, still standing a year later. 4. A reserved address held for a service that was retired, charged for being idle. Each is small; the number of them is not. The detection is the same in every case: look for entry points whose metered element is near zero over a full month, because a door with a standing charge and no work is either waste or a deliberate standby you should be able to name. ## What is not on this line Two things people fold in wrongly. The **bytes leaving the platform** are charged on the transfer schedule, a separate dimension with its own rules about direction and boundary, and it is a different subject from what the door itself costs. And the certificate the platform issues and renews for the served names is ordinarily part of the service rather than a separate metered fee — so a plan to "save money on certificates" by bringing your own usually saves nothing and buys you renewal work. ## The design consequence Because the standing element is fixed and the metered element follows work, the cost per request of a rented door falls sharply with traffic. A high-traffic service gets excellent value; a low-traffic internal service pays mostly for existing. That is the actual argument for consolidating small services behind a shared door, and the actual argument against giving every ephemeral environment its own.

You consolidate six small services behind one entry point. Which part of the bill actually falls?
The standing element, because you hold one door instead of six, plus any address allocations the other five held. The metered element does not fall — the same work is still performed. For small services the standing element dominates, which is why the saving is real.
Which resource here is charged precisely because it is idle, and why?
A reserved public address that is allocated but attached to nothing. The address is a scarce resource held out of the platform's pool whether or not it carries traffic, so charging for the idle state is what stops tenants from hoarding allocations they are not using.

saying these in an interview costs you the question

Thinks a managed entry point with no traffic costs nothing
Assumes the metered element is only bytes moved
Believes deleting the workload removes the entry point
Thinks a reserved address is free while unattached
Treats per-environment doors as too small to matter
Expects consolidation to reduce the metered element too

Your managed entry point appears on the bill in a month it served almost nothing, so what is a rented door's charge shape?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two elements, and only one of them follows traffic

The idle allocation is its own line

A worked decomposition

What consolidation changes, and what it does not

The waste pattern to look for

What is not on this line

The design consequence

▾common follow-ups2 questions

▾red flags6 flags

Two elements, and only one of them follows traffic

The idle allocation is its own line

A worked decomposition

What consolidation changes, and what it does not

The waste pattern to look for

What is not on this line

The design consequence

answer

go deeper