上一篇把帳號放進 AWS Organizations，透過 OU 與政策建立管理邊界，不過有了 Organizations 之後，下一個問題通常不是「能不能集中管理」，而是「需要管理到什麼程度」。

以下用一個假設情境來推演：某家 SaaS 公司目前有六個 AWS 帳號：正式、測試、開發、共用工具，以及兩個企業客戶要求的專用帳號。

• 過去一年新增 4 個帳號，明年預計再增加 8～10 個。
• 雲端治理由 1 位資安工程師兼任。
• 企業客戶開始要求提供資訊安全管理與稽核證明。
• 公司希望在 3 個月內，把開帳號變成可以重複執行的流程。

目前每開一個帳號，工程師就照著文件手動設定 CloudTrail、AWS Config、IAM 角色與 SCP，問題不在於這些設定有多難，而是十幾個步驟只要漏掉一項，通常要等到稽核或事故發生時才會被發現。

三種做法，差別在誰維持一致性

第一種方案可以用 CloudFormation StackSets 或 Terraform，把原本的檢查清單寫成程式碼，這種做法並不會比較不專業，也留得下完整的版本與部署紀錄，差別在於當客戶詢問「所有正式帳號是否都符合這項規則」時，團隊要自行整理 Config、CloudTrail 與 IaC 執行結果。

Control Tower 則提供 Landing Zone、Controls 與集中檢視畫面，讓各帳號的治理狀態比較容易被追蹤，不過導入 Control Tower 不代表自動符合所有稽核要求；規則如何對應客戶需求、相關紀錄如何保存，仍然需要自行設計。

至於 Landing Zone Accelerator on AWS（LZA），它不是 Control Tower 的替代品，而是建立在其上的擴充層，可以進一步管理 Transit Gateway、Network Firewall 與更多安全服務。

以這個案例來說，目前沒有專責平台團隊，也沒有複雜的集中網路需求，因此我在規劃架構時會先淘汰 Control Tower + LZA，不是因為它做不到，而是它提供的能力超過目前需求，維護責任也超過現有人力。

真正改變答案的，不是「現在有六個帳號」。

帳號總數其實是雜訊，關鍵是每季仍會新增兩到三個，而且每一個都需要對外交代治理狀態。

在「1 位兼職治理人力、3 個月導入時程，以及客戶要求稽核證明」的限制下，若選擇 Control Tower，它能同時改善開帳號的一致性與治理狀態的集中檢視，同時接受客製彈性有限、既有帳號需要先整理，以及後續仍要處理設定偏移的責任。

Control Tower 怎麼讓新帳號套用相同設定？

Control Tower 提供的 Account Factory，可以把它理解成一套「建立 AWS 帳號的標準流程」。

管理者可以事先決定新帳號要放進哪個 OU、需要哪些基本設定，以及要套用哪些治理規則，之後建立帳號時，就不必再拿著檢查清單逐項操作，也能降低漏掉 CloudTrail、AWS Config 或必要 IAM 角色的機會。

如果公司已經有其他 AWS 帳號，也可以啟用自動納管功能，當帳號被移進指定的 OU 後，Control Tower 會替它套用該 OU 的基礎設定與治理規則。對這個案例來說，重點不是多了一種建立帳號的工具，而是讓新舊帳號都能遵循相同的管理方式。

過去常見的 Control Tower 架構會建立 Security OU，以及集中處理日誌與安全檢查的帳號，Landing Zone 4.0 之後，企業可以沿用既有的 OU 結構，不必為了導入 Control Tower 重新安排所有帳號，也降低了不少導入阻力。

Controls 該選哪一種？

Controls 不是開得越多越好。選擇前要先確認：這項規則是要擋下操作、找出違規，還是在部署前攔截。

三種類型不能互相替代。

Preventive 最直接，但政策寫得太緊可能阻擋正常部署，開發人員看到的通常只是一句 AccessDenied，也會增加後續除錯的時間。

Detective 只負責發現問題，不會自動修正，團隊仍然需要一套從告警、確認到處理的流程，否則它產出的只是一份越來越長的不合規清單。

Proactive 則只涵蓋透過 CloudFormation 建立，而且有對應檢查機制的資源類型，無法攔住所有從 Console 或 SDK 直接建立的設定。

因此，我會把不能違反的安全邊界交給 Preventive，需要持續盤點的設定交給 Detective；等團隊的 IaC 流程成熟後，再加入 Proactive，而不是一開始就把三種類型全部打開。

導入後仍有哪些責任？

Control Tower 本身沒有額外服務費，但它使用的 AWS Config、CloudTrail 與 S3 仍然會依用量計費，Detective Controls 越多、涵蓋的帳號與 Region 越廣、資源變更越頻繁，AWS Config 需要記錄與評估的內容也會跟著增加。

既有帳號納管前，也要確認原本的 CloudTrail、AWS Config 與 IAM 角色是否和 Control Tower 的設定衝突，這部分的盤點與調整工時，很容易在導入前被低估。

另外，由 Control Tower 建立或管理的資源如果被手動修改，就可能偏離原本的設定，Control Tower 將這種情況稱為 Drift，它不只是導入當下要處理的問題，後續也需要持續檢查與修復。

Landing Zone 4.0 雖然可以選擇是否啟用 Config、CloudTrail、IAM Identity Center 與 Backup 等整合，但這些功能並非完全獨立，例如停用 Config 會連帶影響用來找出不合規資源的 Detective Controls，因此不能只把它當成一個節省費用的開關。

最後，Control Tower 能處理的仍以既有功能與 Controls 為主，當企業需要更複雜的集中網路、安全服務或自訂流程時，還是要透過其他自動化工具或 LZA 擴充，維運複雜度也會再次提高。

這個案例選擇 Control Tower，不是因為六個帳號已經算多，而是因為帳號仍在持續增加、管理人力有限，而且每個帳號都需要對外交代治理狀態。

同樣是六個帳號，只要增長速度、人力或稽核要求不同，最後的選擇就可能完全不同——這是除了帳號數量以外，也確切需要納入考量的事情。

Control Tower 解決的是帳號層級的治理與權限邊界，但它不會直接決定某位開發人員實際能操作哪些資源，下一篇會回到 IAM 的權限判斷流程，看看為什麼政策裡明明寫了 Allow，操作時仍然可能收到 AccessDenied。

參考資料

• What Is AWS Control Tower?
• Landing Zone 4.0 Key Changes
• Move and Enroll Accounts with Auto-enrollment
• Control Behavior and Guidance
• Landing Zone Accelerator on AWS
• AWS Control Tower Pricing