上一篇最後提到，建 Azure 資料庫的時候有一個叫「連線方式」的選項，我隨手選了一個，後來整台砍掉重建。今天就講這件事。

要在 Azure 上開一台託管的 MySQL，流程其實沒幾步：選規格、設帳號密碼、選版本。中間那個「連線方式」會問你要 Public access 還是 Private access，我選了 Public (選錯了QAQ)。

這個選項在問什麼

先用白話講。這個選項決定的是：你的資料庫要不要有一個「對外的門牌號碼」。

Public access 會給資料庫一個公開的網址和 IP，網際網路上任何人都連得到它。當然不是說誰都能登入，前面還有防火牆規則和帳號密碼擋著，但「這台機器在網路上找得到」這件事是成立的。

Private access 則相反。資料庫被放進你自己的虛擬網路裡，只有一個私有 IP，外面完全看不到它。想連它，你得先想辦法「進到那個網路裡面」。

「先進到那個網路裡面」這件事當時我沒放在心上，但後面就是因為這個原因才需要重建。

我為什麼選了 Public

老實說當下沒有想太多。我看到 Public access 的設定裡有防火牆規則，可以指定「只有這些 IP 連得進來」，就覺得夠了。而且它設定簡單，建完馬上就能從自己電腦連上去測試，Private access 那套 VNet、子網、DNS 聽起來麻煩得多。

現在回頭看，我犯的錯不是「選了 Public」，而是我根本不知道這個選項後面接的是什麼。我以為它只是「要不要開對外連線」，是一個之後隨時可以調整的開關。

那防火牆規則不夠嗎

這是我後來一直在想的問題。先講會發生什麼事：資料庫有了公開位址，全世界就掃得到它。網路上有大量自動化程式整天在找開著的資料庫連接埠，這不是針對你，是背景雜訊，任何暴露在公開網路上的服務都會遇到。

但防火牆規則確實擋得住。它在網路層就把不在清單裡的來源拒絕掉，對方連登入畫面都碰不到，更別說試密碼。所以 Public access 加上嚴格的防火牆規則，是可以用的，很多團隊就是這樣用。真正的差別不在「擋不擋得住」，在維持。

那份清單要設對，而且要一直維持正確。只要有人為了除錯臨時放寬、事後忘了收回，或是不小心勾了「允許所有 Azure 服務連入」，那個公開位址就真的公開了。而這種事不會有人通知你，你也不會收到告警。

Private access 的差別是：它不需要任何人記得維持什麼。 資料庫根本沒有公開位址，設定寫錯也不會突然暴露。

所以這兩個選項的差別，與其說是「安全 vs 不安全」，不如說是「靠紀律 vs 靠結構」。紀律會鬆，結構不會。

什麼時候發現不對的

是在準備架 VPN 的時候。VPN 要做的事，是把「雲端的網路」和「地端的網路」接起來。而我打算讓地端的備援資料庫透過這條線，連到雲端的資料庫做同步。

問題就在這裡：Public access 的資料庫，根本不在任何一個虛擬網路裡面。

它有一個公開的位址，誰都連得到，但它不屬於某個內部網路。而 VPN 送進來的流量，是進到那個虛擬網路裡面的。一台不在網路裡的機器，這條線送不到它。

要講精確一點：地端還是連得到那台資料庫，只是得走公開的網路，把公司的對外 IP 加進防火牆白名單就行，複製也跑得起來。

但那樣的話，這條 VPN 就白蓋了。我辛苦拉了一條私有的專線，結果資料庫的流量還是在公開網路上跑。

而且這件事還連帶暴露了另一個更前面的問題：網路的規劃要在建立資料庫之前就做完。

因為資料庫要放進哪一個網路、哪一個子網，是在建立那一刻決定的。而 VPN 閘道自己也需要一個子網，如果它們不在同一個網路裡，還得多做一層網路對接。這些安排必須在按下建立之前就想清楚，而我當時是先把資料庫建起來，才開始想網路怎麼接，順序反了。

為什麼不能改回來

發現之後我翻了一下文件，想找哪裡可以把它改成 Private access，結果沒有。

Azure 的託管 MySQL，連線方式只能在「建立那一刻」決定，建好之後永遠改不了。 不是藏在某個進階頁籤裡，也不是要停機才能改，是根本沒有這個選項。

想從 Public 換成 Private，唯一的辦法是：開一台新的、把資料搬過去、把舊的砍掉。所以那台測試環境的資料庫，就這樣整台重建了。

重建本身其實不太痛。在入口網站上點一點，虛擬網路和子網的網段先規劃好，整台重新開起來很快。

真正的代價不是那段時間，是這件事本來完全不需要發生。而且第二次之所以順利，正好是因為第一次踩過了：我已經知道要先把網段想清楚，再按下建立。

而且不只這一個

這件事之後，我回頭把建立畫面上的選項一個一個看過，想確認還有哪些是「一旦按下去就回不了頭」的。結果又找到兩個：

異地備份（Geo-redundant backup）：這個開關同樣是建立當下決定，之後永遠改不了。我們選擇不開，因為地端的備援本來就涵蓋了整區故障，功能重疊；而且它的作用是「多存一份備份到另一個區域」，不是「多一台可以接手的伺服器」，跟我們要的東西不一樣。

備份保留天數：這個之後改得了，但我特地把它列出來，是因為很多人會把它跟 binlog 保留搞混，包括當時的我。

兩者的目的完全不同。自動備份是給「時間點還原」用的，也就是資料誤刪、想回到某個時間點的時候用；binlog 保留是給「複製」用的，決定備援斷線之後，雲端願意把流水帳留多久等它回來拿。

帶得走的東西

如果只能記一件事，我會記這個：

在雲上建立任何資源之前，先花五分鐘查一下「這個畫面上有哪些選項是建完就改不了的」。

雲端服務給人的印象是「什麼都可以隨時調整」，大部分時候也確實如此，機器規格能升能降、儲存空間能加、參數能改。但總有幾個選項是刻在石頭上的，而它們通常不會特別標示出來。你只有在需要改的那一天，才會發現改不了。

這件事花不了多少時間。翻一下官方文件、搜尋 cannot be changed after creation，把那幾項列出來，建立前多想三分鐘。相較於整台重建，這筆投資划算得多。

至於該選哪一個，我現在的看法是：如果資料庫只給同一個雲裡的服務用，Private access 幾乎沒有理由不選。方便性的差距，遠小於「不用擔心哪天有人把白名單改壞」這件事。

我們的情況正是如此，只是我當時不知道自己在選什麼。

下一篇講另一個選擇題：地端和雲端之間要拉一條線，市面上有免費的方案，也有一個月一百多美金的方案。我們選了貴的那個。