AWS代理帳號開戶 AWS S3 拒絕存取 Access Denied 解決方法

第一章：先搞清楚，Access Denied 到底拒絕了什麼

「AWS S3 拒絕存取」常見的錯誤訊息是 AccessDenied。但這個代碼本身並不告訴你「是哪一條設定」在攔截：是 Bucket Policy？是 IAM Role 的權限？是物件本身的 ACL？還是因為你啟用了某種阻擋公開存取的設定而導致衝突？

很多人排查會先去猜：像是「是不是我沒打開公開權限？」、「是不是路徑寫錯？」然而 S3 的拒絕通常是疊加效果：只要任何一層拒絕生效，整體就會失敗。要有效解決，你需要把問題從「表面錯誤」拉回到「授權判斷」的本質。

我會把後面的內容用一個原則串起來：先定位請求在哪一個層級被拒絕，再逐層確認。你可以把它想成排除故障：先看系統在哪裡掛掉，再去修那個部位，而不是把整台機器重新重裝。

第二章：Access Denied 的最常見成因

2.1 身分與權限不一致：你以為你在用 A，其實是 B

最常見的「自我感覺良好」就是：你以為你用的是正確的 IAM 使用者或角色，但實際請求可能來源不同。例如：

• 本機程式使用的憑證不是預期的那組（環境變數、共享憑證檔案、角色假身失效）。
• 你在 ECS/Lambda 上部署後，角色其實缺少 S3 權限，或權限範圍與你存取的 bucket/object 不匹配。
• 跨帳號存取時，你給了對方帳號的 Bucket Policy，但你實際請求是另一個 Role/使用者。

AWS代理帳號開戶 這一類的特徵通常是：同一段程式在不同環境工作/失敗，或你切換憑證後才發現結果變了。

2.2 Bucket Policy 與 IAM Policy 打架：一個允許不等於能用

S3 授權評估時，允許（Allow）需要足夠的權限，而 任何明確拒絕（Deny） 都會直接讓你失敗。尤其是 Bucket Policy 常見陷阱：

• Bucket Policy 寫了 Principal 範圍過窄，導致你的身份不在清單中。
• AWS代理帳號開戶 Policy 寫了限制條件（例如 aws:userid、aws:PrincipalArn、aws:SourceIp、VPC 條件），但你的請求沒有符合。
• Bucket Policy 設定了 Deny，用來阻止非 TLS、阻止非特定前綴存取等；你以為只是「安全建議」，結果它是硬拒絕。

因此，你看到 AccessDenied 時要先確認：是否存在任何 Deny 在作用。

2.3 Block Public Access：看似關閉不了，但其實一直在阻擋

當你嘗試公開讀取（例如用 URL 直接下載）時，常會踩到 Block Public Access。它不是「讓你更安全」那麼簡單，它會影響 ACL 與 Bucket Policy 的公開配置效果。

你可能做了：

• 在 Bucket Policy 加上公開讀取。
• 或在物件層級調整 ACL。

但如果 Block Public Access 的某些選項啟用，S3 可能會忽略你的公開設定。這時錯誤就會像是「我都設了為什麼還不行？」答案通常是：你設的那套公開方式被阻擋了。

2.4 KMS 加密：你有 S3 權限，但沒有解密權限

若你的 bucket 或物件使用 SSE-KMS（例如 aws:kms），就會出現一種很迷惑的情況：你有 s3:GetObject，但仍然 AccessDenied。此時錯誤常見原因是：

• KMS Key Policy 沒有讓你的角色/帳號被允許使用 kms:Decrypt。
• 你在 S3 端允許存取，但在 KMS 端沒有允許解密。
• 你用錯了 key（例如不同環境用不同 key，但程式寫死了另一把）。

解決方式也很單純：補上對應 KMS 權限。但前提是你先確認它確實是 KMS 造成的，而不是 S3 層級。

2.5 物件路徑或存取點錯誤：不是你以為的那個 key

AccessDenied 有時是因為你其實在請求「另一個物件」。S3 的 object key 是區分大小寫、也包含前綴的。常見錯誤：

• AWS代理帳號開戶 前綴多了一層資料夾（例如實際是 folderA/file.txt，你請成 folderA/sub/file.txt）。
• URL 編碼處理錯誤（空白、特殊字元）。
• 你使用了錯誤的 endpoint（例如 region 不對，會導致你以為在請求同一個 bucket，實際卻不是）。

這類問題的特徵是：你查詢 bucket 中確實存在該檔案，但你取的 key 不匹配。你需要把「請求中的 key」精準對上。

第三章：建議的排查流程（從最快到最準）

AWS代理帳號開戶 下面是一套我建議你按順序做的流程。目標不是「看起來很完整」，而是能把你帶到真正原因。

3.1 第一步：先確認你是用哪個身份在打 S3

你要回答三個問題：

• 請求是由哪個 IAM 使用者/角色發出？（例如 arn:aws:sts...:assumed-role/...）
• AWS代理帳號開戶 請求是來自哪個環境？本機？Lambda？EC2？ECS？
• 憑證是如何提供的？環境變數、AWS profile、STS AssumeRole、Instance Profile？

如果你用程式打 S3，請先檢查「目前程式使用的憑證來源」。很多時候你以為用的是 role，但其實 fallback 到另一個 profile。

3.2 第二步：確認動作（Action）與資源（Resource）是否匹配

S3 的授權不是「有 bucket 就行」，它是以 Action 與 Resource 判定。

常見 Action/需求對應：

• 列出物件：s3:ListBucket（Resource 通常是 bucket arn，不是 object arn）
• 取得物件：s3:GetObject（Resource 通常包含 arn:aws:s3:::bucket-name/prefix*）
• 上傳物件：s3:PutObject
• 刪除物件：s3:DeleteObject

例如你想下載檔案，卻只給了 s3:ListBucket，那肯定不會成功。同樣，你只給了 s3:GetObject，但你的程式先呼叫 List 來找 key，也可能在 List 階段就被拒。

3.3 第三步：檢查物件的公開與 Block Public Access 的關係

如果你的用途是讓外部直接讀取（公開 URL），那 ACL 與 Bucket Policy 的公開設定是否被 Block Public Access 影響非常關鍵。你可以用一個簡化的思路：

• 你是否真的需要公開？
• 你是否應該用 Pre-signed URL 或 CloudFront OAI/OAC，而不是公開 bucket？
• 如果你堅持公開，是否允許該公開方式？Block Public Access 的選項是否阻擋？

很多公司最後都會轉向「不把 bucket 設公開」，而是使用簽名 URL 或 CloudFront。這能降低維運風險，也通常更容易把權限控到位。

3.4 第四步：用 CloudTrail 找到拒絕的精確原因

當你開啟或已有 CloudTrail 時，關鍵不是看「有沒有事件」，而是看拒絕原因與請求內容。CloudTrail 事件通常包含：

• 事件來源與時間
• 由哪個角色/使用者觸發
• AWS代理帳號開戶 請求的資源（bucket/obj）
• 錯誤訊息與拒絕細節

如果你想更快定位，你可以搭配 Access Analyzer 或檢查「最後拒絕」的條件（例如是否因為缺少 kms:Decrypt）。

第四章：針對不同情境的解決做法

下面把常見情境拆開，你可以對號入座。每個情境都會對應「你應該改哪一層」。

4.1 情境一：同帳號、程式下載失敗（GetObject）

你可能已經看到 s3:GetObject 的錯誤，但實際上真正缺的是：

• 你沒有對應到正確的 object prefix
• 你有給角色 s3:GetObject，但 Resource 沒涵蓋你實際 key
• 你有給權限，但 Bucket Policy 有額外條件造成拒絕

修正策略：

• AWS代理帳號開戶 把你要存取的 key 前綴列出來，確保 IAM policy 的 Resource 使用一致的前綴。
• 檢查 Bucket Policy 是否存在 Deny 或條件限制。
• 若物件加了 KMS SSE，確認 KMS key policy 允許 decrypt。

4.2 情境二：列出（List）失敗，但下載（Get）看似成功或反之

這非常常見。很多程式一開始會 List 取得檔名或做分頁，然後才 GetObject。若你的 IAM 只給了 GetObject，ListBucket 會被拒。

修正策略：

• 對需要 List 的前綴補上 s3:ListBucket。
• 注意 ListBucket 的 Resource 是 bucket arn，而不是物件 arn。
• 若使用 prefix 條件（例如 s3:prefix），你的請求 prefix 必須吻合。

4.3 情境三：你把 Bucket Policy 設了公開讀取，但仍然 AccessDenied

通常原因是 Block Public Access 或 ACL/Policy 衝突。你可能在 Bucket 或物件層級做了公開，但被阻擋後，S3 可能直接拒絕。

修正策略：

• 先確認 Block Public Access 的設定（尤其是「阻止公開 ACL」與「阻止公開 Bucket Policy」類型）。
• 如果你要公開，確保你公開的方式是被允許的那一種。
• 如果你願意，改用 Pre-signed URL：它對外部使用者仍然是可用的，但你不必讓 bucket 真正公開。

實務上，用簽名 URL 往往更穩。因為你可以做到有效期、撤銷與更細的控制，不會被「未來有人不小心把策略改成公開」帶來風險。

4.4 情境四：跨帳號存取（Account A 存 Account B 的 S3）

跨帳號最常見的錯誤是你只改了 IAM policy，卻忘了 Bucket Policy 必須允許其他帳號的 Principal。S3 的 Bucket Policy 才是資源端控門。

修正策略：

• 在目標 bucket（Account B）上編寫 Bucket Policy，允許 Account A 的角色或帳號讀取指定 prefix。
• 同時在 Account A 的 IAM 端也要允許該操作（例如 s3:GetObject）。
• 如果使用 SSE-KMS，還要在 KMS Key policy 允許 Account A 的角色使用 decrypt。

跨帳號出錯常見於「三者不齊」：S3 權限、Bucket Policy、KMS Key Policy 任一缺漏都會失敗。

4.5 情境五：使用者透過簽名 URL 下載，仍被拒絕

如果是預簽名 URL（Pre-signed URL），AccessDenied 可能原因包括：

• 簽名過期（時效過短或系統時間不同步）。
• 簽名使用的身份在那一刻就沒有權限。
• 簽名時使用的 HTTP 方法與實際不同（例如簽的是 GET，你用的是 HEAD 或 PUT）。
• AWS代理帳號開戶 你改了 bucket policy/前綴條件，導致簽名雖然仍可解鎖，但策略不再符合。

修正策略：

• 檢查簽名 URL 生成時使用的 credential。
• 核對簽名包含的 method。
• 檢查當時的策略是否與現在不同（尤其是部署後改過 policy）。
• 確認是否存在 KMS 解密權限問題。

第五章：KMS 解密權限的排查與修正重點

這一章我特別想講細一點，因為 KMS 是最常造成「看起來 S3 沒問題但仍 AccessDenied」的原因。

5.1 SSE-KMS 與權限的邏輯

當你用 SSE-KMS 加密物件時，S3 會在你請求讀取時需要呼叫 KMS 做解密。這代表你的身份要同時被允許：

• 在 S3 上執行 s3:GetObject
• 在 KMS 上執行 kms:Decrypt

只要其中一個缺了，就會失敗，而且訊息可能不會清楚告訴你缺的是哪一段。

5.2 你應該看哪裡？S3 設定還是 KMS policy？

通常你要檢查兩件事：

• 該 bucket/物件實際使用的是哪把 KMS key（key ARN）。
• 那把 KMS key 的 key policy 是否允許你的 Principal（角色或帳號）執行 Decrypt。

你也要注意 key policy 的條件（例如 kms:ViaService、描述中的前置條件）。有些人只在 KMS 給了寬鬆權限，但條件沒放行，仍然會拒絕。

第六章：避免再次踩雷的實務建議

解決一次不難，難的是讓系統以後不再突然失效。以下是我常見到有效的維運習慣。

6.1 把權限寫成可驗證的形式，而不是「看起來差不多」

權限最常出問題的原因是：Resource 範圍寫得太寬導致你以為「應該會涵蓋」，或寫得太窄導致實際 key 不在範圍內。你可以採用一個原則：先列出你會用到的前綴，再用它去定義 Resource。

例如你實際上只會讀取 uploads/user-123/，那就別用很寬的 uploads/* 來「假裝安全」，也別只給單一檔案 key。

6.2 使用最小權限，但也要容許流程所需的額外步驟

很多應用除了 GetObject，還會做：

• ListBucket 取得檔案清單
• HeadObject 檢查是否存在或讀取 metadata
• 用 tag/metadata 做判斷

因此權限設計不能只看「你最後要下載」，而要看整段流程。你可以把應用的 S3 呼叫列出來，對照最終需要的 Action。

6.3 把 CloudTrail 與記錄保留做成制度

當 AccessDenied 來得突然時，你往往需要回溯：當天誰在什麼時間以什麼身份打了哪個資源。沒有事件記錄就等於只能猜。

如果你能保留足夠的 CloudTrail 資料，排查會快很多。你至少能知道拒絕發生在流程哪一步，以及用了哪個角色。

第七章：一個完整的快速範例排查（你可以照著做）

AWS代理帳號開戶 假設你現在遇到：你的程式要下載 https://bucket-name.s3.amazonaws.com/reports/2026-07/report.csv，卻回 AccessDenied。你可以照以下順序做。

7.1 確認請求的 object key 是否正確

把你程式送出的 key 印出來，比對是否就是 reports/2026-07/report.csv。同時檢查是否有 URL 編碼差異（例如空白、特殊符號）。

7.2 確認請求身份

在你的執行環境（本機/Server/Lambda）確認使用的角色。若是角色假身，檢查 AssumeRole 是否成功、憑證是否過期。

7.3 檢查 IAM 是否有 GetObject

角色的 IAM Policy 至少要包含 s3:GetObject，並且 Resource 覆蓋到 arn:aws:s3:::bucket-name/reports/2026-07/*（或更精確前綴）。

7.4 檢查 Bucket Policy 是否有 Deny 或條件不符

打開 bucket 的 Bucket Policy，搜尋：

• "Effect": "Deny"
• 限制條件例如 aws:SecureTransport、aws:SourceIp、aws:PrincipalArn、s3:prefix

確保你的請求符合條件。

7.5 若使用 SSE-KMS，補上 kms:Decrypt

查看該物件或 bucket 的加密設定。若是 SSE-KMS，確認 KMS key policy 允許你的 Principal 執行 kms:Decrypt。必要時也確認條件（例如 ViaService）是否吻合。

第八章：常見誤區整理

8.1 只看錯誤代碼，不看拒絕邏輯

AccessDenied 可能是 S3 授權、也可能是 KMS；可能是 Bucket Policy、也可能是 ACL 或條件。光看代碼不夠，你需要找到「拒絕那一層」。

8.2 以為設定一次就會永遠有效

很多團隊會在之後修改 Bucket Policy、加入安全限制、調整 Block Public Access，甚至更換 KMS key。你原本可用，過幾週就不可用，這不是你突然倒楣，而是策略變了。

8.3 把公開當成唯一解法

公開固然方便，但在權限控管上最容易出現「外部能看到、但你不確定為什麼」。如果你的需求只是下載檔案，Pre-signed URL 或 CloudFront 通常更符合現代的安全與維運。

結語：把問題從猜測變成定位

「AWS S3 拒絕存取 Access Denied」的真正難點不在於它很神秘，而在於它可能由多個設定疊加造成。你只要遵循一個穩定的排查方法：先確認身份，再確認 Action/Resource，再檢查 Bucket Policy/Block Public Access，最後釐清是否涉及 SSE-KMS，就能把混亂的錯誤收斂到具體的設定點。

當你不再依賴直覺，而是用事件紀錄與授權邏輯去驗證，解決速度會明顯提升，而且後續也能避免重複踩同樣的坑。