«Управляемый» (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 автоматически переключает нагрузку на запасной. Зона доступности (Availability Zone, AZ) — это отдельный дата-центр в одном регионе; их обычно несколько, чтобы пожар в одном здании не уронил сервис.
- Обновления версий в заранее заданное окно обслуживания.
Aurora — это база данных от AWS, совместимая с PostgreSQL по протоколу, но переписанная внутри. Её главная фишка — отдельный распределённый слой хранения: каждый кусок данных хранится в шести копиях по трём зонам доступности (по две копии на зону). Запись подтверждается, когда её приняли четыре копии из шести, поэтому Aurora переживает потерю двух копий без остановки записи. Реплики читают из того же общего хранилища, что и основной сервер, поэтому отставание реплики почти нулевое, а переключение при сбое обычно занимает меньше минуты. Платится это надбавкой к цене и небольшой потерей ощущения «это просто PostgreSQL» — отдельные параметры, своё поведение под нагрузкой.
Вот что важно понять новичку: управляемая база снимает с вас эксплуатацию железа, но не проектирование данных. 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 — это кэш, а не база данных. Данные, потеря которых недопустима (заказы, платежи), в нём не хранят: кэш может сбросить содержимое в любой момент.
Очереди и брокеры: SQS и MSK
Когда одна часть системы хочет передать работу другой, не дожидаясь ответа, между ними ставят посредника — очередь или брокер сообщений. AWS даёт две разные вещи под разные задачи.
SQS (Simple Queue Service) — простейшая очередь как сервис. Никакого сервера, кластера и обслуживания нет вообще: вы просто кладёте сообщения и забираете их. Ключевые свойства:
- Хранит непрочитанные сообщения до 14 дней (по умолчанию 4 дня).
- Есть очередь недоставленных сообщений (DLQ, dead-letter queue) — туда попадает то, что не удалось обработать после нескольких попыток.
- Оплата за число запросов, а не за работающий сервер.
- Visibility timeout — когда потребитель забирает сообщение, оно становится невидимым для других на заданное время (от 0 секунд до 12 часов, по умолчанию 30 секунд). Это как «арендовать» задачу на время обработки: успел — удаляешь, не успел — сообщение снова станет видимым и достанется другому.
Семантика доставки у SQS — at-least-once («хотя бы один раз»): одно и то же сообщение может прийти повторно. Это не баг, а следствие надёжности — система лучше повторит, чем потеряет. Есть и FIFO-вариант (first-in-first-out): он гарантирует строгий порядок и убирает дубликаты в пределах 5-минутного окна, но за это платит меньшей пропускной способностью. Рядом с 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.
Управляемый против своего: как выбирать
| Управляемый (RDS/MSK/ElastiCache) | Свой на сервере | |
|---|---|---|
| Эксплуатация | Резервные копии, переключение, обновления — AWS | Всё ваше, включая три часа ночи |
| Цена | Надбавка 20–50% к стоимости железа | Дешевле железом, дороже людьми |
| Контроль | Версии и параметры из списка 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 и осознанное размещение компонентов рядом с данными.
Что изучать дальше. Понимание, где живут эти сервисы внутри сети, даёт статья про networking и VPC — управляемые базы кладут в приватные подсети. Кто имеет право обращаться к данным — это IAM и управление доступом. Как поднять при сбое всю систему целиком, а не одну базу — отказоустойчивость и восстановление. Глубже про конкретные сервисы: DynamoDB и serverless, где SQS и DynamoDB особенно естественны. Чтобы создавать всю эту инфраструктуру не кликами, а описанием в коде, начните с основ infrastructure as code и Terraform. Для общей картины облака полезны основы AWS и принципы хорошей архитектуры в Well-Architected.