系统与基础设施geekwire.com
Dropbox 迁出 AWS，两年节省近 7500 万美元
Dropbox saved almost $75M over two years by moving out of AWS
2018 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dropbox 通过自建基础设施逐步迁出 AWS，两年内节省了近 7500 万美元。文章指出，当创业公司成长为拥有数亿用户、对自身计算需求了如指掌的大公司后，针对自身需求定制的基础设施往往比云服务更高效。
为什么经久不衰：它清晰呈现了'云 vs 自建'的成本权衡：云的价值在于灵活性和规避风险，而规模稳定、需求可预测的公司自建更划算——这一判断框架至今仍是基础设施决策的经典参考。
HN 评论精选
AWS 的溢价买的是应对不确定性的灵活性，成熟稳定的企业自建更划算
AWS 卖的是未来的选择权。自建数据中心会让你在许多不确定需求面前变得脆弱：业务增速与计划不符（无论过快还是过慢都是问题）、流量峰值迫使你过度配置、业务方向可能转变。AWS 价格中很大一部分应视为购买未来灵活性的费用。事后用已知的实际需求来比较价格是不公平的，正确的比较是前瞻性的：在多种不确定场景下，用 AWS 还是自建更划算。由此推论，需求可预测的成熟企业自建可能更便宜，而增长中或变化中的业务，AWS 的灵活性更合理。
dzdt查看英文原文
AWS sells optionality. If you build your own data center, you are vulnerable to uncertain needs in a lot of ways. (1) your business scales at a different rate than you planned -- either faster or slower are problems! (2) you have traffic spikes, so you to over-provision. There is then a tradeoff doing it yourself: do you pay for infrastructure you barely ever use, or do you have reliability problems at peak traffic? (3) your business plans shift or pivot A big chunk of the Amazon price should be considered as providing flexibility in the future. It isn't fair to compare prices backwards-looking: where you know what were your actual needs and can compare what it would have cost to meet those by AWS vs in house. The valid comparison is forward looking: what will it cost to meet needs over an uncertain variety of scenarios by AWS compared to in-house. The corallary of this is, for a well-established business with predictable needs, going in-house will probably be cheaper. But for a growing or changing or inherently unpredictable business, the flexibility AWS sells makes more sense!
许多大公司上云并非出于成本或扩容，而是为了规避内部政治和管理负担
使用 AWS 这类服务有两个好理由：一是规模太小、自建设备无法形成规模经济（考虑总拥有成本时 AWS 更便宜）；二是需要快速扩容应对需求。第二个主要取决于数据——有足够的用户历史数据时扩容是可预测的，也可以只把部分基础设施放到云上。有趣的是，我认识的几家依赖 AWS/Azure 的公司并不属于这两种情况：它们是大企业，几乎不做自动扩容，上云更多是出于内部政治因素——少一个高管、缩短沟通链条、出问题时有人可以背锅。它们把自己视为'非科技公司'，尽量少雇技术员工。
Someone1234查看英文原文
There's two good reasons to use a service like AWS: - You're too small for efficient economies of scale on your own equipment (i.e. AWS is cheaper when considering total cost of ownership). - You need to scale rapidly to meet demand The second one is largely a data issue, if you have enough historical data on your customers, their habits, usage, and so on then scaling becomes predictable and even when it isn't you could offload only part of your infrastructure to a cloud vendor. What's interesting is that several companies that I know which rely on AWS/Azure/et al aren't on it for either of the two above stated "good" reasons. They are large businesses and do almost no automated scaling. They're on it for what can only be described as internal political limitations, meaning that they are on these services to remove the politics of technology infrastructure, one less manager at the top, a shorter chain of communications, an external party to blame when something does go wrong, and issues like HR/benefits/etc for infrastructure employees is outside the scope. In effect they view themselves as "not a technology company" so look to employ the fewest technology employees as they can. Even in cases where technology is paramount to their success. It is very interesting to watch, and I'm not even claiming they're "wrong" to handle their infrastructure this way, just that it is hard to quantify the exact reasoning for it.
超过约 300 台服务器的规模自建即划算，混合云是兼顾两者的最佳方案
这并不意外。在 Blekko 负责运维时我们算过两次账（C 轮融资时证明自建划算，被 IBM 收购时证明迁入 Softlayer 太贵）。如果你能搭建合理的管理工具，且需要超过约 300 台服务器和大量存储，自建在成本上就是赢家。最佳方案是在一个有 10G 管道接入亚马逊网络的数据中心自建，这样可以在峰值或等待自有设备就绪时临时启用 AWS，两全其美。
ChuckMcM查看英文原文
This isn't surprising. At Blekko where I ran operations we did the math not once but twice (once when we got our series C to show that it made sense, and once when we got acquired by IBM to show why moving it into Softlayer was going to be too expensive). If you can build reasonable management tools and you need more than about 300 servers and a bunch of storage, cost wise its a win to do it on your own. The best win is to build out in a data center with a 10G pipe into Amazon's network so that you can spin up AWS only on peaks or while you are waiting to bring your own stuff up. That gives you the best of both worlds.
别照搬 Dropbox 的结论，必须根据自身系统和需求具体测算
提醒一下：你不是 Dropbox。你需要亲自对两种方案都算账。视你的用例而定，用 AWS 可能更便宜，托管机房也可能更便宜，如果规模像 Dropbox 那么大，自建数据中心可能更便宜。这让我想起关于 K8s 的争论：大多数讨论只基于用例，而没有考虑所有可选方案的空间。这不仅是规模问题，需要深入理解你的系统和需求，任何走捷径的做法都会导致成本低效。
ebiester查看英文原文
Just as a reminder: You are not Dropbox. You personally need to run the numbers with both scenarios. Depending on your use case, it may be cheaper to be in AWS, and it may be cheaper to be co-located. If you are as big as Dropbox, it may be cheaper to build your own data center. It reminds me of the arguments for and against K8s. Most of the discussion is based on use case, and not considering the solution space for all solutions. E.g. if I'm running an Erlang solution in K8s, or have a small number of servers, I may have better options. It isn't only about scale. It takes understanding your system and your needs in depth, and any short cuts lead to cost inefficiencies.
云是打车、自建是买车：短期灵活、长期自建更省
云就像出门都打出租车，裸金属则是自己买车。前者你付溢价让别人操心所有细节和维护，后者你承担这些负担但不用付溢价。这对一切提供服务的东西都成立。需求小或不确定时很好，因为没有初始投入，但长期来看不划算。
llarsson查看英文原文
Cloud is taking a taxi everywhere, bare metal is owning your own car. In one case, you pay a premium so that somebody else worries about all details and maintenance, and in the other, you take on that burden but don't pay the premium. This has always been true for everything where a service is provided to you. Great if your needs are small or not well known because there is no initial investment, but bad in the long run.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选