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 都還是沒改善...

回頭來看一下 Limelight Networks

是因為看到「How Limelight Networks speeds up sales deals with Slack Connect」這篇,才想到 Limelight Networks 這家 CDN 之前也是這個產業很大的 vendor,在很多大型網站可以看到 llnw 的蹤跡 (當時 Microsoft 的 Windows Updates 與 Apple 的軟體下載還會用他的服務),但這十年看起來就被 CloudflareCloudFront 以及 Fastly 這些後起之秀超越過去了... (至少在聲量上面是這樣)

翻到 Global Private Network 這頁,意外發現現在有把節點列出來了,記得以前是不公開的...

在裡面可以看到台灣也有節點,不過拿 HiNet 與 APOL (家裡的 cable) 實際測官網 www.limelight.com,發現都是導去香港的點,可能是有需要的客戶才會導過去,之後有機會也許問問看...

Amazon SES 開東京區與新加坡區了...

Amazon SES 是 2011 年年初發表的服務,過了九年總算想起來這幾區也是需要 SES 的服務了...:「Amazon Simple Email Service is now available in the US East (Ohio), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Asia Pacific (Seoul) Regions」。

這些年來大家應該都是用 us-west-2 或是 us-east-1 workaround 很久了,現在開這些區域主要還是讓 API 的整合會比較方便,如果本來就是透過 IAM user + username + password 的方式寄信的話就沒什麼差...

另外一種是寄比較大的信件 (產生的流量很大),這次這樣可以避免降低跨區而被收兩次流量費用,不過這應該是比較少見的情況...

AWS 義大利區開張

這是這幾天 AWS 新開的區域:「Now Open – AWS Europe (Milan) Region」,這樣就成為歐洲的第六個 region,與美洲的數量也一樣了 (美國四個,加拿大一個,南美一個)。

不過用 aws ec2 describe-regions | jq '.Regions[].RegionName' | xargs -n1 aws ec2 describe-availability-zones --region 掃了一輪,只有 us-east-1 (美東一區)、us-west-2 (美西二區) 與 ap-northeast-1 (日本) 有超過三個 AZ,這樣難怪 AWS 會考慮在日本多開一個大阪區了...

AWS 南非區開張

上個禮拜 AWS 南非區開張營業:「Now Open – AWS Africa (Cape Town) Region」。

不過測了一下從 HiNet 過去的 latency 居然到了 450ms,看了一下 routing,應該是先到美國,繞道歐洲後再到南非,看看後續會不會比較好?從台灣的 GCP 過去也沒好到哪邊,大約 410ms。

APOL 則是 320ms 左右,應該是繞的比較少...