AWS 新的折扣方式 (Saving Plans)

前幾天看到 AWS 推出新的折扣方式,也就是「New – Savings Plans for AWS Compute Services」這篇。裡面給了兩個新的折扣模式:

  • Compute Savings Plans
  • EC2 Instance Savings Plans

首先是 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 提供 7 天的 IA 選項

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 在台灣的機房可以開 Standard Network 的機器了

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.1139.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

剛好跟同事聊到 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 卻長回不來的情況,是因為這時候還在還之前的債...

GCE 的 IP 要收費了...

收到信件通知,本來在 GCE 上使用的 Public IP address 是免費的,2020 年開始變成要收 USD$0.004/hr (Standard,約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible,約 USD$1.44/month):

First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.

從 2020 年一月開始生效,但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費),這樣你會知道你的 IP address 費用會吃多少錢:

We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:

January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.

其實整體成本應該是還好,但看到漲價總是不開心... XD

AWS 推出使用 AMD CPU 的 t3a.*

AWS 推出了 t3a.* 的 EC2 instance:「Now Available – AMD EPYC-Powered Amazon EC2 T3a Instances」。

目前開放的區域有限,但算是個開始:

You can launch T3a instances today in seven sizes in the US East (N. Virginia), US West (Oregon), Europe (Ireland), US East (Ohio), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance form.

價錢大約再低個 10% 左右:

Pricing is 10% lower than the equivalent existing T3 instances; see the On-Demand, Spot, and Reserved Instance pricing pages for more info.

有些超小的機器可以考慮重開的時候就順便換過去...

AWS 推出更便宜的儲存方案 Glacier Deep Archive

AWS 推出的這個方案價錢又更低了:「New Amazon S3 Storage Class – Glacier Deep Archive」。

在這之前在 us-east-1S3 最低的方案是 Glacier Storage,單價是 USD$0.004/GB (也就是 $4/TB)。

而這次推出的 Glacier Deep Archive Storage 在同一區則是直接到 USD$0.00099/GB ($0.99/TB),大約是 1/4 的價錢。

Glacier Deep Archive 在取得時 first byte 的保證時間是 12 小時,另外最低消費是 180 天:

Retrieval time within 12 hours

先前就有的 Glacier Storage 則是可以在取用時設定取得的 pattern (會影響 first byte 的時間),而最低消費是 90 天:

Configurable retrieval times, from minutes to hours

Pricing for each of these metrics is determined by the speed at which data is requested based on three options. "Expedited" queries <250 MB are typically returned in 1-5 minutes. "Standard" queries are typically returned in 3-5 hours. "Bulk" queries are typically returned in 5-12 hours.

多一個更便宜的選擇可以用。

Spotify 向歐盟投訴 Apple Music 的不公平競爭

Spotify 向歐盟提出不公平競爭的投訴,並且發出新聞稿:「Consumers and Innovators Win on a Level Playing Field」。

重點在於 Spotify 服務透過蘋果的平台會有 30% 的抽成,但 Apple Music 因為自家服務而不需要:

To illustrate what I mean, let me share a few examples. Apple requires that Spotify and other digital services pay a 30% tax on purchases made through Apple’s payment system, including upgrading from our Free to our Premium service. If we pay this tax, it would force us to artificially inflate the price of our Premium membership well above the price of Apple Music. And to keep our price competitive for our customers, that isn’t something we can do.

不過裡面好像沒提到超過一年後的費用會降到 15% (參考「Auto-renewable Subscriptions」),應該會是蘋果向歐盟回應的重點?

開始把一堆網域轉到 Cloudflare 上...

看到「Cloudflare Registrar at three months」這篇文章,然後前幾天剛好也有其他人提到轉到 Cloudflare 的事情,就把手上的網域也轉一轉...

轉過來最主要的原因還是價錢,另外也是因為都掛進 Cloudflare 了,直接把註冊商掛在 Cloudflare 上有很多設定會比較簡單。

批次轉移界面做的還不錯,系統會先把帳號內的網域都列出來,然後依照註冊商歸類後給你填 auth code,之後開始轉就會收到確認信,確認後就都過去了。不過還是有些沒收到確認信,不知道是不是等五天...

另外一個是信用卡的部份,元大的 JCB 刷不過 (不過元大的系統擋很凶似乎是用這張的人都知道了...),改用富邦的 VISA 一刷下去就過了,但是轉 n 個網域就產生了 n 筆交易,然後就接到銀行的關切電話了...

雖然支援了 246 個 tld,但目前 *.tw 還不能轉,先把其他的轉過來了...

Amazon EFS 的 IA Storage Class

Amazon EFS 一直找不太到好用的使用情境,因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來,而拿來堆 log 的成本又超級高...

最新推出的 storage class 則是透過提供低儲存成本的版本,解決了堆 log 這種使用情境:「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。

不過 EFS 不像 S3 可以直接選擇 storage class,是需要讓系統管理的:

開啟後 30 天沒有被碰過的檔案就會切過去:

Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.

而 latency 也會增加:

Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.

us-east-1 為例子來說,Standard 是 USD$0.3/GB-month,而 IA 只要 USD$0.045/GB-month,但抓取時會有 USD$0.01/GB 的傳輸費用,可以看出價錢低不少。

不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard,可能得找機會問問看...