Главная ценность облака для backend-команды — не виртуалки, а managed-данные: PostgreSQL, Redis, Kafka и очереди, у которых бэкапы, репликация, фейловер и патчи — забота AWS. Эта статья — карта соответствий «что мы знаем self-hosted → что это в AWS», и честный список того, что managed-сервис не снимает.
RDS и Aurora: PostgreSQL как сервис
RDS for PostgreSQL — тот же PostgreSQL, что вы знаете из раздела про PG, но с автоматикой: Multi-AZ реплика с фейловером, бэкапы с PITR, патчи по окну обслуживания. Aurora — совместимый с PG движок AWS с отделённым хранилищем: шесть копий данных по трём AZ, реплики делят хранилище с мастером (лаг почти нулевой), фейловер быстрее. Платится это премией к цене и лёгкой потерей «это просто постгрес» (отдельные параметры, поведение под нагрузкой).
Что managed не снимает — всё содержимое PG Style Guide: схема, индексы, блокировки, миграции expand-contract, уровни изоляции, тюнинг запросов. RDS защищает от умершего диска, не от SELECT без индекса.
Деталь, которая стреляет: лимит соединений. Считается от памяти инстанса, и толпа сервисов с Hikari-пулами по 10 выедает его незаметно. Ответ — дисциплина пулов и RDS Proxy (общий мультиплексор соединений) — обязательный, если рядом есть Lambda.
ElastiCache: Redis как сервис
Managed Redis (и его форк Valkey): кластер, реплики, фейловер — от AWS. Применение то же, что в caching-гайде: кеши с TTL, distributed lock, rate limiting. Не снимается: дисциплина ключей и TTL, выбор сериализации, cache stampede — это в коде, не в консоли. И помнить: ElastiCache — это кеш, не БД; данные, которые больно потерять, в нём не живут.
Очереди: SQS против RabbitMQ, MSK против своей Kafka
SQS — простейшая очередь как сервис: безлимитная, с DLQ, retention до 14 дней, оплата за запросы. Нет брокера, нет кластера, нет эксплуатации вовсе. Семантика — at-least-once с visibility timeout (сообщение «арендуется» на время обработки — родня lease из батч-процессинга); FIFO-вариант даёт порядок и дедупликацию ценой пропускной способности. Для work queue «обработай задачу» SQS закрывает большинство сценариев RabbitMQ без единого сервера. SNS рядом — pub/sub веер: одно событие → много подписчиков (SQS-очереди, лямбды).
MSK — managed Kafka. Это именно Kafka (вся Kafka-серия применима: партиции, consumer groups, retention, outbox), AWS забирает брокеры и ZooKeeper/KRaft. Не забирает: дизайн топиков и ключей, идемпотентность потребителей, мониторинг lag-а, schema registry. Выбор между SQS и MSK — это выбор между «очередь задач» и «журнал событий»: тот же разговор, что sync vs async и AMQP vs Kafka, просто с поправкой «SQS эксплуатировать не надо вообще».
DynamoDB: другая лига
Единственный пункт списка, не имеющий self-hosted прототипа в нашем стеке. Key-value/документная БД с миллисекундами на любом масштабе и оплатой за запросы — но с жёсткой моделью: доступ только по ключу и заранее спроектированным индексам, никакого ad-hoc SQL. Это не «NoSQL-замена PostgreSQL»: дизайн таблицы DynamoDB начинается с перечисления всех запросов (single-table design) и плохо переживает «а теперь покажи это по-другому». Честная ниша: сессии, корзины, фиче-флаги, счётчики — высоконагруженный key-value с предсказуемыми паттернами. Сравнение моделей — та же логика, что PG vs Mongo, только с ещё более узкой специализацией.
Managed против self-hosted: критерии
| Managed (RDS/MSK/ElastiCache) | Self-hosted | |
|---|---|---|
| Эксплуатация | Бэкапы, фейловер, патчи — AWS | Всё ваше, включая 3 часа ночи |
| Цена | Премия 20–50% к железу | Дешевле железом, дороже людьми |
| Контроль | Версии и параметры из списка | Любые расширения, форки, тюнинг |
| Данные | В аккаунте, шифрование KMS | Где скажете |
| Привязка | PG/Kafka переносимы; DynamoDB/SQS — нет | Нет |
Дефолт здравого смысла: stateful-компоненты — managed, пока нет причины уровня «нужно расширение, которого нет в RDS» или «регуляторика требует своего железа». Команда, самостоятельно эксплуатирующая PostgreSQL при доступном RDS, должна уметь объяснить, чем заняты освобождённые RDS-ом инженеры.
Типичные ошибки
- Self-hosted «для экономии» без подсчёта стоимости людей и инцидентов. Считайте полную цену, не цену инстансов.
- DynamoDB как универсальная БД. Третья перепроектировка single-table design под новый паттерн запросов стоит дороже RDS с самого начала.
- SQS-потребитель без идемпотентности. At-least-once означает повторы; двойная обработка денег в облаке работает так же, как и на земле.
- Пулы соединений по дефолту на флоте сервисов → исчерпан лимит RDS. Пулы считаются от лимита базы, не от привычки.
- Игнорировать цену трафика. Cross-AZ и NAT-трафик к данным — заметные строки счёта; VPC endpoints и осознанное размещение решают.
Что почитать дальше
- PostgreSQL-раздел и PG Style Guide — всё это действует и в RDS.
- Kafka-серия — MSK не отменяет ни строчки из неё.
- Интеграция из Spring — SQS-листенеры и SDK в коде.
- PG vs ClickHouse — аналитическая ветка выбора хранилищ.