本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
後續步驟
本指南說明不同案例的各種網路存取方法，並說明每個架構的優點和缺點。您應該了解為什麼選擇網路存取方法不應只是技術討論。商業和技術之間的一致性至關重要。下列後續步驟和建議可協助您透過評估目前功能、分析市場需求和實作控管控制，來評估和標準化網路架構策略。
評估目前的架構和功能
根據相關資料來源檢閱目前的網路架構，例如本指南中的自我評估架構、目前的法規要求，以及目前的市場狀態 （包括您的客戶和競爭分析）。例如，請考慮使用 AWS Well-Architected Framework
檢閱任何潛在的例外狀況、一次性和歷史產品決策。保持好奇、挑戰它們，並且不要自動假設其有效性。多年前的客戶要求可能不再有效。挑戰假設可創造簡化和降低架構複雜性的機會。
簡單來說，請記錄觀察結果，以便組織中的不同角色可以存取和了解這些觀察結果。擷取目前狀態與目標狀態不同的位置、目標狀態、影響，以及進行觀察的時間。記錄此資訊有助於您的組織根據新資料做出決策。
市場和客戶分析
收集市場趨勢的洞見。消費者目前偏好的 SaaS 產品存取方式是什麼？ 您仍在與客戶會面嗎？ 客戶群組或行為是否變更？ 您的高階主管是否將船舶轉向新市場、具有特定法規要求的地理位置或新客戶層？ 您的業務或營運模式是否有所變更？ 例如，您是否正在考慮將服務標示為白標籤？ 您的成長計畫是否包括與合作夥伴合作，以便在客戶與這些合作夥伴連線時，提供這些服務？
策略一致性
當您了解目前的功能、目前的架構、市場和客戶時，請呼叫策略一致性會議。使用相關的產品、業務和技術利益相關者，挑戰哪些要求仍然有效，以及哪些新要求需要考慮。透過捨棄不再需要的要求，尋找降低複雜性的機會。這不是委員會的設計；工程團隊需要準備並擁有實際的架構和實作詳細資訊。不過，此會議應釐清為什麼這是一組要求，可最大限度地為您的客戶和組織帶來好處。
標準化
為了吸引客戶，讓每個客戶自由選擇如何連接到您的服務可能會很有吸引力。畢竟，任何解決方案在技術上都可以運作，而且您可能也具備管理及操作所有解決方案的專業知識和資源。這可以在特定時間點上正常運作，但隨著您的業務擴展，很難管理。您的可觀測性堆疊需要支援來自多個解決方案的指標，而您的站點可靠性工程師也需要能夠了解這些指標。您需要每種連線方法up-to-date文件。您應用程式的主要變更需要針對您提供的每個存取方法進行評估。您需要為每個存取方法撰寫和維護自動化和基礎設施作為程式碼 (IaC)。未標準化服務存取的額外額外負荷，必須權衡您想要提供給客戶的彈性。
如果您需要北星來引導您的決策制定，我們建議標準化。標準化您的客戶如何與您提供的服務互動，通常是您可以採取的最有影響力行動，以改善整個組織的許多成功指標。標準化可讓產品團隊更輕鬆地了解服務的成本結構，並做出資料驅動型產品決策。在根據預先定義的標準開發、推出和操作的環境中，操作團隊可以更輕鬆地對問題進行故障診斷，並自動化部分故障診斷程序。它可協助您偵測惡意演員的異常、意外行為或動作。標準化也可減少技術負債。工程團隊需要較少的週期來測試和推展生產變更。它也可以加快您的上市速度、改善自助服務上線成功，並降低法規風險。
因此，我們建議您也檢閱目前可能已就緒的任何一次性項目。量化您用來支援現有客戶的操作週期數量。將您的結果與歷史資料進行比較，並評估您目前的方法是否在未來幾年內擴展。每當需要轉移標準時，請挑戰這些請求背後的需求。評估影響，並平衡立即利益與長期承諾。
如果自訂是不可避免的，但與您的標準衝突，請考慮共同的責任模型。在此模型中，您的產品在很大程度上會受到請求變更的保護，而自訂會在最少的專用環境中進行。如需範例，請參閱 與傳輸 VPC 架構連線一節。
控管
為了符合法規要求和您自己的內部標準，控管至關重要。透過適當的控管，您可以控制強制執行標準的位置和方式。您也可以建立 來控制 ，以偵測與標準的差異，並通知資源擁有者必要的修正動作。AWS Organizations、AWS CloudTrail、 AWS Config和 AWS Control Tower是其中一些 AWS 服務 可協助您管理和控管 中工作負載 AWS 雲端。
重複
使用您最初工作的學習，設定輕量且可重複的程序，以在未來保持一致。定義您需要輸入的角色、頻率、資料需要的準確度、資料如何共用，以及誰將對其採取行動。
