Why Managed Looks Expensive
In one line
If you compare the price lists of managed services directly, they always look expensive. That is because some items are missing — our time, and the things we will no longer be able to do.
Why it was needed
The comparison "RDS is twice as much as installing it ourselves on EC2" comes up often in meetings. The numbers are right. But that comparison table has no lines like these.
| Missing item | If you run it yourself |
|---|---|
| Planning and applying patches | A few days every quarter, night work |
| Backup setup and verification | Initial build plus recovery rehearsals |
| Redundancy setup | Replication setup and failover tests |
| Monitoring | Collecting metrics and writing alert rules |
| Incident response | Calls at dawn. Rare, but not zero |
| Version upgrades | Once every few years, a big job each time |
Converted into people's time, this usually exceeds the price difference. The smaller the team, the more this is true — in a team of 3, if one person spends 20% on DB operations, that is 6–7% of labor costs and more than the price difference of most managed services.
Exceptions to choosing managed
But managed is not always the answer
You also have to do the calculation in the opposite direction.
- At very large scale, the unit cost of running it yourself becomes much lower. At the scale of hundreds of machines, having dedicated staff is cheaper.
- If the load is unusual, the managed service's default settings do not fit. There is no room for tuning, so you can only solve it with money, and that is more expensive.
- If you are already doing it well, there is no reason to move. Changing something that works also costs money.
How to turn the judgment into numbers
Writing down just three lines usually gives a conclusion.
1. 월 요금 차액 = ( 관리형 − 직접 ) 원
2. 직접 운영에 드는 월 인시(person-hours)
3. 인시 × 시간당 비용 = 숨은 비용 원
2+3 이 1 보다 크면 관리형이 싸다.
Adding one more line makes it accurate — the value of the work you could not do in that time. If there is a feature you could not build because you were looking after the DB, that is the real cost.
A checklist for moving to managed
- Are the required versions and extensions supported?
- Do the connection count and performance limits withstand our load?
- Do the backup retention and recovery time (RTO) meet the requirements?
- Can we see the logs and metrics as much as we need?
- Can we choose the maintenance window?
- When we leave, how do we get the data out?
Few teams check item 6 at the start, and later it is the one that costs the most.
What running it yourself really costs
If you compare only the price lists of managed and self-operated, self-operated always looks cheaper. The comparison holds only when you also count what is not on the price list.
| Item | Self-operated | Managed |
|---|---|---|
| Instances and storage | As on the price list | As on the price list (usually 1.5–3 times) |
| High-availability setup | Standby node cost plus setup time | Included (or a single switch) |
| Backup and recovery rehearsals | People design and verify | Included, point-in-time recovery with a click |
| Major upgrades | Planning, rehearsal and a window every quarter | Pick a window and it's done |
| On-call duty | People wake up at night | Usually they don't |
| Monitoring and alerting | Build and maintain | Default dashboards |
The biggest items are the last three. If one DB major upgrade takes two engineer-days, four times a year is 8 days. If you put labor at 600,000 won a day, that is 4.8 million won — the price of a few instances.
Turning the judgment into one line of numbers
자체 운영 총비용 = 인프라 + (연간 운영 시간 × 시간당 인건비) + 사고 비용 기댓값
관리형 총비용 = 인프라(비싼 값) + (남는 시간 × 그 시간에 만들 가치)
The last term is the key. Buying a managed service is buying time, and if you can build the product in that time, it is a good deal. Conversely, if you have enough people and need special tuning, self-operating is right.
Converting lock-in into a value
The real price of a managed service is not the charge but the difficulty of leaving. Even this, though, has degrees.
| Type | Degree of lock-in | Examples |
|---|---|---|
| Standard protocol as is | Low | Managed PostgreSQL, Redis, Kafka |
| Standard plus proprietary extensions | Medium | Extensions of Aurora and ElastiCache |
| Fully proprietary API | High | DynamoDB, Firestore, serverless functions |
The first row has practically no lock-in. You just dump the data and move it to another place that uses the same protocol. If lock-in worries you, start with managed services on standard protocols. When you use a proprietary API, first calculate whether its benefit exceeds the cost of moving.
What it looks like in the field
- Compared only the charges and ran it ourselves → six months later the person in charge quit, and nobody knew anything.
- Moved to managed but hit the connection count limit → a missed pre-check.
- Managed costs grew, and going back was daunting because exporting the data was blocked → item 6 was not checked.
What to look at next
Finally, we talk about what not to move to the cloud.