id: cost title: What a deployment costs its operator, broken out by service status: open crates: [] dependsOn: [deploy] exitCriterion: > An operator can name, for one deployment, the estimated monthly cost of every AWS service infra/pds/ provisions, the marginal cost of one more account, and the marginal cost of one account that goes viral — each figure labelled measured or estimated, and cited to its source. #

cost #

The owner asked for a cost model, broken out by service, benchmarked against AWS. Nothing has run on real AWS yet — infra/pds/ has never been applied — so every figure in this epic starts as an estimate, sourced from AWS's public pricing pages rather than a bill, and stays labelled that way until a real deployment's Cost Explorer says otherwise. An estimate presented as measured is worse than a gap, because it gets planned against.

What infra/pds/ provisions #

Confirmed against the tree as of this writing, not guessed: one EC2 instance (infra/pds/ec2.tf, t3.small by default) with two gp3 EBS volumes — a 20 GB root volume and a 20 GB data volume holding the write-ahead log and blob store — an Elastic IP, a Route53 hosted zone (infra/pds/route53.tf) and nothing inside it (the server populates records itself at runtime), an IAM role and instance profile (infra/pds/iam.tf) with SSM read, ECR pull and Route53 write grants, a dedicated KMS key for the SSM SecureString parameters, a security group open only on 443, an AWS Backup vault and plan (infra/pds/backup.tf) covering the data volume, and an ECR repository for the container image. There is no ALB and no ACM certificate: plan/deploy.md records that the server terminates TLS itself over ACME DNS-01, so certificate issuance is free and the load balancer's cost — and its data transfer surcharge — is simply gone from this design.

Per-service estimate, at rest #

"At rest" means one idle deployment: the instance running, the zone existing, no accounts, no requests beyond health checks. Every price below is AWS's published on-demand rate for us-east-1, checked in August 2026; none of it has been confirmed against an actual invoice.

Summing the rows that do not depend on traffic or on data actually written — instance, EBS, the EIP, the hosted zone, and the KMS key — gives roughly $23 a month to keep one idle, empty deployment running. That number excludes backup storage (unmeasured, see above) and data transfer (covered next, because it is not really an "at rest" cost at all).

The cost driver specific to this design #

zone-scale already names the shape: "did:web resolution has nothing in front of it. Every resolution by every stranger is an HTTPS request to this server for a distinct hostname. did:plc has a directory absorbing that load and this method has none, so read volume scales with how interesting the accounts are rather than with how many there are." That is a capacity statement and a cost statement at once, and it is the most important thing this epic has to say: an operator cannot cache this away. There is no CDN or directory in front of the instance (see "what infra/pds/ provisions" above — no ALB, nothing else in the request path), so every did.json fetch is billed data transfer out, and every DNS lookup for an agent's hostname that a client's resolver did not already cache is a billed Route53 query.

The marginal cost of one ordinary account is close to zero. Provisioning it costs no new AWS resource: its name comes from the existing pool (zone-scale), its record is one more entry in the hosted zone Terraform already created (Route53 bills per zone and per query, not per record), and an account nobody looks up generates no data transfer. Its only recurring cost is whatever trickle of resolution traffic it draws, which for an account nobody is following is small enough to round to nothing against the $23/month baseline above.

The marginal cost of one popular account is not the same number, and that is the point. A did.json document is on the order of a kilobyte or two. At the $0.09/GB post-free-tier rate, a million resolutions of one document cost under a dollar in data transfer — cheap per-resolution, but the multiplier is a popularity number the operator does not control and cannot predict, because it tracks how widely that agent's posts circulate, not how many accounts the operator runs. An agent whose activity gets reposted into a large timeline can draw resolution volume that dwarfs the rest of the deployment's traffic combined, and unlike a cache-fronted resolution scheme, every one of those requests reaches this instance and this instance's bill. The 100 GB/month free tier absorbs tens of millions of document-sized resolutions before the metered rate even starts, which is worth stating plainly so this reads as a real but distant risk rather than an alarm: it becomes a line item at genuinely viral resolution volumes, not at the scale of a handful of interested followers. What is missing to turn "distant risk" into a number an operator can act on is occupancy and request-rate data from a real deployment, which does not exist yet.

What is measured versus estimated #

Nothing here is measured. infra/pds/ has never been applied against an AWS account (see plan/deploy.md's open backup-restore item, which says the same thing about restore: wired up, never run). Every rate above is AWS's public, current list price; none of it accounts for savings plans, reserved capacity, or a first-year free tier the SSM/ECR rows already flag. The one thing this epic can promise is that a figure claimed here without a citation, or claimed as measured without a bill behind it, is a bug in this file.

How an operator sees their own cost #

This epic does not invent a third surface for cost. ops-dashboard already shows live operational state to a signed-in owner, and alerts already gives the server a channel to say something is wrong, signed with its own key. A per-deployment cost figure — resolution count, data transfer, backup growth — belongs as data on the first of those, not a new page: the dashboard already reads bot.did.stats and the session/account state that a cost estimate would need as inputs. Whether that figure should be a live AWS Cost Explorer pull (a second AWS credential the instance would need to hold) or a locally-computed proxy (bytes served, resolution count, multiplied by the rates in this file) is open and belongs to whichever of those two epics picks it up.

• Confirm the estimates above against a real bill, once deploy has an instance running against a real AWS account for at least one full month. Replace "estimated" with "measured" one row at a time, not all at once.
• Measure AWS Backup's actual GB-month, which this epic could not estimate: it depends on write-ahead-log churn from real accounts, and no real deployment has produced any yet.
• Decide where a resolution counter lives so "marginal cost of a popular account" stops being an order-of-magnitude argument and becomes a number bot.did.stats or the dashboard can show per account.
• Say what a fleet costs, once fleet exists: ten deployments are ten Route53 zones, ten instances and ten EBS volumes, not one deployment times ten — restate the per-service table as "times N" rather than re-deriving it, and note where it is not linear (a shared operator credential, if fleet ever needs one, is not a tenth of anything).
• Revisit the EIP line if infra/pds/ec2.tf ever changes: the $0.005/hr public-IPv4 charge applies to the address regardless of whether it is attached, which was not true before February 2024 and is easy to re-assume away.

Done #

Nothing closed yet.