目前 AWS 台北區只能開 *.2xlarge 的機器

前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來,剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge

改成 c5.2xlarge 然後就開起來了:

翻了目前所有的 local zone,看起來大多都是類似的情況,選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多,這是邁阿密:

這是洛杉磯:

這樣目前要拿來當 VPS 取代品還不太好用,就真的是 local zone 的定位。

AWS 的台北區 (Local Zone) 開了

AWS 總算是宣佈啟用台北 Local Zone 了:「AWS Local Zones Expansion: Taipei and Delhi」,中文的公告在「AWS 宣布在台全新 AWS Local Zone 正式啟用」。

翻了一下先前的預告是六月初的時候,大概是四個月前,當時寫了「AWS 宣佈將在台灣推出 Local Zone」這篇。

看 Jeff Barr 提供的 screenshot 可以看到如同先前了解的,就是掛在東京區下面 (ap-northeast-1):

比較奇怪的地方是啟用的方式,我是在在 EC2 的 dashboard 上看到這個進去開 (然後是 Service health),在 VPC 裡面反而沒看到:

然後開了之後要等他幾分鐘啟用,不是幾秒後 refresh 就會出現,我大概等了兩分鐘,跟當初開其他 non-default region 的經驗類似:

然後再回到 VPC 裡面開 subnet,開完後再回到 EC2 上開機器,流程不是很直覺。

另外從「AWS Local Zones features」這邊可以看到目前的服務有限,另外 Jeff Barr 的公告也可以看到目前台北區支援的項目:

After you do this, you can launch Amazon Elastic Compute Cloud (Amazon EC2) instances, create Amazon Elastic Block Store (Amazon EBS) volumes,and make use of other services including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon Virtual Private Cloud (Amazon VPC). The new Local Zones include T3, C5, M5, R5, and G4dn instances in select sizes, along with General Purpose SSD (gp2) EBS volumes.

不過這邊有不一致的地方:在 AWS 頁面上是寫 T3 是 upcoming,但 Jeff Barr 的公告則是說可以用 T3,這點晚點來測試看看才知道哪個是對的... 因為我現在連 m5.large 也開不起來:

只要把設定換到東京的 subnet 內就正常,這個錯誤訊息實在是不知道發生什麼事情 (已經設 gp2),還得繼續摸...

Prerender 從 AWS 搬回傳統機房的成本節省

Hacker News 上看到「We reduced our server costs by moving away from AWS (gitconnected.com)」這篇,原文在「How we reduced our annual server costs by 80% — from $1M to $200k — by moving away from AWS」這邊。

偶而會看到這類的報導,這次是 Prerender 這家的服務,從本來在 AWS 上的 $1m/y 降到 $200k/y (這邊都是用美金在計算)。

但好像沒提到第一次投資購買硬體花了多少錢,不過就以前的經驗上來說,把每個月非人力的 OPEX 加上 CAPEX 的各種攤提,大概會是雲端的 1/3 到 1/2 的費用。

近年來 k8s 以及各種架構愈來愈完整,很多技術也都收斂,慢慢變成業界標準了,不需要自己土砲搞一堆東西而導致產生可觀的維護成本。

crt.sh 上面搜尋 prerender.io 可以看到 Prerender 選擇的工具,像是在地端上面應該是用 k8s,然後有用 Sentry 以及 Redash

這個跟當年算過的經驗類似,startup 可以先上雲端把服務做起來,雲端的擴充性對於初期的幫助會很大 (先 scale up 撐住,再改寫成可以 scale out 的版本),而當量又大到一定程度時就反過來先問 discount,如果不滿意的話就可以規劃搬回地端。

Prerender 的量看起來超過臨界值不少,搬到地端省成本應該是蠻理所當然的...

Route 53 提供 100% SLA,而 Route 53 Resolver 提供 99.99% SLA

AWS 宣佈 Route 53 提供 100% 的 SLA,而 Route 53 Resolver 則提供 99.99% 的 SLA:「Amazon Route 53 Resolver Endpoints announces 99.99% Service Level Agreement and updates its Service Level Agreement for Route 53 hosted zones」。

Route 53 的部份指的是 hosted zone,參考「Amazon Route 53 Service Level Agreement」這邊,可以看到是 2022/08/29 更新的條款。

Route 53 Resolver 的部份可以參考「Amazon Route 53 Resolver Endpoints Service Level Agreement」這邊,也是 2022/08/29 更新的條款。

要注意 99.99% 是指 Multi-AZ Resolver Endpoints SLA;如果是 Single-AZ Resolver Endpoints SLA 看起來是設定在 99.5%。

不確定是不是 AWS 的第一個 100% SLA 條款...

CloudFront 在越南開點

AWS 宣佈在越南設立 edge:「AWS announces new edge locations in Vietnam」。

新的 edge 包括了各種服務,像是標題寫到的 CloudFront

The new locations offer edge networking services including Amazon CloudFront and AWS Global Accelerator that are integrated with security service AWS Shield that includes Distributed Denial of Service (DDoS), Web Application Firewall (WAF), and bot protection.

看起來是拓點,第一次進到越南,先前應該是會被導去泰國或是香港?

不過在 CloudFront 的「Global Edge Network」頁面上面意外的還沒看到越南的點 (參考 Internet Archive這邊以及 archive.today這邊)。

AWS 在阿聯開區域了 (me-central-1)

AWS 在阿聯開新的區域了:「Now Open–AWS Region in the United Arab Emirates (UAE)」。

也是首發就 3 AZ:

The Middle East (UAE) Region has three Availability Zones that you can use to reliably spread your applications across multiple data centers.

中東的第一個區域是巴林,首都麥納瑪離阿聯的首都杜拜直線距離大約 500km,算起來蠻近的... 對於主要客群是中東的用戶,看起來可以設計 Active-Active 的機制做到跨區備援?

不過更重要的還是繼續等台灣的 local zone...

AWS Support 整合到 Slack 頻道內

在「New – AWS Support App in Slack to Manage Support Cases」這邊看到的新功能,主要是下面這張圖,看起來可以直接在 Slack 上面開 private channel 跟 AWS Support 成員討論事情:

依照說明,有 Business 以上的等級都可以用:

The AWS Support App in Slack is now available to all customers with Business, Enterprise On-ramp, or Enterprise Support at no additional charge.

雖然好像不是哪麼常跟 AWS 的人打交道,但平常先掛起來好像不錯...

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇,大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情,基本上討論的內容大概都想的到...

AWS 這邊的話,最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態),但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種),讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著,官方現在應該是主力在推 DynamoDB

兩種完全不同的作法...

CloudFront 支援 HTTP/3

雖然 HTTP/3 還沒有進到 Standard Track,但看到 CloudFront 宣佈支援 HTTP/3 了:「New – HTTP/3 Support for Amazon CloudFront」。

只要在 CloudFront 的 console 上勾選起來就可以了:

看了看 RFC 9114: HTTP/3 文件裡的描述,client 可以試著建立 UDP 版本的 QUIC 連線,但要有機制在失敗時回去用 TCPHTTP/2 或是 HTTP/1.1

A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級:

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

像是這樣:

Alt-Svc: h3=":50781"

然後 client 就可以跑上 HTTP/3:

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

另外在 FAQ 裡面有提到啟用 HTTP/3 是不另外計費的,就照著本來的 request 費用算:

Q. Is there a separate charge for enabling HTTP/3?

No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.

先開起來玩看看...

EC2-Classic 的狀態

Twitter 上看到這個:

2022/08/15 是 EC2-Classic 最後活著的時間,先前在「AWS 宣佈 EC2-Classic 退役的計畫」這篇也有提到。

在官方的公告文章「EC2-Classic Networking is Retiring – Here’s How to Prepare」這邊裡面有提到最後的日期:

On August 15, 2022 we expect all migrations to be complete, with no remaining EC2-Classic resources present in any AWS account.

不過畢竟是用 expect,應該還有客戶沒有換過去,而且 AWS 官方好像也沒有提到這個 milestone...