The One Thing You Cannot Buy Is Latency
In one line
Latency is the one thing you cannot buy with money in the cloud. You can buy everything else, so everything else is a matter of calculation.
Why decide with numbers
Cloud decisions usually turn into a fight over preferences. "Isn't the Seoul region better?", "Managed services are expensive," "Let's just move to the cloud first" — with no evidence, the loudest voice wins, and six months later nobody can explain why it was decided that way.
But all four of these decisions have a basis you can calculate.
| Decision | What settles it |
|---|---|
| Where to put the region | The physical limit that comes from distance |
| Whether to split AZs | What you buy for 1 ms |
| Whether to use a managed service | A comparison that includes people's time |
| What you are responsible for protecting | Whether you can configure it |
Once it is written down as numbers, it can be checked or challenged, and the discussion moves forward from there. Below we work out the four one by one.
You cannot beat the speed of light
Seoul to Virginia is about 11,000 km. Light travels at about 200,000 km/s in optical fiber (two thirds of its speed in a vacuum, because of a refractive index of 1.5).
편도 55ms · 왕복 110ms
This is a physical limit. You cannot reduce it by making the instance bigger, by paying more, or by laying a dedicated line. In practice the path is not a straight line and passes through equipment many times, so you see about 180 ms.
And here is why it matters — if a page calls the API 5 times, that is also 5 round trips. 110 ms × 5 = 550 ms, and nothing happens during that time.
So choosing a region is not a matter of preference but of calculation. And a design that reduces the number of round trips (batched requests, caching, edge) is far more effective than making the instance bigger.
An AZ buys something different for the same price
| Distance | Round trip | What it survives | |
|---|---|---|---|
| Same AZ | Same building | < 0.5 ms | One server |
| Between AZs | Same metropolitan area | About 1 ms | Building, power and cooling |
| Between regions | A continent | Tens to hundreds of ms | A city or a disaster |
If you split across AZs, you survive a building failure almost for free. Latency grows by only 1 ms. That is why you almost always spread across AZs and spread across regions only when needed.
Shared responsibility — if you don't know the boundary, neither side protects it
There is one criterion.
What I can configure is my responsibility.
| My responsibility | The provider's responsibility |
|---|---|
| Bucket public-access settings | Hypervisor patching |
| IAM key management | Physical access control |
| OS security updates | Power and cooling |
| Application vulnerabilities | Minor patches of a managed DB |
| Backup settings | Hardware replacement |
There is one confusing case — an instance that stopped because an AZ lost power is the provider's responsibility. But having deployed only there is my responsibility. The provider said from the start that an AZ can die, and told you to use multiple AZs.
Incidents almost always happen in the place where both sides thought it was not their job.
Why managed services look expensive
Because you compare only the infrastructure charges.
직접 운영 인프라 400$ + 사람 20시간 × 60$ = 1,600$
관리형 900$
Without people's time, the managed service looks twice as expensive; with it, the managed service is $700 cheaper.
People's time does not show up in the ledger. You are already paying salaries, so it feels "free." But that time is usually spent at night, when an incident happens, and that person cannot do other work in the meantime.
The break-even is worked out like this.
(900 - 400) / 60 = 8.3시간
If it takes less than 8 hours a month, running it yourself is cheaper. Do backup checks, patching, monitoring, capacity reviews and even one incident response fit within 8 hours? Usually they do not.
When the cloud is not the answer
It is not "the cloud is cheap" but "the cloud is flexible." If you don't need flexibility, there is no reason to pay for it.
- Large-scale compute with a steady load that you will use for 3 years or more — autoscaling has nothing to do
- Workloads that send out large volumes of data — egress charges dominate
- Data residency regulation — if there is no region, you cannot use it
- Special hardware — if it is not offered, you cannot use it
Conversely, if the load is uneven, if you don't know how much you will need, or if you have to start quickly, the cloud is almost always better. What you are buying then is not compute but the right to postpone the choice.
What it looks like in the field
- A team put the region in Virginia because headquarters is in the US, and page loads for Korean users grew by nearly a second — each page was calling the API five times.
- A team deployed to a single AZ, and when the AZ failed, it closed the retrospective by blaming the provider. The next quarter the same thing happened again.
- A team chose to run it themselves because managed services were expensive, and since then twenty hours a month go into patching, checking backups and night-time incident response. Those hours are in no ledger.
- A team reported a leak from a publicly opened bucket as a provider security incident, and only afterward confirmed that the party who set the configuration was itself.