Amazon Simple Queue Service(SQS)편집자 확인

Amazon Simple Queue Service의 표준 큐는 무제한 처리량을 제공하는 기본 큐 유형이다. 메시지 전송 순서가 최선형(best-effort)으로 유지되며, 대부분의 경우 순차적 전달을 보장한다. 그러나 높은 처리량 환경에서는 메시지가 중복되거나 순서가 바뀔 수 있다. 이러한 특성은 마이크로서비스 아키텍처나 이벤트 기반 시스템에서 높은 확장성을 요구하는 애플리케이션에 적합하다.

표준 큐는 초당 거의 무제한에 가까운 트랜잭션을 지원하며, 메시지 보관 기간은 최대 14일이다. 가시성 제한 시간 동안 메시지가 처리되지 않으면 다시 큐에 표시되어 다른 소비자가 처리할 수 있다. 이는 메시지 손실을 방지하고 시스템의 신뢰성을 높이는 데 기여한다.

이 서비스는 완전관리형으로 제공되므로 사용자는 인프라 관리 없이 메시지 송수신에 집중할 수 있다. AWS 관리 콘솔, AWS SDK, 또는 AWS CLI를 통해 쉽게 통합하고 관리할 수 있다. 표준 큐는 애플리케이션 통합, 작업 큐, 이벤트 버스 등 다양한 사용 사례에 폭넓게 적용된다.

FIFO 큐는 메시지의 순서를 엄격하게 보장하고 중복 메시지 전송을 방지하는 Amazon Simple Queue Service의 큐 유형이다. 표준 큐가 높은 처리량을 제공하는 반면, FIFO 큐는 메시지가 전송된 순서대로 정확히 한 번 처리되는 것을 보장하는 데 중점을 둔다. 이는 금융 거래 처리, 주문 처리 시스템, 데이터베이스 업데이트와 같이 작업 순서가 매우 중요한 마이크로서비스 아키텍처나 분산 애플리케이션에서 필수적이다.

FIFO 큐는 메시지 그룹 ID와 메시지 중복 제거 ID라는 두 가지 핵심 개념을 기반으로 작동한다. 메시지 그룹 ID는 동일한 그룹에 속한 메시지들이 순서대로 처리되도록 하며, 서로 다른 그룹 간 메시지는 병렬로 처리될 수 있어 확장성을 유지한다. 메시지 중복 제거 ID는 5분의 중복 제거 간격 동안 동일한 메시지가 큐에 두 번 이상 들어오는 것을 방지하여 정확히 한 번 전송을 실현한다.

이 큐의 처리량은 표준 큐에 비해 제한적이다. 기본적으로 초당 최대 3,000개의 메시지를 전송할 수 있으며, 배치 처리를 사용하면 초당 최대 3,000개의 배치(최대 10개 메시지/배치) 또는 초당 최대 30,000개의 메시지를 처리할 수 있다. 이러한 처리량 제한은 메시지 순서와 중복 방지의 강력한 보장을 유지하기 위한 설계적 선택이다.

FIFO 큐는 데드 레터 큐와 통합되어 재처리 횟수를 초과한 메시지를 격리할 수 있으며, 가시성 제한 시간 설정을 통해 메시지 처리 시간을 관리할 수 있다. 이러한 특성 덕분에 이커머스 플랫폼의 주문 이행 파이프라인이나 회계 시스템의 거래 로그 처리와 같이 데이터 정확성과 순서가 생명인 사용 사례에서 널리 채택되고 있다.

지연 큐는 Amazon Simple Queue Service에서 제공하는 기능으로, 메시지가 큐에 전송된 후 일정 시간 동안 소비자에게 보이지 않도록 지연시키는 역할을 한다. 기본적으로 모든 표준 큐는 지연 기능을 지원하며, 지연 시간은 0초에서 최대 15분까지 설정할 수 있다. 이 기능은 메시지를 즉시 처리하지 않고 특정 시간 이후에 처리해야 하는 작업을 예약하거나, 일시적인 부하를 완화하는 데 유용하게 활용된다.

지연 시간은 큐 전체에 대한 기본 지연 시간으로 설정하거나, 개별 메시지를 전송할 때 메시지 수준에서 별도로 지정할 수 있다. 메시지 수준 지연 시간은 큐의 기본 지연 시간보다 우선 적용된다. 예를 들어, 큐의 기본 지연이 5분으로 설정되어 있어도, 특정 메시지를 전송할 때 지연 시간을 30초로 지정하면 해당 메시지만 30초 후에 가시화된다.

이 기능은 애플리케이션의 특정 구성 요소가 아직 준비되지 않았을 때 메시지 처리를 늦추거나, 일괄 처리 작업을 특정 시간에 시작하도록 스케줄링하는 등의 사용 사례에 적합하다. 또한, FIFO 큐에서는 지연 큐 기능을 사용할 수 없으며, 이는 메시지의 순서 보장과 지연 기능이 상충되기 때문이다.

데드 레터 큐는 Amazon Simple Queue Service에서 처리에 실패한 메시지를 격리하기 위한 보조 메시지 큐이다. 소스 큐에서 메시지가 여러 번 재시도되어도 소비자가 성공적으로 처리하지 못하면, 해당 메시지는 자동으로 데드 레터 큐로 이동한다. 이를 통해 문제가 있는 메시지가 원본 큐를 계속해서 차지하거나 애플리케이션 처리 흐름을 방해하는 것을 방지한다.

데드 레터 큐를 설정하려면 소스 큐의 리드라이브 수신 정책을 구성해야 한다. 이 정책에서는 메시지가 데드 레터 큐로 전달되기 전까지 소스 큐에서 수신을 시도할 최대 횟수를 지정한다. 또한 메시지를 수신할 데드 레터 큐의 Amazon Resource Name을 명시해야 한다. 이렇게 구성하면, 지정된 재시도 횟수를 초과한 메시지는 자동으로 지정된 데드 레터 큐로 전송되어 격리된다.

격리된 메시지는 데드 레터 큐에서 별도로 저장되며, 개발자나 운영자는 이 큐를 모니터링하여 처리 실패의 근본 원인을 분석할 수 있다. 예를 들어, 메시지 형식 오류, 처리 로직의 버그, 또는 의존성 서비스의 장애 등을 조사할 수 있다. 문제를 해결한 후에는 데드 레터 큐의 메시지를 다시 소스 큐로 보내거나 수동으로 처리할 수 있다.

데드 레터 큐의 사용은 애플리케이션의 견고성을 높이는 데 도움이 된다. 시스템의 주요 처리 흐름을 실패한 메시지로부터 보호하고, 디버깅과 문제 해결을 위한 명확한 지점을 제공한다. 이는 마이크로서비스 아키텍처나 이벤트 기반 시스템에서 특히 중요한 기능으로 평가받는다.

가시성 제한 시간은 Amazon Simple Queue Service에서 메시지를 처리하는 동안 다른 소비자가 해당 메시지를 다시 수신하지 못하도록 일시적으로 메시지를 잠그는 기능이다. 소비자가 큐에서 메시지를 가져오면, 메시지는 즉시 삭제되지 않고 일정 시간 동안 '가시성 제한 시간' 상태로 유지된다. 이 시간 동안에는 다른 소비자가 동일한 메시지를 가져올 수 없어, 메시지의 중복 처리를 방지한다.

이 제한 시간은 소비자가 메시지를 성공적으로 처리하고 큐에서 명시적으로 삭제할 수 있는 시간적 여유를 제공한다. 예를 들어, 메시지 처리에 시간이 오래 걸리는 작업이거나, 처리 중 오류가 발생하여 재시도가 필요한 경우에 유용하다. 기본 가시성 제한 시간은 30초로 설정되어 있으며, 필요에 따라 최대 12시간까지 조정할 수 있다.

소비자가 메시지 처리를 완료하면, 메시지의 수신 시 받은 수신 핸들을 사용하여 메시지를 삭제해야 한다. 만약 가시성 제한 시간이 만료되기 전에 삭제 요청이 이루어지지 않으면, 메시지는 다시 큐로 돌아가 다른 소비자에게 가시화되어 재처리될 수 있다. 이는 메시지 처리에 실패한 경우를 위한 자동 복구 메커니즘 역할을 한다.

가시성 제한 시간은 메시지 처리의 신뢰성을 보장하는 핵심 메커니즘이다. 이를 통해 분산 시스템의 구성 요소들은 동일한 메시지를 중복으로 처리하지 않으면서도, 장애 발생 시 메시지가 유실되지 않고 재처리될 수 있는 안정적인 통신을 구현할 수 있다. 또한, ChangeMessageVisibility API를 사용하면 처리 중인 메시지의 가시성 제한 시간을 연장할 수 있어 유연성을 제공한다.

Amazon Simple Queue Service는 마이크로서비스 아키텍처나 분산 시스템에서 애플리케이션 구성 요소를 느슨하게 연결하는 데 널리 사용된다. 이는 서로 다른 애플리케이션 또는 동일한 애플리케이션 내의 독립적인 모듈 간에 메시지를 안정적으로 전달하는 통합 계층 역할을 한다. 예를 들어, 주문 처리 시스템에서 결제 모듈과 배송 모듈이 직접 통신하지 않고, SQS를 통해 메시지를 교환함으로써 각 구성 요소의 독립성과 확장성을 보장할 수 있다.

이러한 통합 방식의 핵심 장점은 시스템의 결합도를 낮추는 데 있다. 한 구성 요소가 다운되거나 업데이트 중이더라도, 메시지는 큐에 안전하게 보관되어 다른 구성 요소가 복구된 후에 처리될 수 있다. 이는 전체 시스템의 내결함성을 크게 향상시킨다. 또한, 생산자와 소비자가 서로의 처리 속도에 영향을 받지 않고 독립적으로 작동할 수 있어, 트래픽이 급증하는 상황에서도 버퍼 역할을 수행한다.

SQS를 활용한 애플리케이션 통합은 다양한 시나리오에 적용된다. 웹 애플리케이션의 프론트엔드 서버가 사용자 요청을 받아 즉시 응답을 반환한 후, 실제 무거운 처리 작업(예: 이미지 변환, 데이터베이스 정리)에 대한 메시지를 큐에 넣고, 별도의 백엔드 워커 인스턴스들이 이 메시지를 비동기적으로 처리하는 패턴이 대표적이다. 또한, 레거시 시스템과 현대적 클라우드 애플리케이션 간의 데이터 교환 브리지로도 활용되어 시스템 현대화를 지원한다.

작업 큐는 Amazon Simple Queue Service의 핵심 사용 사례 중 하나로, 분산 시스템에서 비동기적으로 처리해야 하는 작업 단위를 효율적으로 분배하고 실행하는 데 사용된다. 애플리케이션이 이미지 처리, 비디오 트랜스코딩, 데이터 변환 또는 보고서 생성과 같이 시간이 오래 걸리거나 자원을 많이 소모하는 작업을 생성하면, 해당 작업에 대한 요청이 메시지 형태로 SQS 큐에 전송된다. 이후 별도의 작업자 프로세스(워커)들이 이 큐에서 메시지를 끌어와(Polling) 실제 작업을 수행한다. 이 방식을 통해 작업 생산자와 소비자를 분리함으로써 시스템의 확장성과 내결함성을 높일 수 있다.

작업 큐 패턴의 주요 장점은 부하 평준화와 확장성에 있다. 작업 요청이 급증하는 경우에도 생산자는 단순히 큐에 메시지를 추가하기만 하면 되며, 소비자 측면에서는 필요에 따라 작업자 프로세스의 수를 늘려 처리량을 확장할 수 있다. 예를 들어, Amazon EC2 오토 스케일링 그룹의 인스턴스들이 SQS 큐를 모니터링하며, 큐에 쌓인 메시지 수에 따라 인스턴스 개수를 자동으로 조정하는 구성이 가능하다. 또한, 작업 처리 중 일부 소비자 인스턴스에 장애가 발생하더라도, 가시성 제한 시간이 지난 미처리 메시지는 다시 큐로 돌아가 다른 정상 인스턴스에 의해 재처리되어 작업 손실을 방지한다.

SQS는 표준 큐와 FIFO 큐 두 가지 유형을 제공하여 작업 큐 구현 시 요구사항에 맞게 선택할 수 있다. 대부분의 백그라운드 작업 처리에는 높은 처리량과 최소 한 번 전송을 보장하는 표준 큐가 적합하다. 반면, 작업의 순서가 중요하거나 중복 처리를 허용하지 않는 트랜잭션 기반 작업의 경우, 정확히 한 번 처리와 선입선출 순서를 보장하는 FIFO 큐를 사용할 수 있다. 처리에 실패한 작업을 격리하고 분석하기 위해 데드 레터 큐를 함께 구성하는 것도 일반적인 모범 사례에 속한다.

Amazon Simple Queue Service는 이벤트 기반 아키텍처에서 이벤트 버스 역할을 수행할 수 있다. 이벤트 버스는 애플리케이션 내에서 발생하는 다양한 이벤트를 중앙에서 수집하고, 해당 이벤트에 관심이 있는 다른 구성 요소나 서비스에 전달하는 중개자 패턴이다. SQS는 이러한 이벤트 메시지를 안정적으로 버퍼링하고 전달하는 데 적합한 플랫폼을 제공한다.

이벤트 버스로서의 활용은 마이크로서비스 환경에서 특히 효과적이다. 예를 들어, 주문 처리 서비스에서 '주문 완료' 이벤트를 SQS 큐에 발행하면, 재고 관리 서비스, 결제 서비스, 알림 서비스 등 여러 구독자 서비스들이 각자의 처리 속도에 맞춰 해당 이벤트 메시지를 비동기적으로 소비할 수 있다. 이는 시스템 구성 요소 간의 느슨한 결합을 가능하게 하며, 특정 서비스의 장애가 전체 시스템으로 전파되는 것을 방지한다.

SQS를 이벤트 버스로 구성할 때는 주로 표준 큐가 사용된다. 이는 이벤트 처리에서 최대 처리량과 순서보다는 이벤트의 신뢰성 있는 전달이 더 중요할 수 있기 때문이다. 또한, 데드 레터 큐를 함께 설정하여 반복적으로 처리에 실패하는 이벤트를 격리하고 분석할 수 있어 시스템의 견고성을 높인다. 이벤트 버스 패턴은 서버리스 컴퓨팅 환경에서 AWS Lambda 함수를 트리거하는 데에도 널리 사용된다.

Amazon Simple Queue Service의 보안은 AWS Identity and Access Management 정책을 통해 세밀하게 제어된다. IAM 정책은 JSON 형식으로 작성되며, 특정 사용자, 그룹, 또는 역할이 SQS 큐에 대해 수행할 수 있는 작업을 정의한다. 이를 통해 최소 권한 원칙에 따라 접근을 제한할 수 있다.

정책은 액션, 리소스, 효과 등의 요소로 구성된다. 액션은 SendMessage, ReceiveMessage, DeleteMessage 등과 같은 특정 API 작업을 지정한다. 리소스는 정책이 적용될 특정 큐의 Amazon Resource Name을 명시하며, 와일드카드를 사용하여 여러 큐를 포함할 수도 있다. 효과는 해당 정책 문장이 허용(Allow)인지 거부(Deny)인지를 결정한다.

또한, 조건 키를 사용하여 보다 정교한 접근 제어가 가능하다. 예를 들어, 특정 IP 주소 범위에서만 큐에 접근하도록 하거나, 암호화가 활성화된 경우에만 메시지를 전송하도록 요구할 수 있다. 이러한 IAM 정책은 AWS 관리 콘솔, AWS CLI, 또는 AWS SDK를 통해 관리 및 배포된다.

Amazon Simple Queue Service (SQS)의 VPC 엔드포인트는 AWS 퍼블릭 클라우드 환경 내에서 SQS와의 통신을 위한 프라이빗 연결 경로를 제공한다. 이 기능은 인터넷을 경유하지 않고 Amazon Virtual Private Cloud (VPC) 내의 리소스가 SQS 서비스와 안전하게 통신할 수 있도록 한다. 이를 통해 데이터가 퍼블릭 네트워크를 통과하지 않아 보안이 강화되고, 네트워크 트래픽이 AWS 백본 네트워크 내에 유지되어 지연 시간이 예측 가능해진다.

VPC 엔드포인트는 인터페이스 엔드포인트와 게이트웨이 엔드포인트 두 가지 유형이 있다. SQS는 AWS PrivateLink 기술을 기반으로 하는 인터페이스 엔드포인트를 사용한다. 사용자는 VPC 내에 엔드포인트 네트워크 인터페이스를 생성하고, 이를 통해 SQS API 호출을 프라이빗 IP 주소로 라우팅할 수 있다. 이 연결은 IAM 정책과 VPC 엔드포인트 정책을 통해 세밀하게 제어된다.

이 구성을 통해 EC2 인스턴스나 AWS Lambda 함수와 같은 VPC 내 애플리케이션 구성 요소는 NAT 게이트웨이나 인터넷 게이트웨이 없이도 SQS에 안전하게 메시지를 보내거나 받을 수 있다. 이는 규정 준수 요구사항이 엄격한 금융 또는 의료 분야 애플리케이션, 그리고 데이터 프라이버시를 중시하는 마이크로서비스 아키텍처에서 특히 유용하다.

Amazon CloudWatch는 Amazon Simple Queue Service의 성능과 상태를 모니터링하는 데 사용되는 AWS의 모니터링 및 관찰 가능성 서비스이다. SQS 대기열에 대한 다양한 지표를 실시간으로 수집하고 시각화하여 운영 상태를 파악할 수 있게 해준다.

주요 모니터링 지표로는 대기열의 메시지 수, 지연된 메시지 수, 빈 대기열 요청 수, 메시지 송수신 작업의 성공률 등이 포함된다. 이러한 지표는 CloudWatch 콘솔을 통해 그래프로 확인하거나, 특정 임계값을 초과할 경우 SNS를 통해 알림을 받도록 CloudWatch 경보를 설정할 수 있다. 이를 통해 시스템의 병목 현상을 신속히 감지하고 대응할 수 있다.

또한 CloudWatch는 SQS와의 통합을 통해 대기열 작업에 대한 상세한 로그 데이터를 수집할 수 있다. CloudWatch 로그를 활성화하면 메시지가 대기열에 들어오고 나가는 과정에 대한 정보를 기록하여, 디버깅이나 감사 목적으로 활용할 수 있다. 이는 복잡한 분산 시스템 환경에서 애플리케이션의 동작을 추적하는 데 유용하다.

CloudWatch를 통한 모니터링은 SQS의 효율적인 운영과 비용 최적화에 기여한다. 예를 들어, 지나치게 많은 메시지가 대기열에 쌓이는 현상을 감지하여 소비자 애플리케이션의 확장 필요성을 판단하거나, 불필요한 빈 대기열 요청을 줄여 요금을 절감하는 데 활용할 수 있다.

Amazon Simple Queue Service (SQS)는 Amazon Web Services (AWS)가 제공하는 완전관리형 메시지 큐 서비스이다. 이 서비스는 분산 시스템의 구성 요소 간에 메시지를 안전하게 전송, 저장 및 수신할 수 있도록 설계되었다. SQS를 사용하면 마이크로서비스 아키텍처나 분리된 애플리케이션 구성 요소 간에 신뢰할 수 있는 통신 채널을 쉽게 구축할 수 있으며, 개발자는 메시징 인프라를 관리할 필요 없이 애플리케이션 로직에 집중할 수 있다.

SQS는 2006년 7월 13일에 출시되었으며, AWS가 처음으로 공개한 서비스 중 하나에 해당한다. 이 서비스의 등장은 클라우드 컴퓨팅 환경에서 확장성과 내결함성을 갖춘 애플리케이션을 구축하는 방식을 크게 변화시켰다. 사용자는 표준 큐와 FIFO (First-In-First-Out) 큐 두 가지 유형의 대기열을 선택하여 생성할 수 있으며, 각 유형은 처리량, 순서 보장, 중복 제거 등 서로 다른 요구사항에 맞춰 설계되었다.

주요 용도로는 애플리케이션 통합, 작업 큐 (Task Queues) 구현, 그리고 이벤트 기반 아키텍처에서의 구성 요소 분리 등이 있다. 예를 들어, 웹 애플리케이션의 프론트엔드 서버가 사용자 요청을 받아 SQS 큐에 작업 메시지를 넣으면, 백엔드의 워커 프로세스가 그 메시지를 꺼내 비동기적으로 처리하는 패턴이 널리 사용된다. 이를 통해 시스템의 부하를 분산시키고 처리 지연을 격리시킬 수 있다.

SQS는 AWS Lambda, Amazon EC2, Amazon SNS (Simple Notification Service) 등 다른 AWS 서비스와 긴밀하게 통합되어 있다. 특히 Amazon SNS와의 조합은 Pub/Sub (발행-구독) 모델을 구현하는 데 자주 활용되며, AWS Lambda를 트리거하여 서버리스 아키텍처를 완성하는 핵심 구성 요소로 작동한다.

AWS Lambda는 Amazon Simple Queue Service와 함께 사용될 때 서버리스 아키텍처의 강력한 이벤트 처리 핵심 구성 요소가 된다. SQS는 메시지를 안정적으로 저장하고 전달하는 반면, Lambda는 이러한 메시지를 트리거로 삼아 코드를 실행하는 컴퓨팅 서비스이다. 사용자는 SQS 큐를 Lambda 함수의 이벤트 소스로 지정할 수 있으며, 큐에 메시지가 도착하면 AWS가 자동으로 Lambda 함수를 호출하여 메시지를 처리한다. 이 조합은 서버 프로비저닝이나 관리 없이도 메시지 기반 애플리케이션을 구축할 수 있게 해준다.

SQS와 Lambda의 통합은 특히 비동기적이고 이벤트 주도적인 워크플로우에 적합하다. 예를 들어, 사용자가 웹 애플리케이션에 파일을 업로드하면 애플리케이션은 처리 작업 요청을 SQS 큐에 보낼 수 있다. 별도로 구성된 Lambda 함수는 이 메시지를 수신하여 즉시 파일 처리를 시작한다. 이 방식은 업로드 요청을 처리하는 프론트엔드 서버와 실제 처리 작업을 분리시켜 애플리케이션의 확장성과 내결함성을 높인다.

이 통합을 구성할 때는 몇 가지 중요한 설정을 고려해야 한다. Lambda의 배치 크기(Batch Size)를 조정하여 한 번의 함수 호출에 처리할 메시지 수를 결정할 수 있다. 또한, Lambda 함수가 메시지를 성공적으로 처리한 후에는 SQS에서 해당 메시지가 자동으로 삭제되지만, 함수 실행이 실패하면 메시지는 가시성 제한 시간이 지난 후 큐에 다시 나타나 재시도된다. 처리에 실패한 메시지를 격리하기 위해 데드 레터 큐를 설정하는 것도 일반적인 모범 사례이다.

SQS와 Lambda 외에도, Amazon Simple Notification Service를 이벤트 소스로 활용하거나, 처리된 데이터를 Amazon DynamoDB에 저장하는 등 다른 AWS 서비스와 결합하여 복잡한 서버리스 애플리케이션을 완성할 수 있다. 이는 개발자가 인프라 관리 부담을 줄이고 비즈니스 로직 구현에 집중할 수 있도록 지원하는 클라우드 컴퓨팅의 대표적인 사례이다.

Amazon EC2는 Amazon Web Services가 제공하는 확장 가능한 컴퓨팅 용량을 제공하는 클라우드 컴퓨팅 서비스이다. Amazon Simple Queue Service와 함께 사용될 때, EC2 인스턴스는 SQS 대기열에서 메시지를 가져와 처리하는 소비자 역할을 수행한다. 이는 마이크로서비스 아키텍처나 작업 큐 패턴에서 일반적으로 볼 수 있는 구성으로, 애플리케이션의 처리 계층을 유연하게 확장할 수 있게 해준다.

SQS는 EC2 인스턴스와 같은 컴퓨팅 리소스 사이에 완전관리형 메시지 브로커를 제공함으로써 시스템 구성 요소 간의 결합도를 낮춘다. 예를 들어, 웹 서버 역할을 하는 EC2 인스턴스는 사용자 요청을 처리한 후 결과 메시지를 SQS 대기열에 보내기만 하면 된다. 별도의 백엔드 처리 인스턴스들이 이 대기열을 모니터링하며 메시지를 가져가 비동기적으로 작업을 수행한다. 이를 통해 프론트엔드와 백엔드 시스템이 독립적으로 확장되고 관리될 수 있다.

EC2 오토 스케일링 그룹과 SQS를 연동하면, 대기열의 메시지 수에 따라 처리 인스턴스의 수를 동적으로 조정할 수 있다. 대기열에 메시지가 쌓이면 EC2 인스턴스를 자동으로 추가하여 처리량을 늘리고, 메시지가 줄어들면 인스턴스를 종료하여 비용을 절감할 수 있다. 이는 부하 분산과 리소스 최적화에 매우 효과적인 패턴이다.

또한 SQS는 EC2 인스턴스의 장애에 대한 내결함성을 제공한다. 처리 중인 인스턴스에 문제가 발생하더라도, 메시지의 가시성 제한 시간이 초과되면 해당 메시지는 다시 대기열로 돌아가 다른 정상 인스턴스에 의해 처리될 수 있다. 이렇게 SQS와 EC2의 조합은 확장성, 가용성, 견고성을 갖춘 분산 애플리케이션을 구축하는 데 핵심적인 역할을 한다.