AWS 基礎與 IAM

AWS 的基礎設施由三個層級組成，理解這三層對於設計高可用架構至關重要：

• Region（區域）：地理上獨立的資料中心群，目前全球超過 30 個。選擇 Region 考量四點：合規性（資料不能離境）、延遲（離用戶近）、服務可用性（新服務不一定所有 Region 都有）、定價（各 Region 費用不同）。
• Availability Zone（可用區 / AZ）：每個 Region 內至少有 3 個 AZ，每個 AZ 是一或多個實體資料中心，有獨立電力、網路、冷卻系統，AZ 之間透過低延遲的 AWS 私有骨幹網路連接。
• Edge Location（邊緣節點）：CloudFront CDN 的快取伺服器，全球超過 400 個，數量遠多於 Region。用於讓靜態內容離用戶更近、降低延遲。

• Users（使用者）：代表一個真實的人或應用程式，擁有長期憑證（密碼 + Access Key）。建立後預設沒有任何權限。
• Groups（群組）：使用者的集合，用於批次管理權限。注意：群組不能包含其他群組，且一個 User 最多可以加入 10 個群組。
• Roles（角色）：提供給 AWS 服務、應用程式或其他帳號 使用的臨時憑證（STS Token，由 STS / Security Token Service 簽發——這是 AWS 專門負責核發「臨時憑證」的服務，Token 通常幾十分鐘到數小時後就會自動失效，快過期前系統會自動換發新的，不需要人工更新密碼）。EC2 要存取 S3 → 不該用 Access Key，應該給 EC2 一個 IAM Role。
• Policies（政策）：JSON 格式的權限文件，定義允許或拒絕哪些操作。可以附加到 User / Group / Role。

IAM Policy 是 JSON 格式，每條 Statement 包含以下元素：

• Effect：Allow（允許）或 Deny（拒絕）
• Action：AWS API 操作，如 s3:GetObject、ec2:*（萬用字元）
• Resource：操作對象的 ARN（Amazon Resource Name）——AWS 用來唯一指名每一項資源的命名格式，結構大致是 arn:aws:{服務}:{region}:{帳號ID}:{資源路徑}；例如 arn:aws:s3:::my-bucket/*，S3 是全球服務不分 region/帳號 ID 所以中間兩段留空，my-bucket/* 代表這個 bucket 底下的所有物件
• Condition（可選）：條件限制，如只允許特定 IP、需要 MFA、特定 Tag 的資源

為什麼 Explicit Deny 一定要贏過 Allow？想像一位 User 同時屬於「工程師群組」（Allow 存取所有 S3）和「機密資料封鎖群組」（Deny 存取某個機密 Bucket）——如果 Allow 可以蓋過 Deny，管理員就永遠無法用一條規則保證某人「一定」不能碰某項資源，因為只要對方之後被加進任何一個帶 Allow 的群組，封鎖就會失效。讓 Deny 優先，才能讓「封鎖」變成真正說了算的最後防線。

• AWS Organizations：集中管理多個 AWS 帳號，統一帳單（Consolidated Billing），可共享 Reserved Instances 和 Savings Plans。
• OU（Organizational Unit）：帳號的邏輯分組，例如「生產環境 OU」、「開發環境 OU」。
• SCP（Service Control Policy）：在組織層級設定的最大權限邊界。即便帳號內的 IAM User 有 Admin 權限，SCP 禁止的操作仍無法執行。

• Instance Profile：讓 EC2 取得 IAM Role 的機制。正確做法：建立 Role → 附加到 EC2，應用程式自動取得臨時憑證，不需要存放 Access Key。
• Permission Boundary：設定在 IAM User 或 Role 上的最大可用權限邊界。就算之後有人給這個 User 更高的權限，也無法超出此邊界。
• IAM Identity Center（舊稱 SSO）：集中管理多帳號登入，可整合公司 AD（Active Directory）實現單一登入。
• IAM Access Analyzer：分析資源政策，找出哪些資源被設定為可從外部帳號或互聯網存取，協助發現安全風險。
• AssumeRole（跨帳號存取）：帳號 A 的 Role 可以信任帳號 B，讓帳號 B 的 User 來「扮演」這個 Role，實現跨帳號操作。