云把【从想法到能跑起来】的时间从约 20 天压到约 23 分钟——而这件事真正的价值不在快,在于不用先掏钱:注册就有额度,试完不满意删掉就完了,于是"想到"和"做到"之间第一次没有采购流程挡着。
上一节(云计算改变了IT行业的世界)讲的是云计算把卖 IT 的人改了。从这一节起,镜头转向买方,看云给使用者的日常带来了什么变化——第一节讲的是【时间】。
第一章的 从系统运用角度看云计算的优越性 已经算过两笔时间账(开发环境 20 天 vs 15 分钟、故障恢复 12 小时 vs 4 分钟)。这一节把那个数字再往前推一步:不只是"环境准备得快",而是在正式立项之前,就能先把东西试出来。这个变化的连带后果很大——它改变的是决策方式,不只是效率。
一、"立即做到"改的到底是什么
先看四步:准备账号、拿到机器、装好系统、部署应用。这四步在自建和云上是一样的,变的是每一步要花多久:
| 步骤 | 自建(买机器) | 耗时 | 云上(开账号) |
|---|---|---|---|
| 第一步:准备账号 | 立项、走采购流程 | 约 2 周 | 注册账号、验证身份 |
| 第二步:拿到机器 | 下单、到货、上架 | 约 3 天 | 点几下,起一台实例 |
| 第三步:装好系统 | 装系统、装中间件 | 约 1 天 | 选镜像,开箱即用 |
| 第四步:部署应用 | 部署、联调、验收 | 约 2 天 | 推上去,跑起来 |
| 合计 | 约 20 天 | 约 23 分钟 |
两组数字要分开看,因为它们卡的地方不一样:
- 自建:20 天里,17 天是"等"——等立项批下来、等机器到货、等上架。真正干活的时间加起来也就 3 天。也就是说,85% 的时间不是在做事,是在等审批和物流。
- 云上:23 分钟里,最长的一段是注册账号时的身份验证(约 5 分钟)。剩下的都是点几下的事。
所以"立即做到"改的不是干活的速度,是等待的长度。 而等待的代价不只是时间——在等待期间,需求可能已经变了。
二、真正被改掉的是"先掏钱才能试"
时间账只是表面。下面这一层更重要:
自建的路是"先花钱、再验证"。你要先走完采购流程、把钱花出去、把机器搬回来,才能知道这个方案行不行。如果不行,机器退不掉,钱已经花了。
云上的路是"先验证、再花钱"。注册就送额度,在额度里把想法试出来;试完觉得不行,删掉就完了,花掉 0 元。
这件事的意义,比"快 20 天"大得多。 因为它的连带后果是:
- 更多想法会被真的试一遍。过去"试一下"的成本是几万块的机器加两周时间,很多想法在立项阶段就被劝退了;现在成本接近零,能试的东西变多了。
- 选型从"猜"变成"验"。过去选中间件、选数据库,多数靠看资料、听别人说;现在可以同时开三套跑一天,用实测数据选,而不是用 PPT 选。
- 失败变得便宜。方案不对就重建一个,代价是一杯咖啡的钱和半小时——这让"试错"从一件要汇报的事,变成一件随手做的事。
三、免费试用这件事,有三种形态
"免费"在云上不是一句话,至少是三件不同的事。分不清这三者,是新手收到意外账单的最常见原因。
| 类别 | 内容 | 提醒 |
|---|---|---|
| 注册额度 | 新账号送 100 美元,完成任务最多再赚 100 | 是余额,不是每月重置 |
| 免费套餐期 | Free Plan 最长 6 个月 | 到期关闭,数据留 90 天 |
| 永久免费项 | Lambda 每月 100 万次、DynamoDB 25 GB 等 30 项 | 超出部分按量计费 |
| 最容易踩的坑 | NAT 网关约 33 美元/月、闲置弹性 IP 约 3.6 美元/月 | 忘了它,它照样计费 |
三者的区别是关键:
- 注册额度是一笔一次性余额——它像一个预付钱包,用完就没有了,不是每个月都恢复。所以"每个月都有 200 美元免费额度"是理解错误。
- 免费套餐期是一段时间窗——窗口一关,账号会被自动关闭(数据保留 90 天)。
- 永久免费项才是真正"只要在用就一直有"的部分——但它是按用量封顶的,超了照样计费。
最容易踩的坑要单独说:那些看起来没在用的东西——一个 NAT 网关、一个没挂到实例上的弹性 IP——都在按月计费。新手第一次收到账单,十有八九是因为页面上没显示的东西还在跑。
四、动手 Demo:两条路的时间账
# 两条路的时间账,单位统一到分钟
self_build = {"立项与采购": 14 * 24 * 60, "到货上架": 3 * 24 * 60,
"装系统": 1 * 24 * 60, "部署应用": 2 * 24 * 60}
cloud = {"注册": 5, "起实例": 3, "部署应用": 15}
a = sum(self_build.values())
b = sum(cloud.values())
print("自建合计 %d 分钟 = %.1f 天" % (a, a / 1440))
print("云上合计 %d 分钟" % b)
print("相差 %d 倍" % round(a / b))
实跑输出:
==================================================================================================
D2 想到就可以立即做到的系统:从想法到能跑,要多久
==================================================================================================
【一】同一件事的两条路
步骤 自建(买机器) 耗时 云上(开账号)
------------------------------------------------------------------------------------
第一步:准备账号 立项、走采购流程 约 2 周 注册账号、验证身份
第二步:拿到机器 下单、到货、上架 约 3 天 点几下,起一台实例
第三步:装好系统 装系统、装中间件 约 1 天 选镜像,开箱即用
第四步:部署应用 部署、联调、验收 约 2 天 推上去,跑起来
------------------------------------------------------------------------------------
合计 约 20 天 约 23 分钟
【二】2026 年免费额度的四个特征(以 AWS 为例)
类别 内容 提醒
------------------------------------------------------------------------------------------------
注册额度 新账号送 100 美元,完成任务最多再赚 100 是余额,不是每月重置
免费套餐期 Free Plan 最长 6 个月 到期关闭,数据留 90 天
永久免费项 Lambda 每月 100 万次、DynamoDB 25 GB 等 30 项 超出部分按量计费
最容易踩的坑 NAT 网关约 33 美元/月、闲置弹性 IP 约 3.6 美元/月 忘了它,它照样计费
【三】三个草稿想法,各试一天
过去:要走三次采购流程,约 6 周,机器买回来就退不掉。
现在:在免费额度里挨个试三天,花掉 0 元;不想要,删掉就完了。
读这个输出:第一张表的时间合计是 20 天 vs 23 分钟——相差约 1,250 倍。但这个倍数不该被当成卖点来理解,因为它比的是"等物流"和"点鼠标",本来就不可比。
真正该带走的是第三段那句话:三个想法、三次采购流程、六周、机器退不掉,对比三个想法、三天、零元、删掉就完了。第一张表说明的是快,第三段说明的是敢试——后者才是这一节的重点。
五、⚠️ 2026 现状
- 免费额度的规则在 2025 年 7 月改过一轮,网上多数教程还在讲旧版。老规则是"12 个月内某些服务免费用"(比如 EC2 每月 750 小时);新开的账号已经不走这套,改成"送额度、限时、从额度里扣"。所以看到"每月免费 750 小时"的说法,先看那篇文章的发布日期。
- 各家的免费策略同向但不同步。三家都在做"新账号额度 + 少量永久免费项"这个组合,但额度大小、有效期、覆盖范围都不一样,而且调整很频繁。结论:免费额度只适合验证想法,不适合承载任何长期运行的东西。
- 额度之外最容易踩的还是那几个"看不见的资源":NAT 网关、闲置弹性 IP、没有一起删掉的卷和快照。行业里"云上浪费约三成"的这个数字(见 3-12),有很大一部分就出在试用期留下的这些残留资源上。
30 秒实验
随便找一个你最近想过但没做的技术想法(比如"用某个数据库存一份数据"),然后只做一件事:把要用的服务、要花的钱、要等的时间,在纸上列三行。
- 如果走自建:列一下要买什么、大概多少钱、多久能到。
- 如果走云上:列一下要在哪家开什么服务、免费额度够不够试。
做完你会发现,第二条路的第一行往往写不到 10 分钟就能填完。 这个"不好意思再拖"的感觉,就是这一节想说的事。
常见误区
-
错误:免费额度就是"每个月都免费给这么多"。——纠正:它是余额,不是配额。 Demo 第二张表里那一行说得很清楚——注册额度是一笔一次性余额,用完不恢复。而"永久免费项"才是每月刷新的,但它按用量封顶、只覆盖少数服务。把余额当配额用,是新手收到第一张账单最常见的原因。
-
错误:删掉实例就等于停止计费了。——纠正:不一定,而且往往不是。 挂在上面的存储卷、做过的快照、分配了没用上的弹性 IP,都可能在实例删掉之后继续计费。正确的收尾动作是"从账单倒着看":打开账单页,逐项确认每一行对应的资源还在不在,而不是凭印象觉得自己删干净了。
-
错误:既然 23 分钟就能起来,那就不需要规划了。——纠正:刚好相反——因为太快,反而更容易出乱子。 自建的 20 天里,人会自然地停下来想清楚需求;而 23 分钟的路径上,人容易直接开干,于是架构没想清楚就上线、权限没设计就先跑起来。云降低的是"动手"的成本,不是"想清楚"的必要性——后者一分都没省。
-
错误:免费额度用完了就得马上交钱。——纠正:要分清两种账号形态。有的形态在额度用完或到期后会自动关闭账号(数据保留一段时间),有的形态则直接转成按量计费继续跑。注册时选哪一种,决定了你后面会不会收到一张意外的账单。 这件事值得在注册的第一步就看清楚,而不是等账单来了再研究。
自测三问(点开对答案)
1. 自建的 20 天里,真正"在干活"的时间大约占多少? —— 大约是 **三成**。真正动手的部分(装系统 1 天 + 部署 2 天)约 3 天,其余 **17 天是等待**——等立项、等采购、等物流、等上架。**这个比例说明:自建慢的不是技术,是流程。** 所以"云更快"这件事,快在流程上,不在技术上——这也解释了为什么它同时改变了决策方式。 2. "先验证再花钱"和"先花钱再验证",对决策的影响有什么不同? —— **前者的试错成本接近零,后者要真金白银出去才能知道行不行**。后果是:前一条路下,**能试的想法变多、选型靠实测、失败可以重来**;后一条路下,**想法在立项阶段就被劝退、选型靠资料、失败要写检讨**。所以这不只是效率问题,是**一个组织一年能试多少个想法**的问题。 3. 为什么说"免费额度只适合验证想法,不适合承载长期运行的东西"? —— 因为**免费额度的性质是"余额 + 期限"**,它天然会在某个时点结束——而长期运行的系统最怕的就是"某一天规则变了"。一旦额度用完或套餐到期,要么服务中断、要么自动转成按量计费,**两种结果都是意外**。**判断标准很简单:需要一直跑的东西,从一开始就按正式计费来规划;只想试一下的东西,才用免费额度。**- ☐ 下一节(3-3 云服务的使用动态:信息与通信白皮书)
相关笔记
- 云计算改变了IT行业的世界 —— 上一篇:云计算先把卖方改了
- 云服务的特点 —— 按量收费与扩展性,是"敢试"这件事的底层机制
- 从系统运用角度看云计算的优越性 —— 另一笔时间账:开发环境与故障恢复
- 云服务的费用 —— 免费期结束之后,钱是怎么算的
- ☁️ 云计算 · 索引 —— 全课路线图