AWS企業帳號購買 AWS Organizations 組織下子帳號無法建立資源？SCP 服務控制策略排查

先判斷：到底是 IAM 不夠，還是 SCP 擋住了

在 AWS Organizations 裡，子帳號突然無法建立資源，很多人第一反應是去查 IAM 權限，結果查了半天還是找不到問題。這種情況很常見，因為真正把請求攔下來的，往往不是帳號裡的使用者權限，而是上層掛著的 SCP 服務控制策略。

SCP 的作用不是直接給權限，而是設定邊界。簡單說，IAM 決定你「能做什麼」，SCP 決定你「最多能做到哪裡」。只要 SCP 明確拒絕，或是沒有把某項服務放進可用範圍，子帳號就算 IAM 寫得再完整，最後還是會失敗。

所以排查這類問題，第一步不是急著改 IAM，而是先確認請求被誰擋下。若錯誤訊息出現 AccessDenied、explicit deny、not authorized to perform，而且同一個 IAM 身分在其他沒有套用相同 SCP 的帳號能正常使用，基本上就可以把懷疑方向放到 SCP。

SCP 為什麼會讓子帳號「看起來有權限，實際上不能用」

很多人會誤解 SCP，以為它和 IAM policy 是同一類東西。其實不是。IAM policy 是授權文件，SCP 是組織層級的保護框架。前者是加法，後者是上限。最後能不能做某件事，要同時看兩邊，而且是以更嚴格的一方為準。

這代表一件事：只要 SCP 擋住，IAM 再寬也沒有用。例如你在 IAM 裡給了 ec2:RunInstances、iam:PassRole、ec2:CreateTags，但 SCP 只允許少數幾個服務，或者對某些區域、某些條件做了限制，那麼建立 EC2、建立 S3 Bucket、開 RDS、甚至建立 IAM 角色，都可能失敗。

另一個容易忽略的點是，SCP 不是只看單一帳號。它會沿著 Organizations 的層級一路繼承下來：根組織、OU、帳號本身，只要任一層有策略限制，最後都會反映到子帳號的有效權限上。也因此，很多人明明在帳號裡沒看到任何問題，卻還是一直報錯。

排查順序：從上層往下看，不要從帳號裡亂猜

第一步：確認資源建立失敗的動作是什麼

先把問題說清楚，不要只看一句「不能建立資源」。是建立 EC2、RDS、S3、EKS，還是註冊 Route 53、建立 KMS key、發佈 Lambda？不同動作對應不同 API，SCP 的限制方式也不一樣。只有先知道失敗的是哪個 API，後面才有辦法對照策略內容。

例如建立一台 EC2，不只是 ec2:RunInstances。如果你同時掛了 IAM role、需要建立網卡、標籤、使用 EBS，過程中可能還會碰到 iam:PassRole、ec2:CreateNetworkInterface、ec2:CreateTags、kms:Decrypt 等權限。SCP 只要卡住其中一環，整個流程就會失敗。

第二步：看組織、OU、帳號上掛了哪些 SCP

AWS企業帳號購買 排查時要依層級往上看，先看帳號本身，再看它所屬的 OU，最後看根組織。很多團隊會把限制策略掛在 OU 上，帳號移進去之後才開始出問題；也有團隊把策略掛在根組織上，結果所有新帳號都被套上相同限制。

如果你只在子帳號裡看 IAM，當然看不到問題。SCP 不在帳號的 IAM 清單裡，它在 Organizations 的控制範圍內。這也是為什麼組織管理員通常要先建立清楚的 OU 分層，把生產、測試、沙箱、共享服務分開，不然一張策略誤套，影響面會非常大。

第三步：檢查是否存在明確拒絕

SCP 裡最有殺傷力的是 Deny。只要命中明確拒絕，請求就會失敗，而且通常很難靠 IAM 補救。常見寫法包括：

• 拒絕所有非特定區域的操作
• 拒絕建立未加標籤的資源
• 拒絕使用某些高風險服務
• 拒絕刪除 CloudTrail、Config、GuardDuty 這類治理服務

這些設計本身沒有問題，反而是好做法，但問題出在條件寫得太寬、例外沒寫全，或新服務上線時沒有同步更新白名單。結果就是，原本只想限制少數行為，最後卻連正常建立資源都一起擋掉。

最常見的幾種錯誤場景

場景一：以為 IAM 已經給足權限

這是最典型的誤判。很多工程師看到 IAM policy 裡有 AdministratorAccess，就理所當然覺得帳號一定可以做事。可是在 Organizations 架構下，SCP 可以把這個管理員權限整個壓住。結果就是帳號內看起來像超級管理員，實際上卻被上層政策限制得很死。

如果是這種情況，重點不是再加 IAM，而是回去看 SCP 是否有把對應服務放行。尤其是新開帳號、從測試 OU 移到生產 OU、或是剛套入安全基線的時候，最容易發生這種落差。

場景二：只允許少數服務，沒把依賴服務算進去

有些團隊為了控管風險，會在 SCP 裡只放行幾個核心服務，例如 S3、EC2、CloudWatch。看起來很安全，但實際操作時，很多 AWS 服務都會互相依賴。你以為只是開一台機器，背後其實還需要 IAM、EC2、EBS、KMS、STS、SSM 或其他服務的支援。

如果 SCP 只允許主服務，卻把依賴服務擋掉，表面上看起來像主服務不能建立，實際上是某個隱藏步驟卡住了。這種問題最麻煩，因為錯誤訊息不一定直接指出真正被拒絕的服務。

AWS企業帳號購買 場景三：限制區域，卻忘了控制台或自動化流程的預設區域

不少組織會用 SCP 限制只能在特定區域建資源，避免雲資源分散失控。這很合理，但如果開發團隊的控制台預設區域不是允許的區域，或 CI/CD pipeline 還在送到舊區域，請求就會被拒絕。

這類問題在新專案、複製環境、或跨區部署時特別常見。開發者以為是服務壞了，實際上只是被 SCP 的區域條件擋下來。遇到這種狀況，除了修策略，也要一起檢查工具鏈的預設設定，否則改完還會再發生。

場景四：資源建立時需要標籤，但請求沒帶上

很多組織會要求建立資源時必須帶上成本中心、專案名稱、環境等標籤。這通常會透過 SCP 或搭配 IAM 進行管控。如果建立流程沒有正確傳入標籤，請求可能在 ec2:RunInstances、s3:CreateBucket 或其他建立動作時直接失敗。

這種狀況常見於手動在控制台建立資源時，因為使用者忘了填標籤；也常見於 Terraform、CloudFormation、CDK 等自動化工具，因為模板沒把標籤參數設好。不是雲服務不能用，而是你沒有滿足組織要求的條件。

實際排查時可以怎麼做

先從報錯訊息反推服務與動作

把錯誤訊息完整看一遍，重點是動作名稱與拒絕原因。若訊息裡直接出現 explicit deny in a service control policy，幾乎就能確定是 SCP。若沒有寫得那麼明白，就去看是在哪個 API 失敗，再回到 Organizations 檢查相關策略。

如果是透過控制台操作，很多錯誤會被包裝得比較模糊。這時可以改用 CloudTrail 或服務端事件記錄，找出真正被拒絕的 API。先定位行為，再定位策略，效率會高很多。

再確認帳號所屬的 OU 與繼承策略

同一個帳號如果被移到不同 OU，結果可能完全不同。排查時一定要確認該帳號目前的實際位置，而不是憑印象猜。很多事故都是因為帳號調整組織架構後，原本在測試 OU 的寬鬆規則沒了，卻沒有人注意到。

如果團隊有多層 OU，還要看上層是否已經套用通用限制。不要只看最底層帳號，因為最終生效的是整條鏈的交集。某一層多一條 Deny，就足以讓整個流程失敗。

最後再檢查策略寫法是否過度限制

常見問題包括把服務名稱寫錯、條件欄位用錯、區域列表漏掉、例外帳號沒排除，或是把允許清單寫得太窄。特別是當你用白名單思路寫 SCP 時，只要忘了補一個必要服務，某些工作負載就會全部卡住。

如果你不確定是哪一條規則造成影響，最實際的方法是先在隔離環境複製同樣的 SCP，逐條比對。不要在正式環境裡靠猜修改，因為 SCP 一改錯，可能不是單一團隊受影響，而是整個 OU 內的帳號都無法正常操作。

修正原則：不是一味放開，而是把邊界畫準

遇到 SCP 擋住資源建立時，不建議直接刪掉整張策略，也不建議乾脆放寬到幾乎沒有控制。正確做法是先確認業務需要，再調整最小必要放行範圍。SCP 的價值就在於把風險留在組織層先攔住，因此修正時應該追求精準，而不是粗暴。

AWS企業帳號購買 如果是正式環境，建議把策略拆成幾層：一層管基礎治理，一層管區域，一層管高風險服務，一層管標籤與命名規範。這樣一來，當某個動作失敗時，比較容易知道是哪一層在作怪，也比較方便做例外處理。

對於需要持續擴充的團隊，最好建立一套變更流程：新服務上線前先檢查 SCP 白名單，新 OU 建立前先確認繼承規則，新帳號加入前先驗證基本建立流程。這樣可以避免今天修一個限制，明天又因為別的策略把自己堵死。

真正有效的排查心法

處理這類問題，最重要的不是背很多 AWS 名詞，而是養成從上到下看邊界的習慣。IAM 是帳號內的角色分工，SCP 是組織的安全護欄。當子帳號無法建立資源時，如果你只盯著 IAM，不去看 Organizations 的層級限制，往往會在錯的方向上浪費大量時間。

簡單記住三句話就夠了：先看報錯屬於哪個動作，再看該帳號掛了哪些 SCP，最後確認策略是被明確拒絕，還是條件沒滿足。只要把這三件事做對，大多數子帳號無法建立資源的問題，都能很快收斂到真正原因。

換句話說，SCP 不是麻煩本身，它只是把組織規則提前寫死。真正讓人困擾的，通常是規則沒有被看懂，或是改了組織架構之後，沒同步更新策略。把這一點釐清，後面的排查就不會那麼亂。