iT邦幫忙

2026 iThome 鐵人賽

DAY 9
0
佛心分享-SideProject30

toui:一條短網址能做到哪些事——從轉址到 AI 工作流系列 第 9

Day 09|AWS SES 費用:上線前五天,我把已經能動的寄信服務拆掉重做

  • 分享至 

  • xImage
  •  

前一篇 Day 8〈名字取好只是開始:side project 轉成正式作品的命名學〉 談名字,名字定下來、功能也做得差不多了,接著就是上線。

但我在上線前那幾天真正忙的事,不是在補最後幾個功能,而是把一個已經完整能動的機制整個拆掉,重新做了一遍。

toui 的登入不用設密碼,除了使用 Google 登入機制,另一種方式是 Magic Link,輸入 email 後會寄一封信給你,點了信中的連結後就完成登入了。這個功能說起來不難,但真正要完成的眉眉角角不少,規劃功能時盤點過,當時的判斷是 Resend 介接快,用它我就能把開發能量放在 toui 的核心功能。

這個想法原本沒錯,但我卻在上線前五天,推翻了這個決定。把 Resend 轉換成 AWS SES。

這個過程的技術細節我寫在〈無密碼登入不用買服務:用 AWS SES + Lambda 親手做 Magic Link 登入機制〉,那篇講的是怎麼做,這篇著重的是怎麼算。

一點點就差很多:階梯和斜坡

四月初,要上線的功能還在如火如荼地趕工時,我突然心血來潮,把自己推估一年後的用戶數換算成發信量,再套進 Resend 的計價級距。

在上線前看著 Resend 的免費額度覺得應該夠用,但如果把時間拉到上線一年後,登入信(每個使用者每次登入都是一封)、歡迎信、帳務通知、偶爾的公告疊起來,帳單數字就不一樣了。

同樣是「這個月多寄了幾百封」,在兩種收費方式底下,發生的事完全不同。

訂閱制是階梯。 免費層有一個上限,跨過去不是多付一點點,是跳進第一個付費級距。你剛好超過那個上限的第一封信,跟你把整個級距用滿的最後一封信,帳單是同一個數字。而且上限常常不只一個,除了每個月的總量,可能還有每天的、甚至每秒鐘的。

日上限特別容易在你最不希望它出事的那天撞到。平常一天寄不了幾封,離月上限還很遠,但只要你的服務被一篇報導或一則貼文推到很多人面前,那個下午湧進來註冊的人就可能抵得上平常一整週。當天的額度幾個小時內就會用完,然後新的使用者收不到登入信。

用量計價是斜坡。 多寄一封就多那一封的錢,少寄一封帳單就少那麼一點。沒有級距,也不會有「這個月忘了降回去」這種事。我當時搬過去的 AWS SES 就是後者,按封數算。

兩種收費方式各有各的道理,取捨的關鍵在於你現在站在哪裡

初創業階段最痛的正是第一階。你的量還很小、離下一階還很遠的時候,那一階的月費在你的總支出裡佔的比重非常高,可能就等於這個專案整個月的成本。同樣是多寄幾百封,在階梯上是跳一級,在斜坡上幾乎沒感覺。

初創業的成本,一點點就可以差很多,差的往往不是絕對金額,而是它在你當時那份總支出裡的比重。

訂閱制買的其實是「不用想這件事」

它賣的其實是時間,信件到達率、退信處理、網域驗證那些設定,你不用一開始就懂,也不用自己顧。對一個還在找方向的 side project 來說,那非常划算,因為你手上最缺的資源本來就是時間,不是錢。

如果你今天做的東西還沒有量、也還不知道會不會有量,選那個能讓你半天就上線的,通常是對的。

只是當我把未來的預估成本放進來看時,我原本以為便宜買到的那段時間,就變得一點也不便宜,或者至少,超出了我能投入的成本。

不要只盯著啟用時的價目表,要推估成長的成本

https://ithelp.ithome.com.tw/upload/images/20260901/201788137dlMhuJZuX.png

在寫這篇時,我回頭去看了當時抓的那張成本對照表。後來實際的用量,的確超過了表上最初的那一階

即便這是個 happy trouble,但能不能事先就評估到才是重點。這其實就是成本的風險控管,有幾個問題一開始最好就先問:

  • 這筆錢會不會隨著我長大而變化? 有些支出是固定的,有些會跟著用量走,兩者要分開看。
  • 變化是階梯還是斜坡? 這決定了「多用一點點」的代價。
  • 我離下一階多遠? 不要只拿現在的量算,要拿三個月、六個月或是一個極端的量去算。

第三個問題最容易被跳過,因為上線前沒有用戶,未來還太模糊,難估算就不估了。即便估算錯誤還可以修正,仍然需要一個預估值來幫助自己做成本規劃。

我後來反過來要求自己,每個要用的服務,都得先把它的用量限額算出來。同樣的,也要讓別人算得出自己的用量,toui 的 API 免費額度(每分鐘、每天、每個月各有一條)就直接寫在 API 文件裡。

先算出你離上限還有多遠

在上線前幾天才更換登入機制不是個好的決定。如果我在選用服務當時就仔細算過,這個更換就不會發生,雖然只花了一個下午就改完,但它本來可以是一個不需要存在的下午。

如果你手上有一個 side project,正在用某個免費層看起來還很寬鬆的服務,挑一個出來,去找出它免費層的上限,然後算你離最近的那一個還有多遠,再用這幾個月的成長速度把距離換算成時間,看看是否安全。

風險究竟是高或低,除了實際的情況之外,還有每個人的風險承受能力。我是寧可儘量不要面臨意外的人,對許多經營 side project 的人也是一樣,不希望有天突然就有個天價帳單等著自己。

老話一句,小心駛得萬年船。


上一篇
Day 08|名字取好只是開始:side project 轉成正式作品的命名學
系列文
toui:一條短網址能做到哪些事——從轉址到 AI 工作流9
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言