一個AWS賬戶塞下所有東西？這才是安全隱患

很多團隊的第一反應是"先跑起來再說"，把生產環境、測試代碼、部署流水線全塞進同一個AWS賬戶。這在創業初期確實省事，但等系統穩定后，安全債就開始計息了。

一位工程師最近分享了他們的整改經歷：原本所有應用共享一個賬戶，現在要按AWS最佳實踐拆成多賬戶架構。核心挑戰不是"要不要拆"，而是怎么讓現有的持續交付流水線（CI/CD）跨賬戶工作。

為什么賬戶隔離是安全基線

AWS架構完善框架的安全支柱明確建議：用賬戶級別隔離不同環境（生產、開發、測試）和工作負載。這不是可選優化，而是SEC01-BP01這條基礎最佳實踐的核心要求。

賬戶隔離提供的是硬邊界——安全事件不會跨賬戶蔓延，計費可以精確拆分，權限管控也更清晰。原文提到的反模式正是很多團隊的現狀：把不同敏感等級的無關工作負載塞進同一個賬戶，"這正好就是我們的情況"。

整改方案分五步推進。前三個步驟相對直接，真正的技術難點在最后兩步：如何讓CodePipeline跨賬戶部署，以及如何設計網絡架構。

共享子網 vs 每個賬戶自建網絡

多賬戶架構有個常見誤區：讓每個應用賬戶都獨立搭建虛擬私有云（VPC）和子網。這會帶來運維噩夢——IP地址規劃沖突、路由表爆炸、安全組管理碎片化。

原文采用的方案是共享子網模型。從安全和運維雙重視角看，這有幾個明顯收益：網絡配置集中管控，減少重復建設；安全策略統一收口，避免各自為戰；運維復雜度顯著降低，工程師不用在十幾個賬戶之間切換排查。

具體實現上，需要讓原有的CI/CD組件具備跨賬戶操作能力。這涉及IAM角色信任鏈、制品（Artifact）跨賬戶傳遞、以及部署階段的權限委托——每一步都需要精細設計，否則流水線會在賬戶邊界處卡住。

CodePipeline的跨賬戶改造

改造前的流水線全在一個賬戶內運轉：代碼提交→構建→打包→部署，所有環節共享同一套憑證和權限。拆分到多賬戶后，這個閉環被打破了。

關鍵設計是讓生產賬戶"信任"工具賬戶的流水線。具體做法是：在生產賬戶中創建IAM角色，明確允許工具賬戶的CodePipeline服務代入（AssumeRole）。這樣流水線本身留在工具賬戶，但部署動作以生產賬戶的身份執行，實現權限最小化。

制品傳遞也需要重新設計。S3存儲桶不能簡單跨賬戶訪問，需要配置存儲桶策略，允許目標賬戶讀取。或者更干凈的做法：讓每個賬戶的流水線階段自己從授權來源拉取，避免長距離權限穿透。

原文展示的簡化架構圖里，最終形態清晰分離了三個層次：共享網絡基礎設施、集中式工具鏈（CodePipeline、ECR鏡像倉庫、S3制品桶）、以及按工作負載隔離的應用賬戶。每個應用賬戶只包含運行中的工作負載，不存放部署工具。

為什么這件事值得現在做

多賬戶架構的改造成本確實不低——網絡重構、流水線重寫、權限重新梳理。但原文的案例說明了一個判斷標準：當系統已經穩定運行，正是還安全債的窗口期。等業務再膨脹，耦合更深，遷移成本會指數級上升。

另一個啟示是"共享子網"這個設計選擇。很多團隊一想到隔離就走向極端，每個賬戶完全自治。但云架構的精髓在于找到控制與敏捷的平衡點：賬戶邊界提供安全隔離，共享基礎設施降低運維負擔，兩者并不矛盾。

對于正在AWS上構建系統的團隊，這個案例的價值在于展示了從"單賬戶湊合"到"多賬戶規范"的具體路徑。不是抽象的最佳實踐宣講，而是帶著真實約束的改造記錄——包括哪些步驟直截了當，哪些需要重點攻堅。

最后留個判斷：賬戶隔離正在從"大公司專屬"變成"基礎標配"。隨著合規要求收緊和供應鏈攻擊頻發，權限爆炸半徑的控制能力會成為技術選型的核心指標。能在架構早期就預留賬戶隔離擴展性的團隊，后期會少很多凌晨救火的事故。