How do AWS error codes relate to HTTP status codes?

AWS returns a specific error code in the response body (the Code or __type field) alongside an HTTP status. Many different codes share the same status — for example AccessDenied and ExpiredToken are both 403 — so you should branch on the AWS error code, not just the HTTP status.

Which AWS errors should I retry?

Throttling errors (Throttling, ThrottlingException, ProvisionedThroughputExceededException), 5xx server errors, and ServiceUnavailable are transient and should be retried with exponential backoff and jitter. Client 4xx errors such as AccessDenied or ValidationException are terminal and will not succeed on retry.

What causes a SignatureDoesNotMatch error?

SignatureDoesNotMatch means the request signature AWS computed does not match yours. Common causes are an incorrect secret access key, signing for the wrong region, an out-of-date system clock, or a payload that changed after signing. Verify the credentials, region, and clock skew.

What is the difference between Throttling and ServiceUnavailable?

Throttling means your request rate exceeded the service's per-account limit, so you should slow down and back off. ServiceUnavailable means the AWS service itself is temporarily overloaded or unavailable; both are retryable, but throttling is about your rate while the latter is about the service's state.

Is anything I search uploaded?

No. The full error index and the search run entirely in your browser. Nothing you type is sent anywhere.

AWS Error Codes — Gera Tools

This is a searchable index of AWS API error codes across the most-used services — S3, EC2, Lambda, IAM, STS, RDS and DynamoDB. Each row gives the error code, the originating service, the HTTP status it ships with, whether it is safe to retry, and a plain-English explanation, so you can decide quickly whether to back off, fix permissions, or give up.

How it works

Every AWS API failure returns a machine-readable error code in the response body — the Code element for XML services like S3, or the __type field for JSON services like DynamoDB and Lambda — together with an HTTP status. The HTTP status alone is ambiguous: AccessDenied, ExpiredToken and SignatureDoesNotMatch are all 403. Robust clients therefore switch on the AWS error code.

Errors fall into two broad classes. Transient errors — anything matching Throttling, ProvisionedThroughputExceeded, ServiceUnavailable, InternalError, or a 5xx status — are retryable, and the AWS SDKs automatically retry them with exponential backoff and jitter. Terminal client errors — AccessDenied, ValidationException, NoSuchBucket, ConditionalCheckFailedException — will not succeed on retry and signal a configuration, permission, or logic problem you must fix.

Tips and example

Use the retry column (or the retryable-only filter) to drive your error-handling strategy:

ThrottlingException       → back off + retry (transient)
ProvisionedThroughput...  → back off, or move table to on-demand
AccessDenied              → fix IAM/resource policy (terminal)
ConditionalCheckFailed... → expected race; re-read and retry the logic
NoSuchKey / NoSuchBucket  → wrong key/bucket (terminal)

When a write to DynamoDB returns ConditionalCheckFailedException, that is not an infrastructure error — it means your condition expression evaluated false, which is often an expected optimistic-locking race you handle in application logic. Everything runs in your browser; nothing is uploaded.

AWS Error Codes

Email me this result

How it works

Tips and example