Managed Services

Autoscaling only works if your compute is disposable, which means state has to live somewhere else. This page is about that somewhere — and the choice it forces: do you run your own database, queue, and cache on raw VMs, or do you rent managed versions where the provider runs them for you? This is the build-vs-buy decision, and it’s one of the highest- leverage architectural calls a team makes.

A managed service is a PaaS-style offering for a specific piece of infrastructure: a database (RDS, Cloud SQL), a message queue (SQS, Pub/Sub), a cache (ElastiCache, Memorystore), a search index, an object store. You don’t get a VM and install Postgres on it; you ask for “a Postgres,” and you get an endpoint to connect to. The provider runs the machine, the OS, the software, the backups, the failover, and the patching.

The undifferentiated heavy lifting argument

Here is the core case for buying, and it’s worth stating precisely. Running a production database is an enormous amount of work: provisioning, replication, automated backups, point-in-time restore, failover when the primary dies, version upgrades, security patching, monitoring, tuning. That work is real, hard, and necessary — and almost none of it is specific to your business.

Amazon’s term for this is undifferentiated heavy lifting: labor that is genuinely difficult but identical to what every other company doing the same thing must also do. Your users do not care, and cannot tell, whether you ran the database failover or the provider did — they only care that it worked. Time spent on it is time not spent on the thing that actually differentiates your product.

   What your users pay you for     vs.    Undifferentiated heavy lifting
   ───────────────────────────            ──────────────────────────────
   your product's features                running Postgres failover
   your domain logic                      rotating DB backups nightly
   the thing only YOU do                  patching the message broker
   ─── spend engineering here ───         ─── buy this from the provider ───

The argument: pay the provider to do the undifferentiated parts so your scarce engineering time goes to the differentiated ones. A three-person startup that runs its own Postgres HA cluster has spent a third of its capacity becoming a part-time database operations team — for a database that gives them no advantage over anyone else.

This is the cloud’s deepest version of the book’s thread

Every managed service is the recurring question — what manual, error-prone step does this remove? — answered at the scale of an entire operational discipline. The manual steps removed aren’t one command; they’re running backups, testing restores, configuring replication, and executing failover at 3 a.m. — exactly the toil that, done by hand under pressure, causes the worst data-loss incidents. The provider does it with dedicated teams, tested automation, and SLAs. That’s the safety dividend.

What buying costs you

Managed services are not free wins, and a balanced engineer names the costs out loud. There are three, and they’re real:

• Lock-in. A managed service ties you to one provider’s API, behavior, and pricing. Self-hosted Postgres is portable — move the data, run it anywhere. But the more you adopt a provider-specific managed service (a proprietary database, a serverless queue with no open equivalent), the harder and more expensive leaving becomes. Lock-in is the convenience-for-control trade in its sharpest form.
• Less control. You get the provider’s version, the provider’s config knobs, the provider’s maintenance windows. Need a specific extension, a tuning parameter they don’t expose, or a database version they haven’t certified yet? You may simply be unable to. When something is slow inside the managed layer, you often can’t see in to debug it.
• Egress and pricing surprises. Managed services bill in ways raw compute doesn’t, and the sharpest edge is data egress — the cost of moving data out of the provider’s network. Ingress (data in) is usually free; egress is metered and can be expensive. Architectures that shuffle large volumes of data across regions or out to the internet can run up bills that dwarf the compute, and it’s a cost that’s easy to miss until the invoice arrives.

Egress is the cost that ambushes people

Data going into the cloud is typically free; data coming out — to users, to another region, to another provider — is metered per gigabyte. This quietly shapes architecture: it’s why you co-locate compute next to its data, why cross-region replication has a running cost beyond the storage, and why “just move it to another cloud” is rarely as cheap as it sounds. Egress is also the financial teeth of lock-in: leaving means paying to drag all your data out. (Since 2024, under EU Data Act pressure, the major clouds waive egress for customers migrating off entirely — but that’s a one-time exit door; everyday and cross-cloud egress is still metered.)

A decision framework

Build-vs-buy isn’t a coin flip; it’s a question you can answer with a few sharp criteria. Lean toward buy unless a specific factor pushes you toward build:

Question	Leans BUY (managed)	Leans BUILD (self-host)
Is this core to your product?	No — it’s plumbing	Yes — it’s a differentiator
Do you have the ops expertise + headcount?	No / small team	Yes — a real platform team
Is the workload standard?	Yes — vanilla Postgres/Redis	No — exotic config or extensions
How much does scale change the math?	Small/medium scale	Huge scale where managed markup hurts
How costly is the lock-in here?	Low — portable tech	High — proprietary, hard to leave
How tight is the data-out (egress) flow?	Low egress	Egress-heavy, latency-sensitive

The honest default for most teams, most of the time, is buy the managed service — especially for databases, where the operational risk of getting backups and failover wrong by hand is the highest in the stack, and the cost of getting it wrong is irreversible data loss. You build when the thing is your competitive edge, when you have a genuine platform team to run it, when the workload is too unusual for a managed offering, or when scale makes the managed markup unbearable.

   start ─► Is it core to the product?
              │ yes ─► consider building (it's your edge)
              │ no  ─► Do you have the ops team to run it well?
                          │ no  ─► BUY (you'd run it worse, for no gain)
                          │ yes ─► Is the lock-in / egress cost acceptable?
                                     │ yes ─► BUY for speed
                                     │ no  ─► BUILD for portability

By the numbers — what egress actually costs

Data in is free; data out to the internet is metered at roughly $0.08–0.12 per GB on the major clouds (approx, mid-2020s) — usually cheaper between regions, but rarely zero:

   move 100 TB out  =  100,000 GB × ~$0.09/GB  ≈  $9,000

Nine thousand dollars to move data you already paid to store and compute on — and it recurs every time you ship it. This is why architectures co-locate compute next to its data, why a chatty cross-region design quietly out-costs the servers, and why “just move to another cloud” usually means paying to drag every byte out the door (the clouds’ 2024 exit-fee waivers apply only when you leave entirely). Egress is the financial teeth of lock-in.

The thread: trading toil for dependency

The manual, error-prone steps managed services remove are the operational discipline of running stateful infrastructure: provisioning replicas, scheduling and verifying backups, rehearsing and executing failover, applying security patches, scaling storage before it fills. Done by hand, these are the steps most likely to cause a catastrophic, unrecoverable incident — a botched failover, an untested backup that won’t restore, a patch missed until it’s a breach. Buying them hands all of it to a team that does nothing else, with tested automation and an SLA.

What you pay for that safety is dependency: lock-in to a provider, loss of fine control, and a bill with egress teeth. The skill is not “always buy” or “always build” — it’s knowing which of your services are undifferentiated plumbing (buy them, free up your people) and which are your actual product (build them, own them). Get that sorting right and you spend your scarce engineering exactly where it creates advantage.

Buying capacity and services so freely raises the obvious next question — how much is all of this costing, and who’s watching? That’s Cost & FinOps.

The architect’s lens

Five questions for the build-vs-buy call:

• Why does it exist? Because autoscaling forces state off disposable compute, so something has to run your database, queue, and cache — and most of that work is undifferentiated heavy lifting users can’t even tell you did.
• What problem does it solve? Buying hands provisioning, backups, replication, failover, and patching to a dedicated team with tested automation and an SLA — the very steps that, fumbled by hand at 3 a.m., cause irreversible data loss.
• What are the trade-offs? Three real costs — lock-in to a provider’s API, less control (their version, their knobs, no peeking inside the layer), and egress (~$0.08–0.12/GB out, ~$9k for 100 TB), which is the financial teeth of lock-in.
• When should I build instead? When the thing is your product, you have a genuine platform team, the workload is too exotic for a managed offering, or scale makes the managed markup unbearable.
• What breaks if I self-host everything? A small team becomes a part-time DB-ops team for infrastructure that gives it no advantage — and the highest-stakes failure in the stack (backups and failover) is now yours to get wrong.

Check your understanding

1. Define “undifferentiated heavy lifting” and explain why running your own database usually qualifies. How does this connect to where you should spend engineering time?
2. Name the three real costs of adopting managed services, and give a concrete example of each.
3. What is data egress, why is it asymmetric with ingress, and how does it shape architecture and reinforce lock-in?
4. Walk the decision framework: name two factors that push toward buy and two that push toward build.
5. Using the book’s thread, explain why managed databases specifically are the page’s strongest buy-it case — what manual steps do they remove, and why is getting those wrong so dangerous?

Show answers

1. It’s labor that is genuinely hard but identical for everyone doing the same thing — not specific to your business. Running a database (backups, replication, failover, patching) qualifies because users can’t tell whether you or the provider did it; they only care that it worked. So that work should be bought, freeing your engineers for the differentiated features users actually pay you for.
2. Lock-in (a proprietary serverless queue with no open equivalent makes leaving costly); less control (you can’t enable a Postgres extension or tuning knob the provider doesn’t expose, and can’t debug inside the managed layer); egress / pricing surprises (a cross-region data pipeline running up per-GB data-out charges that dwarf compute).
3. Egress is the metered cost of moving data out of the provider’s network. It’s asymmetric because ingress (data in) is usually free while egress is billed per GB. It pushes you to co-locate compute with its data and makes cross-region/cross-cloud movement expensive — and it’s the financial teeth of lock-in, because leaving means paying to drag all your data out (barring the full-exit fee waivers the major clouds added in 2024).
4. Toward buy: it’s non-core plumbing; you lack the ops team to run it well; the workload is standard; lock-in/egress is low. Toward build: it’s a core differentiator; you have a real platform team; the workload is too exotic for a managed offering; or scale makes the managed markup unbearable.
5. Managed databases remove provisioning replicas, scheduling and verifying backups, rehearsing and executing failover, and patching — the operational discipline of stateful infra. Getting these wrong by hand is the most dangerous failure in the stack because the consequence is irreversible data loss (a botched failover, a backup that won’t restore), and it tends to happen under maximum pressure at 3 a.m. — exactly when humans make mistakes and dedicated automation does not.