<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Billing on 水源一二三</title><link>https://theweidi.net/tags/billing/</link><description>Recent content in Billing on 水源一二三</description><generator>Hugo</generator><language>zh-TW</language><lastBuildDate>Sun, 24 Oct 2021 07:19:56 +0000</lastBuildDate><atom:link href="https://theweidi.net/tags/billing/index.xml" rel="self" type="application/rss+xml"/><item><title>「最佳化」AWS 帳單</title><link>https://theweidi.net/optimizing-aws-billing/</link><pubDate>Sun, 24 Oct 2021 07:19:32 +0000</pubDate><guid>https://theweidi.net/optimizing-aws-billing/</guid><description>&lt;p&gt;第一次認真看完 Corey Quinn 的信，在講 &lt;a href="https://www.lastweekinaws.com/blog/the-turbotax-of-aws-billing/"&gt;The TurboTax of AWS Billing&lt;/a&gt;，除了一如既往生動的舉例跟嘲諷以外，他提到為什麼他的諮詢費用是「固定費用」而不是取決於「幫客戶省下多少錢」。&lt;/p&gt;
&lt;p&gt;簡單來說，不是帳單變少就是好，我的價值是幫你做出最好的調整。如果要高可用當然費用就會增加，但不是每個場景都會需要這種架構（例如水源一二三不需要多區域部署來增加 availability，但定期的 S3 備份可以提高 durability）。如果今天我收費模式是「抽佣省下來的金額」，我的目標會被導向找出可以省錢的點，而非「如果我是你我會這樣架構」。很好理解卻也很容易踩入的誤區。&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;Side note: &lt;a href="https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concepts.wa-concepts.en.html"&gt;Concepts&lt;/a&gt; of AWS Well-Architected Framework&lt;/p&gt;</description></item></channel></rss>