AWS KMS 推出 Multi-region keys

這應該是 AWS 被許多大客戶敲碗許久的功能之一,AWS KMS 支援 global key:「Encrypt global data client-side with AWS KMS multi-Region keys」。

以前不支援這個功能時,在加密儲存跨區域的資料會有兩種作法,以 us-east-1ap-northeast-1 為例子來說:

第一種是透過 replication 的概念,檔案內容從 us-east-1 解開後,透過 TLS 傳到 ap-northeast-1 再加密,所以不同區的密文內容是不同的。

第二種是自己抽象一層 AES key,檔案內容都用這把 AES key 加解密,而這把 AES key 則透過不同區的 AWS KMS 保護,但這樣做又要自己搞 key rotation,另外還可能會有 auditing 的問題...

現在 AWS KMS 直接支援就省事很多了:

文章裡面是拿 DynamoDB 當範例,不過其他只要能夠用 AWS KMS 應用應該也能用。

AWS 區域間的連線測試

Hacker News 首頁上看到「AWS Latency Monitoring」這個,看起來是常態性在所有的機房都開機器一直測試蒐集資料,就可以直接拉出來看...

有常見的 p50 與 p99 資訊,對於在規劃架構的時候還蠻有用,在「mda590/cloudping.co」這邊可以看到他是用 LambdaDynamoDB 的 endpoint 測試。

好像沒有 packet loss rate 的資訊,這個也蠻重要的...

Amazon EC2 提供跨區直接複製 AMI (Image) 的功能

Amazon EC2AMI 可以跨區複製了:「Amazon EC2 now allows you to copy Amazon Machine Images across AWS GovCloud, AWS China and other AWS Regions」。

如同公告提到的,在這個功能出來以前,想要產生一樣的 image 得重新在 build 一份:

Previously, to copy AMIs across these AWS regions, you had to rebuild the AMI in each of them. These partitions enabled data isolation but often made this copy process complex, time-consuming and expensive.

有一些限制,image 大小必須在 1TB 以下,另外需要存到 S3 上,不過這些限制應該是還好:

This feature provides a packaged format that allows AMIs of size 1TB or less to be stored in AWS Simple Storage Service (S3) and later moved to any other region.

然後目前只有透過 cli 操作的方式,或是直接用 SDK 呼叫 API,看起來 web console 還沒提供:

This functionality is available through the AWS Command Line Interface (AWS CLI) and the AWS Software Development Kit (AWS SDK). To learn more about copying AMIs across these partitions, please refer to the documentation.

AWS 大阪區開放

AWS 大阪區開放給大家使用了,而且有標準的三個 AZ 可以用:「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。

大阪區因為之前就已經有機房 (附加在東京區),所以對應的 routing 看起來不算太差,但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency,分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。

另外測了其他的 ISP,有些上日本的點是以東京為主,反而會多繞了一圈,大阪區的 latency 會比較高。

不過如果放遠來說,東京大阪的直線距離大約是 400km,光纖的傳輸速度大約是光速的 2/3,所以單趟大約差了 2ms,如果有機會最佳化的話應該有機會擠出 4ms 出來?

然後是 EC2Pricing 頁面,上面還是寫 Asia Pacific (Osaka-Local),無法確定是新資料還是舊資料,但以往的慣例應該是更新了...

對照文章裡有提到支援的機器,目前看起來還沒有很齊,像是目前都還沒有 AMDARM 架構的機器,另外也沒有 GPU 類型的機器:

The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.

就支援的類型隨意挑了幾個 instance type 比較,翻了一下價錢看起來跟東京的一樣。

整體看起來,如果是有考慮到異地的需求是可以考慮,另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來),但既有的服務應該不需要急著搬...

AWS 計畫在 2022 下半年開瑞士區

AWS 宣佈要在瑞士開新的區域:「In the Works – New AWS Region in Zurich, Switzerland」。

目標是 2022 的下半年開三個 AZ:

It will open in the second half of 2022 with three Availability Zones and will give developers, startups, and enterprises, as well as government, education, and non-profit organizations the ability to run their applications and serve end-users from data centers located in Switzerland.

如果是講「啟用」的話,接下來應該是 2021 上半年要開的大阪區,先等這個消息好了,不知道 COVID-19 對這些計畫的影響有多大...

OpenBGPD 接 AWS Direct Connect 時只讓單區路由的方法

算是繼上篇「用 pfSense 接 AWS Direct Connect (Public VIF) 的方式」的改善,上篇的方法設定完後預設會是全部都會 routing 進來。也就是說,如果你接到新加坡區,美東 routing 也會進來。

這可能是你要的,但也可能不是你要的,所以找了一下方法,在 AWS 的文件裡面有提到可以透過 BGP community 控制這些 routing:「Routing policies and BGP communities」。

第一個方向是從 pfSense 送出去的封包,這個要過濾從 BGP 送進來的 routing table:

AWS Direct Connect applies the following BGP communities to its advertised routes[.]

把:

allow from 1.2.3.4

改成:

allow from 1.2.3.4 community 7224:8100

另外一個是讓 AWS 不要把我們的 network 送到其他區,這是在 network 上加上 BGP community tag:

You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions.

把本來的:

network 1.2.3.4/30

變成:

network 1.2.3.4/30 set community 7224:9100

先這樣搞,用 mtr 看了一下應該沒錯...

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡,ap-southeast-1),但發現偶而會很不順,傳輸的時候會很卡,所以後來決定租了一條專線用 AWS Direct Connect 接進去。

不過因為跑在 AWS 上面的服務是掛在 public network 上,而不是 private ip 的網段,所以就不能用 IPsec site-to-site 打通收工,而需要搞 BGP routing,然後就卡關卡的亂七八糟 XD

首先是文書作業的部份,因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權),這部份在 web console 上建立完 Public VIF 後會進入審核階段,接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定,我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。

這邊比較有趣的是,如果你沒有買 support plan 的話無法開 technical support,但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別:「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。

過了審核後接下來是設定 pfSense 的部份,因為是要接通 public network 的部份,所以你要收 AWS 提供的 BGP routing,這部份在 pfSense 上會透過 OpenBGPD 解決,但主要還是因為對 BGP 不熟悉,所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題,不然現在事後來看,自己 tcpdump 應該就有能力找到問題了...

主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。

這是一個 TCP extension,連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改:「Protection of BGP Sessions via the TCP MD5 Signature Option」。

要注意的是這個協定不是 application level,而是在 TCP 層本身就保護起來,包括 3-way handshake 的部份,所以從一開始 SYN 封包過去就要有 md5sig 的資訊。

這也表示用 telnet 不會通是正常的,這點讓我找問題找錯方向好久...

另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD),這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到:

Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.

That module is required for TCP_SIGNATURE to function.

If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.

到了對應的選項那邊要選擇,因為我們的 pfSense 機器比較低階,沒有那堆硬體加速度的東西,所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。

設定完後新的連線也還是不會有效果,後來想了一下還是整台重開機,然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題,純粹就是不熟悉這些東西造成的。

AWS Ground Station 多了南非區可以打

看到「AWS Ground Station is now available in the Africa (Cape Town) Region」這邊的消息,AWS Ground Station 可以在南非區使用。

這是南半球第二個點 (第一個是雪梨):

AWS Ground Station is available today in US West (Oregon), US East (Ohio), Middle East (Bahrain), EU (Stockholm), Asia Pacific (Sydney), EU (Ireland), and Africa (Cape Town) with more regions coming soon.

如果以補 coverage 的角度來看,南美與東北亞 (東京或是南韓) 應該也有機會?

AWS 在 Los Angeles 開第二個 Local Zone

AWS 在 Los Angeles 開了第二個 Local Zone:「Announcing a second Local Zone in Los Angeles」,所以現在兩個 zone 的代碼分別是 us-west-2-lax-1aus-west-2-lax-1b

稍微回頭複習一下,發現大阪區 (Local Region) 跟東京的直線距離大約是 400km 左右,但如果是以 Los Angeles (Local Zone) 與 Portland 的話則是 1300km 左右,如果是 Seattle 的話就會到 1500km 左右。

而且 Los Angeles 的 Local Zone 是掛在 us-west-2 而不是 us-west-1 (N. California) 上面,看起來這兩個主要的差異是在商業考量上,us-west-2 應該是目前的主力 (從各種產品推出的發佈時程看得出來),所以才會這樣規劃...

回頭翻「AWS 在 us-west-2 開 Local Zone」這篇的時候,發現當時我應該是把 Local Region 與 Local Zone 搞混了...

AWS 南韓區開第四個 AZ

AWS 南韓區開第四個 AZ 了,比想像中的快不少:「Now Open – Fourth Availability Zone in the AWS Asia Pacific (Seoul) Region」。

而且不像東京,新客戶只能看到三個 AZ:「Regions and Availability Zones」。

*New customers can access three Availability Zones in Asia Pacific (Tokyo).

雖然台灣過去的 routing 都還是沒改善...