合規別先封路：Sevdesk 的平台治理實戰
這場分享談的不是再造一套「完美平台」，而是怎麼讓雲端合規真的推得動。Sevdesk 平台團隊以 AWS 多帳號架構隔離環境、權限與成本，再用 AWS Config 等原生服務檢查資源狀態，透過事件驅動方式把違規資訊送進 Slack。重點是先做 minimum viable governance：讓開發者快速知道哪裡不合規、為什麼要改，而不是一開始就阻擋部署。
現實應用
這套做法適合正在從單一 AWS 帳號擴張、開始面對成本歸屬、安全稽核或多團隊協作的 SaaS 公司。Sevdesk 約有 80 至 90 位工程師、15 個團隊，已經大到不能再靠口頭約定，卻又沒有餘裕維護大量自建工具。Platform、Security、FinOps 團隊都用得上，尤其適合內部平台評價已經不太好、不想再用強制政策激怒產品團隊的組織。
期望評估
低標期望方面，我認為至少能取得一致的資源標籤、較清楚的成本責任，以及集中可見的違規清單。即使暫時不自動修復，只要通知能附上資源、負責團隊與處理方法，就能少掉不少來回追問。
高標期望方面，我猜它最後可以演進成依風險分級的治理：Sandbox 保留實驗彈性，Production 才逐步加入強制控制；平台團隊則利用違規數據找出共同痛點，把重複問題做成自助式模組。不過這仍取決於規則品質與團隊互信，工具本身救不了失真的流程。
商業策略分析
最直接受影響的是維護 Keycloak、Longhorn、Harbor 等自管元件的平台人員，以及必須調整 CI/CD、帳號切換和映像推送流程的產品工程師。Sevdesk 改採 IAM Identity Center、EBS、ECR、Inspector、Security Hub、AWS Config 與 GuardDuty，降低補丁與整合負擔，但也增加對 AWS 的依賴。
我認為值得跟進的不是照抄服務清單，而是「先回饋、再執法」的導入順序。商業上，這能減少平台維運成本與合規摩擦，也避免產品交付速度被一次性大改拖垮；代價則是 vendor lock-in，以及開發者仍得補齊雲端操作能力。
實作細節
案例先以 AWS Organizations 多帳號架構 分隔團隊、環境與敏感資料，再啟用 Security Hub、AWS Config、GuardDuty 等集中檢查。AWS Config 的狀態事件可交給 Amazon EventBridge，再串接 Slack 回報違規。已知問題是遷移會迫使團隊修改 pipeline，而過長、過時的 Confluence 文件也無法防止標籤拼錯；通知內容與修正路徑因此比文件篇幅更重要。