vault

Buy versus Build for Managed Services

14 min read

Buy versus Build for Managed Services

Buy-versus-build is the recurring architecture decision of whether to adopt a provider’s managed service (a database, cache, queue, or search cluster you consume through an API and never patch) or to run the equivalent yourself on raw compute. The honest framing is not “managed always wins” — it is a genuine trade in which a managed service exchanges control, per-unit cost, and portability for operational relief, speed, and reliability you would otherwise have to build. The decision turns on six axes: total cost of ownership (including the salaries of the people who would otherwise operate it), operational load, the feature ceiling of the managed offering, your need for control and customization, portability and lock-in, and compliance. Getting it right means costing the whole thing — not comparing the managed service’s monthly bill against the price of an equivalently-sized VM, which is the single most common analytical error. This note builds the framework and, crucially, is explicit about the cases where running it yourself still wins. For the strategic exit dimension, see Vendor Lock-In and Exit Strategy.

Boundary with the siblings

This note owns the decision framework. What each managed service is lives in the neighboring §6 leaves (Managed Relational and NoSQL Databases, Managed In-Memory Caches, Managed Message Queues and Streaming); how you provision either choice as code belongs to the Infrastructure as Code MOC; how you operate the self-run option belongs to the Site Reliability Engineering MOC. The FaaS-specific instance of this decision is in Function as a Service Platforms.

Mental Model — You Are Buying Down Operational Work, Not Renting a Server

The framing that trips people up is treating a managed service as “a server plus a markup.” It is not. When you buy Amazon RDS or Google Cloud SQL, you are not renting a database VM at a premium — you are paying the provider to make an entire category of operational work disappear: patching the engine, taking and testing backups, configuring replication, executing failover, applying security fixes at 3 a.m. This is the work Amazon CTO Werner Vogels named “undifferentiated heavy lifting” back in 2006 — “all the hard technology work … that doesn’t add value to the business or its customers but is a necessary step” — and the entire economic case for managed services is that a business should “stop spending money on undifferentiated heavy lifting” and redirect that effort to what actually differentiates it (InfoQ on Vogels; Forbes, Amazon’s cloud lessons). AWS’s Well-Architected Framework encodes this as a cost best practice: “Analyze all components of this workload,” select cost-effective services, and prefer managed and serverless options so the provider absorbs operational overhead (AWS Cost Optimization Pillar, COST05).

flowchart TD
    Q["A workload needs a database /<br/>cache / queue / search engine"] --> A{"Is running this system<br/>a source of competitive<br/>differentiation?"}
    A -- "No — it's plumbing" --> B{"Does the managed offering<br/>meet the feature ceiling<br/>(version, extensions, tuning)?"}
    A -- "Yes — it IS the product" --> BUILD["Lean toward BUILD /<br/>self-run"]
    B -- "Yes" --> C{"Does portability / lock-in<br/>risk exceed the<br/>operational savings?"}
    B -- "No — you need a<br/>forbidden feature" --> BUILD
    C -- "No" --> D{"At your scale, does<br/>per-unit cost dominate<br/>the salary savings?"}
    C -- "Yes — hard exit needs" --> BUILD
    D -- "No" --> BUY["Default to BUY /<br/>managed service"]
    D -- "Yes — extreme scale" --> BUILD

What it shows and the insight to take: the default is buy — for undifferentiated plumbing the managed service almost always wins — but four gates can flip it: the workload is your differentiation, the managed feature ceiling blocks you, lock-in outweighs the savings, or your scale is large enough that per-unit price dominates the operational salary you would save. The rest of this note is those gates in detail.

Axis 1 — Total Cost of Ownership, Including the Payroll

The costliest mistake is comparing sticker prices: “an RDS db.r6g.large is Y, and Y < X, so I’ll self-host.” That comparison is wrong because it omits the largest line item — the fully-loaded cost of the humans who operate the self-hosted system. Total Cost of Ownership (TCO) of the build option is the sum of:

  • Infrastructure — the compute, storage, and network you provision (this is the only term the naive comparison counts).
  • Operational labor — the fraction of one or more engineers’ salaries spent patching, upgrading, monitoring, tuning, and firefighting. A single on-call database engineer, fully loaded, can cost more per year than a very large managed-database bill.
  • Reliability engineering — building and maintaining the backup pipeline, the replication topology, the failover automation, the runbooks. The managed service ships these; the build option must create them.
  • Opportunity cost — every hour spent operating undifferentiated plumbing is an hour not spent on the product. This is the term Vogels emphasizes and the one spreadsheets omit.
flowchart LR
    subgraph BUYC["BUY — managed service"]
        B1["Service bill<br/>(higher per unit)"]
        B2["~0 ops labor"]
        B3["reliability included"]
    end
    subgraph BUILDC["BUILD — self-run"]
        C1["Infra bill<br/>(lower per unit)"]
        C2["ops labor<br/>(often the biggest term)"]
        C3["build + maintain<br/>backups / HA / failover"]
        C4["opportunity cost"]
    end

What it shows and the insight to take: the managed bill looks bigger because it is itemized in one number; the self-run bill looks smaller because most of it is hidden in payroll and time. A defensible TCO comparison prices the build column’s labor, reliability, and opportunity terms — over a 3–5 year horizon, because that is where maintenance dominates. Industry framing repeatedly warns that maintenance, not initial build, is where the money goes, and that buying can be more expensive in raw dollars yet still correct because it removes operational burden and speeds time-to-value (Forbes Tech Council, build-vs-buy framework).

Uncertain

Verify: the widely-repeated claim that maintenance exceeds half of a system’s lifecycle cost (and can run several times the original build cost). Reason: this appears in secondary build-vs-buy write-ups and general software-engineering lore, not in a primary source consulted here. It is directionally well-established (maintenance is the dominant lifecycle cost) but the exact percentage is unsourced in this note. To resolve: ground against a primary software-economics study before quoting a specific figure. #uncertain

Axis 2 — Operational Load and Who Carries the Pager

Beyond dollars, the decisive question is often who wakes up at 3 a.m. A managed service shifts a large slice of the operational burden across the shared-responsibility line to the provider: they patch the engine, they replace failed hardware, they execute the failover you clicked “multi-AZ” to enable. You still own your schema, your queries, your capacity planning, and your data — but you no longer own the operating system, the engine binary, or the replication machinery. For a team without a dedicated database or platform group, this is frequently the whole decision: a five-person startup cannot credibly run a highly-available, backed-up, patched Postgres cluster and build its product, so it buys. For a large organization with a mature platform team, the calculus shifts, because the operational load it would offload is load it can already absorb.

The subtle point is that managed services do not reduce operational load to zero — they change its shape. You trade “patch the engine and manage failover” for “understand the service’s quotas, throttling, and failure modes.” A managed queue removes broker operations but adds the discipline of respecting its concurrency and payload limits; a managed function removes server patching but adds the discipline of statelessness and cold-start management (see Function as a Service Platforms). The load moves up the stack; it does not vanish.

Axis 3 — The Feature Ceiling and the Control You Give Up

Every managed service is an opinionated subset of the thing it manages, and that subset is its feature ceiling. This is where “buy” most often breaks:

  • Version and upgrade cadence. A managed database may not offer the engine version you need on the day you need it, or may force an upgrade on the provider’s schedule rather than yours.
  • Forbidden extensions and modules. Managed Postgres offerings allowlist extensions; if you depend on one the provider does not permit, or a custom C extension of your own, the managed service simply cannot run it.
  • Superuser and low-level tuning. Managed engines withhold the superuser role and lock down kernel/filesystem parameters, replication internals, and plugins. If your workload needs tuning below the knobs the provider exposes, the ceiling blocks you.
  • Custom builds and patches. If you must run a forked or patched build of the engine, no managed offering will host it.

This is a hard gate, not a preference: when the feature you require sits above the managed ceiling, the buy option is simply unavailable and you self-run — not because self-running is cheaper, but because it is the only thing that runs your workload at all. AWS’s own guidance frames service selection as first identifying organizational requirements and then analyzing each component thoroughly against them (AWS COST05 best practices) — precisely to surface a ceiling conflict before committing.

Axis 4 — Portability and Lock-In

Adopting a managed service means adopting the provider’s proprietary surface — its API, its data format, its quirks — and the more differentiated (and useful) the service, the deeper the lock-in. A vanilla managed MySQL is fairly portable (MySQL runs anywhere); a proprietary service like a cloud-native distributed database, a serverless data warehouse, or a fully-managed event bus is not — its wire protocol, its query dialect, and its operational model exist nowhere else. Two forces compound the cost of leaving: data gravity (moving terabytes out incurs egress charges and time) and behavioral coupling (your application has come to depend on the service’s exact semantics). The buy-vs-build decision must therefore price the exit, not just the entry — how much portability is worth paying for, and what it would actually cost to migrate off. That full analysis is Vendor Lock-In and Exit Strategy; here it is one axis: if a hard portability or multi-cloud requirement exists, it can outweigh the operational savings and push you toward a self-run, portable stack (often open-source software you could run anywhere).

Axis 5 — Compliance and Data Residency

Regulated workloads add a gate that is orthogonal to cost. A managed service can help compliance — providers publish attestations (SOC 2, ISO 27001, PCI DSS, HIPAA eligibility) that you inherit for the layers they operate, which is far cheaper than certifying your own stack. But it can also block it: if a regulation demands data reside in a jurisdiction the service does not offer, or forbids a third party from holding the data at all, or requires control the managed abstraction does not expose (specific key-management, audit, or isolation guarantees), then the managed option is off the table regardless of its economics. The compliance axis is therefore two-directional — managed services usually reduce the compliance burden by shifting controls to the provider, but a specific mandate can be the reason you must self-run.

When Running It Yourself Still Wins

The framework is not a slogan for “managed everything.” Here are the cases where build is the correct answer — and why:

SituationWhy self-run wins
Extreme scale where per-unit cost dominatesAt very high, steady utilization the managed markup multiplies across a huge base until it exceeds the salary of a team that could run it more cheaply on raw compute. The classic pattern: companies self-host at hyperscale (their own Kafka, Cassandra, Postgres fleets) because a few percent per-unit saving is worth millions and justifies a dedicated platform org.
You need a version, extension, or patch the managed service forbidsA hard feature-ceiling conflict (§Axis 3): the managed offering cannot run your required extension/superuser/custom build, so buy is unavailable.
Hard portability or multi-cloud requirementIf the business mandates the ability to move providers or run identically across clouds, a portable self-run open-source stack avoids the proprietary lock-in that a differentiated managed service imposes (§Axis 4).
The system IS your differentiationIf operating this system exceptionally well is a competitive advantage (a search company’s search infrastructure, a data company’s storage engine), it is by definition not undifferentiated heavy lifting — you build and own it.
Compliance mandates control the abstraction hidesA residency, key-custody, or isolation requirement the managed service cannot satisfy (§Axis 5).
Deep customization / low-level tuningWorkloads needing control below the exposed knobs (kernel, filesystem, replication internals) must run on infrastructure you own.

The unifying principle: managed wins for undifferentiated plumbing at ordinary scale; self-run wins when scale, feature needs, portability, differentiation, or compliance make the managed abstraction either too expensive per unit or fundamentally unable to do the job. Note the asymmetry in reversibility: choosing buy first and migrating to build later is usually feasible (you already understand the workload); choosing build first and never revisiting it silently accrues the operational cost forever. When genuinely uncertain and the workload is undifferentiated, defaulting to buy and re-evaluating at scale is the lower-risk path.

A Sequenced Decision Procedure

flowchart TD
    S1["1. Classify the workload:<br/>differentiating or plumbing?"] --> S2["2. Check the feature ceiling:<br/>does managed run what you need?"]
    S2 --> S3["3. Price the FULL TCO of build<br/>(infra + labor + reliability +<br/>opportunity, over 3-5 yrs)"]
    S3 --> S4["4. Weigh lock-in / portability<br/>and the cost of exit"]
    S4 --> S5["5. Check compliance:<br/>does managed help or block?"]
    S5 --> S6["6. Estimate scale trajectory:<br/>where does per-unit cost cross<br/>the salary savings?"]
    S6 --> DEC{"Any gate flipped?"}
    DEC -- "no gate flipped" --> BUY["BUY — managed default"]
    DEC -- "a gate flipped" --> BUILD["BUILD — with eyes open<br/>to the operational cost"]

What it shows and the insight to take: the procedure front-loads the disqualifiers (differentiation, feature ceiling) before the arithmetic, because a hard gate makes the TCO spreadsheet moot. Only once no gate is flipped do you let cost and scale decide — and there the default is buy.

Common Misunderstandings and Failure Modes

  • Comparing the managed bill to a bare VM price. The canonical error — it omits labor, reliability engineering, and opportunity cost, which are usually the largest terms. Always cost the whole build column.
  • “Managed is always more expensive.” Often false once payroll is included; and even when the raw dollars are higher, buying can be correct for the time-to-value and reliability it buys (Forbes Tech Council).
  • “We’ll build it, it’s just a database.” Underestimating the reliability tail — backups you have tested, failover that actually works, patching under CVE pressure — is how a “simple” self-hosted system becomes a permanent operational tax.
  • Ignoring the exit. Adopting a deeply proprietary managed service without pricing the migration cost is how data gravity quietly welds you to one provider (see Vendor Lock-In and Exit Strategy).
  • Self-hosting to “save money” at small scale. At low utilization the per-unit saving is tiny and the fixed operational cost is large — exactly the regime where managed dominates. The savings only materialize at scale.
  • Treating the decision as permanent. Scale trajectory changes the answer; a workload correctly bought at launch can correctly move to self-run once it is large and steady. Revisit at inflection points.

Production Notes

The real-world pattern most mature organizations converge on is a portfolio, not a doctrine: buy the undifferentiated plumbing (managed databases, caches, queues, DNS, object storage) and build only where the workload differentiates them or where scale has crossed the cost threshold. The hyperscalers themselves model both sides — they sell managed services precisely because they operate the underlying systems at a scale where owning them is worth it, which is the same logic that justifies a large customer eventually self-hosting its own highest-volume systems. AWS’s Well-Architected review bakes the question into governance: the Cost Optimization pillar asks teams to evaluate cost when selecting services and to prefer managed/serverless options as a default, precisely so that “build” becomes a deliberate, justified exception rather than an unexamined reflex (AWS Cost Optimization Pillar). The discipline is to make buy-vs-build an explicit, re-examinable decision with the full TCO on the table — not a sticker-price reflex in either direction.

See Also

Graph View