跳到主要內容

why create at least two subnets in different AZs is a must have practice?

今天遇到了一個有趣的問題,在 AWS VPC 裡要 create RDS DB instance 遇到了一個無解的問題。

原本的 VPC 規劃時只有兩個 subnet,而且無法再加進其他 subnet。

VPC CIDR: 192.168.1.0/24
Subnet 1 CIDR: 192.168.1.0/25
Subnet 2 CIDR: 192.168.1.128/25

更悲劇的是,這兩個 subnet 都是屬於同一個 Availability Zone (AZ).....

雖然在 VPC 裡 create RDS instance 時可以選擇 "Multiple AZ deployment = No" 但接下來卻還是一定要 create DB subnet group.

而 DB subnet group 則是至少要有兩個 subnet 要在不同的 AZ,
我原本以為如果我選擇只要 single AZ deployment,那 create DB subnet group 應該就不是必要的,但看起來 AWS 是不允許的。去翻了一下 Working with an Amazon RDS DB Instance in a VPC 第一條真的寫了
"Your VPC must have at least one subnet in at least two of the Availability Zones in the region where you want to deploy your DB instance. A subnet is a segment of a VPC's IP address range that you can specify and that lets you group instances based on your security and operational needs."

雖然我不知道怎麼只有一個 subnet 但是可以有兩個 AZ,但就我的理解應該就是指,你的 VPC 下要有兩個以上的 subnet,然後至少有兩個 subnet 是屬於不同 AZ。

這個故事告訴我們:

  • 創建 VPC 時,可大,不可以小。雖然目前只有兩個 subnet 可以用,但是可以留一些空間讓以後還有機會加 subnet 進去。
  • VPC 裡的 subnet 最好手動指定在不同的 AZ。
不然要砍掉 VPC 或者 subnet 重建會是很麻煩的一件事...

留言

這個網誌中的熱門文章

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下,把一些 public API 移到 VPC 裡面,只讓特定網路的人可以存取。 當然最直覺的想法就是,建一個新的 VPC ,加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering,建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway,然後再加一個 ALB ,裡面的 target group 指向 VPC endpoint 的 IP和 443 port,ALB 設定好 Domain Listener,API Gateway 也加上相同的 Custom Domain Name,這樣子 ALB 就可以當成特定網路 access 的 entry point,一但 Peering 完成後,從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想,Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面,A 帳號的 VPC 只是啟用了 VPC endpoint,一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取,即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...

全球鷹/響尾蛇 D300 行車記錄器

全球鷹 Global Eagle /響尾蛇 D300 行車記錄器 前後雙鏡頭,透過電瓶的壓升壓降來開啟/關閉行車記錄器主機 wifi 是 mmcx 接頭,去淘寶買一條 20 元 預設 wifi 密碼是 12345678 透過 TimaCam 可以 wifi 連線主機,用來看即時鏡頭畫面還可以 但是要下載一個片段 216MB 非常慢,讓我看到噪音管和吐白煙的想檢舉也覺得麻煩... 主機拆下後,即使透過 USB 供電也無法開機, 要操作主機只能發動機車在車子旁邊操作, 主機沒接線的裝態也不能直接拿來看錄影檔。 從 2018.3 月安裝到現在,發生過一次熄火吃完飯(約20分鐘),竟然沒關機還在錄影。還好只是 20 分鐘,不然電瓶的電不知道會不會被吃完。 現在都很提心吊膽,熄火後都會等他壓降關機後(約 1 分鐘)才會離開。 早知道還是裝一般開電門供電,關電門關機的機種。 wifi 看檔和安裝容易都只是噱頭,買了才知道難用。

Publish lambda layer to regions from s3 bucket?

boto3 有個  publish_layer_version  API,你可以使用 S3 bucket + key or zipfile 來發布 lambda layer. 使用 zipfile 的話就是從命令執行端上傳,所以假設你的 lambda packet 是 20MB 然後你要發佈到 16 個 AWS region 的話,就看你命令執行端的網路上傳速度了。 使用 S3 bucket 來放要發佈的 zipfile 檔似乎比較合理,因為這樣子檔案的複製就是在 AWS 的網路內發生。 But... 很機車的是,如果你的 zipfile 是放在 us-west-1 的 S3 bucket 那麼你就只能發佈到 us-west-1 .... 當你要發佈到其他 region 會出現 error botocore.errorfactory.InvalidParameterValueException: An error occurred (InvalidParameterValueException) when calling the PublishLayerVersion operation: Error occurred while GetObject. S3 Error Code: PermanentRedirect. S3 Error Message: The bucket is in this region: us-east-1. Please use this region to retry the request S3 bucket name 是 global unique 但其實 bucket 位置是有 region 的... 目前還沒有看到什麼比較好的方式來發佈 lambda layer 到全部的 region.... replicate 所有的 zipfile 到所有的 region, 然後每個都有自己的 bucket name 似乎蠻蠢的?....