前面幾篇講的都是選型。今天講一個我以為根本不用選的東西：資源要建在哪一區。

我原本的規劃很單純：現有的 Kubernetes 叢集在馬來西亞，那新的資料庫就建在馬來西亞，同一區、延遲最低、不用多想。結果一台都建不起來。

建不起來

送出建立之後，跳出來的錯誤是 InternalServerError。這個錯誤最麻煩的地方是它什麼都沒說。它不是「你的名稱重複了」、不是「配額不足」、也不是「這個參數不合法」，就只是「伺服器內部錯誤」。你完全不知道是自己哪裡填錯，還是它自己壞掉了。

正常的下一步應該是開個支援案問微軟。但我們的訂用帳戶是基本方案，不含技術支援，想問也沒得問。

所以我只能上網查，然後發現有其他人在同一個區域遇到一模一樣的狀況，錯誤訊息也一樣。

這沒有解決問題，但至少可以確定不是我填錯了什麼，而是這一區本身佈建不出來。於是換一區。

第二站：新加坡

確認馬來西亞行不通之後，我往鄰近的區域找，選了新加坡。這一站的問題不是建不起來，是配額不夠。

雲端的每個區域對每種機器都有配額上限，超過就得申請提高。這通常是個例行手續，填個表、講一下用途，過幾天就批了。我們的申請被拒絕了。

而且回覆不是「這次不行、之後再說」，是未來半年都沒有辦法提高。那一區的資源就是這麼緊，新加坡這條路就這樣封死了。

第三站：日本

被拒絕之後，我開始往更遠一點的地方找。日本是下一個看起來合理的選項：離台灣不遠、是 Azure 的主要區域之一、服務齊全。

試著申請配額，這次馬上就過了。需要的機器規格、要開的資源數量，送出去沒多久就批下來，沒有排隊、沒有審核。

延遲的部分我沒有實際量過。當時的想法很單純：東京離台灣比新加坡近，延遲應該不會更差。這是一個從地圖上看出來的判斷，不是從監控看出來的。後來實際跑起來也沒有人反應變慢，所以我就沒有再回頭驗證。

寫這篇的時候翻自己的文件，看到當初記的是「對台灣延遲與新加坡相當」，語氣像是查證過的結論。其實那只是我的推測，被我寫成了事實。

換到日本還有一個附帶的好處：這一站是全新建置，所以我把整組東西（Kubernetes、資料庫、VPN 閘道、儲存體）全部放進同一個虛擬網路的不同子網。測試環境當初沒辦法這樣做，為什麼不行、差在哪裡，留到 Day 11 專門講。

同一個網路的好處，後面幾篇會一直遇到：不用做網路對接、DNS 解析自動涵蓋、少掉一整套設定和一整類故障。

帶得走的東西

我原本以為「選哪一區」是一個規格問題：查一下延遲、看一下價格，選一個就好。

實際上它更像一個供應問題。雲端服務商在不同區域提供的服務不一樣，同一個服務在不同區域的成熟度也不一樣，而這些差異通常不會寫在你會看到的地方。價目表上有這個服務，不代表你要的那一區真的建得出來。

所以現在如果要在一個沒用過的區域開東西，我會先做兩件事：用最小的規格把每一種資源各建一台試試看，以及先確認配額夠不夠、不夠的話申請得下來嗎。

這兩件事花不到半小時，但它們能幫你省掉「規劃做到一半才發現地基不存在」的折騰。而配額那項特別值得先問，因為它不是技術問題，是你有沒有資格用的問題，而那個答案不會寫在任何文件上。

還有一件事我後來才體會到：沒有付費支援的時候，你的除錯管道只剩下搜尋引擎。

這是一個要納入規劃的事實，不是抱怨。遇到那種什麼都沒說的錯誤訊息時，大公司可以開支援案，我們只能查別人有沒有踩過。查得到就算幸運，查不到就只能換條路走。

而且還有一個附帶的好處：被迫換區域，反而讓我們有機會從零重建。 這件事當下很煩，事後看是撿到的，至於撿到了什麼，Day 11 再算這筆帳。

到這裡決策篇就結束了，接下來要開始動手。明天先講雲端和地端之間那條線怎麼接起來，這部分我會拆成上下兩篇，因為兩端要做的事完全不同。