你的 AWS 帳號有幾個人在用？每個人都用 Root 登入嗎？Region 選對了嗎？三題有一題答不出來，這篇你得認真看——因為其中兩題答錯之後要改，等於搬家。
結論：六件事，分兩種
| # | 事 | 做錯的代價 |
|---|---|---|
| 1 | Root 鎖起來 | 不做 → 出事查不出是誰 |
| 2 | 人用 Identity Center，不建 IAM user | 不做 → 離職收不乾淨、key 永不過期 |
| 3 | Region 選對 | 做錯 → 搬家 |
| 4 | CloudTrail 第一天開，送另一個帳號 | 不做 → 稽核時沒證據 |
| 5 | 一環境一帳號 | 做錯 → 搬家 |
| 6 | 標籤規則第一天定 | 做錯 → 永遠清不出誰的資源 |
前三件和後三件的差別：不做會出事的，出事那天補還來得及；做錯的那三件，補救叫搬家。
一、Root：做完三件事就不要再碰
Root 帳戶什麼都能做，也什麼都能搞砸。
我見過最慘的案例：某個團隊所有人共用 Root，結果有人不小心把 production 的 S3 bucket 砍了。因為大家都用同一個帳號，連是誰幹的都查不出來。
Root 拿到之後：開 MFA（用實體安全金鑰或 passkey，官方建議用抗釣魚的那種）、把密碼存進密碼管理器、然後設定 Identity Center 給自己一個管理員身分（下一節）。從此 Root 只在帳務和 AWS 明列「只有 Root 能做」的事情時用，用了要有通知。
很多教學到這一步會叫你 aws iam create-user 建一個 admin user——不要。理由在下一節。
二、人用 Identity Center，不建 IAM user
IAM 最佳實踐的第一條原話：「要求人類使用者透過身分提供者聯合登入、使用臨時憑證存取 AWS」，並且「建議用 IAM Identity Center 集中管理帳號存取與權限」。
IAM user 是給「不得不用長期憑證」的例外場景——文件列的是無法用 role 的第三方工具那類。人不在例外裡。
差別在哪：
- IAM user 的 access key 永遠不過期，AWS 不會提醒你。離職了沒收，那把 key 就一直有效。
- Identity Center 接公司的身分來源（Google Workspace、Entra ID，或它自己的目錄），離職在身分來源停用，AWS 這邊自動失效。
- 權限用「權限集」分角色——唯讀、開發、維運、管理——一個人可以在不同帳號有不同角色，登入時選。
# Identity Center 建好之後，CLI 這樣登入，拿到的是幾小時就過期的臨時憑證
aws configure sso
aws sso login --profile prod-admin已經有 IAM user 的話，用 credential report 找出來，一個一個搬：
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d | \
awk -F, 'NR>1 && $9=="true" {print $1, "key age:", $10}'Permissions boundary 一句話：它是「這個人最多能有的權限上限」，官方定位是授權別人管權限時用的保險——你讓開發者自己建 role，boundary 擋住他們建出比自己更大的 role。
三、Region：一開始選錯，後面搬家超痛苦
Region 就是 AWS 機房的地理位置。原則：離使用者近、你要的服務那裡有、法規允許資料放那裡。台灣多數是東京（ap-northeast-1），台北區域上線後要看服務齊不齊。
我一開始沒注意 Region，在 us-east-1 開了一堆東西，後來才發現延遲高到不行。搬家超痛苦——EC2 snapshot 跨 Region 複製要等很久、RDS 要重建、Security Group 不能搬——別重蹈覆轍。
新服務通常先在 us-east-1 上線，要最新功能可能得犧牲延遲。但金流和個資有資料落地要求的，法規優先於延遲。
aws configure set region ap-northeast-1四、CloudTrail：第一天開，送另一個帳號
CloudTrail 記錄「誰在什麼時候呼叫了哪個 AWS API」。這是稽核的第一手證據，也是第一節那個案例「查不出誰砍的」的解法。
第一天就開、全區域開、log 送到另一個帳號的 S3——自己的 log 自己能刪，等於沒有 log。保留多久是合規要求不是技術選擇，金流通常至少一年。細節在第 12 篇第三層。
aws cloudtrail create-trail --name org-trail \
--s3-bucket-name audit-logs-in-security-account \
--is-multi-region-trail --enable-log-file-validation
aws cloudtrail start-logging --name org-trail五、一環境一帳號
帳號是 AWS 最強的隔離邊界——dev 的爆炸半徑碰不到 prod，帳單天然分開。IAM 最佳實踐原話：「隨著工作負載擴大，用 AWS Organizations 管理的多個帳號把它們分開」，並用 SCP 建立「所有帳號都不能做的事」的護欄。
SCP 不給權限，只擋：關 CloudTrail、開沒加密的 S3、刪 GuardDuty——不管你是誰都不行。
這件事為什麼要第一天做：單帳號長大之後拆帳號，資源要搬、IAM 要重建、跨帳號 role 要重設。等於搬家。一開始就開 Organizations，就算暫時只有一個帳號，之後加帳號是十分鐘的事。
有金流的話，把碰卡號的服務關進獨立帳號，是縮小 PCI 稽核範圍最有效的一招。
六、標籤與預算：第一天不定，永遠清不出誰的資源
每個資源至少三個標籤：project、env、owner。用 SCP 擋「沒標籤的資源不能建」——事後補標籤幾乎不可能，因為沒人記得那台是誰開的。
再設一道預算警報：實際花費 80% 通知、預測超過 100% 有人要看。帳單異常常常是被入侵的第一個訊號。細節在第 11 篇。
這篇的驗證標準
| 主張 | ❌ 不算 | ✅ 算 |
|---|---|---|
| Root 沒人用 | 「我們都知道不要用」 | CloudTrail 搜 root 的登入事件，最近 90 天零筆（除了你自己記得的那次） |
| 人不用 IAM user | Identity Center 設好了 | credential report 裡 IAM user 只剩服務用的，且每個有理由 |
| 離職收得乾淨 | 有離職清單 | 拿上一位離職者的名字，在身分來源和 credential report 各搜一次，零殘留 |
| 標籤有效 | 規則寫了 | Cost Explorer 按 project 分，沒有「未標籤」那一塊 |
實戰 Checklist
- Root：MFA 用安全金鑰、密碼進管理器、登入有通知、不再日常使用
- Identity Center 設好，人都從那裡登入；既有 IAM user 列出來逐一搬
- Region 選定且寫進 IaC 的變數，不靠
aws configure的預設 - CloudTrail 多區域開、送另一帳號、保留期符合合規
- Organizations 開了，SCP 至少擋「關 CloudTrail」；沒標籤的資源建不出來
從 K8s 過來的話
最常見的對法是把 IAM user 對到 ServiceAccount——錯了。ServiceAccount 是工作負載的身分，對應的是 IAM Role（第 8 篇）；人的身分在 K8s 是 kubeconfig 裡的 user，對應 Identity Center。RBAC 對應權限集。
差最多的是帳號這個邊界：K8s 用 namespace 隔離，AWS 用帳號隔離——重得多，但也硬得多，而且是你第一天就要決定的事。K8s 那邊的 RBAC 在 K8s 配置管理。
相關文章
- 回 AWS 系列目錄，下一篇 NAT
- 人的身分那一層的完整版：安全：四層邊界
- 概念層：Identity & Access
權限管理不性感，但它是你和天價帳單之間唯一的防線——而且有三件事，第一天沒做對，之後就是搬家。