Amazon SQS 常見問答集

按實際用量付費，而且沒有最低費用。

Amazon SQS 的費用是依請求個別計算，再加上從 Amazon SQS 傳出資料的數據傳輸費 (除非資料傳輸到相同區域內的 Amazon Elastic Compute Cloud (EC2) 執行個體或 AWS Lambda 函數)。如需各佇列類型和區域的詳細定價明細，請參閱 Amazon SQS 定價。

Amazon SQS 免費方案每月免費提供 100 萬個請求。

許多小規模應用程式應該能夠完全在這個免費方案限制內操作。不過，可能仍然需要支付數據傳輸費。如需詳細資訊，請參閱 Amazon SQS 定價。

免費方案是每月優惠，免費使用量不能跨月累計。

是，您需要支付免費方案以外的任何請求費用。所有 Amazon SQS 請求都要計費，且以同一費率計費。

否。批次操作 (SendMessageBatch、DeleteMessageBatch、和 ChangeMessageVisibilityBatch) 的所有費用都與其他 Amazon SQS 請求相同。透過將訊息群組為批次，可降低 Amazon SQS 的費用。

開始使用 Amazon SQS 無須支付初始費用。月底將自動從您的信用卡扣取當月用量的費用。

您可以隨時在 AWS 網站上查看目前計費期間的費用。

1. 登入您的 AWS 帳戶。
2. 在 Your Web Services Account 下選取 Account Activity。

您可以使用成本分配標籤，針對資源和成本管理來標記和追蹤佇列。標籤是包含鍵值組的中繼資料標籤。例如，您可以依照成本中心標記佇列，然後根據這些成本中心分類和追蹤成本。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的標記您的 Amazon SQS。如需 AWS 資源成本分配標記的詳細資訊，請參閱 AWS 帳單與成本管理使用者指南中的使用成本分配標籤。

除非另有說明，否則我們的價格不包括任何適用的稅金和關稅 (如增值稅和適用的營業稅)。

帳單地址在日本的客戶若使用任何區域的 AWS，則需負擔日本消費稅。如需詳細資訊，請參閱 Amazon Web Services 消費稅常見問答集。

是。若要讓應用程式更具彈性和可擴展性，使用 Amazon SQS 時可搭配運算服務 (如 Amazon EC2、Amazon Elastic Container Service (ECS) 和 AWS Lambda) 和儲存及資料庫服務 (如 Amazon Simple Storage Service (Amazon S3) 和 Amazon DynamoDB) 一起使用。

您可以使用 AWS 管理主控台存取 Amazon SQS，以協助您輕鬆建立 Amazon SQS 佇列和傳送訊息。

Amazon SQS 還提供 Web 服務 API。而且它也已經與 AWS 開發套件整合，可讓您使用自己選擇的程式設計語言。

如需訊息佇列操作的資訊，請參閱 Amazon SQS API 參考。

只有 AWS 帳戶擁有者 (或帳戶擁有者已指派權利的 AWS 帳戶) 可在 Amazon SQS 訊息佇列執行操作。

是。利用 Amazon SQS 的可擴展性、低成本和高可用性，您就無須為執行自己的 JMS 叢集而操心和支付高額的開銷。 

Amazon 提供實作 JMS 1.1 規格的 Amazon SQS Java 訊息程式庫並使用 Amazon SQS 做為 JMS 提供者。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的搭配 JMS 使用 Amazon SQS。

Java 訊息服務 (JMS)

所有訊息都有全域唯一的 ID，Amazon SQS 在訊息遞送到訊息佇列時會傳回該 ID。對訊息執行任何進一步動作不需要該 ID，但對於追蹤訊息佇列中的某個特定訊息回條則很有用。

從訊息佇列接收訊息時，回應中包含刪除訊息時必須提供的接收控點。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的佇列和訊息識別碼。

在 Amazon SQS 中，您可以使用 API 或主控台來設定無效字母佇列，這些佇列用來接收其他來源佇列中的訊息。設定無效字母佇列時，您需要使用 RedriveAllowPolicy 為無效字母佇列重新驅動設定適當的許可。

RedriveAllowPolicy 包含無效字母佇列重新驅動許可的參數。它定義哪些來源佇列可以將無效字母佇列指定為 JSON 物件。

在您設定無效字母佇列後，它會在無法完成嘗試處理次數上限之後收到訊息。您可以使用無效字母佇列隔離無法處理的訊息，以供日後分析。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的使用 Amazon SQS 無效字母佇列。

可見性逾時是 Amazon SQS 防止其他使用元件接收和處理訊息的一段時間。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的可見性逾時。

是。Amazon SQS 訊息最多可包含 10 個中繼資料屬性。您可以使用訊息屬性將訊息內文與描述該訊息的中繼資料分開。這有助於以更快的速度和更高的效率來處理和存放資訊，因為您的應用程式不需要檢查整個訊息，即可了解所需的處理步驟。

Amazon SQS 訊息屬性採用 name-type-value 三元素格式。支援的類型包括字串、二進位和數字 (包括整數、浮點數和雙精度數)。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的使用 Amazon SQS 訊息屬性。

若要判斷排隊時間值，可在接受訊息時請求 SentTimestamp 屬性。將目前時間減去該值即可獲得排隊時間值。

SendMessage、ReceiveMessage 及 DeleteMessage API 請求的延遲一般為數十或一百多毫秒。

AWS 帳戶 ID 無法使用 (例如，當匿名使用者傳送訊息) 時，Amazon SQS 會提供 IP 地址。

Amazon SQS 長輪詢是從 Amazon SQS 佇列擷取訊息的方法。即使輪詢的訊息佇列為空，一般短輪詢仍會立即回應，而長輪詢只會在訊息送達訊息佇列或長輪詢逾時的時候才傳回回應。

一旦有訊息，長輪詢可立即從您的 Amazon SQS 佇列擷取該訊息，且價格非常低廉。使用長輪詢可能會降低使用 SQS 的成本，因為可以降低空白接收數。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 Amazon SQS 長輪詢。

否。長輪詢 ReceiveMessage 呼叫的收費方式與短論詢 ReceiveMessage 呼叫的收費方式完全相同。

幾乎在所有情況下，使用 Amazon SQS 長輪詢都比使用 Amazon SQS 短輪詢更好。長輪詢請求可以使您的佇列消費者在訊息抵達佇列時立即收到訊息，同時減少傳回空 ReceiveMessageResponse 執行個體的次數。

在大部分的使用案例中，Amazon SQS 長輪詢都可提升效能並降低成本。不過，如果您的應用程式期待從 ReceiveMessage 呼叫收到立即的回應，則可能必須對應用程式進行一些修改，才能利用長輪詢的優勢。

例如，如果您的應用程式使用單一執行緒輪詢多個佇列，從短輪詢切換到長輪詢可能不可行，因為單一執行緒會等待所有空佇列的長輪詢逾時，進而導致延遲處理可能包含訊息的任何佇列。

在這類應用程式中，最好的作法是使用單一執行緒處理一個佇列，進而使應用程式能夠利用 Amazon SQS 長輪詢的優勢。

一般情況下，長輪詢逾時最長應設定為 20 秒。因為較高的長輪詢逾時值會減少傳回空 ReceiveMessageResponse 執行個體的次數，因此盡可能將長輪詢逾時設得越高越好。

如果 20 秒的最長逾時不適用於您的應用程式 (請參閱上一個問題的範例)，可以設定較短的長輪詢逾時值，最短為 1 秒。

預設情況下，所有 AWS 開發套件都使用 20 秒的長輪詢。如果您不使用 AWS 開發套件存取 SQS，或者您已經特地將 AWS 開發套件設定為較短逾時，則您可能需要修改 Amazon SQS 用戶端，以允許更長的請求或者使用較短的長輪詢逾時。

適用於 Java 的 AmazonSQSBufferedAsyncClient 可實作 AmazonSQSAsyncClient 界面，並新增了數個重要功能：

• 自動批次處理多個 SendMessage、DeleteMessage 或 ChangeMessageVisibility 請求，不需要對應用程式進行任何變更。
• 將訊息預先擷取到本機緩衝區，能夠讓您的應用程式立即處理來自 Amazon SQS 的訊息，無須等到擷取訊息。

自動批次處理和預先擷取功能搭配使用，可提高輸送量並降低應用程式延遲，同時減少 Amazon SQS 請求的數量以降低成本。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的用戶端緩衝與請求批次處理。

您可以在 適用於 Java 的 AWS SDK 下載 AmazonSQSBufferedAsyncClient。

否。實作適用於 Java 的 AmazonSQSBufferedAsyncClient 時，會將它當成現有 AmazonSQSAsyncClient 的淺顯替代品。

如果您更新應用程式以使用最新的 AWS 開發套件，並變更用戶端以使用適用於 Java 的 AmazonSQSBufferedAsyncClient 來代替 AmazonSQSAsyncClient，您的應用程式將獲得自動批次處理和預先擷取功能所帶來的額外優勢。

1. 在 Amazon SQS 主控台中，選取一個 Amazon SQS 標準佇列。
2. 從 Queue Actions 的下拉式清單中選取 Subscribe Queue to SNS Topic。
3. 在對話方塊中，從 Choose a Topic 下拉式清單中選擇主題，然後按一下 Subscribe。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的訂閱佇列到 Amazon SNS 主題。

是。您可以使用 PurgeQueue 動作刪除 Amazon SQS 訊息佇列中的所有訊息。

當您清除訊息佇列時，所有之前傳送到訊息佇列的訊息都將刪除。由於您的佇列及其屬性都將保留下來，因此不需要重新設定訊息佇列；您可以繼續使用它。

如果只想刪除特定的訊息，可以使用 DeleteMessage 或 DeleteMessageBatch 動作。

如需詳細資訊，請參閱這個教學：從 Amazon SQS 佇列清除訊息。

FIFO 佇列可在提供 Amazon SQS 的所有 AWS 區域使用。如需 Amazon SQS 區域可用性的詳細資訊，請參閱這裡。

FIFO 佇列的設計永遠不會出現重複的訊息。不過，訊息生產者可能會在某些情況下放入重複項目：例如，如果生產者傳送一則訊息，但沒有收到回應，然後重新傳送相同的訊息。Amazon SQS API 提供重複資料刪除功能，可避免您的訊息生產者傳送重複的訊息。訊息生產者引入的任何重複項目都會在 5 分鐘的重複資料刪除間隔內移除。

對於標準佇列，您可能偶爾會收到重複的訊息副本 (至少交付一次)。如果您使用標準佇列，必須將應用程式設計為等冪 (也就是說，如果它處理相同的訊息超過一次以上，必須不受負面影響)。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的確切的一次性處理。

無。Amazon SQS 標準佇列 (現有佇列的全新名稱) 保持不變，而且您仍然可以建立標準佇列。這些佇列會持續提供最高的擴展性和輸送量；但無法保證順序的正確性，且可能收到重複的訊息。

標準佇列適用於許多案例，像是有多個等冪消費者的工作分發。

否。您必須在建立時選擇佇列類型。不過，還是有方法可以轉換成 FIFO 佇列。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的從標準佇列移到 FIFO 佇列。

要利用 FIFO 佇列功能，您必須使用最新的 AWS 開發套件。

FIFO 佇列使用與標準佇列相同的 API 動作，而且接收和刪除訊息以及變更可見性逾時的機制都一樣。不過，傳送訊息時，您必須指定訊息群組 ID。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 FIFO 佇列邏輯。

FIFO 佇列支援標準佇列支援的所有指標。對於 FIFO 佇列，所有近似值指標都會傳回正確的計數。例如，支援下列 AWS CloudWatch 指標：

• ApproximateNumberOfMessagesDelayed – 佇列中延遲且無法立即讀取的訊息數。
• ApproximateNumberOfMessagesVisible – 可從佇列擷取的訊息數。
• ApproximateNumberOfMessagesNotVisible – 傳輸中的訊息數 (傳送到用戶端但尚未刪除或可見性時段尚未結束)。

訊息在 FIFO 佇列內會按照順序組成不同的「服務包」。每個訊息群組 ID 中的所有訊息都以嚴格的順序傳送和接收。但若訊息群組 ID 的值不同，便可能不會按照順序來傳送和接收訊息。請務必在訊息群組 ID 與訊息之間建立關聯性。如果沒有提供訊息群組 ID，動作就會失敗。

如果多個主機 (或相同主機的不同執行緒) 將擁有相同訊息群組 ID 的訊息傳送到 FIFO 佇列，Amazon SQS 會以這些訊息抵達進行處理的順序交付訊息。為了確保 Amazon SQS 維持訊息傳送和接收的順序，請確定多個寄件者以唯一的訊息群組 ID 傳送每個訊息。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 FIFO 佇列邏輯。

是。一或多個生產者可以傳送訊息到 FIFO 佇列。系統會依照 Amazon SQS 成功接收訊息的順序存放訊息。

如果多個生產者同時傳送訊息，且未等待 SendMessage 或 SendMessageBatch 動作的成功回應，則可能不會保留生產者間的順序。SendMessage 或 SendMessageBatch 動作的回應包含 FIFO 佇列用來將訊息放到佇列的最終順序序列，所以您的多個平行生產者代碼可判斷佇列中訊息的最後順序。

Amazon SQS FIFO 佇列的設計不會將來自相同訊息群組的訊息一次傳送到多個消費者。但如果 FIFO 佇列有多個訊息群組，就可以利用平行消費者，允許 Amazon SQS 將不同訊息群組的訊息傳送到不同消費者。

根據預設，FIFO 佇列每秒支援高達 3,000 則使用批次功能的訊息，或者每秒高達 300 則未使用批次功能的訊息 (每秒 300 次傳送、接收或刪除操作)。如果需要更高輸送量，則可在 Amazon SQS 主控台上為 FIFO 啟用高輸送量模式，非批次處理時每秒支援最多 70,000 則訊息，批次處理時則更高。如需每個區域的 FIFO 高輸送量模式配額明細，請參閱 AWS 文件。

FIFO 佇列的名稱結尾必須是 .fifo 尾碼。這個尾碼算在佇列名稱的 80 個字元限制內。若要確認佇列是否是 FIFO，您可檢視佇列名稱是否以尾碼結尾。

Amazon SQS 會將所有訊息佇列和訊息存放在一個高度可用、包含多個冗餘可用區域 (AZ) 的 AWS 區域，這樣單一電腦、網路或 AZ 的故障就不會導致無法存取訊息。如需詳細資訊，請參閱 Amazon Relational Database Service 使用者指南中的區域與可用區域。

身份驗證機制可確保存放在 Amazon SQS 訊息佇列中的訊息受到保護，不受未經授權的存取。您可以控制誰能傳送訊息到訊息佇列，以及誰可以從訊息佇列接收訊息。如需增加安全性，您可以建置應用程式，將訊息加密後再放入訊息佇列中。

Amazon SQS 本身有以資源為基礎的許可系統，該系統使用的政策編寫語言與 AWS Identity and Access Management (IAM) 政策相同：例如，您可以使用變數，就像在 IAM 政策中一樣。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 Amazon SQS 政策範例。

Amazon SQS 支援透過 SSL (HTTPS) 連接 HTTP 和 Transport Layer Security (TLS) 協定。大部分用戶端會自動協調以使用較新版的 TLS，而不用變更任何程式碼或組態。Amazon SQS 在所有區域中都支援版本 1.0、1.1 和 1.2 的 Transport Layer Security (TLS) 協定。

Amazon SQS 傳回訊息給您時，無論您實際上是否收到該訊息，該訊息都保存在訊息佇列中。您要負責刪除該訊息，而刪除請求可確認您已處理了該訊息。

如果您不刪除訊息，Amazon SQS 將在收到另一個接收請求時再次遞送該訊息。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的可見性逾時。

否。FIFO 佇列不會有重複的訊息。

至於標準佇列，在極少數情形下，您可能會再次收到之前刪除的訊息。 

對之前已刪除的訊息發出 DeleteMessage 請求時，Amazon SQS 會傳回一個 success 回應。

SSE 可讓您在加密佇列中傳輸敏感資料。SSE 使用 AWS Key Management Service (AWS KMS) 中受管金鑰保護 Amazon SQS 佇列中的訊息內容。SSE 在 Amazon SQS 一收到訊息時立刻加密。訊息以加密格式存放，而 Amazon SQS 只會在訊息傳送給授權的取用者時才會解密訊息。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 使用伺服器端的加密 (SSE) 與 AWS KMS 來保護資料。

是。若要執行此操作，您需要啟用 AWS 服務 (例如 Amazon CloudWatch Events、Amazon S3 與 Amazon SNS) 與使用 SSE 的佇列之間的相容性。如需詳細說明，請參閱 SQS 開發人員指南中的相容性部分。 

Amazon SQS 的伺服器端加密 (SSE) 可在所有提供 Amazon SQS 的 AWS 區域使用。如需 Amazon SQS 區域可用性的詳細資訊，請參閱這裡。

若要使用 Amazon SQS API 為新的或現有佇列啟用 SSE，請透過設定 CreateQueue 或 SetQueueAttributes 動作的 KmsMasterKeyId 屬性來指定客戶主金鑰 (CMK) ID：AWS 受管 CMK 或自訂 CMK 的別名、別名 ARN、金鑰 ID 或金鑰 ARN。

如需詳細指示，請參閱 Amazon SQS 開發人員指南中的使用伺服器端加密建立 Amazon SQS 佇列和為現有 Amazon SQS 佇列設定伺服器端加密 (SSE)。

標準佇列和 FIFO 佇列都支援 SSE。

您必須先設定 AWS KMS 金鑰政策允許加密佇列及加密和解密訊息，才可以使用 SSE。

若要為佇列啟用 SSE，您可以為 Amazon SQS 使用 AWS 受管客戶主金鑰 (CMK) 或自訂 CMK。如需詳細資訊，請參閱 AWS KMS 開發人員指南中的客戶主要金鑰。

若要將訊息傳送至加密佇列，生產者必須擁有 CMK 的 kms:GenerateDataKey 和 kms:Decrypt 許可。

若要從加密佇列收到訊息，取用者必須擁有用來加密指定佇列中訊息的任何 CMK 的 kms:Decrypt 許可。如果佇列是無效字母佇列，取用者也必須有用來加密來源佇列中訊息的任何 CMK 的 kms:Decrypt 許可。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的我需要哪些許可才能使用 SSE？。

無須支付額外的 Amazon SQS 費用。不過，從 Amazon SQS 呼叫 AWS KMS 需要付費。如需詳細資訊，請參閱 AWS Key Management Service 定價。

使用 AWS KMS 的費用取決於為佇列設定的資料金鑰重複使用期間。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的如何評估我的 AWS KMS 用量成本？

SSE 會加密 Amazon SQS 佇列中訊息的內文。

SSE 不會加密下列元件：

• 佇列中繼資料 (佇列名稱和屬性)
• 訊息中繼資料 (訊息 ID、時間戳記和屬性)
• 每佇列指標

Amazon SQS 會根據 Amazon SQS 的 AWS 受管客戶主金鑰 (CMK) 或自訂 CMK 產生資料金鑰，提供可設定時間期間 (從 1 分鐘到 24 小時) 的封套加密和訊息解密。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 SSE for Amazon SQS 會加密哪些項目？。

SSE 使用 AES-GCM 256 演算法。

SSE 不會限制 Amazon SQS 的輸送量 (TPS)。您可以建立的 SSE 佇列數受到下列限制：

• 資料金鑰重複使用期間 (1 分鐘到 24 小時)。
• AWS KMS 每帳戶配額 (預設為 100 個 TPS)。
• 存取佇列的 IAM 使用者數或帳戶數。
• 大量積存 (更大量的積存需要更多 AWS KMS 呼叫)。

例如，我們假設下列情況：

• 您將資料金鑰重複使用期間設定為 5 分鐘 (300 秒)。
• 您的 KMS 帳戶預設 AWS KMS TPS 配額為 100 個 TPS。
• 您使用的 Amazon SQS 佇列沒有積存，而且有 1 位 IAM 使用者對所有佇列執行 SendMessage 或 ReceiveMessage 動作。

在這個案例中，可以計算使用 SSE 在理論上的最大 Amazon SQS 佇列數：

300 秒 × 100 個 TPS/1 位 IAM 使用者 = 30,000 個佇列

若要預估 AWS 帳單的費用並更清楚地了解帳單明細，您需要知道 Amazon SQS 使用 CMK 的頻率。

注意：雖然下列公式可讓您清楚理解預估的費用，但是由於 Amazon SQS 的分散式性質，實際費用可能更高。

若要計算每佇列的 API 請求數 (R)，請使用下列公式：

R = B / D * (2 * P + C)

B 是計費期間 (以秒為單位)

D 是資料金鑰重複使用期間 (以秒為單位)

P 是傳送到 Amazon SQS 佇列的生產主體數目。

C 是從 Amazon SQS 佇列接收的取用主體數。

重要：一般而言，生產主體會產生取用主體兩倍的費用。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的資料金鑰重複使用期間如何運作？。

如果生產者和取用者有不同的 IAM 使用者，費用會增加。

如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的如何評估我的 AWS KMS 用量成本？

是。Amazon SQS 已經過 PCI DSS 第 1 級認證。如需詳細資訊，請參閱 PCI 合規。

是，AWS 已經擴展其 HIPAA 合規計劃，將 Amazon SQS 納入 HIPAA 合格服務。如果您擁有與 AWS 共同履行的商業夥伴協議 (BAA)，可以使用 Amazon SQS 建立 HIPAA 合規應用程式、存放傳輸中的訊息和傳輸訊息 (包括內含受保護醫療資訊 (PHI) 的訊息)。

如果已經擁有與 AWS 共同履行的 BAA，則可立即開始使用 Amazon SQS。如果沒有 BAA 或對在 HIPAA 合規應用程式使用 AWS 有任何問題，請聯絡我們以取得詳細資訊。

注意：如果您不想透過 Amazon SQS 傳輸 PHI (或者您的訊息大於 256 KB)，可改為使用適用於 Java 的 Amazon SQS Extended Client Library 透過 Amazon S3 傳送 Amazon SQS 訊息承載 (Amazon S3 是 HIPAA 合格服務，不包含使用 Amazon S3 Transfer Acceleration)。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的適用於 Java 的 Amazon SQS 擴充用戶端程式庫。

較長的訊息保留期可提供更大的靈活性，允許在訊息產生和消耗之間有更長的間隔。

Amazon SQS 訊息保留期值的設定範圍為 1 分鐘到 14 天。預設值是 4 天。達到訊息保留配額之後，就會自動刪除您的訊息。

要設定訊息保留期，請使用主控台或使用 Distributiveness 方法設定 MessageRetentionPeriod 屬性。使用此屬性指定 Amazon SQS 保留訊息的秒數。

您可以使用 MessageRetentionPeriod 屬性，將訊息保留期設定為 60 秒 (1 分鐘) 到最長 1,209,600 秒 (14 天)。如需使用此訊息屬性的詳細資訊，請參閱 Amazon SQS API 參考。

要設定最大訊息大小，請使用主控台或 SetQueueAttributes 方法設定 MaximumMessageSize 屬性。 此屬性指定 Amazon SQS 訊息可以包含的位元組數量。將此屬性設定為 1,024 位元組 (1 KB) 到 262,144 位元組 (256 KB) 之間的值。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的使用 Amazon SQS 訊息屬性。

若要傳送大於 256 KB 的訊息，可以使用適用於 Java 的 Amazon SQS 擴充用戶端程式庫。此程式庫可讓您傳送 Amazon SQS 訊息，其中包含 Amazon S3 訊息承載的參考，大小可達 2 GB。

Amazon SQS 訊息可包含最多 256 KB 的文字資料，包括 XML、JSON 和無格式文字。接受以下 Unicode 字元：

#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #x10FFFF]

如需詳細資訊，請參閱 XML 1.0 規格。

單一 Amazon SQS 訊息佇列可以包含無限則訊息。不過，標準佇列的傳輸中訊息數量配額為 120,000，而 FIFO 佇列為 20,000。訊息會在從佇列接收後但尚未從佇列刪除時，由使用的元件傳遞。

您可以建立任意數量的訊息佇列。

佇列名稱限制為 80 個字元。

您可以使用英數字元、連字號 (-) 和底線 (_)。

訊息佇列名稱在 AWS 帳戶和區域中必須是唯一的。您可以刪除訊息佇列之後，重新使用該名稱。

您可以建立存取政策陳述式 (和指定要授予的許可) 與共用訊息佇列的關聯。Amazon SQS 提供建立和管理存取政策陳述式的 API：

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

如需詳細資訊，請參閱 Amazon SQS API 參考。

訊息佇列擁有者負責支付共用訊息佇列存取的費用。

Amazon SQS API 使用 AWS 帳號識別 AWS 使用者。

要與 AWS 使用者共用訊息佇列時，請提供要共用之訊息佇列的完整 URL。CreateQueue 和 ListQueues 操作會在回應中傳回此 URL。

是。您可以設定允許匿名使用者存取訊息佇列的存取政策。

Permissions API 對開發人員提供一個共用訊息佇列存取權的界面。不過，這個 API 不允許有條件存取和更為進階的使用案例。

SetQueueAttributes 操作支援完整的存取原則語言。例如，您可以使用政策語言，依 IP 地址和時間對訊息佇列的存取進行限制。如需詳細資訊，請參閱 Amazon SQS 開發人員指南中的 Amazon SQS 政策範例。

對於提供服務的區域，請參閱 AWS 全球基礎設施區域表。

否。每個區域中的 Amazon SQS 訊息佇列都是各自獨立的。

Amazon SQS 的定價在所有區域都一致，僅中國 (北京) 例外。如需詳細資訊，請參閱 Amazon SQS 定價。

您可以在單一區域內的 Amazon SQS 與 Amazon EC2 或 AWS Lambda 之間免費傳輸資料。

在不同區域的 Amazon SQS 與 Amazon EC2 或 AWS Lambda 之間傳輸資料時，會向您收取標準的資料傳輸費。如需詳細資訊，請參閱 Amazon SQS 定價。

無法寄出信件佇列是一個 Amazon SQS 佇列，如果來源佇列的使用者應用程式無法成功使用訊息，來源佇列可以將訊息傳送到該佇列。無法寄出信件佇列可讓您更輕鬆地處理訊息取用失敗，並管理未取用訊息的生命週期。您可以為傳遞到無法寄出信件佇列的任何訊息設定警報，檢查可能導致它們傳遞到佇列的異常的日誌，並分析訊息內容以診斷消費者應用程式問題。恢復消費者應用程式後，您可以將訊息從無法寄出信件佇列重新驅動到來源佇列。

建立來源佇列時，Amazon SQS 可讓您指定無法寄出信件佇列 (DLQ) 以及 SQS 應將訊息移動到 DLQ 的條件。條件是消費者可以從佇列接收訊息的次數，定義為 maxReceiveCount。帶有來源佇列和 maxReceiveCount 的無法寄出信件佇列的這種組態稱為重新驅動政策。當訊息的 ReceiveCount 超過佇列的 maxReceiveCount 時，Amazon SQS 旨在將訊息移至無法寄出信件佇列 (使用其原始訊息 ID)。例如，如果來源佇列的重新驅動政策將 maxReceiveCount 設定為 5，並且來源佇列的使用者收到一則訊息 6 次但沒有成功取用它，則 SQS 會將訊息移至無法寄出信件佇列。

重新驅動政策透過將訊息從來源佇列移動到無法寄出信件佇列來管理未使用訊息生命週期的前半部分。現在無法寄出信件佇列重新驅動到來源佇列透過將這些訊息移回來源佇列來有效地完成循環，如下所示。

首先，它可讓您透過顯示訊息屬性和相關中繼資料來調查無法寄出信件佇列中可用的訊息範例。然後，一旦您調查了這些訊息，您就可以將其移回來源佇列。您還可以選擇重新驅動速度來設定 Amazon SQS 將訊息從無法寄出信件佇列移動到來源佇列的速率。

是。不過，在 FIFO 佇列必須使用 FIFO 無效字母佇列。(同樣地，在標準佇列只能使用標準無效字母佇列。)