skip to content

Forty services each took a platform-provisioned external balancer and the bill jumped — what is being charged, and what consolidates it?

level: seniorimportance: must knowfreq 55%

answer

  1. count addresses, not services
  2. an instance charged while it exists
  3. idle still costs
  4. one address can front many hostnames
  5. consolidation buys one shared blast radius

basics

~20 s

Each workload's own balancer holds an allocated external address and a managed balancer instance, both charged for as long as they exist, with traffic on top — forty times over. A shared edge routing by hostname and path collapses forty addresses into one.

solid answer

~50 s

Three things are being charged, and only one of them is traffic. Each workload holds an **allocated external address**, each has a **managed balancer instance** billed for the time it exists, and each pays for the bytes through it. The first two accrue even for a workload nobody called all month, so the bill scales with the number of services rather than with load — forty services, forty addresses, forty instances. What consolidates it is a **shared edge**: one external address in front of many workloads, picking the destination from each request's hostname and path, so the estate pays for one address and one instance. What consolidation costs is real too: one shared failure domain instead of forty small ones, a change surface every team touches, and a hard constraint that the edge can only carry traffic it can parse into requests.

code

yaml · 13 lines
yaml
sharedEdge:
  externalAddresses: 1
  certificateHeldBy: edge
  routes:
    - hostname: reports.partner.example
      pathPrefix: /render
      sendTo: report-renderer
    - hostname: ledger.partner.example
      pathPrefix: /v1/balances
      sendTo: payments-ledger
    - hostname: status.partner.example
      pathPrefix: /
      sendTo: status-page

go deeper

for a junior

Know that asking the platform to expose a workload externally creates real infrastructure underneath, and that it is charged for whether or not anyone calls the workload.

for a middle

Name the three charges — held address, running instance, traffic — and explain why the first two make the bill scale with the number of services rather than with load.

for a senior

Run the consolidation properly: the arithmetic, the exemption list, the edge's capacity headroom, and the blast radius you knowingly accept in exchange for one address.

for a principal

Own the estate-level trade: what the single edge is worth against forty isolated failure domains, and what you will fund to keep the edge from becoming everyone's bottleneck.

## What the bill is actually made of When a workload's spec asks for external exposure and the platform provisions a balancer for it, three separate resources come into existence and each one is charged for differently. 1. **An allocated external address.** A routable address is reserved on the workload's behalf and held for as long as the exposure exists. 2. **A managed balancer instance.** The infrastructure underneath runs something that accepts connections at that address and forwards to the workload's current replicas. It is charged for the time it exists, typically by the hour. 3. **Traffic.** Bytes through the balancer are usually metered on top. The first two are the ones that surprise teams, because they do not depend on demand. A workload that served no request all month still held an address and still ran an instance, so it still appears on the invoice. **The bill therefore scales with the number of workloads, not with the load on them** — forty services means forty addresses and forty instances, whatever the traffic was. ## Why the shape produces that This shape is defined by giving each workload an entry point of its own. That is not accidental overhead; it is what you were buying. Each workload gets its own address, its own failure domain, and an entry point that does not have to understand the traffic — there is only one possible destination, so nothing has to be parsed to choose it. The cost multiplies for the same reason the isolation does. ## What consolidates it A **shared edge**: one external address, one instance, and a routing table that picks the workload from the hostname the client asked for and the path it requested. Forty entries in a table replace forty provisioned addresses. | | Balancer per workload | Shared edge | |---|---|---| | External addresses for 40 services | 40 | 1 | | Managed instances billed | 40 | 1 | | Chooses destination by | nothing — one destination | hostname and path | | Can carry unparseable traffic | yes | no | | Blast radius of one change | one workload | every workload behind it | | Certificates to renew | 40 owners | one owner | ## What consolidation costs - **One shared failure domain.** A misapplied routing change or an overloaded edge reaches all forty workloads at once. You traded forty small blast radii for one large one, and that is the price of the single address. - **A shared change surface.** Every publish, rename or path change is an edit to something the whole estate depends on, which means review, and review means latency. - **A protocol constraint.** Only traffic the edge can parse into requests carrying a hostname can be routed this way. A workload speaking something else cannot move. - **Capacity that must be planned centrally.** One workload's traffic spike is now capacity pressure on everyone's entry point, so the edge needs headroom and its own scaling story. - **Coarse controls move inward.** Rate limiting and similar admission decisions can live at the edge, but per-workload authorisation must not leave the workload — the edge is now a single place to get a rule wrong. ## Which workloads keep their own balancer anyway - One whose traffic is not request-structured, or carries no hostname for the edge to route on. - One whose outage must not be shared with the rest of the estate, for a reason someone can state — a regulatory boundary, a contractual availability commitment, a separate tenancy. - One whose traffic volume is large enough that putting it behind the shared edge would distort capacity planning for everyone else. Each of those is an exemption with a written reason. "We would prefer our own" is not one, and granting it dissolves the saving. ## Doing the arithmetic before the argument The honest form of this discussion is numbers, not preference. Count the addresses and instances currently held, multiply by the rate charged for holding them, and set that against the shared edge's single address plus the headroom it needs and the engineering time to run it. Then count how many workloads genuinely cannot move, because those keep their own cost either way. The saving is the difference between forty held resources and one plus the exemptions — and if the exemption list turns out to be twenty workloads long, consolidation was the wrong answer for this estate and the real problem is the protocol mix, not the bill.

  • Which workloads would you still leave on a balancer of their own?
    Ones whose traffic the edge cannot parse into routable requests; ones whose outage must not be shared with the estate for a reason someone can state, such as a regulatory or tenancy boundary; and ones whose volume would distort capacity planning for everyone else behind the edge. Each of those is an exemption with a written reason, not a preference.
  • What moves to the edge when forty workloads sit behind it, and what must not?
    Hostname and path routing moves there, certificate renewal moves there, and coarse admission such as rate limiting usually does too. Per-workload authorisation must not: the workload still has to establish who is calling, because the edge is now one place where a single misconfiguration would open forty services at once.
  • The estate's bill barely moved after consolidation. What would you check first?
    How many workloads were actually exempted. If half kept their own address and instance, you are paying for the edge plus most of what you had. Then check whether the addresses of the migrated workloads were released — a balancer removed from a workload spec does not always release the address that was allocated for it.

saying these in an interview costs you the question

  • Thinks only traffic is charged, not the balancer existing.
  • Believes an idle balancer with no requests costs nothing.
  • Says consolidation is risk-free because the workloads are unchanged.
  • Assumes every workload can move behind a hostname-routing edge.
  • Counts the address and forgets the managed instance.