AWS 的 Availability Zone (AZ) 設計

昨天因為 AWS 宣佈有計畫在台北建立 region (「AWS 宣佈了台北區將在 2025 年初推出完整的 3-AZ Region」),想說之前有印象官方有把 AZ 講的蠻細的,但寫文章的當下一直沒找到,結果剛剛找到後發現我自己在十年前有寫下來過...:「AWS 的機房架構」。

AWS 官方的原始影片在 YouTube 的「AWS re:Invent 2014: AWS Innovation at Scale with James Hamilton (SPOT301)」這邊可以看到,當年看的 Gigaom 原文看起來已經掛了,但可以在 Internet Archive 上看到:「Amazon details how it does networking in its data centers」。

這些至少是 2014 年當時的情況,現在 2024 不一定,但還是可以當作個參考:

可以看到同一個 AZ 中,data center 之間要求是 <0.25ms,以光纖內光速距離來推差不多是 50km,當年沒有注意到「Don't need inter-AZ independence」這句話,看起來不同 AZ 是允許共用 data center 的

這邊可以看到當年公開出來 AZ 間的要求是 <2ms apart,換算是 400km (當 latency 算) 或是 200km (當 RTT 算),但有提到 usually <1ms apart,換算是 200km 或是 100km。

現在則是直接寫成 60mile/100km,所以我猜 (猜!) 上面應該是 RTT。

然後大概是有些 AZ 之間雖然直線距離在 100km 內,但因為 fiber 不是直線所以 latency 會超過 1ms,而 marketing team 覺得寫成 2ms 很不爽,乾脆改成 60miles/100km?

最後這張倒是比較確定改變很多,畢竟科技也在成長。

AWS 宣佈了台北區將在 2025 年初推出完整的 3-AZ Region

今天早上在 Facebook 上看到的,AWS 宣佈將在 2025 年年初在台北推出 3-AZ region:「AWS Asia Pacific (Taipei) Region coming soon」。

Amazon Web Services (AWS) announced plans to open a new AWS Region in Taiwan by early 2025. The AWS Asia Pacific (Taipei) Region will consist of three Availability Zones at launch.

剛好也看到有人在討論機房是不是都會在雙北,找了一下 AZ 的規範,發現現在有寫出來一些白紙黑字的東西 (記得以前沒有):「Availability Zones」。

Availability Zones in a Region are meaningfully distant from each other, up to 60 miles (~100 km) to prevent correlated failures, but close enough to use synchronous replication with single-digit millisecond latency.

所以要在一個直徑 100km 的圓蓋住的範圍裡面放機房。

拉了幾個地標,汐科火車站到苗栗火車站的直線距離差不多就剛好 100km,所以如果小道消息說桃園與新竹有 AWS 機房的話也不會太意外。

翻資料看到 CloudFront 是 2014 年進台灣的:「CloudFront 有台灣機房了...」,2018 年開了第二個點與第三個點:「CloudFront 在台北的第二個 PoP」、「CloudFront 在台北增加第三個點...」。

再來是 2022 年做為東京區的 AZ 有了 Local Zone:「AWS 的台北區 (Local Zone) 開了」。

然後現在宣佈在 2025 年開 region (會 delay 嗎?),看起來是有量慢慢拉起來?

聊了一下 Amazon S3 Express One Zone 的用途...

昨天寫了「AWS 推出 Amazon S3 Express One Zone」這篇,剛好跟朋友聊了一下 Amazon S3 Express One Zone 的用途...

首先 Amazon S3 Express One Zone 這個產品的定位會是有多台機器需要存取同一包資料:如果是同一台機器要存取的話,放到 Amazon EBS 甚至是 local disk 上就好了。

另外可以知道 Amazon S3 Express One Zone 主要的服務對象不會是靜態資料:靜態資料可以先把所有的資料打包成一大包,丟到標準的 Amazon S3 上面跑,讓每一台機器下載下來,這樣 latency 的影響也會小很多。

所以可以抓到產品的定位:會是有很多機器需要存取同一包資料,而且這包資料會不斷更新。

但畢竟 Amazon S3 Express One Zone 還是要走 HTTPS 去跟 server 要資料,如果你在本地端使用 EBS 或是 local disk,latency 一定還是比較低;而且就程式的開發來說,比較直覺的方法還是在本地端直接弄一個 ext4 filesystem,然後跑很多 process 處理。

(而且這樣還有使用記憶體做的 filesystem cache,加上 EBS 的儲存費用還比 Amazon S3 Express One Zone 便宜)

所以 Amazon S3 Express One Zone 的定位又再被縮小到一台 EC2 instance 沒辦法完成上一段提到的情境。

如果再把前幾天新推出的機器拿來看:「AWS 推出 32TB RAM 的機種 u7in-32tb.224xlarge」,這台新機器是 896 vCPU + 32TB RAM,代表你每跑 896 個 process (假設程式還沒用 threading 打散),而每個 process 可以吃 36GB RAM...

算過以後就會發現,這是個 scale up 可以暴力解很多問題的年代,只要你的演算法不是 n^2 這類的 case...

但回到這個產品的定位,從上面的推敲可以找出還是有對應的需求方,而且知道這是一個比較小眾的產品線,但遇到這種問題的人都會是大型客戶,這樣去思考為什麼會推出 Amazon S3 Express One Zone 就合理多了。

AWS 推出 Amazon S3 Express One Zone

AWS 推出了以效能為導向的 Amazon S3 Express One Zone:「Announcing the new Amazon S3 Express One Zone high performance storage class」。

從名字裡的 One Zone 可以看到這是只有在一個 AZ,主打超低 latency:

The new Amazon S3 Express One Zone storage class is designed to deliver up to 10x better performance than the S3 Standard storage class while handling hundreds of thousands of requests per second with consistent single-digit millisecond latency, making it a great fit for your most frequently accessed data and your most demanding applications.

但費用相當貴,以 us-east-1 來看的話是 $0.16/GB/mo,如果拿其他一些 storage 方案來比,可以看到非常大的差距:

  • S3 Standard:$0.023/GB/mo
  • General Purpose SSD (gp3):$0.08/GB/mo
  • General Purpose SSD (gp2):$0.1/GB/mo

可以猜測後面應該全是 NVM 之類的 storage (不過文章裡沒有提到)。

這次的 Amazon S3 Express One Zone 也多出了很多特別的限制。

首先是新的 bucket type,在這個 bucket type 下面 ListObjectsV2 呼叫就必須以 / 結尾 (這暗示後面的資料處理有對這點 optimization),另外傳回的資料不保證順序了:

The path delimiter must be “/“, and any prefixes that you supply to ListObjectsV2 must end with a delimiter. Also, list operations return results without first sorting them, so you cannot do a “start after” retrieval.

另外看起來是在 AZ 裡面直接認證,所以有新的 authentication model:

The new CreateSession function returns a session token that grants access to a specific bucket for five minutes.

然後 bucket naming 因為有後處理,在命名上不需要在整個 AWS 是唯一的 (因為被加料了):

Directory bucket names must be unique within their AWS Region, and must specify an Availability Zone ID in a specially formed suffix. If my base bucket name is jbarr and it exists in Availability Zone use1-az5 (Availability Zone 5 in the US East (N. Virginia) Region) the name that I supply to CreateBucket would be jbarr--use1-az5--x-s3.

另外資料還是可以在同一個 region 下跨 AZ 存取,而且同一個 region 下面的 compute resources (像是 EC2) 不收傳輸費用:

Although the bucket exists within a specific Availability Zone, it is accessible from the other zones in the region, and there are no data transfer charges for requests from compute resources in one Availability Zone to directory buckets in another one in the same region.

費用的部分還有個比較特別的但書,超過 512KB 的 request 會需要額外收費:

You pay an additional per-GB fee for the portion of any request that exceeds 512 KB. For more information, see the Amazon S3 Pricing page.

主要是給自己開發的應用程式用的,現有的 framework 大多都有利用 batch & buffering 的技巧降低 latency 所帶來的效能影響。

平常應該是用不太到,但就有個印象,真的在架構設計上跑不掉的時候有個選擇...

Python 3.12 將淘汰 datetime.datetime 的 utcnow() 與 utcfromtimestamp()

Simon Willison 這邊看到「It's Time For A Change: datetime.utcnow() Is Now Deprecated」,引用的文章是「It's Time For A Change: datetime.utcnow() Is Now Deprecated」這篇。

文章裡面有提到歷史因素,以及這樣設計造成的問題。

在文章後面有提到替代方案,改了一下裡面的用法,等價於這個:

from datetime import datetime, timezone
datetime.now(timezone.utc)
datetime.fromtimestamp(timestamp, timezone.utc)

或是這樣:

import datetime
datetime.datetime.now(datetime.timezone.utc)
datetime.datetime.fromtimestamp(timestamp, datetime.timezone.utc)

要稍微注意一下這個歷史遺跡要被拆了... (StackOverflow 上面應該有很多用到這兩個 function 的解答)

AWS 弄出了 AWS Dedicated Local Zones,很像 AWS Outposts...

AWS 推出了 AWS Dedicated Local Zones:「Announcing AWS Dedicated Local Zones」。

先講 AWS Outposts,他就是提供 AWS 自己的硬體,放到用戶的機房裡面,所以依照需求有不同大小的機器,甚至是整個機櫃:

AWS Outposts is a family of fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience. Outposts solutions allow you to extend and run native AWS services on premises, and is available in a variety of form factors, from 1U and 2U Outposts servers to 42U Outposts racks, and multiple rack deployments.

在「What is AWS Outposts?」這邊有詳細列出有哪些服務可以跑在上面,可以看到主要就是基礎服務,以及一些吃 local 特性的服務。

另外在「How AWS Outposts works」這邊可以看出架構上會在同一個 VPC 裡面,但是不屬於同一個 AZ 下:

而這次推出的 Dedicated Local Zones 還是有些地方沒看懂跟 AWS Outposts 差在哪裡,看起來很像是重新包裝而已...

首先是首頁提到的,這邊有提到 AWS Nitro System,所以猜測這是 AWS 的硬體,而不是自己的硬體:

Build with AWS managed secure cloud infrastructure

Benefit from the same AWS security standards that apply to AWS Regions and AWS Local Zones and are delivered with the security of the AWS Nitro System to help ensure confidentiality and integrity of customer data.

另外在公告裡面提到的服務,跟 Outposts 有些差異:

AWS services, such as Amazon EC2, Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS), Elastic Load Balancing (ELB), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Direct Connect are available in Dedicated Local Zones.

另外在「AWS Dedicated Local Zones FAQs」這邊則試著說明兩者差異,但就這些句子看起來,只是不同面向的東西:

Q: How are AWS Dedicated Local Zones different from AWS Outposts?

AWS Outposts is designed for workloads that need to remain on-premises due to latency requirements, where customers want those workloads to run seamlessly with their other workloads in AWS. AWS Outposts racks are fully managed and configurable compute and storage racks built with AWS-designed hardware that allow customers to run compute and storage on-premises, while seamlessly connecting to AWS’s broad array of services in the cloud.

AWS Dedicated Local Zones are designed to eliminate the operational overhead of managing on-premises infrastructure at scale. Some customers have long-term, complex cloud migration projects and need infrastructure that seamlessly scales to support their large-scale demand. Some of these customers represent the interests of a customer community and also need multi-tenancy features to efficiently coordinate across their stakeholders. Dedicated Local Zones enable these customers to reduce the administrative burden of managing their own infrastructure on-premises with scalable, resilient, and multitenant cloud infrastructure that is fully AWS-managed and built exclusively for their use.

另外回到首頁看使用單位,目前是 GovTech Singapore,看起來就是重新包裝?

另外一個猜測是在客戶的機器上面裝 AWS Nitro System,然後裝 AWS 的軟體?這就有點怪了,而且這樣相容性之類的問題也頗麻煩,也許要指定配合的機種?

等有機會遇到的時候再跟 AWS 的人問問看好了,目前也還用不到...

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

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

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

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

這是洛杉磯:

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

AWS 在同一區不同 AZ 頻寬費用的特別地方

剛好在處理 AWS 同一個 region 下不同 AZ 之間的傳輸費用,跟帳單互相比對,查了以後才發現跟想像中不一樣,這邊以 EC2 為例子,可以參考「Amazon EC2 On-Demand Pricing」這頁裡面的說明。

從 Internet 端進 AWS 的流量是不計費的:

Data Transfer IN To Amazon EC2 From Internet
All data transfer in $0.00 per GB

但從 AZ 進到另外一個 AZ 時,in 與 out 都要收費:

Data transferred "in" to and "out" from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

所以直接用 US$0.01/GB 的計算是不夠的,得用 US$0.02/GB 來計算。

同樣的,如果是 Public IP 與 Elastic IP 也都是雙向收費,跨 VPC 也是雙向收費,所以都要用 US$0.02/GB 來算:

IPv4: Data transferred “in” to and “out” from public or Elastic IPv4 address is charged at $0.01/GB in each direction.
IPv6: Data transferred “in” to and “out” from an IPv6 address in a different VPC is charged at $0.01/GB in each direction.

AWS 宣佈將在台灣推出 Local Zone

公司的人丟了訊息過來,AWS 要在台灣設 local zone 了:「AWS 宣布在台部署全新 AWS 本地區域,擴充本地基礎設施」。

Amazon Web Services(AWS)宣布將在台灣推出全新 AWS Local Zone(本地區域)。

沒看到確切的時間點... 不過 local zone 的功能都很少,可以參考「AWS Local Zones features」這邊的列表,看看目前已經啟用的 local zone 所支援的服務與機種,像是 RDS 都不一定會有。

不過對個人來說,拿來當 VPS 用還不錯?到時候來看看 routing 的調教如何...

網頁的死亡線

是一篇 2017 年的文章,前幾天在 Hacker News 上重新被提出來:「The Line of Death (2017) (textslashplain.com)」。

文章開頭在講瀏覽器 UI 的信任區,這條線以上是 native UI,以下是網站可以任意操控的內容:

所以 UI 上面有些小細節讓你區分,但這其實對不是專精 phishing 的人很不友善:

另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了:

另外提到了 Fullscreen API,這使得信任區間變成 0:

提到 Fullscreen API 所以就去翻資料,意外發現 IE11 居然支援這組 API,雖然是帶 ms 的 prefix,而且不支援一些輔助性的功能 (像是傳回 Promise object)。

這些 UI 與 security 類的問題,主要還是得考慮到使用者未必那麼熟悉,以及就算有經驗的人也很有可能不小心中獎...