Подписка SQS на SNS: пошаговая инструкция и лучшие практики

Кратко: подключите очередь Amazon SQS как подписчика темы Amazon SNS, чтобы пересылать сообщения из SNS в SQS. В статье показаны шаги: проверка существующих ресурсов, изменение политики доступа SQS, создание подписки с включённой «Enable raw message delivery», проверка доставки сообщений и удаление подписки. Важное предупреждение: не ставьте универсальный Principal в production.

Основная идея

Подписка SQS на SNS позволяет автоматически дублировать сообщения, публикуемые в теме SNS, в одну или несколько очередей SQS. Поддерживается пересылка «raw» сообщений и атрибутов сообщения из SNS. Это удобно для надёжной асинхронной интеграции между компонентами приложения.

Коротко о терминах

• SNS — сервис уведомлений и публикации/подписки (pub/sub).
• SQS — управляемая очередь сообщений для асинхронной обработки.
• ARN — уникальный идентификатор ресурса AWS.

Предварительные требования

1. Аккаунт AWS (создайте, если нет).
2. Тема SNS (Topic) — уже создана.
3. Очередь SQS — уже создана.

Важно: создание SNS и SQS в этой статье не рассматривается — предполагается, что ресурсы уже есть.

Что мы сделаем

1. Войдём в AWS Console.
2. Проверим тему SNS.
3. Проверим очередь SQS и изменим политику доступа при необходимости.
4. Создадим подписку SNS → SQS.
5. Опубликуем сообщение в SNS и проверим, что оно пришло в SQS.
6. Удалим подписку.

Войти в AWS

Перейдите в консоль AWS и авторизуйтесь под своей учётной записью.

После входа вы увидите главную страницу управления AWS.

Проверка SNS

В поле поиска вверху введите SNS и перейдите на панель службы.

На дашборде SNS откройте раздел «Topics» (Темы) в левой колонке.

Вы увидите список тем SNS в выбранном регионе. Выберите тему, которую собираетесь использовать (в примере — «sns-test»).

Откройте детали темы. В примере подписок ещё нет.

Проверка SQS и изменение политики доступа

Перейдите в SQS через поиск в консоли.

Вы увидите список очередей в выбранном регионе. Выберите нужную очередь (в примере — «sqs-test»).

Откройте вкладку «Access policy» (Политика доступа) и нажмите «Edit».

В поле политики при необходимости замените конкретный ARN аккаунта на символ глобального доступа, например на звездочку () в блоке Principal, только для тестовых окружений. В production использование ‘‘ не рекомендуется — лучше явно указывать ARN темы SNS или роль, которой доверяете.

Важно

• Для production указывайте минимально необходимые права и конкретные ARN.
• Проверяйте политику на отсутствие избыточного доступа.

Создание подписки SNS → SQS

Вернитесь в тему SNS и нажмите «Create subscription».

В форме укажите протокол Amazon SQS и в поле Endpoint вставьте ARN очереди SQS. Установите флажок «Enable raw message delivery» если хотите получить сообщение в SQS без дополнительной оболочки SNS (полезно для простых текстовых/JSON payload). Затем создайте подписку.

После успешного создания вы увидите подписку со статусом confirmed.

Проверка доставки сообщений

Теперь протестируем доставку: перейдите в очередь SQS и нажмите «Send and receive messages».

Нажмите «Poll for messages» для начала опроса.

Перейдите в тему SNS и опубликуйте сообщение — нажмите «Publish message».

Заполните Subject и выберите опцию «Custom payload for each delivery protocol» при необходимости (если нужно разное содержимое для HTTP, SQS и т. п.).

Нажмите Publish.

Вернитесь к SQS — сообщение должно появиться в очереди. Откройте сообщение, чтобы увидеть тело, которое пришло от SNS.

В разделе с телом сообщения вы увидите payload, отправленный из SNS (в случае включённого «raw» — без оболочки SNS).

Удаление подписки

Если подписка больше не нужна, её можно удалить из консоли SNS: выберите подписку и нажмите Delete.

Подтвердите удаление — операция необратима, будьте внимательны в production.

Когда это не сработает

• Политика доступа SQS запрещает публикацию от SNS — сообщение не будет доставлено. Проверьте блок Principal и права на действие sqs:SendMessage.
• Если в политике указана конкретная тема SNS, а в подписке используется другой ARN — доступ будет отклонён.
• Если в регионе нет соответствующих ресурсов (SQS и SNS в разных регионах) — проверяйте совместимость ARN и регионов.
• Для FIFO-очередей SQS нужно учитывать формат и атрибуты, например messageGroupId.

Альтернативные подходы

• Прямая интеграция с HTTP/S endpoints вместо SQS — подходит для реального времени, но менее надёжна при сбоях.
• Использование Lambda как подписчика SNS, которая затем помещает данные в SQS с дополнительной логикой трансформации.
• EventBridge для маршрутизации событий с более гибкой фильтрацией и трансформацией перед отправкой в SQS.

Методология тестирования (мини)

1. Подготовка: создать тестовую тему SNS и тестовую очередь SQS в одном регионе.
2. Настройка политики SQS только для тестовой темы SNS.
3. Создать подписку с включённым raw delivery и без него — проверить разницу.
4. Опубликовать набор тестовых сообщений, включая JSON, большие payload и атрибуты сообщений.
5. Подтвердить доставку и соответствие тела и атрибутов.
6. Проверить поведение при ошибках (удаление подписки, изменение политики).

Критерии приёмки

• Сообщение, опубликованное в SNS, появляется в SQS в течение ожидаемого окна (секунды).
• Если включён raw delivery — тело сообщения совпадает с отправленным payload.
• Если отключён raw delivery — тело содержит оболочку SNS с метаданными и оригинальным сообщением.
• При удалении подписки доставки прекращаются.

Роли и чек-листы

• Для разработчика:

  • Убедиться, что payload сериализуется корректно.
  • Тестировать обработку дублей и порядок (особенно для FIFO).

• Для инженера по эксплуатации:

  • Проверить политики доступа SQS.
  • Мониторить ошибки доставки и задержку.
  • Настроить alarms для количества невостребованных сообщений.

• Для инженера по безопасности:

  • Не давать широкой подписке права ‘*’ в production.
  • Шифровать сообщения при необходимости (SQS поддерживает KMS).
  • Проверить хранение и ретеншн PII в очередях.

Безопасность и приватность

• Никогда не включайте универсальный Principal в продакшн.
• Рассмотрите шифрование сообщений на стороне SQS (SSE-KMS) при передаче конфиденциальных данных.
• Период хранения сообщений (VisibilityTimeout и MessageRetentionPeriod) должен соответствовать политике хранения данных и требованиям GDPR/локальным нормам.

Набор тестовых сценариев

• Отправка простого текстового сообщения — приемка в SQS.
• Отправка JSON-объекта с атрибутами — все атрибуты воспроизводятся в SQS.
• Отправка при выключенной подписке — сообщение не доставляется.
• Изменение политики SQS, запрещающее отправку от SNS — проверка отказа доставки.

Ментальные модели и эвристики

• SNS = распределитель (fan-out), SQS = буфер/рабочая очередь.
• Используйте SNS → SQS для масштабирования потребителей: одна публикация — несколько очередей и независимая обработка.
• Включайте raw delivery, если хотите минимальную трансформацию и простую интеграцию.

Схема принятия решения

flowchart TD
  A[Нужно распределять сообщения?] -->|Да| B{Требуется персистентность}
  B -->|Да| C[Использовать SQS как подписчик]
  B -->|Нет| D[HTTP/S или Lambda подписки]
  C --> E{Нужен порядок сообщений}
  E -->|Да| F[Использовать FIFO-очередь с messageGroupId]
  E -->|Нет| G[Стандартная очередь SQS]

Краткий глоссарий

• SNS: сервис публикации/подписки.
• SQS: очередь сообщений для отложенной обработки.
• Raw delivery: режим доставки сообщения без дополнительной оболочки SNS.
• ARN: Amazon Resource Name — уникальный идентификатор ресурса.

Итог

В статье показано, как подписать SQS на SNS, проверить доставку сообщений и удалить подписку. Ключевые моменты: проверьте политику доступа SQS, используйте raw delivery при необходимости, и не давайте универсальный доступ в production. Следуйте чек-листам и тестовым сценариям, чтобы убедиться в корректной интеграции.