Amazon SQS FAQ

요금은 사용량에 따라 지불하고 최소 요금이 없습니다.

Amazon SQS 비용은 요청당 계산되며 Amazon SQS 외부로 전송된 데이터에 대한 데이터 전송 요금이 추가됩니다(데이터가 Amazon Elastic Compute Cloud(EC2) 인스턴스 또는 동일한 리전 내의 AWS Lambda 함수로 전송되지 않는 경우). 대기열 유형과 리전에 따른 자세한 가격 체계는 Amazon SQS 요금을 참조하세요.

Amazon SQS 프리 티어는 매월 1백만 건의 요청을 무료로 제공합니다.

규모가 작은 애플리케이션 대부분은 프리 티어 한도 내에서 모두 운영할 수 있습니다. 하지만 데이터 전송 요금은 계속 부과될 수 있습니다. 자세한 정보는 Amazon SQS 요금을 참조하세요.

프리 티어는 월간 서비스입니다. 무료 사용량은 월별로 누적되지 않습니다.

예, 프리 티어를 초과하는 모든 요청에 요금이 부과됩니다. 모든 Amazon SQS 요청에 요금이 부과되며, 모든 요청은 같은 요율로 청구됩니다.

배치 작업(SendMessageBatch, DeleteMessageBatch 및 ChangeMessageVisibilityBatch)의 모든 요금은 다른 Amazon SQS 요청과 동일합니다. 메시지를 배치로 그룹화함으로써 Amazon SQS 비용을 줄일 수 있습니다.

Amazon SQS 사용을 시작하는 데는 초기 비용이 들지 않습니다. 월말에 사용자의 신용 카드에서 월 사용액이 자동으로 결제됩니다.

언제든지 AWS 웹 사이트에서 현재 청구 기간에 대한 요금을 확인할 수 있습니다.

1. AWS 계정으로 로그인합니다.
2. 웹 서비스 계정에서 계정 활동을 선택합니다.

비용 할당 태그를 사용하여 대기열에 태그를 지정하고 추적하여 리소스 및 비용을 관리할 수 있습니다. 태그는 키 값 페어로 구성된 메타데이터 레이블입니다. 예를 들어 대기열에 비용 센터별 태그를 지정하고 이러한 비용 센터를 기준으로 비용을 분류 및 추적할 수 있습니다.

자세한 내용은 Amazon SQS 개발자 안내서에서 Amazon SQS 대기열에 태그 지정을 참조하십시오. AWS 리소스의 비용 할당 태깅에 대한 자세한 내용은 AWS Billing and Cost Management 사용 설명서에서 비용 할당 태그를 참조하십시오.

달리 명시하지 않는 한 요금에는 VAT 또는 해당 판매세를 비롯한 관련 조세 공가가 포함되지 않습니다.

청구지 주소가 일본으로 되어 있는 고객의 경우, 리전과 관계없이 AWS 사용 시 일본 소비세가 적용됩니다. 자세한 내용은 Amazon Web Services 소비세 FAQ를 참조하세요.

예. Amazon EC2, Amazon Elastic Container Service(ECS), AWS Lambda와 같은 컴퓨팅 서비스는 물론 Amazon Simple Storage Service(Amazon S3) 및 Amazon DynamoDB와 같은 스토리지 및 데이터베이스 서비스와 함께 Amazon SQS를 사용하여 애플리케이션을 보다 유연하고 확장 가능하게 만들 수 있습니다.

Amazon SQS 대기열을 손쉽게 생성하고 메시지를 전송하는 데 유용한 AWS Management Console을 사용하여 Amazon SQS에 액세스할 수 있습니다.

Amazon SQS는 웹 서비스 API도 제공합니다. 이 또한 AWS SDK와 통합되므로 원하는 프로그래밍 언어로 작업할 수 있습니다.

메시지 대기열 작업에 대한 자세한 정보는 Amazon SQS API 참조를 참조하세요.

AWS 계정 소유자만(또는 계정 소유자가 권한을 위임한 AWS 계정) Amazon SQS 메시지 대기열에 대한 작업을 수행할 수 있습니다.

예. 자체 JMS 클러스터를 실행하는 부담과 높은 오버헤드 없이 Amazon SQS의 규모, 저렴한 비용 및 높은 가용성을 활용할 수 있습니다. 

Amazon에서는 JMS 1.1 사양을 구현하고 Amazon SQS를 JMS 공급자로서 사용하는 Amazon SQS Java 메시징 라이브러리를 제공합니다. 자세한 정보는 Amazon SQS 개발자 안내서의 JMS 및 Amazon SQS 사용 섹션을 참조하세요.

Java 메시지 서비스(JMS)

모든 메시지에는 메시지가 메시지 대기열로 전송될 때 Amazon SQS가 반환하는 전 세계적으로 고유한 ID가 있습니다. 이 ID는 메시지에 추가 작업을 수행할 때는 필요 없지만, 메시지 대기열에서 특정 메시지의 수신을 추적할 때는 유용합니다.

메시지 대기열에서 메시지를 수신할 때 응답에는 메시지 삭제 시 꼭 필요한 수신 핸들이 포함됩니다.

자세한 내용은 Amazon SQS 개발자 안내서의 대기열 및 메시지 식별자 섹션을 참조하세요.

Amazon SQS에서는 API 또는 콘솔을 사용하여 배달 못한 편지 대기열을 구성할 수 있습니다. 배달 못한 편지 대기열은 다른 소스 대기열에서 메시지를 수신합니다. 배달 못한 편지 대기열을 구성할 때는 RedriveAllowPolicy를 사용하여 배달 못한 편지 대기열의 재구동을 위한 적절한 권한을 설정해야 합니다.

RedriveAllowPolicy에는 배달 못한 편지 대기열 재구동 권한을 위한 파라미터가 포함되어 있습니다. 이 파라미터는 배달 못한 편지 대기열을 JSON 객체로 지정할 수 있는 소스 대기열을 정의합니다.

배달 못한 편지 대기열을 만들면 배달 못한 편지 대기열에서 최대 처리 시도 횟수를 완료할 수 없게 된 후에 메시지를 수신합니다. 이후 분석을 위해 배달 못한 편지 대기열을 사용하여 처리되지 못한 메시지를 격리할 수 있습니다.

자세한 내용은 Amazon SQS 개발자 안내서에서 Amazon SQS DLQ(Dead Letter Queue) 사용을 참조하세요.

제한 시간 초과는 Amazon SQS가 메시지를 소비하는 다른 구성 요소에서 메시지를 수신 및 처리하지 못하도록 하는 기간입니다. 자세한 내용은 Amazon SQS 개발자 안내서의 가시성 제한 시간 섹션을 참조하세요.

예. Amazon SQS는 메시지는 최대 10개의 메타데이터 속성을 포함할 수 있습니다. 메시지 속성을 사용하여 메시지를 설명하는 메타데이터에서 메시지의 본문을 분리할 수 있습니다. 이렇게 하면 애플리케이션이 메시지를 어떻게 처리할지 파악하기 전에 전체 메시지를 검사할 필요가 없으므로 정보를 더욱 빠르고 효율적으로 처리하고 저장할 수 있습니다.

Amazon SQS 메시지 속성은 이름-유형-값이라는 3개 부분으로 이루어진 형식을 갖추고 있습니다. 지원되는 유형에는 문자열, 바이너리 및 숫자(정수, 부동 소수점 및 실수 포함)가 포함됩니다. 자세한 내용은 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 짧은 폴링보다 긴 폴링을 사용하는 것이 좋습니다. 긴 폴링 요청을 사용하면 대기열 소비자가 대기열에 메시지가 도착하는 대로 이를 수신할 수 있으므로 빈 ReceiveMessageResponse 인스턴스가 반환되는 횟수가 줄어듭니다.

Amazon SQS 긴 폴링은 대부분의 사용 사례에서 비용은 감소하고 성능은 향상되는 결과를 보입니다. 하지만 애플리케이션이 ReceiveMessage 호출에서 즉각적인 응답을 요구하는 경우, 긴 폴링의 이점을 활용하려면 애플리케이션을 일부 수정해야 할 수도 있습니다.

예를 들어 애플리케이션에서 단일 스레드를 사용하여 여러 대기열을 폴링하는 경우, 단일 스레드는 빈 대기열에 대한 긴 폴링의 제한 시간이 끝나기를 기다리게 됩니다. 이로 인해 짧은 폴링에서 긴 폴링으로의 전환이 제대로 수행되지 않아 실제로 메시지가 들어 있는 대기열의 처리가 지연될 수 있습니다.

이러한 애플리케이션에서는 단일 스레드로 하나의 대기열만 처리하여 애플리케이션이 Amazon SQS 긴 폴링이 제공하는 이점을 활용하도록 하는 것이 좋습니다.

일반적으로 최대 20초의 긴 폴링 제한 시간을 사용해야 합니다. 긴 폴링 제한 시간 값이 클수록 빈 ReceiveMessageResponse 인스턴스가 반환되는 빈도가 감소하므로 긴 폴링 제한 시간을 가능한 한 길게 설정하는 것이 좋습니다.

최댓값인 20초가 사용자의 애플리케이션에 적합하지 않은 경우(이전 질문의 예제 참조), 긴 폴링 제한 시간을 더 짧게 설정하십시오(최하 1초).

모든 AWS SDK는 기본적으로 20초의 긴 폴링으로 작동됩니다. Amazon SQS에 액세스하는 데 AWS SDK를 사용하지 않거나 AWS SDK의 제한 시간을 특별히 더 짧게 구성한 경우, 더 긴 요청을 허용하도록 Amazon SQS 클라이언트를 수정하거나 더 짧은 긴 폴링 제한 시간을 사용해야 할 수도 있습니다.

Java용 AmazonSQSBufferedAsyncClient는 AmazonSQSAsyncClient 인터페이스의 구현을 제공하고 몇 가지 중요한 기능을 추가로 제공합니다.

• 애플리케이션을 변경할 필요 없이 여러 개의 SendMessage, DeleteMessage 또는 ChangeMessageVisibility 요청을 자동 배치
• 애플리케이션이 Amazon SQS에서 메시지가 검색될 때까지 기다리지 않고 메시지를 즉시 처리할 수 있도록 로컬 버퍼로 메시지를 프리페치

자동 배치와 프리페치를 함께 사용하면 Amazon SQS 요청 빈도를 줄여 비용을 절감하면서 애플리케이션의 처리량을 높이고 지연 시간은 줄일 수 있습니다. 자세한 내용은 Amazon SQS 개발자 안내서의 클라이언트 측 버퍼링 및 요청 일괄 처리 섹션을 참조하세요.

AmazonSQSBufferedAsyncClient는 AWS SDK for Java의 일부로서 다운로드할 수 있습니다.

아니요. Java용 AmazonSQSBufferedAsyncClient는 기존 AmazonSQSAsyncClient를 즉시 대체할 수 있도록 구현되었습니다.

최신 AWS SDK를 사용하도록 애플리케이션을 업데이트하고 AmazonSQSAsyncClient 대신 Java용 AmazonSQSBufferedAsyncClient를 사용하도록 클라이언트를 변경하면 애플리케이션에서 자동 배치 및 프리페치라는 추가적인 혜택을 받게 됩니다.

1. Amazon SQS 콘솔에서 [Amazon SQS standard queue]를 선택합니다.
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분 간격의 중복 제거 기간 내에 제거됩니다.

표준 대기열의 경우, 메시지의 중복 사본을 수신할 수 있습니다(최소 1회 전달). 표준 대기열을 사용하는 경우, 애플리케이션을 idempotent(즉, 같은 메시지를 여러 번 처리하더라도 부정적인 영향을 미쳐서는 안 됨) 방식으로 설계해야 합니다.

자세한 내용은 Amazon SQS 개발자 안내서의 정확히 1회 처리 섹션을 참조하세요.

Amazon SQS 표준 대기열(기존 대기열의 새 이름)은 바뀌지 않았고 여전히 표준 대기열을 생성할 수 있습니다. 이 대기열은 최고의 확장성과 처리량을 계속 제공합니다. 다만 순서화는 보장할 수 없고 중복이 발생할 수 있습니다.

표준 대기열은 여러 idempotent 소비자에 대한 작업 배포 같은 여러 시나리오에 적합합니다.

아니요. 대기열을 만들 때 대기열 유형을 선택해야 합니다. 단, FIFO 대기열로 이동하는 것은 가능합니다. 자세한 내용은 Amazon SQS 개발자 안내서의 표준 대기열에서 FIFO 대기열로 이동을 참조하세요.

FIFO 대기열 기능을 활용하려면 최신 AWS SDK를 사용해야 합니다.

FIFO 대기열은 표준 대기열과 동일한 API 동작을 사용하며, 메시지 수신 및 삭제와 제한 시간 초과 변경 메커니즘은 동일합니다. 다만 메시지를 보낼 때는 메시지 그룹 ID를 지정해야 합니다. 자세한 내용은 Amazon SQS 개발자 안내서의 FIFO 대기열 로직을 참조하세요.

FIFO 대기열은 표준 대기열이 지원하는 모든 지표를 지원합니다. FIFO 대기열의 경우, 모든 근사 지표가 정확한 개수를 반환합니다. 예를 들어 다음 AWS CloudWatch 측정치가 지원됩니다.

• ApproximateNumberOfMessagesDelayed – 대기열 중 지연되고 즉시 읽기가 불가능한 메시지 수.
• ApproximateNumberOfMessagesVisible – 대기열로부터 검색이 가능한 메시지 수.
• ApproximateNumberOfMessagesNotVisible – inflight(클라이언트에게 전송되었지만 아직 삭제되지 않았거나 가시성 기간의 끝에 도달하지 않은) 메시지 수.

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를 위한 큰 처리량 모드를 활성화할 수 있습니다. 배치 처리를 사용하지 않는 경우 초당 최대 7만 개의 메시지를 지원하고 배치 처리를 사용하는 경우 그보다 더 많은 메시지를 지원할 수 있습니다. 리전별 FIFO 큰 처리량 모드 할당량에 대한 자세한 내용은 AWS 설명서를 참조하세요.

FIFO 대기열의 이름은 .fifo 접미사로 끝나야 합니다. 접미사는 80자 대기열 이름 제한에 포함됩니다. 대기열이 FIFO인지 알아보려면 대기열 이름이 접미사로 끝나는지 확인하면 됩니다.

Amazon SQS는 모든 메시지 대기열과 메시지를 가용성이 뛰어난 단일 AWS 리전 내 여러 중복 가용 영역(AZ)에 저장하므로 하나의 컴퓨터, 네트워크 또는 AZ에 장애가 발생하더라도 메시지에 액세스할 수 있습니다. 자세한 내용은 Amazon Relational Database Service 사용 설명서의 리전 및 가용 영역을 참조하세요.

인증 메커니즘이 갖추어져 있어 Amazon SQS 메시지 대기열에 저장된 메시지가 무단 액세스로부터 확실하게 보호됩니다. 메시지 대기열에 메시지를 전송할 수 있는 사용자와 메시지 대기열에서 메시지를 수신할 수 있는 사용자를 제어할 수 있습니다. 보안 강화를 위해 애플리케이션이 메시지를 대기열에 올리기 전에 암호화하도록 구성할 수도 있습니다.

Amazon SQS는 자체 리소스 기반 권한 시스템을 갖추고 있으며 이 시스템은 AWS Identity and Access Management(IAM) 정책에서와 같은 언어로 작성된 정책을 사용합니다. 즉, 예를 들어 IAM 정책에서 사용하는 것처럼 변수를 사용할 수 있습니다. 자세한 내용은 Amazon SQS 개발자 안내서의 Amazon SQS 정책 예제를 참조하세요.

Amazon SQS는 HTTPS(HTTP over SSL)와 TLS(전송 계층 보안)를 지원합니다. 대부분 클라이언트는 코드 또는 구성 변경 없이 최신 버전의 TLS를 사용하도록 자동으로 조정할 수 있습니다. Amazon SQS는 모든 리전에서 TLS(전송 계층 보안) 프로토콜 버전 1.0, 1.1 및 1.2를 지원합니다.

Amazon SQS는 메시지를 반환할 때 사용자가 실제로 이 메시지를 수신했는지에 상관없이 해당 메시지를 메시지 대기열에 그대로 보관합니다. 메시지 삭제는 사용자의 책임입니다. 삭제 요청이 있으면 사용자가 메시지를 처리한 것으로 간주됩니다.

메시지를 삭제하지 않으면 다른 수신 요청을 받을 때 Amazon SQS가 해당 메시지를 다시 전송합니다. 자세한 내용은 Amazon SQS 개발자 안내서의 가시성 제한 시간 섹션을 참조하세요.

아니요. FIFO 대기열에는 중복 메시지가 절대 유입되지 않습니다.

표준 대기열의 경우, 드문 경우지만 이전에 삭제한 메시지를 한 번 더 수신할 수도 있습니다. 

이전에 삭제한 메시지에 대해 DeleteMessage 요청을 발행하면 Amazon SQS에서 성공 응답을 반환합니다.

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가 제공되는 모든 리전에서 사용할 수 있습니다. Amazon SQS 리전 가용성에 대한 자세한 정보는 여기를 참조하세요.

Amazon SQS API를 사용하여 새로운 또는 기존 Amazon SQS 대기열에 SSE를 활성화하려면, CreateQueue 또는 SetQueueAttributes 작업의 KmsMasterKeyId 속성을 설정하여 고객 마스터 키(CMK) ID, 즉 AWS 관리형 CMK 또는 사용자 지정 CMK의 별칭, 별칭 ARN, 키 ID 또는 키 ARN을 지정합니다.

세부 지침은 Amazon SQS 개발자 가이드에서 서버 측 암호화를 사용하여 Amazon SQS 대기열 생성 섹션 및 기존 Amazon SQS 대기열에 대해 서버 측 암호화(SSE) 구성 섹션을 참조하세요.

표준 대기열과 FIFO 대기열 모두 SSE를 지원합니다.

SSE를 사용할 수 있으려면, 대기열 암호화와 메시지 암호화 및 복호화를 허용하도록 AWS KMS 키 정책을 구성해야 합니다.

대기열에 대한 SSE를 활성화하려면 Amazon SQS용 AWS 관리형 고객 마스터 키(CMK) 또는 사용자 지정 CMK를 사용하면 됩니다. 자세한 내용은 AWS KMS 개발자 안내서에서 고객 마스터 키 섹션을 참조하세요.

암호화된 대기열로 메시지를 전송하려면, 생산자가 CMK에 대한 kms:GenerateDataKey 및 kms:Decrypt 권한을 가지고 있어야 합니다.

암호화된 대기열에서 메시지를 수신하려면, 소비자가 지정된 대기열의 메시지를 암호화하는 데 사용된 CMK에 대한 kms:Decrypt 권한을 가지고 있어야 합니다. 대기열이 DLQ(Dead Letter Queue)의 역할을 하면, 소비자가 소스 대기열의 메시지를 암호화하는 데 사용된 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 개발자 안내서의 Amazon SQS용 SSE는 무엇을 암호화합니까? 섹션을 참조하세요.

SSE는 AES-GCM 256 알고리즘을 사용합니다.

SSE는 Amazon SQS의 처리량(TPS)을 제한하지 않습니다. 생성할 수 있는 SSE 대기열의 수는 다음 조건에 따라 제한됩니다.

• 데이터 키 재사용 기간(1분에서 24시간).
• 계정당 AWS KMS 할당량(기본값은 100TPS).
• 대기열에 액세스하는 IAM 사용자 또는 계정 수.
• 대규모 백로그가 존재(백로그가 크면 AWS KMS 호출 수가 증가함).

예를 들어 다음과 같이 가정해보겠습니다.

• 데이터 키 재사용 기간을 5분(300초)으로 설정합니다.
• KMS 계정의 AWS KMS TPS 할당량이 기본값인 100TPS로 설정되어 있습니다.
• 백로그가 없고 모든 대기열에 대한 SendMessage 또는 ReceiveMessage 작업에 대해 1명의 IAM 사용자가 있는 Amazon SQS 대기열을 사용합니다.

이 경우, SSE가 적용된 Amazon SQS 대기열의 이론적 최대 크기를 다음과 같이 계산할 수 있습니다.

300초 × 100TPS / IAM 사용자 1명 = 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는 Amazon SQS를 HIPAA 적격 서비스에 추가하도록 HIPAA 규정 준수 프로그램을 확장했습니다. AWS와 Business Associate Agreement(BAA)를 체결한 경우 Amazon SQS를 사용하여 HIPAA 규정 준수 애플리케이션을 빌드하고, 전송 중인 메시지를 저장하고, 메시지를 전송할 수 있습니다(개인 건강 정보(PHI)가 담긴 메시지 포함).

AWS와 이미 BAA를 체결한 경우 Amazon SQS를 즉시 사용할 수 있습니다. BAA가 없거나 HIPAA 규정 준수 애플리케이션에 AWS를 사용하는 방법에 대해 질문이 있는 경우 Amazon에 문의하여 자세히 알아보시기 바랍니다.

참고: Amazon SQS를 통해 PHI를 전송하고 싶지 않은 경우(또는 256KB보다 큰 메시지가 있는 경우), Amazon SQS Extended Client Library for Java를 사용하여 Amazon S3를 통해 Amazon SQS 메시지 페이로드를 전송할 수도 있습니다(Amazon S3 Transfer Acceleration 사용을 제외하고 Amazon S3는 HIPAA 적격 서비스입니다). 자세한 내용은 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바이트(1KB)와 262,144바이트(256KB) 사이의 값으로 설정합니다. 자세한 내용은 Amazon SQS 개발자 안내서의 Amazon SQS 메시지 속성 섹션을 참조하세요.

256KB보다 큰 메시지를 전송하려면 Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용합니다. 이 라이브러리를 사용하면 참조가 포함된 Amazon SQS 메시지를 최대 2GB까지 Amazon S3의 메시지 페이로드로 전송할 수 있습니다.

Amazon SQS 메시지는 XML, JSON, 서식 없는 텍스트 등의 텍스트 데이터를 최대 256KB까지 포함할 수 있습니다. 다음 Unicode 문자를 사용할 수 있습니다.

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

자세한 정보는 XML 1.0 사양을 참조하세요.

단일 Amazon SQS 메시지 대기열은 메시지를 무제한으로 포함할 수 있습니다. 그러나 표준 대기열의 경우 120,000개의 전송 메시지 수와 FIFO 대기열의 경우 20,000개의 할당량이 있습니다. 메시지를 사용하는 구성 요소가 대기열에서 메시지를 수신하였지만 메시지가 대기열에서 삭제되지 않으면 메시지는 inflight 상태가 됩니다.

원하는 만큼 메시지 대기열을 생성할 수 있습니다.

대기열 이름은 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 배달 못한 편지 대기열을 사용해야 합니다. (마찬가지로 하나의 표준 대기열과 함께 하나의 표준 배달 못한 편지 대기열만 사용할 수 있습니다.)