幹壞事是進步最大的原動力
Amazon EKS 宣佈降價 50%：「Amazon EKS Price Reduction」。
開頭這段就講了重點：
[...] We are reducing the price by 50%.
As of the 21st of January, the price will reduce from $0.20 per hour for each Amazon EKS cluster to $0.10 per hour. This new price is for all new and existing Amazon EKS clusters.
本來的價錢換算成月費大約是 USD$144/month，現在降到 USD$72/month，看起來好像很多，但因為這其實只是 kubernetes 的 controller 費用，實際跑 pod 的 EC2 instance 還是照舊，所以應該是還好...
對於每個 cluster 的量都夠大的人來說其實沒有太多感覺，主要是對於每個 cluster 量不大的人會好很多...
Rasmus Lerdorf 整理的資料 (就是生出 PHP 的那個 @rasmus)，關於平價 VPS 的測試：「Low-Cost VPS Testing」。
因為是 PHP 的大頭，所以把編 PHP 當作是 benchmark 的項目之一也不算太意外。另外還是有比較常見的 dd 與 iperf3 測試資料可以看。
算是一個挖掘的點，之後也可以租幾台測試看看...
相較於 Amazon EC2 有 Spot Instance (可以利用 Spot Instance 的競價機制省下很多費用)，這次 AWS re:Invent 時 Fargate 也推出了對應的產品線：「AWS Fargate Spot Now Generally Available」。
跟 EC2 的相同，你在上面跑的應用程式必須可以接受隨時中斷服務 (i.e. 必須是 crash-safe)，常見的情境是 worker 類的程式。
價錢上大約在三折 (寫這篇時 us-east-1 目前的價錢)，考慮到啟動的速度比 EC2 快很多，這樣好像是個可以考慮的方案...
Amazon API Gateway 宣佈一個新的產品，提供 HTTP APIs 管理 RESTful APIs (???)：「Amazon API Gateway Offers Faster, Cheaper, Simpler APIs Using HTTP APIs (Preview)」。
官方是這樣描述 HTTP APIs 的：
Use HTTP APIs to build high performance RESTful APIs that require API proxy functionality without API management features. HTTP APIs are optimized for serverless applications and HTTP backends, and offer up to 70% cost savings compared to REST APIs.
你已經有了 RESTful APIs，然後跑去接個沒有 API management features 的 API Gateway...？
然後翻了一下之前 API Gateway 的豐功偉業，本來打了一大堆，但還是留點口德好了... 看起來 API Gateway 團隊裡老大的後台很硬啊，搞成這樣都沒被幹掉？
話說回來，去年 ALB 宣佈支援 AWS Lambda，該不會是 API Gateway 實在太爛，所以 Serverless 的大方向逼 ALB 支援的啊？
Amazon RDS 推出了 Connection Pool 的產品，叫做 Amazon RDS Proxy：「Introducing Amazon RDS Proxy (Preview)」。
目前支援 MySQL (包括了傳統的與 Aurora 版本的)：
Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.
定價策略看起來是依照後端資料庫的 vCPU 計算：
Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.
翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料)，而如果是 t2 系列的機器，最低是以 2 vCPUs 計算，不是照使用比例算：
RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.
這樣一個 vCPU 一個月大約要 USD$21.6，算起來頗貴的... 如果 SLA 允許的話，用基本的方式 failover 也許就 ok 了...
如果 SLA 真的要追求到這麼高的話，可以在這些區域測試：
Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.
Amazon Elasticsearch Service 的新功能，使用 Amazon S3 當作第二級儲存空間 (UltraWarm)：「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。
UltraWarm 需要不同的機器 (跑不同版本？)，機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本，但是貴了不少，所以需要夠大的資料量才會打平回來...
拿 us-east-1 來看，SSD EBS 的空間成本就是 USD$0.135/GB，而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用？)，但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB，看起來是直接包括了 API 的呼叫費用？
前幾天看到 AWS 推出新的折扣方式，也就是「New – Savings Plans for AWS Compute Services」這篇。裡面給了兩個新的折扣模式：
首先是 Compute Savings Plans，不限制地區，而且包括了很多類型的服務，不僅是 EC2：
The plans automatically apply to any EC2 instance regardless of region, instance family, operating system, or tenancy, including those that are part of EMR, ECS, or EKS clusters, or launched by Fargate.
而 EC2 Instance Savings Plans 則是只有在 EC2 上使用，需要指定地區與機型：
Just like with RIs, your savings plan covers usage of different sizes of the same instance type (such as a c5.4xlarge or c5.large) throughout a region.
就目前的理解來看，EC2 Instance Savings Plans 其實就是換個包裝的 Regional RIs，因為 Regional RIs 本來就可以給同個 family type 使用 (沒有使用到的 c5.xlarge RI 可以拿到 c5.2xlarge 使用，照比率抵一半計算，另外一半照正常價錢)。
Compute Savings Plans 算是新的東西，你給個 hourly commit 付錢後，很多服務都可以使用這筆 hourly commit 折抵。
Amazon EFS 有 IA 的儲存方案，儲存的價位便宜很多，但需要另外收存取費用。不過這對於丟 log 之類的倒是還算方便，很多現有的程式就可以直接往裡面丟...
不過系統的設計上不是讓你指定哪些檔案放到 IA，而是設定 Lifecycle Management Policy 以及時間，當超過指定的時間後就會安排搬到 IA 裡面。
先前最低的時間是 14 天，剛剛看到 AWS 宣佈有 7 天的選項了，從 web console 上就可以看到選項可以選了：「Amazon Elastic File System Infrequent Access Now Supports a 7-day Lifecycle Management Policy」。
這樣對於開始堆資料的人，一開始塞東西進去而需要付 Standard Storage 的時間可以少蠻多的...
Google Cloud Platform 一開始是提供 Premium Network，會透過 Google 自家的網路骨幹連到最近的點，然後再透過當地的機房交換出去，這樣可以確保頻寬的穩定性，但成本當然也就比較高...
後來提供了 Standard Network 則是從機房出去後就直接交換，成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇)，但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請？)，所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了，不確定是已經全開了還是分批開。
測了一下發現網路相當... 爛？是還在調整嗎...
像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題)：
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms
然後 168.95.1.1、139.175.1.1 也都很差 (61.31.1.1 不給 ping)：
PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data. 64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms 64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms 64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms --- 168.95.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data. 64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms 64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms 64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms --- 139.175.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms
不過學術網路倒是還不錯：
PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data. 64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms 64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms 64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms --- 140.112.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data. 64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms 64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms 64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms --- 140.113.250.135 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data. 64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms 64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms 64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms --- 140.117.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms
有需要的人可以測試看看了...
剛好跟同事聊到 Amazon EC2 的 T2/T3 Unlimited，因為有些疑惑所以回家查了一下資料，發現以前的理解不夠完整。這是 T2/T3 Unlimited 的說明文件：「Unlimited Mode for Burstable Performance Instances」。
在文件的這塊說明了 T2/T3 Unlimited 模式的計算方式：
When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a flat additional rate per vCPU-hour.
我本來以為是剩下的 CPU credit 不夠時就會被收費，但依照官方文件的說明，是可以用後面賺到的 CPU credit 支付前面使用的 CPU credit，而可跨越的時間區間是 24 小時。
所以有時候會在 AWS web console 上看到 CPU 沒有在用，但是 CPU credit 卻長回不來的情況，是因為這時候還在還之前的債...