Renting an authorization server bills per identity: how does that compare with running your own when the population is 40,000 for ten months and 4 million for two?

seniorshould knowfreq 38%

answer

compare shapes, not sticker prices
one bill breathes, the other is flat
what counts as a billed identity
the rotation is funded all twelve months
crossover is staffing versus peak bill

basics

~20 s

A per-identity bill breathes with the population and concentrates almost all of a seasonal year's cost into two months. A self-run issuer is mostly fixed — capacity floor, datastore, on-call rotation — and the fixed part does not shrink in the quiet months.

solid answer

~50 s

Compare the shapes before the numbers. A rented bill tracks identities month by month, so a hundred-fold seasonal swing means the peak months dominate the year and the first question is what counts as a billed identity — registered accounts, or only those active in the month. For a population that files once a year those two definitions differ by an order of magnitude. The self-run side is mostly fixed: a capacity floor you keep running, a datastore, and an on-call rotation and engineering time that stay funded through ten quiet months. Only the burst capacity for the peak is variable, and you must provision and rehearse it in advance. So the crossover is not a user count — it is the point where the fixed cost of the people who would operate it beats the peak-month bill, with the expected cost of a failed sign-in on deadline night on the same sheet.

Compare the *shapes* before the numbers. A rented bill tracks identities month by month, so a hundred-fold seasonal swing means the peak months dominate the year and the first question is what counts as a billed identity — registered accounts, or only those active in the month. For a population that files once a year those two definitions differ by an order of magnitude. The self-run side is mostly fixed: a capacity floor you keep running, a datastore, and an on-call rotation and engineering time that stay funded through ten quiet months. Only the burst capacity for the peak is variable, and you must provision and rehearse it in advance. So the crossover is not a user count — it is the point where the fixed cost of the people who would operate it beats the peak-month bill, with the expected cost of a failed sign-in on deadline night on the same sheet.

code

pseudocode · 17 lines

pseudocode

# monthly_population[m] for m in 1..12 — 40_000 for ten months, 4_000_000 for two

rented(monthly_population):
    billed = [billable_identities(p) for p in monthly_population]
    #        ^ registered, or only active this month? this choice moves the total ~100x
    return sum(b * price_per_identity for b in billed)

self_run(monthly_population):
    fixed  = on_call_rotation + engineering_time      # all 12 months, population-independent
    fixed += floor_estate * 12                        # instances, datastore, backups
    burst  = peak_capacity_cost * peak_months         # sized and rehearsed in advance
    return fixed + burst

# crossover: fixed > sum(rented) is NOT a user count.
# Add to BOTH sides before comparing:
#   expected_cost_of_failed_signin_on_deadline_night
#   amortised_cost_of_migrating_if_this_choice_is_reversed

go deeper

for a junior

Know that the two options have different cost shapes: one bill follows how many people use the service, the other is mostly a fixed estate plus the people who run it. That alone answers the screening version of this question.

for a middle

Explain why a seasonal population makes the shapes diverge, and ask what counts as a billed identity before comparing totals. Be able to say which costs stay constant when nobody is signing in.

for a senior

Show the year-long arithmetic: a month-by-month sum on one side, fixed staffing plus a sized burst on the other, and the rehearsal that peak capacity needs before a date you cannot move. Name the operating rotation as the dominant self-run term.

for a principal

Treat the seasonal spike as a commercial lever and the choice as reversible only at a cost you should quantify now. Put the expected cost of a deadline-night failure and the price of reversing the decision on the same sheet as the invoice.

What you are actually comparing

Two cost shapes, not two numbers. A rented authorization server is metered: you pay for identities, usually per month, and the bill follows the population up and down. A self-run one is mostly a fixed estate — a capacity floor, a datastore, backups, and the engineers who keep it patched and answer for it at night — plus a variable slice for burst capacity at the peak.

That difference is invisible in a flat population and enormous in a seasonal one. Take the filing assistant that reads a payroll system on the filer's behalf: roughly 40,000 people use it for ten months of the year, and roughly 4 million in the two months around a statutory deadline. A hundred-fold swing, once a year, with a hard date.

The rented bill

The definition of a billed identity is the whole argument. Priced on registered accounts, a population that files once a year is billed at full size for twelve months and the seasonality never appears. Priced on monthly active identities, ten months are nearly free and the two peak months carry almost the entire year. Establish which one you are buying before comparing anything.
The peak is the number that matters. Even under monthly-active pricing, the two deadline months may carry 90% of the annual bill. A budget built from the quiet-month figure is wrong by an order of magnitude.
It is negotiable, and the seasonal shape is your lever. A predictable annual spike is easier to commit to than steady growth: an annual commitment priced against a forecast peak is a normal conversation, and so is a ceiling above it.
Sign-in volume may be billed separately from stored identities. Ask, because a deadline crush is a volume event as much as a population event.

The self-run floor

The rotation does not shrink. Whatever the population, somebody carries the pager, patches the software and rehearses the restore. That funding is constant across all twelve months and it is usually the largest single line.
The floor estate is constant too — enough instances and datastore to serve the quiet months, plus backups and the monitoring you will actually look at.
The peak is capacity you must size, provision and prove in advance, because the test is a fixed date you cannot move. Autoscaling helps the compute; the datastore, the rate limits and the delivery path for out-of-band codes are the parts that bite.
The unseen line is engineering time: the next second factor, the next accessibility requirement, the next upgrade. It arrives in the quiet months and it is not free there either.

Where the crossover actually sits

Not at a user count. State it as a comparison of the two shapes over a full year:

Compute the rented figure month by month under the actual billing definition and sum it — never multiply the peak or the average by twelve.
Compute the self-run figure as fixed staffing and floor estate, plus the burst, and be honest that the staffing is a fraction of real people, rounded up, not a number of servers.
Add the terms neither spreadsheet has a column for: the cost of a failed sign-in at 23:40 on deadline night, weighted by how likely each option makes it, and the cost of the migration if you pick wrong and reverse it later.

Run that arithmetic and the crossover usually lands where the fixed cost of the people who would operate an issuer beats the peak-month bill — which for most teams is a much larger population than intuition suggests, because the operating staff is the dominant term long after the servers stop being.

	Rented	Self-run
Bill shape	Tracks the population month by month	Mostly flat, with a short peak
Quiet ten months	Near-zero under active-identity pricing	Full rotation and floor estate
Two peak months	Almost the whole annual bill	Burst capacity you sized in advance
Dominant term	Price per identity at peak	Salaried operating time
Lever you control	The contract	The architecture

What the seasonal shape lets you do

A spike with a known date is the friendliest possible negotiating position, and it is worth using. It is also the reason a hybrid rarely helps: splitting the population between two issuers to dodge a price band gives you two systems to operate, two sets of identities, and the migration problem permanently rather than once. Decide, price the exit, and revisit at renewal.

## What you are actually comparing Two cost *shapes*, not two numbers. A rented authorization server is metered: you pay for identities, usually per month, and the bill follows the population up and down. A self-run one is mostly a fixed estate — a capacity floor, a datastore, backups, and the engineers who keep it patched and answer for it at night — plus a variable slice for burst capacity at the peak. That difference is invisible in a flat population and enormous in a seasonal one. Take the filing assistant that reads a payroll system on the filer's behalf: roughly 40,000 people use it for ten months of the year, and roughly 4 million in the two months around a statutory deadline. A hundred-fold swing, once a year, with a hard date. ## The rented bill - **The definition of a billed identity is the whole argument.** Priced on *registered* accounts, a population that files once a year is billed at full size for twelve months and the seasonality never appears. Priced on *monthly active* identities, ten months are nearly free and the two peak months carry almost the entire year. Establish which one you are buying before comparing anything. - **The peak is the number that matters.** Even under monthly-active pricing, the two deadline months may carry 90% of the annual bill. A budget built from the quiet-month figure is wrong by an order of magnitude. - **It is negotiable, and the seasonal shape is your lever.** A predictable annual spike is easier to commit to than steady growth: an annual commitment priced against a forecast peak is a normal conversation, and so is a ceiling above it. - **Sign-in volume may be billed separately** from stored identities. Ask, because a deadline crush is a volume event as much as a population event. ## The self-run floor - **The rotation does not shrink.** Whatever the population, somebody carries the pager, patches the software and rehearses the restore. That funding is constant across all twelve months and it is usually the largest single line. - **The floor estate is constant too** — enough instances and datastore to serve the quiet months, plus backups and the monitoring you will actually look at. - **The peak is capacity you must size, provision and prove in advance**, because the test is a fixed date you cannot move. Autoscaling helps the compute; the datastore, the rate limits and the delivery path for out-of-band codes are the parts that bite. - **The unseen line is engineering time**: the next second factor, the next accessibility requirement, the next upgrade. It arrives in the quiet months and it is not free there either. ## Where the crossover actually sits Not at a user count. State it as a comparison of the two shapes over a full year: 1. Compute the rented figure **month by month** under the actual billing definition and sum it — never multiply the peak or the average by twelve. 2. Compute the self-run figure as **fixed staffing and floor estate, plus the burst**, and be honest that the staffing is a fraction of real people, rounded up, not a number of servers. 3. Add the terms neither spreadsheet has a column for: the **cost of a failed sign-in at 23:40 on deadline night**, weighted by how likely each option makes it, and the **cost of the migration** if you pick wrong and reverse it later. Run that arithmetic and the crossover usually lands where the fixed cost of the people who would operate an issuer beats the peak-month bill — which for most teams is a much larger population than intuition suggests, because the operating staff is the dominant term long after the servers stop being. | | Rented | Self-run | |---|---|---| | Bill shape | Tracks the population month by month | Mostly flat, with a short peak | | Quiet ten months | Near-zero under active-identity pricing | Full rotation and floor estate | | Two peak months | Almost the whole annual bill | Burst capacity you sized in advance | | Dominant term | Price per identity at peak | Salaried operating time | | Lever you control | The contract | The architecture | ## What the seasonal shape lets you do A spike with a known date is the friendliest possible negotiating position, and it is worth using. It is also the reason a hybrid rarely helps: splitting the population between two issuers to dodge a price band gives you two systems to operate, two sets of identities, and the migration problem permanently rather than once. Decide, price the exit, and revisit at renewal.

Why does the definition of a billed identity matter so much for a population that files once a year?
Because registered accounts and monthly-active identities differ by roughly the seasonal ratio. Billed on registrations, four million people cost the same in a quiet month as in the deadline crush; billed on monthly actives, the quiet months nearly vanish and two months carry the year. Same headcount, an order of magnitude apart on the invoice.
What cost does a self-run authorization server carry that rarely appears in the comparison?
The people. A pager rotation with enough depth to be humane, the engineering time for upgrades and new authentication methods, and the rehearsal time to prove the peak capacity before the date arrives. It is funded across all twelve months regardless of how few people sign in, and it is usually the largest line on that side.
Would splitting the population across both options to reduce the bill be sensible?
Rarely. You would then operate two issuers, hold identities in two places, and carry a migration problem permanently instead of once, all to sit under a price band. The complexity usually costs more than the discount, and it doubles the surfaces on which someone can be locked out on deadline night.

Metered supply against your own generator. Metered, you pay for what you draw, so a fortnight of heavy use is a fortnight of heavy bills and the quiet months cost almost nothing. Own the generator and the cost is mostly the machine, the fuel contract and the technician who maintains it — sized for the busiest night of the year, and still being maintained on the quietest. Neither is cheaper in the abstract: the answer depends entirely on the shape of the load and on how much the technician costs.

saying these in an interview costs you the question

Quotes a price per user and stops there
Budgets a peak-billed year from the quiet-month figure
Counts servers but not the on-call rotation
Assumes a self-run issuer's cost shrinks off-season
Treats the crossover as a fixed number of users
Ignores what a failed sign-in costs on deadline night

Renting an authorization server bills per identity: how does that compare with running your own when the population is 40,000 for ten months and 4 million for two?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What you are actually comparing

The rented bill

The self-run floor

Where the crossover actually sits

What the seasonal shape lets you do

▾common follow-ups3 questions

▾analogy~30 s

▾red flags6 flags

What you are actually comparing

The rented bill

The self-run floor

Where the crossover actually sits

What the seasonal shape lets you do

answer

go deeper