AWS實名認證 AWS S3 常見錯誤碼處理大全

前言：為什麼 S3 錯誤碼值得「系統化」處理

在用 AWS S3 的過程中，錯誤常常不是「系統壞了」，而是你的請求在某個條件上不符合 S3 的規則。S3 的錯誤碼雖然看起來很雜，但它們其實是很有指向性的信號：是權限不足？是請求格式不對？是物件不存在？是你用錯了端點或桶設定？還是加密或上傳流程的某一步失敗？

如果你只是依賴「看錯誤訊息再猜」，排查會變成無底洞。相反地，只要把常見錯誤碼按類別整理，再配合日誌與請求屬性（Bucket、Key、Region、IAM、Policy、ACL、KMS、是否使用加速/靜態網站等），你就能把每次事故縮短到可預期的步驟。

AWS實名認證 下面我會以「錯誤碼 → 常見原因 → 如何確認 → 修復方向」的方式，整理一份可落地的處理清單。文中也會穿插一些通用排查技巧，讓你在遇到未列出的錯誤時仍能快速收斂。

先建一套通用排查框架：看得懂錯誤、也修得到問題

1）先確認你呼叫的是什麼「端點」與「區域」

S3 的 URL 與端點會影響簽名與路由。常見的錯誤根源是：你用錯了 Region、把靜態網站端點當成 API 端點，或使用了錯誤的簽名服務（例如某些代理層導致主機名改寫）。這類問題往往會讓錯誤碼看起來像權限或金鑰錯誤，但本質在網路與端點設定。

2）把請求細節記下來：Bucket、Key、方法、頭資訊

建議你在應用端針對失敗請求記錄至少以下欄位：

• HTTP 方法：GET/PUT/HEAD/DELETE/ListMultipartUploads
• Bucket 名稱、Key（含 URL 編碼前後的形式）
• 請求的 Content-MD5 / Content-Type（若使用）
• 是否啟用 SSE-S3 / SSE-KMS、KMS Key ARN
• 是否使用暫時憑證（STS AssumeRole）與憑證到期時間
• AWS實名認證 是否使用加速（S3 Transfer Acceleration）或特定域名

這些資訊能直接把排查從「猜」變成「驗證」。

3）用 S3 Access Log / CloudTrail 補齊上下文

AWS實名認證 S3 Access Logs 可以看到每次請求的來源與狀態碼；CloudTrail 可用於檢視涉及 IAM/策略變更、桶設定與 KMS 授權。當錯誤碼呈現「AccessDenied」或「KMS 認證失敗」時，這兩者常能補出你當下看不到的關鍵線索。

4）理解一個現象：S3 的錯誤訊息有時會「刻意保守」

例如 AccessDenied 可能不會告訴你「物件存在與否」。AWS 有時會避免暴露資訊以提升安全性。因此你要用 HEAD/GET 以外的方式結合權限策略、列舉能力與日誌來判斷。

核心錯誤碼類別一：權限、授權與憑證問題

1）AccessDenied（403）

常見原因：

• IAM 使用者/角色沒有執行該動作的權限（例如 s3:GetObject、s3:PutObject、s3:ListBucket）。
• 桶策略或物件層級 ACL 限制了來源、前綴（prefix）、或限制只允許特定條件（如特定 VPC、特定 TLS）。
• 使用 SSE-KMS 時，缺少 kms:Decrypt / kms:Encrypt / kms:GenerateDataKey 權限。
• 使用者請求的簽名憑證不匹配或作用範圍不足，導致看起來像權限不足。

如何確認：

• 檢查 IAM Policy 是否真的授權到該 Bucket/Key 範圍（resource ARN 是否包含正確的前綴或使用通配符）。
• 檢查 Bucket Policy 的 Condition（如 aws:Referer、aws:SourceVpce、s3:prefix、aws:SourceArn、aws:SecureTransport）。
• 若是 KMS 加密物件，確認 KMS Key Policy 是否允許該 IAM principal。

修復方向：

• 補齊缺少的 s3:* 權限（必要時最小權限化到 prefix）。
• 調整 Bucket Policy 的條件邏輯，避免過度限制（尤其是 prefix/來源條件）。
• 為 KMS 對應動作補上權限，並確認 KMS key policy 與 IAM policy 都有授權。

2）AllAccessDisabled

常見原因：使用者或角色的所有存取被禁用，通常是 IAM 層級被限制或帳號/角色狀態異常。也可能是你在使用的憑證是從已失效的路徑取得（例如連結到被停用的角色）。

如何確認：確認該 IAM principal 是否停用、角色是否刪除或被關閉、STS session 是否仍有效。

AWS實名認證 修復方向：更新憑證來源或重新 AssumeRole，並檢查 IAM/角色狀態。

3）InvalidAccessKeyId

常見原因：請求簽名使用了不存在或錯誤的 Access Key ID。常見於環境變數配置錯誤、密鑰輪替未更新、或代理服務替換了 header。

如何確認：核對應用程式目前使用的 AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY，並檢查部署環境是否有混用舊金鑰。

修復方向：更新憑證；若使用臨時憑證（STS），確保刷新機制正常。

4）SignatureDoesNotMatch

常見原因：

• 使用的 Region 不對導致簽名字串不同。
• 請求中某些 Header 或 Query 參數與簽名時不一致（例如 Content-MD5、x-amz-content-sha256、或自訂 header）。
• Key 在簽名時的 URL 編碼方式不同（尤其是含特殊字元時）。
• 系統時間偏差，導致簽名有效期判定失敗（較常見於某些簽名流程或代理層）。

如何確認：

• 確認請求使用的主機名是否符合你簽名時的設定。
• 檢查錯誤發生時的請求是否有額外 header 或重寫。
• 針對含特殊字元的 Key，比對實際發往 S3 的 URL 編碼。

修復方向：統一編碼與簽名流程；確保 Region/endpoint 正確；必要時修正容器/主機時間同步。

5）ExpiredToken（或 RequestTimeTooSkewed 相關）

常見原因：使用 STS 暫時憑證但到期未刷新，或系統時間與 AWS 偏差過大。

如何確認：檢查 session expiration；確認節點時間是否正確（NTP）。

修復方向：增加憑證刷新緩衝（例如到期前提前 5~10 分鐘更新）；修正時間偏移。

6）KMSAccessDenied / AccessDeniedException（搭配 KMS 常見）

常見原因：使用 SSE-KMS 或需要 KMS 進行加解密，但 principal 沒有對 KMS Key policy/IAM policy 的權限。

如何確認：查看 KMS key policy，確認包含 kms:Encrypt、kms:Decrypt、kms:GenerateDataKey 等必要動作；並確認 key policy 的 principal 指向正確。

修復方向：補上 KMS 授權；若跨帳號，特別注意 key policy 與信任關係。

核心錯誤碼類別二：物件、路徑與請求格式問題

1）NoSuchBucket

常見原因：Bucket 名稱不存在、拼字錯誤、或呼叫了錯誤的帳號/環境。

AWS實名認證 如何確認：核對 Bucket 名稱與建立區域；檢查是否使用了不同環境（dev/test/prod）導致指向錯誤桶。

修復方向：修正 Bucket 參數或環境變數。

2）NoSuchKey

常見原因：

• AWS實名認證 Key 拼錯或前綴拼接錯誤。
• URL 編碼導致 Key 被解讀不同（例如空白、%2F、特殊字元）。
• 你以為物件存在，但其實上傳失敗或被覆蓋。

如何確認：用正確的 Key 直接測試 HEAD 或 GET（在你有權限時）；或查詢 S3 Inventory / 日誌確認是否真的上傳成功。

修復方向：修正 Key 組裝邏輯；必要時在上傳後用 HEAD 驗證。

3）InvalidObjectState

常見原因：物件狀態與操作不相容，例如：

• 對「仍在進行分段上傳」的狀態做不允許的操作。
• 版本控制或刪除標記相關的版本狀態與請求不匹配。

如何確認：檢查你是針對最新版本還是特定 VersionId；確認是否是 multipart 上傳的中間流程。

修復方向：用正確的 VersionId 或先完成 multipart；必要時調整流程中的狀態檢查。

4）InvalidRequest / InvalidURI / MalformedXML

常見原因：

• XML body（如某些 List 或 Delete 多物件）格式不正確。
• AWS實名認證 Query 參數或 URL 結構不符合規範。
• 某些 Header 值不合法，例如 Content-Length 不匹配。

如何確認：把實際送出的 request body/headers 打印到安全的測試環境；確認 XML 結構與命名空間（若使用）。

修復方向：修正請求格式；採用 AWS SDK 避免手動組裝簽名與 XML。

5）InvalidAccessPointState（與存取點/多區域存取點相關）

常見原因：你在存取點尚未就緒、或狀態處於不允許操作的期間進行請求。

如何確認：檢查存取點（Access Point）與其策略是否完成設定；確認所在區域與狀態。

修復方向：等待資源狀態完成；修正策略與網路設定。

AWS實名認證 核心錯誤碼類別三：分段上傳與傳輸流程問題

AWS實名認證 1）InvalidPart / InvalidPartOrder

常見原因：

• PartNumber 超出範圍或重複。
• AWS實名認證 提交的 part ETag 與你在完成 multipart 時提供的不一致。
• 你在傳輸過程中切換了不同的 uploadId 或 bucket/key。

如何確認：確認 uploadId 一致；確認每個 part 上傳成功並保留回傳的 ETag；檢查完成步驟使用的清單（parts）是否完整且順序正確。

修復方向：修正 multipart workflow；確保「每個 part 的 ETag」對得上最後 CompleteMultipartUpload 的清單。

2）NoSuchUpload

常見原因：你使用了不存在或過期的 uploadId。

如何確認：檢查 uploadId 是否被覆蓋、是否跨請求被遺失；若有重試機制，確保 retry 不會誤用舊 uploadId。

修復方向：重新發起 CreateMultipartUpload；重建上傳狀態。

3）EntityTooLarge（或 MaxKeys 等相關）

常見原因：

• 上傳的物件超出限制，可能是單次 PUT 超出大小上限，或分段上傳配置不當。
• 批次列舉（List）參數不符合限制。

如何確認：確認目標是單次上傳還是 multipart；檢查 part 大小是否符合 S3 規則。

修復方向：採用 multipart；調整 part size 與流程。

核心錯誤碼類別四：靜態網站、索引文件與轉址設定

1）NoSuchBucket / AccessDenied 在靜態網站中的特性

靜態網站通常使用「網站端點」而非一般 S3 API 端點。若你把 API 端點當網站端點，可能出現看似權限或不存在的錯誤。反過來也成立：用網站端點去做需要 API 回傳內容的操作，可能得到不符合預期的回應。

如何確認：確認你的 URL 使用對了。靜態網站端點會有特定格式，且它不支援某些 API 行為。

修復方向：分清前端靜態網站存取與後端 S3 讀寫；必要時在應用端把 base URL 拆開管理。

2）Redirect / Method Not Allowed 相關行為

當網站規則或請求方法不符合時，可能出現重導向或方法不被允許的狀態。這不一定是某個單一錯誤碼，但在排查「網站讀不到檔案」時很常遇到。

如何確認：檢查你發送的是 GET 還是 HEAD/PUT；同時確認 index 與 error doc 的設定。

修復方向：修正前端請求方式與網站配置（IndexDocument、ErrorDocument、路徑規則）。

核心錯誤碼類別五：版本控制、刪除標記與對象生命週期

1）NoSuchVersion / InvalidVersionId（視情境而定）

常見原因：

• 你在請求中帶了 VersionId，但該 VersionId 不存在或已被刪除。
• 刪除標記（DeleteMarker）存在，但你期待取回物件內容。

如何確認：檢查請求是否含 VersionId；查驗該 key 的版本歷史（可用 ListObjectVersions）。

修復方向：更新流程邏輯：要嘛不傳 VersionId 要嘛改用正確的版本；若要取回非刪除版本，需明確選定版本。

AWS實名認證 2）InvalidObjectState 與 Glacier/歸檔恢復（若你使用對象歸檔）

當物件處於歸檔或尚未完成恢復，某些讀取操作可能失敗。具體行為會取決於你使用的存儲類別與復原狀態。

如何確認：確認該物件的儲存類別；查看是否正在恢復、復原到期時間。

修復方向：等待恢復完成或改用不同儲存策略；在應用端加入「恢復中」的降級邏輯。

核心錯誤碼類別六：加密（SSE-S3、SSE-KMS）與需求頭

1）InvalidRequest / KMS 相關錯誤（例如 NotFoundException 在 KMS）

常見原因：SSE-KMS 參數帶錯（KMS Key ARN 不存在或不在同區域/權限範圍），或你提供了與物件不一致的加密參數。

如何確認：核對 SSE 相關 header：x-amz-server-side-encryption、x-amz-server-side-encryption-aws-kms-key-id。

修復方向：修正 header 與 key ARN；確保 KMS key policy 與 IAM 授權都到位。

2）AccessDenied 與 SSE-S3

即使是 SSE-S3，仍可能因為你沒有權限執行對應的動作、或桶策略限制了加密方式而出錯。例如只允許 SSE-KMS，卻你改用 SSE-S3。

如何確認：檢查 Bucket Policy 是否限制 s3:x-amz-server-side-encryption 的值。

修復方向：跟隨策略要求的加密方式，或放寬策略。

核心錯誤碼類別七：簽名與網路條件（比你想像更常見）

1）RequestTimeTooSkewed（或簽名有效期相關）

常見原因：系統時間偏差太大，導致簽名的有效時間判斷失敗。

如何確認：檢查節點時間（容器是否共用 host、是否可同步）；查看 NTP 是否正常。

修復方向：修正時間；在容器環境啟用時間同步或手動校準。

2）SignatureDoesNotMatch 的「非授權」根源

很多團隊會把 SignatureDoesNotMatch 全部歸因為權限，但其實最常見的是：端點/Region/編碼/頭資訊與簽名流程不一致。你可以用一個簡單原則：如果它不是存取權限問題，那就回頭檢查你當初簽名時用到的所有輸入是否與實際送出一致。

修復方向：固定 endpoint 與 Region；避免在簽名後才修改 request headers；對 Key 做一致的 URL 編碼策略。

核心錯誤碼類別八：列舉與刪除（List/Batch/操作限制）

1）InvalidArgument / MalformedXML（常見於批次或清單）

常見原因：DeleteObjects 批次刪除的 XML 結構不符合要求；List 操作的參數格式錯誤；或傳入了不合法的 ContinuationToken。

如何確認：在測試環境中把 XML 內容輸出（注意遮蔽敏感資訊），對照 API 格式。

修復方向：使用 AWS SDK 產生請求；盡量不要手寫 XML。

2）MalformedXML 與字元編碼

XML 解析錯誤常常與字元集（UTF-8）、特殊字元（&、<、>）未 escape 有關。

修復方向：確保 XML 內容正確 escape；避免把原始字串直接插入 XML 而未處理。

錯誤碼到修復：一張「對照表」幫你加速定位

下面把常見錯誤碼做快速對照。你可以在看到錯誤時先判斷它落在何類，再按對應步驟縮小範圍。

• AccessDenied：IAM/Bucket Policy/KMS 授權不完整，或條件限制（TLS、VPC、prefix）。
• InvalidAccessKeyId：憑證來源錯誤或金鑰輪替未更新。
• SignatureDoesNotMatch：端點/Region/編碼/頭資訊不一致，或時間偏差。
• ExpiredToken：STS 憑證到期未刷新。
• NoSuchBucket：Bucket 名稱錯、環境錯、或帳號/權限導致你看不到。
• NoSuchKey：Key 組裝錯、編碼錯、或物件根本不存在。
• InvalidPart / NoSuchUpload：multipart workflow 狀態或 uploadId/part 清單不一致。
• MalformedXML / InvalidRequest：請求格式不符合規範或 XML/參數錯誤。
• KMSAccessDenied：KMS key policy 或 IAM 權限不足。
• InvalidObjectState：物件狀態與操作不相容（multipart 中間狀態、版本/刪除標記、歸檔狀態）。

把排查流程做成 SOP：讓團隊不靠運氣

步驟一：先把失敗的請求「歸因」到類別

看到錯誤碼後，先判斷是權限（AccessDenied 類）、簽名（Signature/InvalidAccessKey/ExpiredToken 類）、物件不存在（NoSuchBucket/NoSuchKey 類）、格式（MalformedXML/InvalidRequest 類）、或流程狀態（multipart/版本/歸檔）。

步驟二：用最小成本驗證假設

• 如果懷疑 Key 拼接錯：先用同一套程式碼對照日誌與實際發出的 URL，比對編碼。
• 如果懷疑權限：用最小動作驗證（HEAD/GET）並查看 CloudTrail/S3 Access Logs。
• 如果懷疑簽名：檢查 Region、端點主機名與 request headers 是否在簽名後被修改。
• 如果是 multipart：先確保 uploadId 與 part 清單一致，再談權限。

步驟三：修復後要做「可觀測性」的驗證

修復不是只讓請求成功一次。建議你至少做以下其中一項：

• 上傳後立刻 HEAD 驗證 Content-Length/etag（若適用）。
• 對加密物件驗證能否讀取並解密（若是 SSE-KMS）。
• 對列舉/批次操作，驗證 prefix 與結果數符合預期。

常見踩雷清單：很多錯誤其實是同一個根因

踩雷一：把 Bucket Policy 的條件寫得過度嚴格

例如只允許特定 VPC endpoint 或特定 TLS；當應用由測試環境搬到生產，網路路徑變了，你就會看到 AccessDenied。這不是 S3 壞掉，而是條件沒命中。

踩雷二：Key 的 URL 編碼不一致

尤其在 Key 含有空白、加號、斜線或中文時，手動拼 URL 很容易造成 SignatureDoesNotMatch 或 NoSuchKey。最佳做法是把 Key 當成原始字串交給 SDK 處理，而不是自己硬編碼。

踩雷三：KMS 授權只改 IAM 沒改 Key Policy（或反過來）

AWS實名認證 KMS 是「雙重授權」邏輯：KMS key policy 與 IAM policy 可能都要符合。你只修其中一方，仍可能出現 AccessDenied 或 KMS 相關錯誤。

踩雷四：multipart retry 用錯 uploadId

很多隊伍的重試邏輯會在部分失敗後重新上傳，但忘了上傳狀態（uploadId）應該跟著流程更新。最後就會遇到 NoSuchUpload 或 InvalidPart。

結語：把錯誤碼變成能力，而不是一次次熬夜

S3 的錯誤碼不是用來嚇人，而是用來縮小範圍。只要你能把錯誤碼映射到「權限/簽名/物件/格式/流程狀態」五個大類，再用日誌與請求細節去驗證假設，排查就會變得清楚且穩定。

下次當你看到 AccessDenied、NoSuchKey 或 SignatureDoesNotMatch 時，請先不要急著改一堆設定。先做歸因，再做最小驗證。你會發現：同樣的問題其實有固定的解法，而你正在建立的是可複用的處理模式。

附錄：建議你在系統中預先做好哪些防呆

1）請求失敗重試要分「可重試」與「不可重試」

例如權限不足與簽名錯誤通常不會因重試而變好。把重試策略設得太死，只會拖慢問題定位。建議依錯誤碼與 HTTP 狀態碼做分流：只對網路暫時錯誤或 transient 狀況重試。

2）對 Key 做一致的建置規則

用同一套 prefix 格式與分隔符約定，並在寫入與讀取時共用同一個 Key builder。這能顯著降低 NoSuchKey 的發生率。

3）把 SSE 與 KMS 設定集中管理

將加密設定與 KMS Key ARN 放在可配置中心或環境設定中，並在啟動時做一致性檢查（例如確認必填的 KMS arn 存在）。避免因不同服務或不同環境差異造成不一致錯誤。

4）把簽名與端點資訊做成單一來源

例如 Region 與 endpoint 由配置注入，避免在多處重複寫死。並避免中間層代理重寫 host header。

5）把 multipart 狀態持久化

uploadId、parts 列表與上傳進度最好能持久化，以便失敗後可以精準接續或正確清理。這能避免 NoSuchUpload 與 InvalidPart 反覆出現。