How do you decide whether to use a managed service or self-host a component, and which cloud costs catch teams out?

Start from what you are transferring, not from what you are buying

The useful framing is not "managed or self-hosted" but "who is holding the pager for this, and what are they responsible for at 3am". A managed database does not remove work in general; it removes a specific, enumerable list of tasks. Minor version patching. Backup execution and, more importantly, restore rehearsal. Automated failover to a standby. Storage growth. The evidence an auditor wants about encryption and access. If you can name those items for the component in question and none of them is work you are currently doing badly, the managed option is buying less than the price difference suggests.

Run the test in reverse too, because that is where candidates are thinner. A managed service removes controls, and the ones that matter are predictable: you take the versions the provider offers on the provider's timetable, you get the extension or plugin list they support and not yours, you often lose filesystem and OS access which means you lose the diagnostic tools that depend on it, and network placement is constrained to what the service supports. The subtlest loss is root-cause access. When a self-hosted broker misbehaves you can attach a profiler and read the logs; when a managed one misbehaves you open a ticket and wait, and your recovery time becomes a function of somebody else's support queue.

The questions that actually decide it

Is this component differentiating? Almost nothing about running a message broker is your competitive advantage, and the effort you spend on it is effort not spent on the thing customers pay for. That argument is strong, and it is also the one people over-apply, so it needs the next question beside it.

What is the exit cost if this is wrong? Lock-in is a gradient, not a binary. A managed service speaking a standard protocol or wire format, so a PostgreSQL-compatible database or something offering the S3 API, is close to interchangeable and the decision is cheap to revisit. A proprietary query language, a bespoke event format, or an identity model with no equivalent elsewhere is a decision you are making for the lifetime of the system, and it deserves proportionally more scrutiny.

Do you have the team, honestly? Self-hosting a stateful system properly means someone who understands its failure modes, replication, backup verification and upgrade path, and who is available when it breaks. Two engineers with the knowledge is not a rota. If the honest answer is that one person knows how it works, you have chosen an operational risk rather than saving money.

And what does the availability arithmetic look like? A provider's SLA is a billing credit, not a promise, and composed dependencies multiply: a request path touching four components each at three nines cannot itself be better than roughly four times that error rate. If the managed option publishes a figure below your SLO, no amount of your own effort inside it will raise it, and the answer is either a different service, redundancy across instances, or a revised SLO agreed with the business.

My default is managed for anything stateful and non-differentiating, self-hosted where you need a control the managed option cannot give you, or where volume has grown large enough that the provider's margin genuinely exceeds the cost of a competent team. Those crossover points exist and they arrive later than most teams believe.

Where the comparison usually goes wrong

The failure is comparing a managed hourly rate against the compute rate for a self-hosted instance, and this comparison is close to always dishonest. It omits the standby replica you need for the failover the managed service was doing for you. It omits backup storage and the periodic restore test. It omits the load balancer, the monitoring, and the log volume. Above all it omits engineer time, which is the largest number in the entire calculation and the only one that never appears on a cloud invoice.

Do the sum with all the lines in it. If a managed instance costs some multiple of the raw compute, and self-hosting requires two instances plus backup storage plus a share of two engineers' attention plus the expected cost of the outage you would have had, the premium usually turns out to be paying for something. Where it does not, you will be able to show it, and that is a far stronger answer than an intuition either way.

Three cost models that surprise teams

Egress is asymmetric. Getting data into a cloud is typically free and getting it out to the internet is billed per gigabyte, which means the architecture that costs nothing to load can cost a great deal to serve. This is why a CDN in front of anything high-volume and cacheable is a cost decision as much as a latency one, and why a workload that reads a large dataset should generally run in the same region and provider as that dataset rather than pulling it across a boundary. Backup and disaster-recovery copies to another region are the same charge, incurred quietly every day. The related trap is a NAT gateway, which bills both an hourly rate and a per-gigabyte processing charge, so pulling container images from the public internet on every scale-out event is a recurring cost that a gateway or private endpoint to the registry removes.

Traffic between availability zones is billed; traffic within one is not. This is the one that catches people, because it turns a resilience decision into a permanent line item. Spread a chatty service and its cache and its database across three zones for availability, and a meaningful share of every request now crosses a billed boundary, in some providers charged in both directions.

Derive it rather than guessing. Assume 1,000 requests per second at peak, each request making two calls that cross a zone boundary, each returning 20 KB. That is 2 × 20 KB × 1,000 = 40 MB per second on the wire. Over a 30-day month, 40 MB/s × 2,592,000 s is about 103,700 GB. Multiply by your provider's current inter-zone rate for that region, remembering that some bill each direction separately, and you have a defensible figure. The point of the arithmetic is not the number, which changes with your provider and region; it is that a hundred terabytes a month of internal chatter is the kind of quantity nobody expects from an architecture diagram that shows three tidy boxes. Zone-aware routing, so a request prefers a replica in its own zone, is often the largest single saving available, and it improves latency at the same time.

Idle capacity is the biggest line nobody looks at. Cloud billing is for what you reserve, not what you use. A node pool averaging 25% CPU is paying four times over for compute. Non-production environments running around the clock for a team that works one third of the day are two thirds wasted, and shutting them on a schedule is the least glamorous and most reliable saving in this list. Then there is the residue: unattached volumes, snapshots of instances deleted a year ago, reserved addresses pointing at nothing, one load balancer per service where a shared ingress would do, and a managed instance per microservice each with an hourly minimum. Log and metric ingestion belongs in the same category, priced per gigabyte ingested and retained, and it is regularly the second largest line on the bill because it scales with traffic while nobody owns it.

The discipline that makes this tractable is attribution: tags that map spend to a team and a service, enforced by policy so untagged resources are visible, and a per-request or per-tenant unit cost that someone reviews. Without attribution, cost optimisation is an annual panic. With it, the team that created a cost is the team that sees it.

Choose managed or self-hosted on the operational load you are transferring and the controls you are giving up, then check the decision against a cost model that includes engineer time, cross-zone chatter and the capacity you are paying for but not using.