Управляемые данные в AWS: RDS, ElastiCache, SQS, MSK

«Управляемый» (managed) сервис — это когда вы пользуетесь технологией, а её обслуживанием занимается провайдер. Своя база данных на сервере — это вы сами ставите PostgreSQL, настраиваете резервные копии, по ночам чините, когда диск заполнился. Управляемая база — это та же PostgreSQL, но резервные копии, замена сломанного узла и обновления версий делает AWS. Вы платите за это деньгами, но не временем и не бессонными ночами.

Главная ценность облака для backend-разработчика — не виртуальные машины, а именно управляемые данные: базы, кэши, очереди и брокеры сообщений, у которых рутина переложена на провайдера. Эта статья — карта соответствий «то, что вы знаете по своему серверу → как это называется в AWS», и честный список того, что управляемый сервис за вас не делает.

RDS и Aurora: PostgreSQL как сервис

RDS (Relational Database Service) — это реляционные базы данных под управлением AWS. RDS for PostgreSQL — это тот же самый PostgreSQL, к которому вы привыкли, только вокруг него автоматика:

• Резервные копии с возможностью восстановиться на любую секунду в прошлом (Point-In-Time Recovery, PITR).
• Реплика в другой зоне доступности (Multi-AZ): если основной сервер умирает, AWS автоматически переключает нагрузку на запасной. Переключение занимает обычно минуту-две, и приложение обязано переподключиться — адрес базы остаётся прежним, а вот открытые соединения рвутся. И сразу снимем главное заблуждение: запасной экземпляр не читается, снять с него отчёты нельзя, это не удвоение мощности. Нужны чтения — заводят отдельные read-реплики или берут вариант Multi-AZ DB cluster, где запасных двое и оба читаемые. Зона доступности (Availability Zone, AZ) — это отдельный дата-центр в одном регионе; их обычно несколько, чтобы пожар в одном здании не уронил сервис.
• Обновления версий в заранее заданное окно обслуживания.

Aurora — это база данных от AWS, совместимая с PostgreSQL по протоколу, но переписанная внутри. Её главная фишка — отдельный распределённый слой хранения: каждый кусок данных хранится в шести копиях по трём зонам доступности (по две копии на зону). Запись подтверждается, когда её приняли четыре копии из шести, поэтому Aurora переживает потерю двух копий без остановки записи. Реплики читают из того же общего хранилища, что и основной сервер, поэтому отставание реплики маленькое — обычно десятки миллисекунд, а переключение при сбое занимает меньше минуты. «Маленькое» — не «нулевое»: прочитать с реплики сразу после записи и увидеть старое значение вполне можно, и на этом ловятся почти все. Платится это надбавкой к цене и небольшой потерей ощущения «это просто PostgreSQL» — отдельные параметры, своё поведение под нагрузкой.

Это тот же PostgreSQL, но без суперпользователя

Главная неожиданность при переезде: движок действительно тот же, а вот привычные способы им управлять — нет.

Суперпользователя вам не дают. Учётная запись, которую вы создаёте вместе с базой, имеет широкие права, но не SUPERUSER. Отсюда следствия: нельзя читать файлы сервера, нельзя ставить произвольные расширения, нельзя менять часть параметров, и часть команд обслуживания недоступна. Роль называется иначе (rds_superuser), и её прав хватает на обычную работу, но не на всё.

ALTER SYSTEM не работает. Параметры сервера меняются не запросом, а через группу параметров (parameter group): это объект AWS, который прикладывается к экземпляру базы. Меняете значение в группе — оно применяется либо сразу (динамические параметры), либо при следующем перезапуске (статические, и это надо планировать). Соответственно, postgresql.conf вы тоже не увидите.

aws rds modify-db-parameter-group --db-parameter-group-name orders-pg16 \
  --parameters "ParameterName=log_min_duration_statement,ParameterValue=500,ApplyMethod=immediate"

Расширения только из списка. Доступные расширения перечислены самой AWS, и список этот большой (pg_stat_statements, pgvector, postgis, pg_trgm и десятки других), но не бесконечный: экзотическое или своё расширение поставить нельзя. Часть расширений требует, чтобы имя было прописано в параметре shared_preload_libraries в группе параметров — а это статический параметр, то есть перезапуск. Проверить, что доступно именно в вашей версии, можно запросом:

живой пример

SELECT name, default_version, installed_version FROM pg_available_extensions ORDER BY name;

Запустить

Запуск примеров доступен в платном доступе. Там этот же код выполняется прямо в статье: редактор, запуск и проверка рядом с абзацем. Три дня бесплатно →

Что из этого следует на практике. Перед переездом смотрят два списка: расширения, которые использует приложение, и параметры, которые кто-то менял на своём сервере. Первое сверяют с перечнем доступных, второе переносят в группу параметров. Почти всегда всё сходится — и почти всегда обнаруживается одна-две настройки, которых в облаке нет, и вокруг них приходится что-то придумывать.

Чем смотреть, что творится в базе

«Тюнинг медленных запросов — ваша работа» верно, и инструменты для этой работы в облаке свои.

Performance Insights — встроенный обзор нагрузки: график активных сессий во времени с разбивкой по тому, чего они ждут (процессор, диск, блокировка, ожидание клиента), и список самых тяжёлых запросов за выбранный период. Это первое, куда смотрят при «база тормозит»: за минуту видно, упёрлись вы в диск, в блокировки или в один неудачный запрос. Включается одной настройкой у экземпляра; базовый срок хранения данных бесплатен, длинный — платный.

pg_stat_statements — то же самое внутри самой базы и подробнее: накопленная статистика по каждому виду запроса (число вызовов, суммарное и среднее время, число прочитанных блоков). В облаке расширение доступно и обычно включено; если нет, добавляют в shared_preload_libraries группы параметров. Разбор того, как этим пользоваться, — в статье про медленные запросы.

Журнал медленных запросов. Параметр log_min_duration_statement в группе параметров (значение в миллисекундах) заставляет базу писать в журнал каждый запрос, который выполнялся дольше порога. Журналы видны в консоли и выгружаются в систему сбора логов. Начинают обычно с 500–1000 миллисекунд: меньше — и журнал заполнится обычной работой.

Метрики экземпляра — процессор, свободная память, операции ввода-вывода, число соединений, отставание реплики. Самые полезные сигналы: свободная память около нуля (база начнёт использовать диск вместо памяти), число соединений у потолка (о нём ниже) и накопление операций ввода-вывода, если у класса машины есть кредитная система на диск.

Порядок разбора «база тормозит», который работает почти всегда: сначала обзор нагрузки (во что упёрлись), потом список тяжёлых запросов оттуда же, потом план конкретного запроса через EXPLAIN — и только потом разговоры про класс машины.

Вот что важно понять новичку: управляемая база снимает с вас эксплуатацию железа, но не проектирование данных. RDS спасёт от сгоревшего диска, но не от запроса SELECT без индекса, который перебирает миллион строк. Схема таблиц, индексы, блокировки, безопасные изменения структуры без остановки сервиса, тюнинг медленных запросов — всё это по-прежнему ваша работа.

Грабли, на которые наступают почти все: лимит соединений. У базы есть максимальное число одновременных подключений, и оно зависит от объёма памяти сервера. Когда десяток приложений держат каждое по пулу из 10 соединений, лимит выедается незаметно, и новые подключения начинают падать с ошибкой. Лечится двумя способами: дисциплиной размеров пулов и компонентом RDS Proxy — это прослойка, которая мультиплексирует (переиспользует) соединения между приложениями. RDS Proxy практически обязателен, если рядом работают функции, которые часто запускаются и останавливаются. База — это фундамент почти любого сервиса, поэтому планируйте её вместе с масштабированием и отказоустойчивостью.

ElastiCache: Redis как сервис

Кэш — это быстрое временное хранилище, куда кладут уже посчитанный результат, чтобы не считать его заново. Redis — самый популярный движок для этого. ElastiCache — управляемый Redis (и его открытый форк Valkey): кластер, реплики и переключение при сбое настраивает AWS.

Применяют его так же, как обычный Redis. Страница каталога собирается пятью запросами к базе и не меняется часами — её ответ кладут в кэш с временем жизни (TTL, time-to-live — через сколько секунд запись сама исчезнет). Две копии приложения одновременно берутся за одну и ту же фоновую задачу — их разводит распределённая блокировка. Один клиент шлёт тысячу запросов в минуту и кладёт всех — его тормозит ограничение частоты запросов (rate limiting): «не больше 100 запросов в минуту с одного клиента».

Что не снимается: дисциплина именования ключей и продумывание TTL, выбор формата сериализации, защита от «лавины» одновременных промахов кэша (cache stampede) — всё это живёт в коде, а не в консоли AWS. И главное правило для новичка: ElastiCache — это кэш, а не база данных. Данные, потеря которых недопустима (заказы, платежи), в нём не хранят: кэш может сбросить содержимое в любой момент.

Три настройки и одна развилка, которые определяют поведение кэша под нагрузкой.

Что происходит, когда память кончилась. За это отвечает политика вытеснения (maxmemory-policy). По умолчанию в управляемом Redis стоит volatile-lru: вытесняются только ключи со сроком жизни, и по давности использования. Практическое следствие неприятное: если часть ключей записана без срока жизни, они не вытесняются вовсе — и в какой-то момент кэш заполнится ими, а новые записи начнут получать ошибку «нет памяти». Отсюда два рабочих варианта: либо дисциплина «срок жизни у каждого ключа обязателен», либо политика allkeys-lru, при которой вытесняется что угодно по давности. Для чистого кэша правильнее второе; для кэша, в котором лежат и блокировки, — первое, потому что вытесненная блокировка означает двух исполнителей одной задачи.

Кластерный режим меняет набор доступных операций. В кластере данные разложены по слотам между узлами, и операция, затрагивающая несколько ключей сразу, работает только если все ключи попали в один слот. То есть привычные MGET по случайным ключам, транзакции и скрипты с несколькими ключами перестают работать с ошибкой про слоты. Лечится это хеш-тегами: часть имени в фигурных скобках определяет слот, и user:{42}:cart с user:{42}:profile гарантированно окажутся вместе. Решение про кластерный режим поэтому принимают до написания кода, а не после.

Без кластера тоже можно масштабироваться — вертикально (класс машины больше) плюс реплики для чтения. Для кэша это часто достаточный путь, потому что узкое место обычно память, а не число узлов.

Serverless-вариант. У ElastiCache есть режим без выбора узлов: платите за объём хранимых данных и за обработанные запросы, масштабируется сам. Это удобный ответ для неровной нагрузки и для того, чтобы не заниматься подбором класса машины; за единицу ресурса он дороже, а часть тонких настроек недоступна. Проверять стоит одно: попадает ли ваш профиль (много мелких запросов, небольшой объём) в выгодную зону — считается это на калькуляторе за десять минут.

Очереди и брокеры: SQS и MSK

Сервис отправки писем лёг — и вместе с ним лёг заказ, который всего лишь хотел отправить письмо. Чтобы одна часть системы могла передать работу другой, не дожидаясь ответа и не завися от её здоровья, между ними ставят посредника — очередь или брокер сообщений. AWS даёт две разные вещи под разные задачи.

SQS (Simple Queue Service) — простейшая очередь как сервис. Никакого сервера, кластера и обслуживания нет вообще: вы просто кладёте сообщения и забираете их. Ключевые свойства:

• Хранит непрочитанные сообщения до 14 дней (по умолчанию 4 дня).
• Есть очередь недоставленных сообщений (DLQ, dead-letter queue) — туда попадает то, что не удалось обработать после нескольких попыток.
• Оплата за число запросов, а не за работающий сервер.
• Одно сообщение — не больше 1 МиБ. Всё, что крупнее (документ, изображение, большая выгрузка), кладут в объектное хранилище, а в очередь отправляют ссылку; для Java и Python у AWS есть готовая библиотека-обёртка, которая делает это за вас.
• Visibility timeout — когда потребитель забирает сообщение, оно становится невидимым для других на заданное время (от 0 секунд до 12 часов, по умолчанию 30 секунд). Это как «арендовать» задачу на время обработки: успел — удаляешь, не успел — сообщение снова станет видимым и достанется другому.

Семантика доставки у SQS — at-least-once («хотя бы один раз»): одно и то же сообщение может прийти повторно. Это не баг, а следствие надёжности — система лучше повторит, чем потеряет. Есть и FIFO-вариант (first-in-first-out): он гарантирует строгий порядок и убирает дубликаты в пределах 5-минутного окна, но за это платит меньшей пропускной способностью. Правда, у FIFO есть и режим высокой пропускной способности, который поднимает потолок на порядки, — так что «FIFO значит медленно» сегодня уже не приговор. Рядом с SQS живёт SNS (Simple Notification Service) — это рассылка по схеме «один-ко-многим» (pub/sub): одно событие веером уходит сразу множеству подписчиков (нескольким очередям SQS, функциям и так далее).

MSK (Managed Streaming for Apache Kafka) — управляемая Kafka. Это именно настоящая Kafka со всеми её понятиями (партиции, группы потребителей, retention — время хранения событий в журнале), просто серверы-брокеры и координацию обслуживает AWS. Что MSK за вас не делает: дизайн топиков и ключей партиционирования, идемпотентность потребителей (защиту от повторной обработки), мониторинг отставания потребителей (consumer lag), реестр схем сообщений.

Очередь задач или журнал событий: как выбрать

Выбор между SQS и MSK — это выбор между очередью задач и журналом событий. SQS — «возьми задачу, выполни, удали»: сообщение прочитали и оно ушло. Kafka/MSK — это лента событий, которую могут читать много разных потребителей независимо, каждый со своей позиции, а события остаются на диске весь срок хранения. Простое правило: если нужно просто раздать работу — берите SQS, его вообще не надо обслуживать; если событие должны переварить несколько разных подсистем или важна история — MSK.

DynamoDB: другая лига

DynamoDB — единственный пункт в этом списке, у которого нет привычного «своего» аналога. Это управляемая NoSQL-база типа ключ-значение и документная: она отдаёт данные за единицы миллисекунд при любом масштабе и тарифицируется по запросам. Но у неё жёсткая модель: доступ только по ключу и заранее спроектированным индексам, никаких произвольных SQL-запросов «а покажи мне теперь вот так».

Это не «NoSQL-замена PostgreSQL». Проектирование таблицы DynamoDB начинается с того, что вы перечисляете все запросы, которые когда-либо будете делать, и под них раскладываете данные (это называется single-table design). Если завтра понадобится посмотреть данные под другим углом, которого не было в исходном списке, переделка обходится дорого. Честная ниша DynamoDB — высоконагруженные сценарии ключ-значение с предсказуемыми обращениями: пользовательские сессии, корзины, флаги функциональности, счётчики. Подробный разбор — в отдельной статье про DynamoDB.

DocumentDB: MongoDB как сервис

MongoDB — популярная документная база: данные хранятся как JSON-подобные документы, а не как строки в таблицах, и по ним можно делать гибкие запросы. DocumentDB — это управляемый сервис AWS, совместимый с MongoDB по протоколу: приложение и драйвер думают, что общаются с MongoDB, а резервные копии, реплики и переключение при сбое берёт на себя AWS (хранение устроено похоже на Aurora — несколько копий по зонам доступности).

Ключевое слово здесь — «совместимый», а не «тот самый MongoDB». Внутри это собственный движок AWS, который эмулирует API MongoDB определённой версии. Большинство обычных операций работает, но не все операторы, команды и свежие возможности MongoDB поддерживаются. Поэтому правило простое: прежде чем брать DocumentDB под существующее Mongo-приложение, проверьте по списку поддерживаемых возможностей, что нужные вам операции есть — иначе миграция упрётся в отсутствующую фичу.

Где DocumentDB, а где DynamoDB? Обе — NoSQL, но ниши разные. DocumentDB берут, когда нужна документная модель Mongo с гибкими запросами (в том числе по разным полям, а не только по ключу) — часто это перенос уже существующего приложения на MongoDB в облако без забот об эксплуатации. DynamoDB — когда важнее предсказуемая задержка и масштаб при доступе по заранее известным ключам. Как и с любой базой, DocumentDB снимает эксплуатацию железа, но проектирование документов и индексов остаётся на вас.

Управляемый против своего: как выбирать

	Управляемый (RDS/MSK/ElastiCache)	Свой на сервере
Эксплуатация	Резервные копии, переключение, обновления — AWS	Всё ваше, включая три часа ночи
Цена	За ту же мощность дороже; насколько — зависит от движка, лицензий, класса машины и Multi-AZ	Дешевле железом, дороже людьми
Контроль	Версии и параметры из списка AWS	Любые расширения, форки, тонкая настройка
Данные	В вашем аккаунте, шифрование ключами KMS	Где захотите
Привязка к AWS	PostgreSQL и Kafka переносимы; DynamoDB и SQS — нет	Нет

Разумное правило по умолчанию: компоненты с состоянием (базы, кэши, очереди) берём управляемыми, пока нет конкретной причины делать иначе — например, нужно расширение PostgreSQL, которого нет в RDS, или требования по хранению данных диктуют своё железо. Прежде чем самостоятельно обслуживать PostgreSQL при доступном RDS, стоит честно ответить, на что инженеры потратят время, которое RDS им освобождает.

Где это применяется

Управляемые сервисы — это основа почти любого приложения в AWS. Веб-сервис почти всегда садится на RDS или Aurora как основное хранилище, кладёт ElastiCache перед базой для скорости и развязывает медленные операции (отправку писем, генерацию отчётов) через SQS. Событийные системы, где много подсистем реагируют на изменения, строят на MSK.

Типичные ошибки начинающих:

• Свой сервер «ради экономии» без подсчёта стоимости инженерного времени и инцидентов. Считайте полную цену владения, а не только цену виртуальной машины.
• DynamoDB как универсальная база. Третья переделка single-table design под новый сценарий запросов обойдётся дороже, чем если бы с самого начала взяли RDS.
• Потребитель SQS без защиты от повторов. Доставка at-least-once означает дубликаты; обработка денежной операции дважды одинаково больно и в облаке, и на своём сервере. Делайте операции идемпотентными.
• Пулы соединений по умолчанию на множестве приложений выедают лимит RDS. Размер пула считайте от лимита базы, а не от привычки.
• Игнорирование платы за трафик. Передача данных между зонами доступности и через NAT — заметные строки в счёте; помогают VPC endpoints и осознанное размещение компонентов рядом с данными.

Глубже: резервные копии: что включено, а что нетрасширенное

Про копии сказано одной строкой, а вопросов у них ровно три: что включено по умолчанию, чем снимок отличается от восстановления на точку во времени и куда всё это восстанавливается.

Автоматические копии. Включены по умолчанию, но срок хранения зависит от того, как создавали базу: через консоль по умолчанию семь дней, а через API или командную строку — один день. Это та разница, которую стоит проверить в первый же день: однодневный срок означает, что вчерашнюю ошибку уже не откатить. Ноль дней вовсе выключает автоматические копии и заодно возможность восстановления на точку во времени, поэтому ставить его нельзя нигде, кроме одноразовых стендов.

Восстановление на точку во времени (PITR) работает благодаря копиям плюс сохранённому журналу транзакций: можно попросить состояние базы на любую секунду внутри срока хранения. Именно это спасает после «удалил не то»: восстанавливаемся на момент за минуту до ошибки.

Снимок (snapshot) — копия, которую вы делаете сами. Она хранится, пока вы её не удалите (в том числе после удаления самой базы), и её можно копировать в другой регион или передавать в другой аккаунт. Отсюда разделение роли: автоматические копии — от аварий и ошибок последних дней, снимки — перед рискованной операцией (миграция, обновление версии) и для долгого хранения по требованиям.

И главное, чего не ждут: восстановление создаёт новый экземпляр базы. Ни PITR, ни снимок не «откатывают» существующую базу на месте — они поднимают рядом новую, с новым адресом. Значит, реальная процедура восстановления выглядит так: восстановили копию, проверили данные, переключили приложение на новый адрес (или перенесли нужные данные из восстановленной базы в рабочую). Времени это занимает от минут до часов в зависимости от размера, и это время и есть ваше настоящее время восстановления — не то, которое написано в описании сервиса.

Что из этого стоит сделать один раз и забыть: срок хранения не меньше семи дней для всего, что не стенд; снимок перед каждым обновлением версии; и — самое важное — пробное восстановление раз в квартал, потому что копия, из которой ни разу не восстанавливались, это не копия, а предположение. Разбор того же на уровне общих принципов — в статье про резервные копии.

Глубже: цена очереди против цены брокерарасширенное

В выборе между простой очередью и управляемой Kafka цена — решающий аргумент, и её стоит назвать, потому что модели оплаты принципиально разные.

Очередь (SQS) платится за запросы: порядка 40 центов за миллион запросов (стандартная очередь), и в простое она не стоит ничего. Ни узлов, ни часов, ни минимальной платы. Миллион сообщений в сутки — это считанные десятки центов в день, и очередь, которой никто не пользуется месяц, обойдётся в ноль.

Управляемая Kafka (MSK) платится за брокеров круглосуточно, плюс за хранилище, плюс за трафик. Даже минимальный отказоустойчивый кластер из трёх небольших брокеров — это заметная постоянная сумма в месяц, независимо от того, идут ли через него сообщения. Есть и вариант без выбора брокеров (MSK Serverless), где платят за раздел-часы и объём, — он дешевле для маленькой нагрузки, но всё равно имеет постоянную составляющую.

Отсюда честное правило выбора, которое стоит применить до архитектурных рассуждений:

• Задачи для одного получателя, развязка, повторы, отложенная обработка — очередь. Это девять из десяти случаев в обычном сервисе, и это самый дешёвый и простой вариант.
• Одно событие нужно нескольким независимым подсистемам — сначала посмотрите на уведомления плюс очереди (об этом ниже) или на шину событий: они дают ту же развязку по цене очереди.
• Kafka нужна за её свойствами: перечитывание истории по смещению, порядок по ключу при нескольких читателях, поток в десятки тысяч сообщений в секунду, потоковая обработка. Если ни одно из этих свойств не названо, кластер брокеров, скорее всего, лишний.

И про порог входа: у очереди его нет вовсе (создали и пользуетесь), у Kafka он есть — разделы, смещения, группы, ребалансы, а также своя эксплуатация и дежурство. Сравнение двух моделей подробно разобрано в статье про выбор между брокерами.

Глубже: уведомления плюс очереди: правило связкирасширенное

SNS называют «рассылкой один-ко-многим», и здесь есть правило, без которого схема теряет сообщения.

Уведомления доставляют сообщение подписчикам сразу и один раз. Если подписчик — это адрес вашего сервиса (HTTP), и сервис в этот момент недоступен, сообщение будет повторено по политике повторов и затем потеряно. Никакого буфера у темы нет.

Поэтому правильная схема выглядит так: тема отправляет сообщение не в сервис, а в очередь каждого подписчика, а сервис читает свою очередь.

                    ┌─→ очередь склада      ─→ сервис склада
событие → тема ─────┼─→ очередь уведомлений ─→ сервис уведомлений
                    └─→ очередь аналитики   ─→ сервис аналитики

Что это даёт: недоступность подписчика превращается в накопление в его очереди, а не в потерю; каждый подписчик разгребает в своём темпе; у каждого своя очередь недоставленных и свои повторы; добавление нового подписчика не задевает остальных. Эту схему так и называют — раздача через очереди (fanout), и она настраивается парой правил без всякого кода.

Две детали к ней. Тема умеет фильтровать сообщения по атрибутам, так что подписчик получает только то, что ему нужно, — это дешевле, чем читать всё и отбрасывать. И у очереди надо разрешить теме в неё писать (это делается политикой самой очереди) — самая частая причина «подписка есть, сообщения не приходят».

Глубже: DocumentDB: сначала проверьте версию совместимостирасширенное

DocumentDB — это не MongoDB, а собственная база AWS, которая эмулирует протокол MongoDB. Работает это хорошо, пока приложение пользуется тем, что реализовано; за пределами — ошибка «команда не поддерживается», и обойти её нельзя.

Поэтому первый шаг при выборе — не сравнение цены, а проверка версии совместимости: каждая версия DocumentDB объявляет, какой версии API MongoDB она соответствует (в актуальных версиях это 5.0, у более старых — 4.0 и 3.6). Дальше берут список неподдерживаемых команд и операторов из документации и сверяют с тем, что реально использует приложение — включая библиотеку доступа к данным, которая может использовать больше, чем видно в коде.

На что смотреть в первую очередь, потому что здесь чаще всего и не сходится: транзакции между документами (появились не сразу), агрегационный конвейер (часть этапов отсутствует), полнотекстовый поиск и $lookup со сложными условиями, некоторые способы работы с индексами, а также команды администрирования, которыми пользуются инструменты миграции.

Практический способ проверить за час, а не за неделю: поднять пробный экземпляр, подключить к нему тестовый набор приложения и прогнать интеграционные тесты. Тесты, которые ходят в базу по-настоящему, находят несовместимость сразу; чтение списков и предположения — нет.

И развилка, которую стоит держать в голове: если приложение сильно опирается на возможности MongoDB, вариантов два — управляемая MongoDB от самих разработчиков (Atlas) в том же регионе облака или свой кластер. Решать это лучше до переезда, а не после того, как половина запросов начнёт отказывать.

Коротко

• RDS это тот же PostgreSQL с копиями, Multi-AZ и окном обновлений, но без суперпользователя: параметры через группу параметров, расширения только из списка AWS, приложение обязано переподключаться после переключения.
• Aurora хранит данные в шести копиях по трём зонам и переключается быстрее, но платят за неё дороже; управляемая база снимает эксплуатацию железа, а не проектирование данных и индексов.
• «База тормозит» разбирают в порядке: обзор нагрузки в Performance Insights, тяжёлые запросы в pg_stat_statements, план через EXPLAIN, и только потом класс машины; лимит соединений считают от базы, а не от привычки к пулу.
• Копии: автоматические хранятся семь дней из консоли и один день из API, снимок живёт, пока его не удалили, а любое восстановление создаёт новый экземпляр с новым адресом; пробное восстановление делают раз в квартал.
• ElastiCache это Redis как сервис: политика вытеснения по умолчанию volatile-lru, кластерный режим ломает операции по нескольким ключам из разных слотов, а дисциплина ключей, TTL и защита от лавины промахов остаются в коде.
• SQS платится за запросы и в простое стоит ноль: доставка хотя бы раз, сообщение до 1 МиБ, видимость до 12 часов, очередь недоставленных; MSK это настоящая Kafka с брокерами круглосуточно и своей эксплуатацией.
• Очередь задач или журнал событий выбирают по свойствам: Kafka берут ради перечитывания истории, порядка по ключу и десятков тысяч сообщений в секунду, всё остальное закрывает очередь; рассылку многим делают темой SNS в очередь каждого подписчика.
• DynamoDB проектируют от всех запросов заранее, а DocumentDB эмулирует API MongoDB определённой версии: до выбора прогоняют интеграционные тесты приложения против пробного экземпляра.
• Компоненты с состоянием берут управляемыми, пока нет конкретной причины делать иначе; полную цену владения считают с инженерным временем и инцидентами.

Что почитать дальше

• Сеть в AWS — управляемые базы живут в приватных подсетях этой сети.
• IAM в AWS — кто имеет право обращаться к данным и очередям.
• DynamoDB — ключи, индексы и когда её брать вместо SQL.
• RabbitMQ или Kafka — подробное сравнение очереди и журнала событий.