Azure 新創公司適用的平台基礎

本文以創業視角，快速介紹五大基礎平台支柱：運算、網路、儲存、容器與資料。每個柱子都會有一份簡短的決策表，將你的狀況對應到預設服務，並附上何時在新創規模擴大時重新檢視該選擇的說明。

在本文中，你將學習如何

為您的階段選擇合適的 Azure 運算、網路和儲存基本元件。
判斷 Azure Kubernetes Service 是否是適合你現階段的容器平台；如果不是，應改用什麼替代方案。
選擇第一個涵蓋關聯型、文件型、向量型和分析工作負載的資料平台。
套用一套精簡的預設設定，兼顧成本、可靠性與安全性，並在規模擴大時依然適用。
要認清那些告訴你預設選項已經不再有用的訊號。

Prerequisites

有效的 Azure 訂用帳戶。
Azure CLI 已安裝並登入。要登入，請執行 az login。
擁有者或貢獻者至少可存取至少一個資源群組。
熟悉 Azure 入口網站的登陸頁面會有幫助，但不是必須的。
對 Azure 基礎（區域、訂閱和資源群組）有基本的熟悉。

為什麼這對新創公司很重要

對處於早期階段的新創公司來說，選錯基礎架構的代價不在於帳單。這是你在建立基礎之後，遷移錯誤服務時損失的一週。本文提出的五大支柱，是那些一旦預設選錯，影響往往會層層擴大的面向：錯誤的運算平台會左右你的部署流程；錯誤的資料庫會限制你的資料模型；錯誤的網路拓撲會讓你無法拿下第一個企業客戶。你不需要平台團隊、網站可靠性工程師或財務營運專家來做出明智的選擇。你需要一個足夠好、可以據此發布的預設值，並且有一個明確的訊號，告訴你何時該重新檢視它。如果你的新創公司加入了 Microsoft for Startups 計畫，這些相同的預設值可讓你的點數用得更久，並讓你日後仍符合取得進階權益的資格。

計算：你的程式碼運行位置

Azure 有十多種運算服務。好消息是：對大多數早期階段的工作負載而言，其中三個就能滿足你的需求。

您的情況	預設 Azure 服務	原因為何	重溫時機
網頁應用程式或 HTTP API、一兩個服務，適合使用受管理的執行環境	Azure App 服務（Linux）	不需要容器建造。內建 TLS、自訂網域、部署位置和自動調整規模。免費和基礎層級的價格夠低，足以用來執行預備環境，不過部署插槽和自動調整規模功能需要 Standard 層級以上。	你想經營超過幾項服務，需要按服務規模計算，或需要側車。
事件驅動函式、排程作業或 Webhook 處理常式	Azure Functions（消費方案）	依執行次數付費。歸零。綁定移除大部分用於佇列、blob 和 HTTP 觸發器的黏合程式碼。	冷啟動會拉高使用者可感知的延遲，或者使您超出取用方案的限制。
容器化微服務，你需要一個有主見的執行環境，卻不需要管理 Kubernetes	Azure 容器應用程式	它是建立在 Kubernetes 上，並採用基於 KEDA 的自動擴展，但你不會管理叢集。 DAPR 作為可選的整合功能提供。包含縮減為零、修訂版本和 HTTPS Ingress。	你需要叢集層級的控制、自訂排程器，或是進階的網路。
長時間執行的批次作業、GPU 訓練，或現有虛擬機工作負載的原樣移轉	Azure 虛擬機器	完整的作業系統控制權。需要水平縮放時，使用虛擬機縮放集。	修補與映像管理的營運開銷開始拖慢出貨速度。
你確定自己需要 Kubernetes（在作此判斷前，請先參閱第 4 節）	Azure Kubernetes Service	受管理的控制平面。適合已有 Kubernetes 經驗或特定平台需求的團隊。	請參閱容器部分了解AKS的決策標準。

Tip

第一個面向使用者的網頁應用可以從 App Service 開始，所有事件驅動的則用 Azure Functions。如果你保持應用程式無狀態，並且寫設定到環境變數，之後可以轉到 Azure 容器應用程式或 Azure Kubernetes Service，而不改動應用程式代碼。

在容器應用程式與應用服務之間做選擇

Container Apps 與 App Service 彼此有所重疊。說句公道話，關鍵的判斷標準是：如果你的應用程式已經以容器映像檔形式執行，而且你希望能以服務為單位進行擴縮（例如 Web 層與 Worker 可設定不同的副本數），那麼 Container Apps 會勝出。如果你的應用程式是單一的網頁程序，且不想維護 Dockerfile，App Service 會勝出。

注意事項

當您有明確需求且簡單選項無法滿足時，可以考慮使用 Azure Kubernetes Service。雖然它提供強大的彈性與控制，但同時也引入了額外的操作考量（如升級、節點池大小、入口配置及憑證管理）。如果太早採用，團隊往往花更多時間在平台管理上，而非開發產品功能。

網路：第一天該設定什麼

大多數早期的 Azure 工作負載在第一天就不需要虛擬網路。 App Service、Functions、Container Apps，以及大多數受控資料庫都會提供受 TLS 保護的公用端點；只要正確設定驗證機制，這些端點就可以安全地對外公開。在還沒有理由之前就增加網路複雜度，是 Azure 上最常見的過早優化方式。

您的情況	預設方法	原因為何	重溫時機
全新應用程式、公開網路流量，還沒有合規要求	使用公開端點搭配 TLS。沒有虛擬網路。	最低的營運開銷。 App Service、容器應用程式和管理式資料庫會幫你處理 TLS。使用Microsoft Entra ID進行認證。	你的第一個企業客戶要求私人連線。
你需要在應用程式和受管理資料庫之間建立私人連線	計算端的虛擬網路整合，資料庫端的私有端點	流量仍停留在 Microsoft 的骨幹網路上。資料庫不會公開曝光。同樣的託管服務，應用程式沒有變動。	如果你處理受保護的資料，從第一天就要開始；否則，就等到稽核或客戶提出要求時。
你需要一個公開入口點，連接多個後端，提供路由、TLS 終止，以及網頁應用程式防火牆	Azure Front Door（全球）或Azure 應用程式閘道（區域）	Front Door 新增了全球內容傳遞網路與邊緣快取功能。應用閘道是區域性、虛擬網路原生選項。	你的需求已超出 App Service 內建的 TLS 和路由功能。
你需要外撥靜態 IP 位址（例如支付處理商的允許清單）	連接到你的虛擬網路的 NAT 閘道器	可預測的外撥IP。許多第三方 API 都要求。	供應商要求這麼做。不要憑猜測加入它。
多區域或多帳號拓撲	虛擬網路對等互連或 Azure Virtual WAN	真正的網路架構從這裡開始。不適用於大多數處於探索階段的團隊。	多區域是真正的要求，而非理想。

Important

先強化 Microsoft Entra ID 和您的訂用帳戶角色指派的安全性，再考慮網路隔離。大多數小型公司的 Azure 安全事件來自於過度授權的身份，而非網路暴露。工程存取時請使用 Microsoft Entra ID 群組，且不要在訂閱範圍內直接給予擁有者。

儲存：blobs、檔案與磁碟

Azure 儲存體是一種單一資源類型（儲存帳號），它會提供四種資料服務：blobs、檔案、佇列和表格。在應用程式儲存決策上，你幾乎總是在 blob（物件儲存）、檔案（受管理檔案共享）和受管理磁碟（連接虛擬機器的區塊儲存）之間做選擇。

您正在儲存的內容	預設 Azure 服務	原因為何	重溫時機
使用者上傳的檔案、產生的報告、日誌、模型工件、備份	Azure Blob 儲存體（熱門等級）	物件儲存。價格實惠、耐用，可擴充至 PB 級。對於不常存取的資料，之後再使用 Cool 或 Archive 層級。	你需要 POSIX 檔案語意，或是從多台機器隨機讀寫單一檔案。
由多個虛擬機或容器掛載的共享檔案系統	Azure 檔案儲存體（標準）或 Azure NetApp Files（高吞吐量）	伺服器訊息區塊（SMB）或網路檔案系統（NFS）共用磁碟區。避免用這些工具來做符合 blob 模型的內容。	你開始把檔案分享當作佇列或資料庫使用。往右邊的原始體移動。
虛擬機器的磁碟	高階 SSD v2 受控磁碟	效能可調，應用磁碟具備良好的價格效能比。 Premium SSD v2 不能用作作業系統磁碟;搭配高級 SSD（v1）或標準 SSD 來搭配作業系統使用。標準 SSD 適合低吞吐量工作負載。	你需要跨虛擬機共享區塊儲存（使用 Azure 彈性 SAN 或 Azure NetApp Files）。
靜態網站資產（單頁應用程式套件、行銷網站、文件）	Azure 儲存體靜態網站主機 + Azure Front Door	Static Web Apps 是現代預設：內建自訂網域、免費管理的 TLS、全域發行版、GitHub Actions CI/CD，以及內建認證功能。 Storage 靜態網站 + Front Door 對於成本極低的部署架構仍然適用，但不原生支援自訂標頭或驗證。	你新增伺服器端渲染頁面。轉用 App Service 或容器應用程式。

Note

儲存體帳戶在每個訂用帳戶的每個區域皆有 250 個的軟性上限（提出申請後可提高至 500 個）。這對早期隊伍來說已經足夠了。必須避免的錯誤是每個微服務都建立一個儲存帳號;而是依環境（生產、預備、開發）及存取模式（熱、冷、歸檔）分組。

關於備份的說明

Azure 備份以及儲存帳號冗餘選項（本地冗餘儲存、區域冗餘儲存、地理冗餘儲存）可依帳號和磁碟調整。本地冗餘儲存（LRS）適合開發和暫定。使用區域冗餘儲存（ZRS）來存放生產資料。地理冗餘儲存會增加成本，且無法取代應用層級的災難復原。

容器與 Azure Kubernetes Service

Azure 有三種方式可以喺生產環境中運行容器：Azure 容器應用程式、Azure 容器執行個體同 Azure Kubernetes Service。它們對應不同的團隊規模和營運需求。

您的情況	預設 Azure 服務	原因為何	當開始疼痛時
你有容器映像檔，並且想要具備 HTTPS 輸入、自動縮減至零和修訂版本功能的託管執行階段	Azure 容器應用程式	Kubernetes 上的無伺服器平台，具備 KEDA 自動擴展功能，但你看不到或管理叢集。只為實際執行的部分付費很適合，直到你遇到叢集層級的需求。 Dapr 可作為可選擇啟用的整合功能提供。	你需要自訂排程器、進階網路（多張網路介面卡、自訂容器網路介面插件），或是特定的 Kubernetes 營運商。
你想將單一容器作為一次性作業或短期批次作業來執行	Azure 容器實例	從映像到執行容器的最快路徑。沒有管弦樂。按每秒運行時間計費。	你需要任何類似服務網格或自動擴展的裝置，超越單一容器。
你已經在別處運行 Kubernetes，或者你的應用程式架構確實需要它	Azure Kubernetes Service	受管理的控制平面。帶上自己的節點池、網路插件、入口控制器和可觀察堆疊。	第一天。規劃持續升級（每 4 個月釋出一次小版本）、節點池調優及憑證管理。
你不確定是否需要 Kubernetes	目前的容器應用程式	如果需要，之後可以在 Azure Kubernetes Service 上重建。舉起一個無狀態容器化的應用程式需要幾天的工作，而不是幾週。	你有一個具體的需求（營運商生態系統、叢集層級政策）可以說出來。「未來防護」並非具體需求。

何時晉升至AKS

當至少有兩個為真時，請移至 Azure Kubernetes Service (AKS)：

你經營超過十項服務，這些服務有共同的生命週期和網路需求。
你需要自訂控制器、側車或自訂資源定義（CRD），這些容器應用程式不會公開。
你需要深度的虛擬網路整合，並嚴格執行政策。
你是在標準化一個基於 Kubernetes 的開放原始碼生態系統（Argo、Istio、KEDA 等）。

若採用 AKS，請遵循 AKS 基準架構。 Microsoft Azure Well-Architected Framework 與 AKS Baseline 參考一起涵蓋了你想要的安全性、擴展性與升級預設值。

適用於小型團隊的 AKS 預設值

Setting	預設值	原因為何
節點大小	Standard_D4s_v5 系統集區，Standard_D8s_v5 使用者集區	適用於一般工作負載的可預測價格效能比
叢集自動調節器	已啟用	避免為閒置節點付費
工作負載身分識別	已啟用	取代 pod 身份，並整合 Microsoft Entra ID
Azure 原則附加元件	已啟用	免費護欄（無特權容器，必須標籤）
容器深入解析	已啟用	Azure 監視器中的一級計量和記錄
私人集群	開始製作	控制平面僅能從 VNet 存取

Azure Container Registry

無論你選擇哪個運算平台，都要將影像儲存在Azure Container Registry。基礎層級對早期隊伍來說已經足夠了。如果你想要硬隔離，可以為每個環境（生產環境、暫存）使用獨立的登錄檔;想要簡單的話，則使用單一登錄檔，搭配獨立的儲存庫和基於角色的存取控制。

資料平台：關聯型、文件型、向量型、分析型

資料平台的決策是最有可能成為永久性的。你在第一個月出貨的架構，將影響接下來兩年的每個功能。選擇一個足夠靈活、能隨著產品成長的預設方案，並抗拒預先選擇尚未開發的功能專用資料庫的誘惑。

你的工作量	預設 Azure 服務	原因為何	重溫時機
具有已知關聯結構的交易應用資料（使用者、訂單、內容）	適用於 PostgreSQL 的 Azure 資料庫（彈性伺服器）	成熟、廣泛理解且強的延伸生態系統（包括用於嵌入的 pgvector）。 Burstable 層級對開發和分期來說夠便宜。	多區域寫入或超大規模讀取模式。可以考慮 Azure Cosmos DB for PostgreSQL。
結構彈性的操作資料、全球分布、可預測的個位數毫秒讀取	Azure Cosmos DB （NoSQL API）	預設為多區域。無伺服器方案價格夠低，適合作為入門起步方案。分區設計很重要;出貨前請先閱讀分割鍵的指引。	你是在強制透過應用程式層進行關聯連接。 PostgreSQL 大概是正確的答案。
跨結構化與非結構化內容搜尋，包括檢索增強生成	Azure AI 搜尋服務	混合關鍵字與向量搜尋。可整合 Azure OpenAI 服務及 Cosmos DB。提供免費方案可供原型開發。	你必須超過每個階級指數的限制（標準1是常見的升級點數）。
用於檢索增強生成功能的向量嵌入	開始使用 PostgreSQL 中的 pgvector 或 Azure AI 搜尋服務	避免在檢索功能的第一版中使用獨立的向量資料庫。你會從實際使用中學到真正需要的（篩選、混合搜尋、擴展）。	你已經描述了讀取模式，這些限制條件值得使用專門引擎。
分析、報告，以及對生產資料的臨時查詢	適用於 PostgreSQL 的 Azure 資料庫讀取複本（瀏覽），Microsoft Fabric（展開與擷取）	對大多數探索階段的分析需求而言，讀取複本就已足夠了。當你不再使用時，Microsoft Fabric 就是現代的分析平台。	你的讀取複本跟不上進度，或是業務利害關係人需要一個自助式的分析介面。
資料庫前的快取層	Azure Cache for Redis（基本版）	標準快取原語後續再加也很便宜；不要基於臆測先加上去。	你會看到一種明顯的熱讀取模式，正在使資料庫達到飽和。加之前先量好。

Important

選擇一個預設資料庫，盡可能長時間使用。一支只有十五位工程師、卻要營運 PostgreSQL、Cosmos DB、Redis、AI 搜尋、佇列和圖形資料庫的團隊，等於是不小心讓自己背上了相當於一個平台團隊的工作量。

Azure OpenAI 服務的定位

Azure OpenAI 服務並非一個數據平台，但它共享相同的決策節奏。大多數新創公司開發生成式 AI 功能，起始會先在單一區域部署一個模型（近期的聊天完成模型），再加上 AI 搜尋或 pgvector 進行檢索。你不需要專門的微調管線、模型閘道或多次部署，除非使用情況需要你加入它們。

本文涵蓋的內容（以及不涵蓋的內容）

主題	本文內容	何時加入
身份與存取管理超越基礎	No	Microsoft Entra ID 設定：第 1 天資訊安全審查時的條件式存取與特權身分管理
基礎設施即程式碼（Bicep，Terraform）	No	當手動傳送門變更開始在不同環境間漂移時，通常是在你新增預備環境時。
持續整合與持續部署管線	No	第一天。 GitHub Actions 或 Azure DevOps Pipelines 都沒問題。
可觀察性（日誌、度量、痕跡）	No	從第一天起就有應用洞察。當你有警報疲勞時，使用 Azure 監視器工作簿。
成本管理	No	第一天就設定訂閱等級的預算。從一開始就為資源加上環境和擁有者標籤。
合規（SOC 2、ISO 27001、HIPAA）	No	當顧客提出要求時。適用於雲端的 Microsoft Defender 有一個合規儀表板，將控制項對應到 Azure 資源。
災難復原與多區域	No	當一小時的停機成本超過第二區域的工程成本時，

當平台的預設不再足夠時

這些成長訊號告訴你，某個特定的違約需要更有意識地被取代：

你已經在 App Service 或 Container Apps 上部署了五個以上不同的服務，而每項服務的規模正成為每日關注的議題。可以參考 Azure Kubernetes Service。
您的每月 Azure 帳單連續兩個月成長速度超過每月營收。是時候進行成本管理檢視及預留實例或儲蓄計畫分析。
您的虛擬網路現在跨越多個訂閱或區域。請參閱 Azure Virtual WAN 和中樞輪輻拓撲。
單一 PostgreSQL 實例無法將工作集存入記憶體，讀取副本也無法彌補空缺。可考慮使用 Cosmos DB for PostgreSQL 或分區式架構。
對生產資料庫的分析查詢明顯影響了應用程式延遲。將分析工作移至 Microsoft Fabric。
你在同一個存取模式下，每個環境都運行超過兩個儲存帳號。整合。
你新增了一個有付費客戶的第三國。是時候評估第二區域、地理冗餘儲存，以及前門路由策略了。